Tirer parti de Flink pour détecter les sessions des utilisateurs et impliquer les consommateurs de DoorDash grâce à des notifications en temps réel

Chez Doordash, nous apprécions chaque occasion d'augmenter les conversions de commandes dans l'application. Lorsque les utilisateurs ne parviennent pas à effectuer un achat après avoir ajouté des articles à leur panier, nous envoyons des notifications push telles que celle illustrée à la figure 1 pour leur rappeler que leur commande est toujours en attente. Il est toutefois difficile de déterminer si les utilisateurs ont réellement abandonné leur panier ou s'ils sont simplement en train de rechercher d'autres articles ou d'autres marchands dans l'application.

To polish the notification experience, we want to ensure that cart abandonment notifications are sent in a timely manner - but only when users truly stop adding to their carts and abandon the app. 

Pour ce faire, nous avons construit un grand job Flink avec état pour suivre les sessions des utilisateurs à l'aide des événements du client mobile/web. En analysant l'activité des utilisateurs et en détectant les périodes d'inactivité sur de courtes périodes, nous pouvons désormais envoyer des notifications à des moments plus opportuns. Cette nouvelle solution a permis d'améliorer considérablement la conversion. Nous examinons ici les différentes options que nous avons envisagées, les raisons pour lesquelles nous pensons que notre nouvelle conception est la plus efficace et ce que nous avons appris au cours de la mise en œuvre de cette solution.

Décider s'il faut déclencher dans le frontend ou le backend

Les événements backend sont généralement générés par des services internes, tandis que les événements frontend sont créés par l'application mobile ou le web. Si notre objectif est d'envoyer des notifications aux utilisateurs qui mettent à jour leur panier et restent ensuite inactifs pendant X minutes, comment faire savoir au système quand déclencher le flux de travail ?

Abandon de panier V1

Notre ancienne conception nécessitait de vérifier constamment l'état de la mise à jour du panier en appelant le service de panier en arrière-plan, ce qui déclenchait le flux de travail d'envoi lorsqu'il n'y avait pas de mise à jour. 

As shown in Figure 2, this design does not reflect the actual status of user activities. It just blindly checks the backend services in the fixed gap and sends potentially unnecessary notifications to the user, reminiscent of my daughter when we're driving somewhere:

Abandon de panier V2

Dans notre nouvelle conception, cependant, la détection de session en temps réel offre une solution plus intelligente qui élimine les appels redondants, comme le montre la figure 3 :

In this design, all user activities in the mobile and web applications generate analytic events. The real-time session detection's job is to receive all frontend events continuously and group them into sessions. This allows detection of when a session ends as a result of user inactivity, generating a signal to the notification service to trigger the workflow.

Déclencheur : Détection de session en temps réel

When customers use DoorDash's app and website, a number of analytics events are generated that yield information about a user's experience and activities. Detecting these user sessions can give the downstream notification services insights about user activities, including start time and end time. This is an opportunity to develop an intelligent notification system that can send context-aware prompts at the appropriate time with relevant content.  

La sessionnalisation est traditionnellement effectuée par lots chez DoorDash. Mais l'assemblage de plusieurs événements et la détection des écarts entraînent des coûts de calcul et des temps de latence considérables, dus en grande partie à la nécessité de charger des quantités massives de données du stockage à froid vers la mémoire avant le traitement. En outre, les heures nécessaires à l'exécution d'un processus par lots sont incompatibles avec la détection de sessions en temps réel. 

L'équipe chargée de la plateforme en temps réel exploite notre plateforme de streaming pour créer des sessions en regroupant et en identifiant divers événements mobiles et web, comme le montre la figure 4. Nous développons une plateforme de sessionnalisation pour que les équipes d'application puissent facilement définir et faire évoluer les sessions avec différents événements d'entrée et écarts de session. Parce qu'il est centré sur le traitement en mémoire, le traitement en flux élimine la nécessité de charger des données à partir d'un stockage à froid ; les événements sont traités dès qu'ils arrivent sur le réseau et en mémoire, ce qui réduit la latence et le coût du chargement des données. Avec le travail de sessionnalisation, nous pouvons facilement détecter quand les clients terminent une session en temps réel, ce qui permet à l'application d'exécuter des opérations avec ces signaux.

La détection des sessions en temps réel pose toutefois quelques problèmes. 

• Infrastructure for large-state computing: To build input events sessions, Flink needs to keep all user session events until the session ends. This inflight data is considered as state in Flink and is managed in the RocksDB state backend. With average DoorDash user sessions lasting around an hour, we will need to maintain an hour's worth of user activities for each customer as its state. That means that the state would be hundreds of gigabytes at any moment. To use the RocksDB backend, we can't use the existing infrastructure, which shares local storage across jobs. We worked with DoorDash's infrastructure team to create a means to facilitate this kind of stateful computation with guaranteed persistent volume for each Flink task manager.
  
  
• Job failure and recovery: Failure recovery is done at Flink's framework level by restarting failed tasks from the last checkpoint. The checkpoint is persisted in S3 to make it durable and scalable. The Flink job manager is set up in high availability mode with two job managers, one as leader and the other standing by. Upon job manager failure by the leader, the standby job manager immediately assumes the lead role and resumes the job from the job manager state stored separately in S3.

