Optimiser le parcours shopper grâce à l’hyper-personnalisation

Chez Lucky cart, nous avons l’intime conviction que chaque shopper est différent. Mais la réalité est que les shoppers ont une expérience d’achat extrêmement similaire sur l’ensemble des sites e-commerce. C’est pourquoi nous avons créé Lucky cart, une plateforme puissante qui utilise la Big Data pour personnaliser l’expérience d’achat en temps réel pour chaque shopper. Notre plateforme utilise la science des données pour déterminer le bon media à afficher au bon shopper au bon moment. Cependant, la puissance du moteur réside dans sa capacité à traiter jusqu’à 10 000 événements par seconde en temps réel, mixant l’historique et le comportement d’achat du shopper (« Cold data ») avec sa navigation courante et notamment son panier (« Hot data ») pour générer l’expérience personnalisée la plus pertinente.

Lucky cart entraîne ses algorithmes uniquement avec des données comportementales et d’historique d’ achats, nous refusons toute autre type de donnée comme les données socio-démographiques avec le principe de confidentialité dès la conception (« privacy by design »), et nous veillons tout particulièrement à être conforme au RGPD. Dans cet article, je décrirai l’architecture technique que nous avons construite chez Lucky cart pour supporter ce traitement Big Data en temps réel.

Quel type de data traitons-nous ?

Pour collecter les données, nous installons des trackers sur les sites et les applications mobiles des enseignes de la grande distribution alimentaire pour collecter toutes les actions des shoppers telles que :
> La page sur laquelle il navigue.
> Les liens sur lesquels il clique.
> Les mots-clés qu’il recherche.
> Les produits ajoutés ou retirés de son panier.
> La commande finale qu’il paie
> Toute mise à jour sur le statut de la commande (par exemple : livrée ou annulée).

Nos trackers enregistrent chaque interaction des shoppers et les envoient à notre plateforme afin qu’elles puissent être traitées en temps réel. Nous appelons ces actions « Shopper Events ». Nous souhaitons réellement disposer de données atomiques sur le comportement des shoppers afin de comprendre leur parcours d’achat complet et de pouvoir personnaliser chaque détail. Ces données atomiques sont également transformées, enrichies et sauvegardées dans notre (« data lake ») pour optimiser les futurs calculs en temps réel.

Autre chose très importante : nous n’enregistrons pas de données nominatives ou socio-démographiques. Le seul identifiant que nous traitons du shopper est l’identifiant client de l’enseigne (identifiant technique ou numéro de carte de fidélité). Nous refusons de collecter son nom, son âge ou son origine ethnique pour respecter le principe de privacy-by-design. Le RGPD est la clé de notre activité et nous traitons les données avec beaucoup de soin. Nous avons des procédures pour supprimer automatiquement toutes les données après un délai contractuel. Nous pouvons également traiter les demandes de suppression des données personnelles des shoppers et effacer toutes les données personnelles que nous stockons à leur sujet. Lorsque nous devons collecter les adresses e-mail des shoppers pour leur envoyer leur récompense (nous offrons à l’acheteur une chance de gagner le montant de la totalité de son panier s’il a acheté les produits promus, nous devons donc communiquer avec lui pour le remboursement), nous stockons ces informations dans une autre base de données pour être sûrs qu’elles ne peuvent pas être utilisées pour personnaliser l’expérience que nous leur proposons.

En parlant d’expérience, la force de Lucky cart est d’utiliser la Big Data pour personnaliser le parcours d’achat à l’aide de ce que nous appelons les « Shopper Experiences ». C’est une interaction personnalisée que nous montrons aux acheteurs pour améliorer leur parcours d’achat, comme :
> La promotion personnalisée (produits, générosité, seuils).
> La promotion ludique.
> La recommandation de produit.
> La tension panier.

Quels défis pour personnaliser l’expérience en temps-réel ?

Nous sommes principalement confrontés à trois défis :
1. ’injection de la donnée.
2. Le stockage de la donnée.
3. Le traitement de la donnée en temps réel.

Nous expliquons chaque élément plus en détail :

1. Injection de la donnée

