Informer les consommateurs des mises à jour de commande avec les Content Cards

Maintenez un flux de Content Cards personnalisé à jour avec le dernier statut de commande. Pour cela, enregistrez les mises à jour de commande provenant de votre système de gestion des commandes (OMS), envoyez des Content Cards pour des mises à jour comme l’expédition ou l’annulation, et supprimez les cartes obsolètes dans l’application à l’aide de paires clé-valeur.

À propos de cet exemple

Flash & Thread, un détaillant fictif de vêtements et de produits de beauté, souhaite proposer dans ses applications mobiles un flux horizontal de Content Cards où chaque carte affiche le statut d’un achat, par exemple lorsqu’une commande passe de picked à dispatched (expédiée) ou lorsqu’elle est cancelled.

Son système de gestion des commandes stocke l’e-mail du consommateur, le numéro de commande, le statut de la commande et l’URL de suivi, et peut appeler Braze lorsque ces valeurs changent. L’équipe marketing veut un texte de carte propre à chaque statut (par exemple, « Votre commande est en route » pour dispatched et « Nous préparons votre commande » pour picked). Les anciennes cartes d’une même commande (comme une carte picked après l’arrivée d’une carte dispatched) doivent être supprimées pour que les consommateurs ne voient que le dernier statut.

Cet exemple montre comment :

1. Enregistrer un événement personnalisé (par exemple, order_update) via /users/track lorsque le système de gestion des commandes enregistre un changement de statut, comme en attente, bloquée, préparée, expédiée ou annulée
2. Déclencher une campagne de cartes de contenu par événement distincte pour chacun de ces statuts, avec une personnalisation Liquid basée sur les propriétés d’événement
3. Définir des paires clé-valeur (extras) comme order_number et order_hierarchy sur chaque carte
4. Dans un flux de Content Cards personnalisé, ne conserver que la carte ayant le order_hierarchy le plus élevé pour chaque order_number et supprimer les autres

Utilisez cette approche lorsque les événements de suppression du tableau de bord ne suffisent pas à cibler la carte d’une seule commande parmi les nombreuses cartes d’un même parcours.

Points à prendre en compte

• Les Content Cards expirent et sont purgées au plus tard 30 jours après leur envoi. Définissez une expiration plus courte pour les statuts finaux (par exemple, annulée) si vous souhaitez qu’ils quittent le flux plus tôt. Consultez Créer une Content Card.
• Si le système de gestion des commandes ne dispose que de l’e-mail, identifiez l’utilisateur dans /users/track avec l’identifiant secondaire email. Privilégiez external_id lorsque le système de gestion des commandes en dispose. Les alias d’utilisateur restent une option lorsque vous avez besoin d’un type d’identifiant personnalisé : définissez alias_name sur la valeur de l’identifiant et alias_label sur son type (par exemple, email). Consultez Résolution des identifiants et Objet alias d’utilisateur.
• Les propriétés d’événement personnalisé sont disponibles pour la personnalisation Liquid et la segmentation par propriété d’événement lorsque vous utilisez l’approche déclenchée par événement. Elles ne sont pas conservées sur le profil en tant qu’attributs, sauf si vous les enregistrez également comme attributs.
• Les campagnes de cartes de contenu déclenchées par API constituent une alternative qui évite d’enregistrer un événement personnalisé (et les points de données associés), mais chaque campagne nécessite son propre envoi de déclenchement, et vous perdez la segmentation par propriété d’événement pour ce signal.
• Les flux personnalisés ne s’actualisent pas en cours de session avant le début de la session suivante ou un appel manuel à requestContentCardsRefresh. Déclenchez l’actualisation lorsque le consommateur ouvre le flux de commandes ou tire pour l’actualiser.
• Les interfaces de Content Cards entièrement personnalisées nécessitent un enregistrement manuel des analyses (impressions, clics, suppressions). Créer une sous-classe du flux par défaut demande moins de travail, mais ne prend pas en charge un carrousel horizontal.
• Cette logique de hiérarchie suppose un seul statut actif par numéro de commande à la fois. Si une commande peut avoir plusieurs statuts simultanés (par exemple, des expéditions réparties entre plusieurs entrepôts), ajoutez une autre clé (comme un ID de traitement) et intégrez-la dans vos règles de conservation ou de suppression.
• La logique de suppression côté application nécessite une nouvelle version de l’application. Testez-la dans un espace de travail de développement avant la mise en production.