Envoyer : Flux de notification V2 de l'abandon du panier

Après le déclenchement du processus d'abandon du panier, nous n'enverrons pas de notifications aux utilisateurs si.. :

• Le panier n'est plus disponible, par exemple si l'utilisateur est déjà passé à la caisse.
• Minimum requirements for sending aren't met, such as missing critical fields.
• D'autres raisons peuvent rendre une notification inefficace.

Les notifications ne parviendront aux consommateurs par l'intermédiaire de la plateforme de notification que si tous les contrôles d'éligibilité ont été effectués, ce qui garantit que ces messages sont opportuns et significatifs.

Résultat : Surpasser les autres notifications

La nouvelle conception de l'abandon de panier permet d'augmenter considérablement le volume des commandes et les recettes. Au cours de notre expérience, la vitesse d'envoi des notifications a été multipliée par six. Nous pensons que le déclenchement étant plus précis et plus rapide, les notifications sont plus pertinentes pour les consommateurs. En conséquence, les consommateurs se sont davantage intéressés aux notifications, avec notamment un taux d'envoi à l'ouverture supérieur de 40 % et une augmentation de 2,6 % des taux de visite au cours de l'expérience. 

Travaux futurs : Notifications d'abandon de panier avec promotions et autres

Notre succès dans la refonte des notifications d'abandon de panier a conduit à une nouvelle série d'expériences, dont voici quelques exemples :

• Ajouter des promotions aux notifications d'abandon de panier lorsqu'il y a des articles éligibles dans les paniers, afin d'encourager les consommateurs à poursuivre leur achat à un prix plus avantageux.
  
  
• Contrôle de la fréquence des notifications d'abandon de panier. Par défaut, nous n'envoyons pas plus d'une notification par jour à un utilisateur. Mais grâce à un nouvel effort d'analyse sophistiqué, nous expérimentons l'amélioration de la visibilité en sélectionnant des consommateurs cibles qui recevront plus d'une notification par jour.

Puisque nous possédons les événements frontaux, l'ajout d'autres notifications telles que les notifications d'abandon de marchand semble être une évolution naturelle. Avec ce système en place, une telle expansion devrait être simple car le pipeline est déjà en place pour gérer les notifications associées aux comportements des consommateurs. En fait, chaque nouvelle notification n'est qu'à deux pas : 

1. Define a real-time event. The sessionization platform can easily define and evolve sessions with different input events, session gaps, and session outputs. The real-time infrastructure team can build automation and UI for developers to easily onboard new real-time signals. That team also is exploring options to enable developers to define custom logic to process a session event - for example, filtering against clients who viewed merchants but didn't place any order. 
   
   
2. Combine real-time events with the sending workflow. By adding necessary validations, the sending pipeline will skip signals that missed critical fields, such as store name and consumer id. Because the sending pipeline is completely configuration-driven, it'll be more flexible and much easier to onboard new sendings rather than update codes.

Conseils pour travailler avec des événements frontaux

By allowing new approaches that can't be done by backend events alone, frontend events play a critical role in cart abandonment use cases. Before you adopt frontend events in your next design, keep in mind:

• Les données frontales issues des activités web mobiles ne sont pas toujours fiables ou stables. Les données peuvent être corrompues ou des champs importants peuvent être manquants. Vérifiez la qualité des données avant de poursuivre.
  
  
• Various glitches may cause unexpected delays. During our experiment, some frontend events reported delays exceeding 24 hours. In some cases, delays were caused when the application was terminated before event syncing to services was completed; delayed events then weren't reported until the application reopened. An application should take possible delays into account and have methods for handling them.
  
  
• Rendez les données plus fiables en vérifiant régulièrement avec l'équipe frontale que tout problème est résolu rapidement.
  
  
• Use both frontend and backend data. Backend calls may be able to answer questions that the frontend can't.  In the cart abandonment workflow, fields such as country code and store open status can be fetched from backend services. There is invaluable synergy between frontend and backend data. It not only enables more accurate decision-making, but also empowers an organization to deliver personalized and contextually relevant experiences to users.

Conclusion

We are thrilled with the results of this project. It not only reduces the likelihood of customers leaving essential items in their carts, but also enhances DoorDash order processing efficiency, improving overall user satisfaction. Leveraging real-time data opens a pipeline to a multitude of future possibilities. For example, the app may suggest the related store or items based on the store view and search history in the sessions. We eagerly anticipate incorporating additional experiments and taking further strides toward elevating our app's user experience.

Remerciements

Applaudissements aux membres de l'équipe qui ont directement contribué au projet : Mengyang Cui, Eleanore Jin, Julie Xue, Sonic Wang, Allen Wang, Yanlin Peng, Nicole Lin, James Smith, Eric Bencomo Dixon et Kristine Fernandez.

Nous remercions tout particulièrement les membres de l'équipe suivants qui ont collaboré étroitement avec nous : Karthik Thota, Michael Adaikalaraj, Xavier Hodges, Praveen Goparaju, Mike Pitre, Jeremy Pian, Chun-Wei Lee, Almer Bacallan, Abhijeet Bane, Keith Lehmann, Lisa Shang, Bronson Mirafuentes, Jason Lai et Yun Huang.