Aujourd’hui, nous sommes connectés à 90% des enseignes françaises de la grande distribution alimentaire et recevons jusqu’à 10 millions d’événements shoppers par jour. Nous sommes sur un seul fuseau horaire et les shoppers font leurs achats en ligne sur les mêmes tranches horaires, nous sommes donc confrontés à devoir gérer certains pics allant jusqu’à 10 000 événements par seconde. Notre architecture technique doit supporter cette mise à l’échelle rapide pour injecter toutes ces données sans perdre aucune information ni ralentir l’expérience d’achat personnalisée.

2. Stockage de la donnée

Nous stockons une énorme quantité de données. Faisons ensemble quelques calculs ! Nous recevons 10 millions d’événements shopper par jour, qui pèsent en moyenne un kilo-octet : cela signifie que nous remplissons chaque jour un disque dur de 10 téraoctets (10¹²) uniquement avec des événements bruts. Nous stockons jusqu’à 3 ans (1 000 jours) d’historique de données, nous parlons donc maintenant d’environ 10 pétaoctets (10¹⁵) de données brutes glissantes. Enfin, pour optimiser le calcul nous dupliquons beaucoup de données. On parle d’environ 30 pétaoctets de données : c’est de la vraie Big Data !

3. Traitement de la donnée en temps réel

Notre métier est de personnaliser l’expérience d’achat, nous ne pouvons donc pas attendre plus d’une seconde pour pousser une interaction avec le client. Notre objectif est de générer une « Shopper Experience » en moins de 250 millisecondes pour le 95e centile. Le terme 95ème percentile désigne le point à partir duquel 5% d’un ensemble de population dépassera la valeur référencée. En effet, sur une navigation web ou mobile, il est primordial d’afficher le plus rapidement possible l’interaction shopper pour rester fluide et éviter que le shopper ne se déplace vers une autre page. C’est pourquoi nous devons pré-calculer beaucoup de données pour avoir moins de calculs en temps réel et être en mesure de répondre le plus rapidement possible lorsque l’acheteur navigue sur les sites de commerce électronique ou les applications mobiles des détaillants.

Comment injecter 10 millions d’événements shoppers par jour ?

Un événement est une action effectuée par le shopper sur l’application ou site e-commerce du distributeur. Nous recevons jusqu’à 10 millions d’événements par jour, avec des pics allant jusqu’à 10 000 événements par seconde aux heures de pointe. Par définition, ces actions appartiennent au passé et ne peuvent pas être mises à jour ou supprimées. Par exemple, pour un produit ajouté au panier (événement « AddedToBasket »), lorsqu’un shopper supprime un produit de son panier, nous créons un nouvel événement « RemovedFromBasket » au lieu de supprimer l’événement précédent. Cela nous permet d’avoir un flux de données très simple : on peut uniquement écrire des événements, on ne peut pas les mettre à jour ou les supprimer.

Les trackers envoient tous ces événements à un seul endpoint de l’API HTTP : la Shopper Event API. Il s’agit de l’API la plus basique au monde : elle persiste et dispatche chaque événement qu’elle reçoit sans aucun traitement supplémentaire. Cela nous permet de nous concentrer sur la partie la plus difficile : être capable d’injecter la grande quantité de données et de passer à l’échelle pendant les heures de pointe. Pour ce faire, nous utilisons des technologies cloud sans serveur telles que AWS Lambda ou GCP Cloud Run. Ces technologies sont très évolutives et très simples d’utilisation : parfaites pour notre utilisation de la Big Data. Le seul point de vigilance concerne le démarrage à froid mais il existe des solutions existantes que nous avons déjà mis en place pour éviter ce problème. Pour sauvegarder les données, nous utilisons également des bases de données NoSQL Cloud telles que BigTable qui ont une faible latence en lecture sur un unique index et en écriture. Cet énorme avantage s’accompagne de certaines contraintes et ces technologies de base de données ne peuvent pas effectuer de requêtes avancées telles que l’agrégation ou la jointure entre plusieurs tables.

Une fois l’événement enregistré dans notre système, nous pouvons commencer à le traiter à l’aide des technologies de streaming du cloud telles que Kinesis ou PubSub pour envoyer l’événement au reste de nos applications afin de le traiter. Le flux a deux processus distincts qui sont déclenchés en même temps : le premier consiste à transformer les données pour pouvoir effectuer des requêtes avancées sur celles-ci, le deuxième consiste à traiter les données en temps réel pour personnaliser l’expérience d’achat.

