Envoyer les événements Wallet à vos outils

Envoyer les événements d’installation, de désinstallation, de scan et de notification du Wallet vers les outils CRM, CDP, BI et d’entrepôt de données avec des webhooks, des connecteurs personnalisés, l’API Carte ou l’API Insights.

Le Wallet Crew ne verrouille pas les données à l’intérieur de la plateforme. Chaque événement émis dans un programme Wallet peut être envoyé vers un CRM, un CDP, un outil BI ou un entrepôt de données. Quatre voies d’intégration couvrent la plupart des besoins : webhooks, un connecteur personnalisé, l’ API Carte, et l’ API Insights.

Les données Wallet appartiennent à la marque. Le Wallet Crew émet chaque événement de Carte en temps réel, et la marque décide où il va et ce qui en est fait.

Exemples concrets

Une équipe CRM ou CDP envoie Carte:Installed des événements dans Braze ou Salesforce pour déclencher des parcours d’intégration après l’adoption du Wallet.
Une équipe BI diffuse les événements Wallet dans BigQuery ou Snowflake, puis utilise l’API Insights pour suivre chaque semaine les installations par canal, Étiquette, ou Hôte.
Une équipe e-commerce conserve en temps réel l’état des installations dans sa stack avec des webhooks, puis utilise un backfill quotidien de l’API Carte pour corriger les écarts après des interruptions.

Ce que signifie le « statut d’installation »

Le statut d’installation est un signal de cycle de vie émis lorsqu’un utilisateur ajoute ou supprime une Carte. Il couvre les installations et les suppressions sur Apple Wallet et Google Wallet, et chaque Wallet peut changer d’état indépendamment.

C’est important parce que l’état d’installation est spécifique au Wallet. Le même client peut installer une Carte sur Apple Wallet, Google Wallet ou les deux, et chaque événement de suppression doit être interprété dans ce contexte.

Chaque Carte doit inclure un identifiant externe stable, tel que customerId ou e-mail. Cet identifiant est utilisé pour réconcilier les événements avec les enregistrements dans le reste de la stack.

Choisissez la bonne méthode de synchronisation

Pour les mises à jour en temps réel, utilisez webhooks ou un connecteur personnalisé.

Pour les tâches par lot ou les backfills, utilisez l’ API Carte.

Lorsque seuls les totaux et les tendances sont nécessaires, utilisez l’ API Insights.

Commencez par l’API Insights pour l’analyse agrégée

Lorsqu’il n’est pas nécessaire de synchroniser chaque client et que l’objectif est d’interroger les tendances et les données agrégées, commencez par l’ API Insights. C’est le chemin le plus rapide vers des questions telles que « combien de Cartes ont été installées cette semaine par canal ? »

Utilisez Insights lorsque les totaux, les tendances et l’analyse groupée comptent plus que les mises à jour au niveau de l’enregistrement. Interrogez des événements tels que Carte:Installed et Carte:Uninstalled avec KQL.

Étape suivante : configurez l’authentification et exécutez une première requête.

Voir API Insights.

Pour l’analyse agrégée dans le back-office, utilisez Tableaux de bord analytiques. Pour les enregistrements au niveau de la Carte, utilisez Rapport.

Décidez quoi synchroniser dans la stack

Commencez par définir la « vérité » que la stack doit stocker. La plupart des équipes conservent à la fois un statut simple et quelques horodatages dans le CRM ou le CDP.

Un champ global plus des champs par Wallet fonctionne généralement le mieux. Cela permet la segmentation sans perdre de détails.

Champs courants :

walletStatus: aucun, Apple, Google, les deux
appleWalletInstalledAt: horodatage, facultatif
googleWalletInstalledAt: horodatage, facultatif
walletLastChangedAt: horodatage
walletLastEvent: installé ou désinstallé

Traitez les événements comme une livraison au moins une fois. Attendez-vous à des doublons et à des livraisons hors ordre.

Réconciliez les événements avec les enregistrements dans la stack

La synchronisation a besoin d’une clé de jointure. Utilisez un identifiant externe stable stocké sur la Carte.

Les bons identifiants sont customerId, accountId, ou un e-mail normalisé. Évitez les identifiants susceptibles de changer fréquemment.

Lorsqu’un événement arrive, associez-le à un seul enregistrement dans la stack. Puis mettez à jour les indicateurs par Wallet et le statut global conservé dans la stack.

Comprenez les cas limites

L’installation est spécifique au Wallet. Un même client peut s’installer sur Apple Wallet et Google Wallet.

La désinstallation reste elle aussi spécifique au Wallet. Une désinstallation sur Apple Wallet n’implique pas une désinstallation sur Google Wallet.

