Surveiller la distribution des Content Cards avec des alertes et Currents

Utilisez les outils de débogage, les alertes de seuil, les événements Currents et la surveillance de l’API pour détecter les baisses de distribution des Content Cards avant que vos utilisateurs ne les signalent.

À propos de cet exemple

Pyrite Financial, une marque fictive de banque mobile, affiche une Content Card dans un emplacement dédié de l’écran d’accueil de son application. Cet emplacement est censé contenir une carte pour la plupart des utilisateurs : un emplacement vide est donc un signal qui mérite d’être examiné.

Cet exemple vous montre comment :

1. Valider l’intégration des Content Cards pendant les tests avec le débogueur SDK, les groupes internes et le journal des événements utilisateurs
2. Définir des alertes de seuil de campagne ou de Canvas sur le volume de messages attendu
3. Suivre les entrées dans le Canvas, les envois, les impressions et les abandons de Content Cards dans Currents
4. Surveiller les endpoints de l’API REST qui déclenchent l’envoi de messages pour détecter les baisses de volume et les réponses autres que 200
5. Ajouter des contrôles complémentaires du volume d’envoi dans Datadog ou avec les endpoints d’exportation de Canvas
6. Journaliser le comportement de repli côté application que Braze ne peut pas observer

Utilisez cette approche lorsqu’un emplacement de Content Card est essentiel pour votre activité et que vous avez besoin d’un signal opérationnel indiquant une baisse de la distribution. Chaque étape est facultative : commencez par celles que votre espace de travail prend déjà en charge.

Points à prendre en compte

• Déterminez d’abord si chaque utilisateur ciblé doit toujours voir une carte dans l’emplacement, ou si un emplacement vide est acceptable pour certains utilisateurs. Les seuils de volume et la logique de repli dépendent de cette réponse.
• Braze surveille la connectivité du SDK et signale les incidents sur la page d’état de Braze. Cet exemple couvre ce que vous surveillez vous-même : la configuration des campagnes et des Canvas, le volume de messages, le trafic API et le comportement de repli côté application.
• Tous les déclencheurs ne produisent pas un message. Une fois qu’un déclencheur atteint Braze, la logique du parcours, le ciblage, la limite de fréquence et la limitation du débit peuvent tous réduire les envois. Comparez le volume de déclencheurs au volume d’envois sous forme de tendance, et non comme une correspondance exacte.
• La surveillance au niveau des événements nécessite Currents. Sans Currents, utilisez plutôt les analyses de campagnes et de Canvas, les alertes de seuil et les endpoints d’exportation REST.
• Les indicateurs Datadog ne rapportent que le nombre d’envois et peuvent légèrement différer du tableau de bord de Braze et de Currents.
• Les actualisations excessives peuvent être soumises à une limitation du débit. Le SDK applique des limites de débit par appareil sur les demandes d’actualisation des Content Cards. Appelez la méthode d’actualisation à des moments pertinents du cycle de vie de l’utilisateur plutôt que de manière répétée en peu de temps. Consultez la limite de débit des Content Cards et Améliorer la latence des Content Cards utilisées comme bannières.
• Liquid peut supprimer une carte intentionnellement. Lorsque Liquid interrompt un message, Braze enregistre un événement d’abandon de Content Card plutôt qu’un envoi. Considérez les abandons comme un comportement attendu pour le contenu conditionnel, et comme un signal uniquement lorsque leur volume change.
• Si votre application affiche un contenu par défaut lorsqu’aucune carte n’est disponible, suivez-le dans vos propres outils d’analyse. Braze sait uniquement ce qu’elle a envoyé, et non si votre application a affiché une carte ou une marque substitutive.

Configuration

Étape 1 : Valider l’intégration avant le lancement

Vérifiez le comportement attendu afin que les alertes en production reflètent de vrais problèmes plutôt que des lacunes d’intégration.

1. Créez une session de débogage dans le débogueur SDK pour observer l’activité du SDK en temps réel et confirmer que les demandes de cartes et les impressions sont bien enregistrées.
2. Ajoutez des comptes de test à un groupe interne afin de tester la campagne ou le Canvas auprès d’utilisateurs test avant le lancement.
3. Consultez le journal des événements utilisateurs d’un utilisateur donné pour confirmer quelle campagne a distribué chaque carte au SDK.

Notez les volumes d’envois, d’impressions et d’abandons observés pendant les tests. Ils serviront de référence pour les seuils que vous définirez.

Étape 2 : Définir des alertes de seuil sur la campagne ou le Canvas

Les alertes de seuil vous préviennent par e-mail ou par webhook lorsque le volume de messages sort de la plage attendue. Les alertes par webhook peuvent être acheminées vers un canal Slack ou un système d’astreinte.

• Campagnes : Définissez des seuils supérieur et inférieur sur la page d’analyse de la campagne. Pour connaître les étapes de configuration, consultez Alertes de campagne.
• Canvas : Configurez des alertes sur les entrées d’utilisateurs, les messages envoyés, ou les deux, depuis la page Gérer les alertes. Pour connaître les étapes de configuration, consultez Alertes de seuil de Canvas.

Choisissez un seuil inférieur au volume normal mais supérieur à zéro, afin qu’une baisse partielle déclenche une notification sans attendre une panne complète.

