Conditions de concurrence

Une condition de concurrence survient lorsqu’un résultat dépend de la séquence ou du timing de plusieurs événements. Par exemple, si la séquence souhaitée est « Événement A » puis « Événement B », mais que parfois « Événement A » arrive en premier et d’autres fois « Événement B » arrive en premier, il s’agit d’une condition de concurrence. Cela peut entraîner des résultats inattendus ou des erreurs, car ces événements sont en compétition pour accéder à des ressources ou des données partagées.

Dans Braze, des conditions de concurrence peuvent survenir lorsque plusieurs actions sont déclenchées simultanément en fonction des données ou des événements utilisateur. Par exemple, si un utilisateur déclenche plusieurs campagnes (comme s’inscrire à une newsletter ou effectuer un achat), il se peut qu’il ne reçoive pas les messages dans le bon ordre.

Types de conditions de concurrence

Les types de conditions de concurrence les plus courants peuvent survenir dans les situations suivantes :

• Ciblage de nouveaux utilisateurs
• Utilisation de plusieurs endpoints API
• Correspondance entre les déclencheurs basés sur les actions et les filtres d’audience

Examinez les scénarios suivants et mettez en œuvre les bonnes pratiques pour éviter ces conditions de concurrence.

Scénario 1 : Ciblage de nouveaux utilisateurs

Dans Braze, l’une des conditions de concurrence les plus courantes concerne les messages ciblant des utilisateurs nouvellement créés. L’ordre attendu des événements est le suivant :

1. Un utilisateur est créé ;
2. Ce même utilisateur est immédiatement ciblé pour un message, effectue un événement personnalisé ou enregistre un attribut personnalisé.

Cependant, dans certains cas, le deuxième événement se déclenche en premier. Cela signifie qu’un message tente d’être envoyé à un utilisateur qui n’existe pas encore. Par conséquent, l’utilisateur ne le reçoit jamais. Cela s’applique également aux événements ou attributs, lorsque l’événement ou l’attribut tente d’être enregistré sur un profil utilisateur qui n’a pas encore été créé.

Dans le cas des messages in-app, le message in-app doit être chargé sur l’appareil de l’utilisateur avant d’être déclenché. Si l’événement déclencheur fait partie du processus d’onboarding, ou si l’utilisateur sort du segment pour l’événement personnalisé lors de sa première session, il est probable que l’utilisateur ne verra pas le message in-app.

Messages in-app

Avec les messages in-app, la situation peut être plus nuancée. Un message in-app doit être distribué et mis en cache dans le SDK, généralement au début d’une session, avant de pouvoir être déclenché. Si l’événement déclencheur fait partie du processus de création de l’utilisateur, ou si la campagne de message in-app est distribuée avant que l’utilisateur ne remplisse (ou après qu’il ne remplisse plus) les critères d’audience lors de sa première session, il se peut qu’il ne voie pas le message in-app.

Bonnes pratiques

Introduire des délais

Après la création d’un nouvel utilisateur, vous pouvez ajouter un délai avant d’envoyer des campagnes ou des Canvas ciblés. Ce délai permet au profil utilisateur d’être créé et aux attributs pertinents d’être mis à jour, ce qui peut déterminer son éligibilité à recevoir le message.

Par exemple, après qu’un utilisateur s’est inscrit sur votre application, vous pouvez envoyer une offre promotionnelle après 24 heures. Ou, si vous créez un utilisateur ou enregistrez un attribut personnalisé, vous pouvez ajouter un délai d’une minute avant de poursuivre votre processus pour éviter cette condition de concurrence.

Vous pouvez également ajouter ce délai dans le SDK Braze pour l’événement personnalisé spécifique qui déclenche l’entrée d’un nouvel utilisateur dans un Canvas.

Scénario 2 : Utilisation de plusieurs endpoints API

Il existe plusieurs scénarios dans lesquels l’utilisation de plusieurs endpoints API peut également entraîner cette condition de concurrence, par exemple lorsque :

• Des endpoints API distincts sont utilisés pour créer des utilisateurs et déclencher des Canvas ou des campagnes
• Plusieurs appels séparés sont effectués vers l’endpoint /users/track pour mettre à jour des attributs personnalisés, des événements ou des achats

Lorsque les informations utilisateur sont envoyées à Braze via l’endpoint /users/track, le traitement peut parfois prendre quelques secondes. Cela signifie que lorsque des requêtes sont effectuées simultanément vers /users/track et vers des endpoints d’envoi de messages comme /campaign/trigger/send, il n’y a aucune garantie que les informations utilisateur soient mises à jour avant l’envoi du message.

Bonnes pratiques

Lorsque vous utilisez plusieurs endpoints, envoyez vos requêtes une par une

Si vous utilisez plusieurs endpoints, vous pouvez essayer d’échelonner vos requêtes afin que chacune soit terminée avant que la suivante ne commence. Cela peut réduire le risque de condition de concurrence. Par exemple, si vous devez mettre à jour des attributs utilisateur et envoyer un message, attendez d’abord que le profil utilisateur soit entièrement mis à jour avant d’envoyer un message via un endpoint.

Si vous envoyez une requête API de message planifié, ces requêtes doivent être séparées, et l’utilisateur doit être créé avant l’envoi de la requête API planifiée.

Inclure les données clés avec le déclencheur

