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 de conditions de concurrence les plus courants peuvent se produire lorsque vous effectuez les opérations suivantes :

• Cibler de nouveaux utilisateurs
• Utiliser plusieurs endpoints API
• Correspondance entre les filtres d’audience et les déclencheurs basés sur l’action.

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

Scénario 1 : Cibler de nouveaux utilisateurs

Dans Braze, l’une des conditions de concurrence les plus courantes se produit avec des messages qui ciblent de nouveaux utilisateurs. L’ordre prévu des événements est le suivant :

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

Cependant, dans certains cas, le deuxième événement se déclenchera d’abord. 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 aux attributs, lorsque l’événement ou l’attribut tente d’être enregistré dans un profil utilisateur qui n’a pas encore été créé.

Bonnes pratiques

Introduire des retards

Après la création d’un nouvel utilisateur, vous pouvez ajouter un délai avant l’envoi de toute campagne de ciblage ou de Canevas. Ce délai permet la création du profil utilisateur et la mise à jour de tout attribut pertinent susceptible de déterminer l’admissibilité de l’utilisateur à recevoir le message.

Par exemple, lorsqu’un utilisateur s’inscrit à votre application, vous pouvez lui envoyer une offre promotionnelle après 24 heures. Par ailleurs, 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.

Scénario 2 : Utiliser plusieurs endpoints API

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

• Utiliser des endpoints API distincts pour créer des utilisateurs et déclencher des Canvases ou des campagnes.
• Effectuer plusieurs appels distincts à l’endpoint /users/track pour mettre à jour des attributs personnalisés, des événements ou des achats.

Lorsque les informations de l’utilisateur sont envoyées à Braze à l’aide de l’endpoint/users/track , leur traitement peut parfois prendre quelques secondes. Cela signifie que lorsque des demandes sont simultanément adressées à /users/track et à des endpoints de messages tels que /campaign/trigger/send, il n’est pas garanti que les informations relatives à l’utilisateur soient mises à jour avant l’envoi d’un message.

Bonnes pratiques

Si vous utilisez plusieurs endpoints, envoyez vos demandes une à la fois.

Si vous utilisez plusieurs endpoints, vous pouvez essayer d’échelonner vos demandes de manière à ce que chaque demande 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 les attributs de l’utilisateur et envoyer un message, attendez d’abord que le profil utilisateur soit complètement mis à jour avant d’envoyer un message à l’aide d’un endpoint.

Si vous envoyez une demande API de messages planifiés, ces demandes doivent être séparées et un utilisateur doit être créé avant d’envoyer la demande API planifiée.

Inclure des données clés dans le déclencheur

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

Lorsque ces objets sont inclus dans 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 du déclencheur ne mettent pas à jour le profil utilisateur, mais sont utilisées uniquement dans le contexte du message.

Utilisez le POST : Suivi des utilisateurs (en vrac) endpoint

Utilisez le point de terminaison/users/track/sync/ pour enregistrer les événements et attributs clients personnalisés et mettre à jour les attributs du profil utilisateur de manière synchrone. L’utilisation de cet endpoint pour mettre à jour les profils utilisateurs en même temps et en un seul appel peut aider à prévenir d’éventuelles conditions de concurrence.

Scénario 3 : Associer des déclencheurs par événement et des filtres d’audience

Une autre condition de concurrence courante peut se produire si vous configurez une campagne basée sur une action ou un Canvas avec le même déclencheur que le filtre d’audience (tel qu’un attribut modifié ou l’exécution d’un événement personnalisé). 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érifiez votre audience après un délai

Pour éviter d’utiliser des filtres d’audience contenant les critères de déclenchement, nous vous recommandons de vérifier votre audience avant la réception/distribution. Par exemple, vous pouvez utiliser les validations de réception/distribution dans les étapes du canvas comme contrôle supplémentaire pour confirmer que votre audience répond aux critères de livraison lors de l’envoi du message. Vous pouvez également exploiter les critères de sortie pour Canvas afin de sortir n’importe quel utilisateur à n’importe quel moment du parcours utilisateur s’il répond à vos critères.

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

Utilisez des filtres uniques avec l’événement déclencheur

Lorsque vous configurez vos filtres, vous pouvez ajouter un filtre redondant “au cas où”. Toutefois, cette redondance peut entraîner d’autres problèmes. Dans la mesure du possible, évitez plutôt d’utiliser un filtre contenant le déclencheur. C’est le moyen le plus sûr d’é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é n’importe quel achat”, cette redondance peut provoquer une condition de concurrence.

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

Cette bonne pratique est similaire à celle qui consiste à é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 interruptions de liquide (attributs uniquement)

Dans les campagnes et les étapes du canvas, utilisez les abandons liquides pour éviter d’utiliser les filtres d’audience qui contiennent les attributs du déclencheur au niveau de la planification d’entrée. Par exemple, disons que vous avez un tableau d’attributs “couleurs préférées” et que vous souhaitez cibler tout utilisateur qui met à jour le tableau d’attributs avec une valeur quelconque et qui a également la couleur “bleu” dans le tableau une fois la mise à jour effectuée. Si vous utilisez les filtres d’audience dans cet exemple, vous rencontrerez une condition de concurrence et manquerez les utilisateurs qui ajoutent “bleu” dans le tableau pour la première fois.

Dans ce cas, vous pouvez mettre en œuvre un délai de déclenchement dans une campagne ou utiliser une étape du canvas pour permettre au profil utilisateur de se mettre à jour pendant un certain temps, puis utiliser la logique d’annulation liquide suivante :

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