Conditions de concurrence

Une condition de concurrence se produit lorsqu’un résultat dépend de la séquence ou de la synchronisation de plusieurs événements. Par exemple, si la séquence d’événements 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 concurrence pour l’accès aux ressources ou aux données partagées.

Dans Braze, des conditions de concurrence peuvent se produire lorsque plusieurs actions sont déclenchées en même temps sur la base de données ou d’événements utilisateur. Par exemple, si un utilisateur déclenche plusieurs campagnes (comme l’inscription à une lettre d’information ou un achat), il se peut qu’il ne reçoive pas les messages dans le bon ordre.

Types de conditions de concurrence

Les types les plus courants de conditions de concurrence peuvent survenir lorsque vous effectuez les actions suivantes :

• Ciblage de nouveaux utilisateurs
• Utilisation de plusieurs endpoints d’API
• Correspondance entre les déclencheurs basés sur des actions et les filtres d’audience
• Utilisation du déclencheur « Interact with Step »

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

Scénario 1 : Cibler les nouveaux utilisateurs

Dans Braze, l’une des conditions de concurrence les plus courantes survient avec les messages ciblant les 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 second événement se déclenche en premier. Cela signifie qu’un message tente d’être envoyé à un utilisateur qui n’existe pas encore. En conséquence, l’utilisateur ne le reçoit jamais. Cela s’applique également aux événements ou attributs, où 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 le déclencheur fait partie du processus d’onboarding, ou si l’utilisateur sort du segment pour l’événement personnalisé au cours de sa première session, il est probable que l’utilisateur ne voie 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 le déclencheur fait partie du processus de création de l’utilisateur, ou si la Campaign 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 Campaigns ou 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 l’éligibilité de l’utilisateur à recevoir le message.

Par exemple, après qu’un utilisateur s’est inscrit à 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 afin d’é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

Important

Nous utilisons un traitement asynchrone pour maximiser la vitesse et la flexibilité. Cela signifie que lorsque des appels API nous sont envoyés séparément, nous ne pouvons pas garantir qu’ils sont traités dans l’ordre dans lequel ils ont été envoyés.

Il existe quelques scénarios dans lesquels plusieurs endpoints API peuvent également entraîner cette condition de concurrence, par exemple lorsque :

• Vous utilisez des endpoints API distincts pour créer des utilisateurs et déclencher des Canvas ou des Campaigns
• Vous effectuez plusieurs appels séparés à l’endpoint /users/track pour mettre à jour des attributs personnalisés, des événements ou des achats

Lorsque des 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 l’endpoint /users/track et les endpoints de messagerie comme /campaign/trigger/send, il n’y a aucune garantie que les informations utilisateur soient mises à jour avant l’envoi d’un message.

Remarque

Si les attributs utilisateur et les événements sont envoyés dans la même requête (soit depuis /users/track, soit depuis le SDK), alors Braze traite les attributs avant les événements ou avant de tenter d’envoyer un message.

Bonnes pratiques

Lors de l’utilisation de 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 les risques 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 distinctes, et un utilisateur doit être créé avant l’envoi de la requête API planifiée.

Incluez 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.

Utilisez 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. Utiliser 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.

Important

This endpoint est actuellement en version bêta. Contactez votre Braze account gestionnaire si vous souhaitez participer à la bêta.

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 se produire si 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é réalisé). 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 et 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 qui contiennent les critères du déclencheur, 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 pour Canvas afin de faire sortir n’importe quel utilisateur à n’importe quel moment du parcours utilisateur s’il remplit vos critères.

Pour les Campaigns, vous pouvez utiliser les événements de sortie afin de permettre aux Campaigns 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 uniques avec l’événement déclencheur

Lorsque vous configurez vos filtres, vous pourriez vouloir ajouter un filtre redondant « au cas où ». Cependant, cette redondance peut entraîner davantage de problèmes. Évitez plutôt d’utiliser tout filtre qui contient 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 au fait d’éviter les filtres redondants avec l’événement déclencheur. En général, un filtre qui suppose que l’événement déclencheur a été mis à jour dans le profil utilisateur échoue.

Utiliser les abandons Liquid (attributs uniquement)

Dans les Campaigns et les étapes Canvas, utilisez les abandons Liquid pour éviter d’utiliser des filtres d’audience qui contiennent les attributs du déclencheur au niveau de la planification d’entrée. Par exemple, supposons que vous ayez un attribut de tableau « couleurs favorites » et que vous souhaitiez cibler tout utilisateur qui met à jour le tableau d’attributs avec n’importe quelle valeur, et qui possède également la couleur « bleu » dans le tableau une fois la mise à jour terminée. 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 Canvas pour permettre au profil utilisateur de se mettre à jour pendant un certain temps, 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%}

Confirmer la manière dont les données utilisateur sont gérées

S’il y a une condition de concurrence lors de l’évaluation d’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 défini 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 soient plus éligibles pour l’audience.

Si un utilisateur déclenche l’événement d’entrée dans le 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 doublon, 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 confirmer la manière dont 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ù le profil de l’utilisateur a été mis à jour.

Scénario 4 : utilisation du déclencheur « Interact with Step »

Dans un Canvas, lorsqu’une étape Message est immédiatement suivie d’une étape Parcours d’action utilisant le déclencheur « Interact With Step », une condition de concurrence peut se produire. Étant donné que les utilisateurs peuvent interagir avec un message dès qu’il est distribué, il est possible qu’un utilisateur effectue l’action suivie avant d’entrer officiellement dans l’étape Parcours d’action.

Dans ce cas, l’étape Parcours d’action n’enregistre pas l’interaction, car elle n’évalue que les événements survenant après l’entrée dans l’étape, ce qui signifie que l’utilisateur peut être dirigé vers un parcours non souhaité.

Un Canvas envoie une notification push dans une étape Message, suivie d’une étape Parcours d’action qui vérifie si l’utilisateur ouvre cette notification push. Si un utilisateur ouvre la notification push immédiatement après l’avoir reçue (avant d’entrer dans l’étape Parcours d’action), l’événement d’ouverture peut ne pas être capturé. L’utilisateur pourrait alors être incorrectement dirigé vers le parcours « n’a pas ouvert », alors qu’il a effectivement interagi avec le message.

Bonnes pratiques

Suivre l’engagement à l’aide d’un événement personnalisé

Évitez de vous appuyer sur « Interact With Step » immédiatement après une étape Message lorsque les interactions des utilisateurs sont susceptibles de se produire rapidement. À la place, suivez l’engagement à l’aide d’un événement personnalisé (par exemple, déclenché depuis l’application ou le site web après l’interaction) et évaluez cet événement dans une étape en aval. Cela garantit que l’événement est enregistré après que l’utilisateur est entré dans l’étape.

Éviter les branches dépendantes d’une interaction

Concevez votre Canvas de sorte qu’une interaction immédiate manquée ne compromette pas l’expérience utilisateur. Par exemple, évitez les décisions de branchement critiques qui dépendent uniquement de la capture ou non de l’interaction dans l’étape suivante, ou ajoutez une logique de suivi permettant de corriger les parcours des utilisateurs.