Au lieu d’utiliser plusieurs endpoints, vous pouvez inclure les attributs utilisateur et les propriétés de déclenchement dans un seul appel API en utilisant l’endpoint campaign/trigger/send.

Lorsque ces objets sont inclus avec le déclencheur, les attributs sont traités en premier, avant que le message ne soit déclenché, ce qui élimine les conditions de concurrence potentielles. Notez que les propriétés de déclenchement ne mettent pas à jour le profil utilisateur, mais sont utilisées uniquement dans le contexte du message.

Utiliser l’endpoint POST : Suivre les utilisateurs (synchrone)

Utilisez l’endpoint /users/track/sync/ pour enregistrer des événements personnalisés et des achats, et mettre à jour les attributs du profil utilisateur de manière synchrone. L’utilisation de cet endpoint pour mettre à jour les profils utilisateur en même temps et dans un seul appel peut aider à prévenir les conditions de concurrence potentielles.

Scénario 3 : Correspondance entre les déclencheurs basés sur les actions et les filtres d’audience

Une autre condition de concurrence courante peut survenir lorsque vous configurez une campagne ou un Canvas basé sur les actions avec le même déclencheur que le filtre d’audience (comme un attribut modifié ou un événement personnalisé effectué). L’utilisateur peut ne pas faire partie de l’audience au moment où il effectue l’événement déclencheur, ce qui signifie qu’il ne recevra pas la campagne ou n’entrera pas dans le Canvas.

Bonnes pratiques

Vérifier votre audience après un délai

Pour éviter d’utiliser des filtres d’audience contenant les critères de déclenchement, nous recommandons de vérifier votre audience avant la distribution. Par exemple, vous pouvez utiliser les validations de distribution dans les étapes de message Canvas comme vérification supplémentaire pour confirmer que votre audience remplit les critères de distribution au moment de l’envoi du message. Vous pouvez également tirer parti des critères de sortie du Canvas pour faire sortir les utilisateurs à tout moment du parcours s’ils remplissent vos critères.

Pour les campagnes, vous pouvez utiliser des événements de sortie pour permettre aux campagnes avec un événement déclencheur d’annuler les messages destinés aux utilisateurs qui effectuent l’événement de sortie pendant le délai.

Utiliser des filtres distincts de l’événement déclencheur

Lors de la configuration de vos filtres, vous pourriez être tenté d’ajouter un filtre redondant « au cas où ». Cependant, cette redondance peut entraîner davantage de problèmes. Évitez plutôt d’utiliser tout filtre contenant le déclencheur lorsque c’est possible. C’est la méthode la plus sûre pour éviter une condition de concurrence.

Par exemple, si le déclencheur de votre campagne est « A effectué un achat » et que votre filtre d’audience est « A effectué un achat quelconque », cette redondance peut provoquer une condition de concurrence.

Éviter les filtres d’audience qui supposent que l’événement déclencheur a été mis à jour

Cette bonne pratique est similaire à celle consistant à éviter les filtres redondants avec l’événement déclencheur. En général, un filtre qui suppose que l’événement déclencheur est mis à jour dans le profil utilisateur échoue.

Utiliser les abandons Liquid (attributs uniquement)

Dans les campagnes et les étapes Canvas, utilisez les abandons Liquid pour éviter d’utiliser des filtres d’audience contenant les attributs de déclenchement dans la planification d’entrée. Par exemple, supposons que vous ayez un attribut de type tableau « couleurs préférées » et que vous souhaitiez cibler tout utilisateur qui met à jour ce tableau avec n’importe quelle valeur, et qui a également la couleur « bleu » dans le tableau après la mise à jour. Si vous utilisez les filtres d’audience dans cet exemple, vous rencontrerez une condition de concurrence et manquerez les utilisateurs ajoutant « bleu » dans le tableau pour la première fois.

Dans ce cas, vous pouvez implémenter un délai de déclenchement dans une campagne ou utiliser une étape de délai dans un Canvas pour laisser le temps au profil utilisateur de se mettre à jour, puis utiliser la logique d’abandon Liquid suivante :

1
2
3
4
{%assign colors={{custom_attribute.$(Favorite Color)|split:”,”}}%}
{%unless colors contains ‘Blue’%}
{%abort_message(Blue not present)%}
{%endunless%}

Vérifier comment les données utilisateur sont gérées

S’il y a une condition de concurrence lors de l’évaluation de l’entrée dans le Canvas, les utilisateurs peuvent entrer dans un Canvas dans lequel ils n’étaient pas censés entrer. Par exemple, le profil de l’utilisateur pourrait être configuré pour être inclus dans l’audience, puis mis à jour après que le Canvas a mis les utilisateurs en file d’attente, de sorte qu’ils ne sont plus éligibles pour l’audience.

Si un utilisateur déclenche l’événement d’entrée du Canvas plusieurs fois dans la même seconde, Braze n’autorise qu’une seule entrée pour cette seconde (même si la réentrée est activée). Cela empêche les entrées en double, de sorte que le nombre total d’entrées dans le Canvas peut être inférieur au nombre total d’événements déclencheurs.

Nous recommandons de vérifier comment les données utilisateur sont gérées et mises à jour, en particulier quand et comment des attributs spécifiques sont mis à jour, que ce soit par le SDK, l’API, l’API par lots ou d’autres méthodes. Cela peut aider à identifier et clarifier pourquoi un utilisateur est entré dans une campagne ou un Canvas par rapport au moment où son profil a été mis à jour.