Snapshots et flux d’événements
Les données se répartissent en deux catégories fondamentales : les snapshots (état) et les flux d’événements (ce qui s’est passé). Comprendre cette distinction et l’appliquer correctement est l’une des choses les plus importantes que vous puissiez faire pour garantir que votre agent Decisioning Studio Pro apprenne efficacement.
Données d’instantané (état)
Un instantané représente l’état d’un client à un moment précis. Il répond à la question : « À quoi ressemble ce client en ce moment ? »
Un instantané est statique et agrégé. Il reflète le résultat cumulé de toutes les modifications jusqu’à ce moment. Il convient particulièrement aux profils utilisateurs et aux caractéristiques calculées (par exemple, « jours depuis le dernier achat », « niveau de fidélité », « score d’attrition »).
Champs obligatoires
| Champ | Objectif |
|---|---|
| Identifiant client | Le client décrit par cet enregistrement |
| Date de l’instantané | Le moment où cet instantané a été pris |
Mise à jour des instantanés
- Déclencheur : Basé sur le temps. Générez des instantanés selon une planification fixe (par exemple, quotidienne), en incluant les clients sans activité ce jour-là.
- Portée : Chaque mise à jour doit inclure tous les clients concernés, y compris ceux qui n’ont eu aucun événement.
- Méthode : Ajoutez les nouveaux enregistrements d’instantané au jeu de données au lieu d’écraser les valeurs précédentes. Cela préserve l’historique des états pour l’entraînement du modèle.
Interroger les données d’instantané pour une distribution quotidienne
Decisioning Studio Pro exécute son pipeline de recommandations une fois par jour. Lorsque vous fournissez des données d’instantané, exportez l’instantané de la veille à chaque exécution du pipeline :
SELECT *
FROM snapshot_data
WHERE snapshot_date = {t-1} -- on pipeline run date t, export the snapshot from t-1
Données de flux d’événements (flux)
Un flux d’événements enregistre des actions distinctes au moment où elles se produisent. Il répond à la question : « Qu’a fait ce client, et quand ? » Un flux d’événements convient parfaitement aux données brutes, immuables, incrémentielles et chronologiques. Chaque enregistrement correspond à un événement survenu à un moment précis. Utilisez par exemple ce flux de données pour les enregistrements d’activation, les journaux d’engagement (ouvertures, clics), les événements de conversion ou les utilisations de coupons.
Champs obligatoires
| Champ | Objectif |
|---|---|
| Identifiant client | La personne concernée par cet événement |
| Type d’événement | Ce qui s’est passé (par exemple, activation, conversion, clic) |
| Horodatage de l’événement | Le moment où l’événement s’est réellement produit |
| Horodatage de création | Le moment où cet enregistrement a été créé dans votre système (voir la remarque de la section suivante) |
| Propriétés d’événement | Métadonnées supplémentaires sur l’événement ; plus elles sont riches, mieux Decisioning Studio Pro peut relier les événements tout au long du parcours client |
L’horodatage de l’événement et l’horodatage de création sont deux champs distincts, et tous deux sont obligatoires. L’horodatage de l’événement indique le moment où l’action s’est réellement produite. L’horodatage de création indique le moment où l’entrée de données a été écrite dans votre système, ce qui peut intervenir plus tard en raison de délais de traitement. Ne confondez pas les deux.
Comment mettre à jour les flux d’événements
- Déclencheur : Basé sur les événements. De nouveaux enregistrements sont ajoutés lorsque de nouveaux événements se produisent.
- Portée : Seuls les clients ayant eu un événement reçoivent de nouveaux enregistrements.
- Méthode : Les enregistrements existants sont immuables. Les mises à jour consistent toujours à insérer de nouveaux enregistrements.
Interroger les données d’événement pour une livraison quotidienne
Découpez les exportations quotidiennes selon create_timestamp. Les événements sont parfois écrits dans votre système après s’être produits (arrivées tardives). Si vous découpez selon event_timestamp, ces enregistrements arrivés en retard seront définitivement perdus.
-- Correct: use create_timestamp to ensure late-arriving events are captured
SELECT *
FROM events_data
WHERE DATE(create_timestamp) = {t-1} -- on run date t, export all records created yesterday
-- Incorrect: slicing on event_timestamp will permanently lose late-arriving events
SELECT *
FROM events_data
WHERE DATE(event_timestamp) = {t-1}
Par exemple, si un événement s’est produit le 1er janvier mais n’a été écrit dans votre système que le 2 janvier, un découpage selon event_timestamp le 2 janvier le manquerait complètement. Un découpage selon create_timestamp le capture correctement.
Pour les intégrations natives de Braze
Braze propose deux mécanismes intégrés qui correspondent directement à ces deux types de données.
Attributs personnalisés : données d’instantané
Les attributs personnalisés stockent l’état d’un utilisateur à un instant donné. Utilisez-les pour les profils utilisateurs et les caractéristiques calculées (par exemple, churn_score, total_purchases_last_30d). Chaque mise à jour écrase la valeur précédente : l’attribut conserve uniquement l’état le plus récent, et les événements antérieurs sont perdus.
Braze Currents : données de flux d’événements
Braze Currents fournit des données brutes et immuables sur le flux d’événements. La table USER_BEHAVIOR_CUSTOM_EVENTS capture chaque instance d’un événement personnalisé au moment où il se produit, ce qui en fait la source appropriée pour les événements d’activation, d’engagement et de conversion.
Considérez les attributs personnalisés comme la source de l’état des clients et Braze Currents comme la source des événements de comportement client. N’utilisez pas les attributs personnalisés pour transmettre des données d’événements brutes à Decisioning Studio Pro.
Problèmes courants
Transmettre les données d’événement sous forme d’instantané
Agréger les données d’événement dans des champs d’instantané avant de les envoyer à Decisioning Studio Pro pose plusieurs problèmes :
- Perte de granularité : Une fois les données agrégées dans un récapitulatif quotidien au niveau client, les enregistrements d’événements individuels disparaissent. Decisioning Studio Pro ne peut pas les reconstituer.
- Horodatages imprécis : Un champ comme « last_email_sent » indique l’occurrence la plus récente, mais perd l’historique complet des événements et rend toute attribution précise impossible.
- Mises à jour fantômes : Même les jours où aucun événement ne s’est produit, l’enregistrement d’instantané est mis à jour, ce qui crée des entrées en double difficiles à dédupliquer.
Si vous utilisez Braze, transmettez les données d’événement brutes à Decisioning Studio Pro avec les exportations Currents.
Mettre à jour les données d’instantané sur un déclencheur d’événement
Certains déploiements ne mettent à jour les données d’instantané que lorsqu’un événement se produit, par exemple en recalculant une fonctionnalité uniquement lorsqu’un client effectue un achat. Les fonctionnalités qui dépendent du temps qui passe deviennent alors obsolètes pour les clients qui n’ont pas eu d’événement récent.
Par exemple, une fonctionnalité comme days_since_last_purchase a une valeur correcte différente chaque jour. Si elle n’est recalculée que lors d’un achat, elle restera figée à une valeur incorrecte pour tous les clients qui n’ont pas acheté récemment. Mettez toujours à jour les données d’instantané selon une planification temporelle qui couvre tous les clients, chaque jour.