Étape 3 : Suivre les entrées, les envois et les impressions dans Currents

Currents transmet en quasi temps réel les événements d’engagement liés aux messages et de comportement des clients vers votre plateforme de données, ce qui vous permet de surveiller le volume et la latence en dehors du tableau de bord de Braze.

Pour une Content Card envoyée depuis un Canvas, ces événements couvrent le parcours de l’entrée jusqu’à l’impression.

Pour une campagne de Content Cards, surveillez les événements d’envoi, d’impression et d’abandon, et filtrez par campaign_id.

• Surveillance du volume : Suivez les envois et les impressions par Canvas ou par campagne sur une période fixe, et déclenchez une alerte lorsque le volume passe sous un seuil établi à partir des données historiques.
• Surveillance de la latence : Comparez les événements d’entrée aux événements d’envoi pour mesurer la latence de création, et les événements d’envoi aux événements d’impression pour mesurer la latence d’affichage. Si les cartes sont créées à la première impression, la mesure de l’entrée jusqu’à l’impression mélange les temps de création et d’affichage : utilisez donc le délai entre l’envoi et l’impression pour la latence d’affichage.

Comparer les volumes entre les étapes permet d’identifier les défaillances courantes :

• Une baisse des entrées indique un problème en amont, au niveau du déclencheur ou de l’audience.
• Des entrées stables avec moins d’envois peuvent indiquer un problème de logique du parcours, de ciblage ou des abandons Liquid. Si les cartes sont créées à la première impression, cela peut aussi signifier que les utilisateurs n’ont pas encore ouvert l’application.
• Des envois stables avec moins d’impressions indiquent un problème entre la création et l’affichage de la carte, comme l’actualisation du SDK, le rendu de l’emplacement ou les limites de débit de l’appareil.

Pour connaître les payloads et les champs des événements, consultez Événements d’engagement liés aux messages.

Étape 4 : Surveiller le trafic API et les réponses d’erreur

Si vos déclencheurs proviennent de vos propres systèmes, surveillez la couche API qui les alimente.

1. Configurez des alertes d’utilisation de l’API sur les endpoints qui déclenchent vos messages. Définissez des conditions pour les baisses de volume et les hausses de réponses autres que 200.
2. Examinez les réponses autres que 200 pour ces endpoints. Une hausse des réponses d’erreur peut indiquer qu’une version récente a introduit une requête mal formée ou que les appels atteignent une limite de débit.

Étape 5 : Ajouter des contrôles de volume complémentaires

Utilisez ces options lorsque vous souhaitez disposer des données de volume d’envoi dans un outil d’observabilité existant ou une tâche planifiée.

• Datadog : L’intégration Datadog fournit l’indicateur braze.messaging.sent, étiqueté avec les identifiants de campagne, de Canvas et d’étape du canvas. Utilisez-le pour obtenir le nombre d’envois d’une étape de message spécifique sur une période donnée. Ces chiffres donnent une approximation agrégée du volume d’envois de Content Cards et n’incluent pas d’identifiants d’utilisateur ou d’envoi.
• Endpoints d’exportation : Interrogez régulièrement /canvas/data_series et /canvas/data_summary pour obtenir les entrées dans le Canvas et les envois de messages, puis comparez les résultats d’une exécution à l’autre pour repérer les tendances et les anomalies.

Étape 6 : Journaliser le comportement de repli dans votre application

Braze rapporte ce qu’elle a envoyé, et non ce que votre application a affiché. Ajoutez une journalisation ou des analyses côté application pour les cas que Braze ne peut pas observer :

• L’actualisation du flux s’est terminée, mais aucune carte n’était disponible pour l’emplacement.
• L’application a affiché un contenu de repli au lieu d’une carte.
• La demande d’actualisation a échoué ou a été soumise à une limitation du débit.

Envoyez-les sous forme d’événements personnalisés si vous souhaitez les consulter avec les données de Braze, ou conservez-les dans votre propre plateforme d’analyse et comparez-les au volume d’impressions de Currents.

Étape 7 : Analyser la situation lorsqu’une alerte se déclenche

Effectuez ces vérifications dans l’ordre :

1. Vérifiez qu’aucun incident n’est en cours sur la page d’état de Braze.
2. Dans Currents (ou dans les analyses de Canvas et de campagnes), comparez les volumes d’entrées, d’envois, d’impressions et d’abandons sur la même période. Si les cartes sont créées à la première impression, le volume d’entrées peut dépasser le volume d’envois jusqu’à ce que les utilisateurs ouvrent l’application : tenez-en compte lorsque vous comparez les volumes.
3. Vérifiez les alertes d’utilisation de l’API et les réponses autres que 200 sur les endpoints qui déclenchent le message.
4. Comparez les événements de repli ou d’emplacement vide côté application au volume d’impressions de Currents.
5. Reproduisez le problème avec un utilisateur représentatif dans le débogueur SDK et le journal des événements utilisateurs.

Articles connexes

• Rapports sur les Content Cards
• Création de cartes
• Alertes de campagne
• Alertes de seuil de Canvas
• Événements d’engagement liés aux messages
• Alertes d’utilisation de l’API