Comment traitons-nous les données pour prédire le comportement des acheteurs à partir de milliards d’événements ?

Dans ce chapitre, j’explique comment Lucky cart prédit le comportement des shoppers pour pouvoir personnaliser leur parcours d’achat en traitant leurs événements. Nous avons vu dans le chapitre  précédent comment ingérer des millions d’événements shopper par jour. La solution de base de données NoSQL Cloud est très efficace pour enregistrer et lire les événements en tant que « données chaudes », mais cela ne permet pas d’effectuer des requêtes avancées avec des agrégations et/ou des jointures complexes avec d’autres tables. C’est pour cela que nous avons besoin d’un processus de refroidissement de la donnée pour transformer les « Shopper Events » d’une base de données NoSQL Cloud en modèles de données métier et relationnels.

Ces nouvelles données transformées sont stockées en tant que « données froides » dans une base de données analytique cloud telle que BigQuery pour effectuer des requêtes à partir d’un grand volume de données afin de calculer nos algorithmes d’apprentissage automatique. Pour effectuer cette transformation, nous utilisons un service d’ETL basé sur Apache Nifi qui s’abonne au flux d’événements et les transforment de manière asynchrone en modèles de données froides. Par exemple, un événement de panier validé générera une ligne dans la base de données des produits vendus pour chaque produit de la commande. Un seul événement Shopper peut donc créer de nombreuses vues de lecture.

Avec cette structure de données froides, il est possible d’effectuer une grande agrégation pour compter le nombre de produits spécifiques vendus à un client spécifique au fil du temps. En utilisant ces données sur un algorithme de Machine Learning supervisé et certaines règles économétriques, Lucky cart calcule ces données pour créer un modèle qui prédit le comportement de chaque shopper.

Comment personnaliser l’expérience d’achat en temps réel en fonction des données chaudes et froides ?

À ce stade, nous avons vu comment organiser la donnée pour que nos algorithmes prédisent le comportement des shoppers à l’aide de données froides. Nous devons maintenant travailler ces prédictions pour les convertir en expériences d’achat personnalisées.

Nous avons donc développé un autre algorithme pour prédire l’ensemble des parcours d’achat d’un shopper avec différentes possibilités et comment réagir en fonction des choix du shopper. Nous avons représenté ce parcours par un arbre où chaque branche représente une expérience différente à montrer au shopper. Nous calculons un « Shopping Experience Tree » pour chaque shopper, avec des expériences et des paramètres personnalisés. Chaque nœud possède un ensemble de conditions permettant de se déplacer dans l’arbre en fonction du comportement prédit du shopper potentiel.

Par exemple, s’il ajoute des « pâtes » à son panier, nous pouvons recommander la bonne « sauce » en fonction de ses achats précédents ou nous pouvons déclencher une promotion personnalisée. Ces arbres de comportement d’achat sont pré-calculés, pour nous aider à traiter chaque événement d’achat en temps réel. Nous nous inscrivons au flux d’événements de l’API Shopper Event et appliquons les règles actuelles du nœud pour déplacer cet acheteur de l’arborescence vers la bonne branche et personnaliser ses expériences en temps réel en mélangeant les données froides et chaudes.

Utiliser la puissance des solutions cloud pour injecter un volume élevé de données est une très bonne solution qui nous permet de nous concentrer sur la création des meilleures expériences d’achat pour les acheteurs au lieu de travailler sur des serveurs internes permettant d’absorber les trafics liés à notre métier. Le pipeline asynchrone nous permet de calculer de grandes quantités de données et d’avoir une connaissance approfondie des comportements de chaque acheteur pour améliorer son parcours d’achat. Enfin, les arbres de décision pré-calculés nous permettent de pousser la personnalisation en temps réel en tenant compte de la navigation client actuelle. C’est ainsi que chez Lucky cart, nous sommes en mesure de personnaliser des millions d’expériences d’achat en utilisant la Big Data (données chaudes et froides) en temps réel sur les sites Web et les applications mobiles des détaillants FMCG.

Sources :
*Intersoft Consulting

CONTACTEZ-NOUS