Certains clients réinstallent rapidement. Utilisez des horodatages pour éviter les oscillations de statut dans les outils en aval.

Option 1 — Webhooks (temps réel, effort minimal)

Les webhooks envoient les événements vers un point de terminaison récepteur au fur et à mesure qu’ils se produisent. Abonnez-vous à Carte:Installed et Carte:Uninstalled.

Étape suivante : configurez le point de terminaison du webhook et validez les signatures.

Voir Webhooks.

Option 2 — Connecteur personnalisé (temps réel, charge utile personnalisée)

Utilisez un connecteur personnalisé lorsque la charge utile par défaut du webhook ne suffit pas.

C’est le bon choix pour des formats de charge utile personnalisés. C’est aussi utile pour une authentification personnalisée (clé API, OAuth) ou une logique supplémentaire.

La logique typique comprend le routage, l’enrichissement, la limitation du débit et les nouvelles tentatives.

Étape suivante : implémentez OnCarteInstalled et OnCarteUninstalled.

Voir Hooks d’installation et de désinstallation de Carte.

Option 3 — API Carte (synchronisation par lot + backfills)

Utilisez l’API Carte pour synchroniser périodiquement l’état d’installation.

C’est aussi le meilleur choix pour reconstruire l’état dans les outils en aval après une interruption.

Commencez par la documentation de l’API. Recherchez les points de terminaison de liste de Cartes pouvant être filtrés par statut d’installation.

Schéma de backfill qui fonctionne bien

Exécutez une tâche planifiée qui recalcule le statut de référence à partir de l’API Carte. La plupart des équipes l’exécutent quotidiennement.

Utilisez les événements en temps réel pour la rapidité. Utilisez le backfill pour la cohérence.

Si la stack et les Cartes divergent, faites confiance à l’API Carte. Réparez ensuite l’enregistrement en aval et poursuivez.

Un workflow pragmatique de bout en bout

1) Ajoutez un identifiant stable à chaque Carte

Choisissez un identifiant. Utilisez le même champ sur chaque Carte.

2) Envoyez les événements en temps réel vers la stack

Utilisez les webhooks pour la plupart des configurations. Utilisez un connecteur personnalisé lorsqu’une charge utile différente est nécessaire.

3) Mettez à jour les champs et les segments dans les outils en aval

Mettez à jour les indicateurs par Wallet et les horodatages. Recalculez le statut global walletStatus.

4) Effectuez régulièrement un backfill

Planifiez une tâche d’API Carte. Utilisez-la pour corriger les dérives et couvrir les interruptions.

5) Suivez l’adoption avec Insights

Utilisez Insights pour les tendances et la supervision. Vérifiez que les installations et les désinstallations correspondent aux attentes.

Dépannage

Lorsque aucun événement n’arrive, commencez par valider la signature. Vérifiez ensuite la disponibilité du point de terminaison et la gestion des nouvelles tentatives.

Lorsque des doublons apparaissent, ajoutez de l’idempotence dans le chemin d’écriture en aval. Utilisez l’horodatage le plus récent comme critère de départage.

Lorsque les événements ne peuvent pas être associés aux clients, un identifiant manque. Ajoutez-le aux données de la Carte, puis effectuez un backfill pour corriger l’historique.

FAQ

Quelle option faut-il utiliser en premier ?

Commencez par l’ API Insights lorsque seules les tendances agrégées comptent. Commencez par webhooks lorsque les événements doivent atteindre en temps réel un CRM, un CDP ou un outil d’automatisation. Ajoutez l’ API Carte lorsqu’un backfill fiable est également nécessaire.

Pourquoi utilise-t-on souvent ensemble les événements en temps réel et un backfill par lot ?

La livraison en temps réel maintient les parcours, alertes et segments à jour. Un backfill planifié de l’API Carte corrige les écarts causés par les nouvelles tentatives, les interruptions ou les défaillances temporaires en aval.

Pourquoi un identifiant stable est-il obligatoire ?

Les événements Wallet ne sont utiles en aval que lorsqu’ils peuvent être associés au bon enregistrement. Un identifiant stable, tel que customerId ou un e-mail normalisé, rend la réconciliation fiable sur les webhooks, les connecteurs et les tâches par lot.

Le même client peut-il apparaître comme installé sur Apple Wallet et Google Wallet ?

Oui. L’installation est spécifique au Wallet. Le même client peut détenir la même Carte dans Apple Wallet et Google Wallet, donc les modèles en aval doivent conserver des champs par Wallet ainsi qu’un statut global.