Panier abandonné : optimisez votre système de relances automatisées personalisées avec la Data Platform de Batch

La récupération de Panier abandonné est un cas d’usage classique des professionnels CRM.

Les taux de récupération varient, les e-commerçants pouvant récupérer jusqu’à 30% du chiffre d'affaires perdu grâce aux relances automatisées et personnalisées dans les heures, voire les minutes, qui suivent l’abandon du panier.

Pour répondre à ce double besoin de réactivité et de personnalisation, le cas d’usage d’abandon de panier nécessite une plateforme d’engagement client qui puisse gérer les données client et des événements en temps réel.

Dans cet article, on vous explique comment la Data Platform de Batch gère ces dimensions de temps réel, de scalabilité et de personnalisation pour optimiser le cas d’usage de l’abandon de panier.

La génération de l’événement add_to_cart

Avec le cas d’usage du panier abandonné, on met ainsi en place le scénario qui permet de relancer pour réengager les utilisateurs qui ont laissé des articles dans leur panier sans finaliser leur achat, et ce, suite à une durée d’inactivité déterminée par l’équipe CRM.

C'est un processus impliquant plusieurs étapes et des déclencheurs spécifiques.

Dès qu'un utilisateur ajoute un produit à son panier, un événement d’ajout au panier (“add_to_cart” par exemple) est envoyé à Batch via le SDK intégré dans l’app mobile ou le site web. Cela fait partie du plan de taggage mis en place par le client.

L’événement add_to_cart est enrichi avec les informations qui vont être importantes pour savoir quel article a été ajouté : le nom de l’article, le lien de la fiche produit ou encore l'image de l'article, etc.

Le déclenchement maîtrisé de l’Automation Trigger

Toutes ces informations relatives à l’ajout panier vont permettre d’envoyer un premier événement à Batch. Celui-ci va permettre de déclencher une Automation Trigger qui est un scénario automatisé et personnalisé dans lequel l’utilisateur entre dès qu’il réalise l’ajout au panier.

La Data Platform de Batch dispose de différents éléments qui, combinés, répondent aux exigences techniques de ce cas d’usage :

• Timer : Par exemple ici 30 minutes, qui commencent dès l'événement d’ajout au panier. Le message est mis en attente pendant cette durée avant d’être envoyé. Si un autre événement d’ajout au panier est reçu, le timer est réinitialisé.
• Cancellation Events : Si l'utilisateur finalise son achat pendant ce temps d’attente, un événement d’achat est remonté par le SDK de Batch (via le plan de taggage), permettant d’annuler l’envoi du message de relance.
• Capping : On a également mis en place un système de limitation des envois (ici 2 pushs par utilisateur), pour réduire toute pression commerciale excessive.

Ensuite, concernant le delivery du message, c'est bien sûr la plateforme Batch qui se charge de déterminer les appareils à contacter. On cible les tokens de push en faisant appel aux services de push d'Apple ou Google, qui vont ensuite délivrer le message sur l'appareil final.

Les boucles de feedback pour l’optimisation continue du cas d’usage

Batch a mis en place un système de feedback qui permet de suivre l’interaction des utilisateurs avec les notifications. C'est essentiel pour évaluer l'efficacité des messages envoyés.

Plusieurs flux retour sont maintenus par Batch (représentés avec les flèches en pointillés ci-dessus) :

• Feedback d’ouverture de notifications push (flèche en les pointillés violets) : Quand l’utilisateur reçoit une notification, il peut cliquer dessus pour ouvrir l'application et consulter ce qu'il a pu laisser dans son panier par exemple. Batch reçoit alors un feedback permettant d’enregistrer et analyser quels utilisateurs ont ouvert la notification et calculer les taux d'ouverture au global.

• Feedback de validité des tokens de push (flèche en pointillés roses) : Les services de push envoient aussi un feedback indiquant si les tokens de push ciblés sont encore valides. Par exemple, des utilisateurs ont pu être ciblés alors qu’ils ont désinstallé l'application. Dans ce cas, les services de push (APNs, FCM etc.) envoient un retour permettant d’identifier les tokens effectivement joignables et ceux qui ne le sont plus. Batch se charge alors de mettre à jour la Userbase en supprimant ces tokens invalides.

Comment la Data Platform de Batch garantit le temps réel de bout en bout pour vos cas d’usage

Comme vous le savez, l'aspect crucial de ce cas d’usage reste la sensibilité au temps, et nos équipes CRM veulent relancer l'utilisateur suite à l’abandon de son panier dans un délai assez court.

Au sein de la plateforme de Batch, outre le timer configuré dans l’Automation Trigger, il est vital que les événements soient traités en temps réel pour assurer une réponse rapide et efficace. C’est l’envoi des événements via le SDK de Batch et leur traitement en temps réel dans nos bases de données qui le permettent.

Ce qui différencie Batch d’autres solutions, et notamment celles dites legacy, c'est notre capacité à gérer les événements avec cette dimension temps réel, contrairement à certaines méthodes plus traditionnelles qui pourraient reposer sur des envois récurrents (exemple toutes les heures, tous les jours, etc.).

C’est une manière d’opérer qui est moins réactive : l’inconvénient étant que si le délai de traitement est trop long, l’utilisateur aura eu le temps d’aller chez un concurrent par exemple et ne pas finaliser son achat sur votre app ou votre site.

Pour plus d'informations, nous vous invitons à contacter nos équipes hello@batch.com