Configuration

Étape 1 : Enregistrer les mises à jour de commande depuis le système de gestion des commandes

Lorsque le système de gestion des commandes enregistre un changement de statut, envoyez un événement personnalisé à /users/track. Incluez les propriétés d’événement que la Content Card utilise pour la personnalisation et que l’application lit depuis extras.

Le tableau suivant présente des exemples de propriétés :

Voici un exemple de requête qui identifie l’utilisateur par son e-mail :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

POST https://rest.iad-01.braze.com/users/track
Content-Type: application/json
Authorization: Bearer {YOUR_REST_API_KEY}

{
  "events": [
    {
      "email": "[email protected]",
      "name": "order_update",
      "time": "2026-09-28T16:02:05Z",
      "properties": {
        "order_number": "12345",
        "order_status": "picked",
        "tracking_url": "https://www.flashandthread.example/track/12345"
      }
    }
  ]
}

Utilisez l’endpoint REST de votre espace de travail et une clé API disposant de l’autorisation users.track. Remplacez l’e-mail et les valeurs de commande d’exemple par le payload de votre système de gestion des commandes.

Étape 2 : Créer une campagne de cartes de contenu par statut de commande

Créez une campagne de cartes de contenu par événement pour chaque statut que vous envoyez (par exemple, pending, held, picked, dispatched, cancelled).

1. Accédez à Envoi de messages > Campagnes, sélectionnez Créer une campagne, puis Content Cards.
2. Configurez une livraison par événement sur l’événement personnalisé order_update. Filtrez sur la propriété d’événement order_status correspondante afin que seul ce statut entre dans cette campagne.
3. Utilisez Liquid avec les propriétés d’événement pour personnaliser le titre ou le corps de la carte :

1

Order {{event_properties.${order_number}}} is {{event_properties.${order_status}}}.

4. Dans l’onglet Paramètres, sélectionnez Ajouter une nouvelle paire et ajoutez les paires clé-valeur utilisées par l’application :

Le tableau suivant présente un exemple de hiérarchie. L’application conserve la carte ayant la valeur la plus élevée pour chaque commande :

5. Définissez l’expiration de la carte (jusqu’à 30 jours). Privilégiez une durée plus courte pour les statuts finaux.

Les événements de suppression du tableau de bord s’appliquent au niveau de la campagne : ils ne peuvent pas supprimer la carte d’une seule commande tout en conservant les autres cartes de la même campagne. C’est pourquoi l’application supprime les cartes obsolètes à l’aide de extras.

Étape 3 : Conserver la carte la plus récente pour chaque commande dans le flux personnalisé

Abonnez-vous aux mises à jour des Content Cards dans votre flux personnalisé, lisez extras et, pour chaque order_number, conservez la carte ayant le order_hierarchy le plus élevé. Supprimez les autres avec l’API de suppression de votre plateforme afin que les analyses restent exactes.

Pour chaque carte du flux :

1. Lisez order_number et order_hierarchy dans extras.
2. Trouvez le order_hierarchy le plus élevé parmi les cartes qui partagent ce order_number.
3. Si la hiérarchie de la carte correspond à la valeur la plus élevée, affichez-la (en associant les champs de la carte à votre objet d’interface personnalisé).
4. Sinon, supprimez la carte.

Implémentez les appels d’abonnement et de suppression avec le SDK actuel de votre plateforme. Commencez par :

• Créer des cartes
• Personnaliser le flux
• Enregistrer les analyses

Lorsque le consommateur se trouve déjà dans l’application, appelez requestContentCardsRefresh pour que les nouvelles cartes de commande s’affichent sans attendre la session suivante.

Étape 4 : Tester le parcours de bout en bout

1. Envoyez une séquence d’événements order_update pour une même commande avec des valeurs order_status croissantes.
2. Vérifiez que chaque campagne de statut envoie la carte attendue et que le code Liquid est correctement résolu.
3. Vérifiez que le flux affiche une seule carte par commande et que les cartes de hiérarchie inférieure sont supprimées.
4. Vérifiez que les impressions, les clics et les suppressions apparaissent dans les analyses de campagne pour votre interface personnalisée.

Articles connexes

• Créer une Content Card
• Paires clé-valeur et comportement des Content Cards
• Créer des Content Cards personnalisées
• Personnaliser le flux de Content Cards
• Enregistrer les analyses des Content Cards
• POST : Créer et mettre à jour des utilisateurs