Principes généraux
Des données bien structurées constituent le fondement d’un agent Decisioning Studio Pro efficace. Avant d’examiner les exigences propres à chaque ressource, il est utile de comprendre les quatre principes fondamentaux qui s’appliquent à l’ensemble des données que vous envoyez à Decisioning Studio Pro. Le non-respect de l’un de ces principes figure parmi les causes les plus fréquentes de dégradation des performances du modèle.
Un identifiant client unique et cohérent pour toutes les ressources
Chaque ressource de données (profils utilisateurs, activations, engagements, conversions) doit faire référence au même identifiant client. Il doit exister un seul identifiant principal qui identifie chaque client de manière unique et cohérente dans toutes les ressources.
| Exigence | Conséquence en cas de non-respect |
|---|---|
| Un identifiant client unique doit être présent dans chaque ressource | Si les ressources utilisent des systèmes d’ID différents (par exemple, un ID d’entrepôt pour les fonctionnalités, mais un ID de plateforme pour les activations), le moteur de Decisioning Studio Pro ne peut pas les joindre de manière fiable. La boucle de rétroaction est alors rompue, ce qui dégrade à la fois l’entraînement du modèle et la précision des rapports. Si le mappage entre les deux systèmes d’ID s’avère être de type plusieurs-à-plusieurs plutôt qu’un-à-plusieurs, les problèmes d’intégrité des données qui en résultent peuvent être graves. |
Consultez Utiliser l’ID externe de Braze pour savoir quel identifiant utiliser.
Les données d’événements doivent être transmises sous forme de flux incrémental
Les événements, tels que les conversions, les engagements et les activations, représentent des actions distinctes survenues à un moment précis. Transmettez chaque événement à Decisioning Studio Pro sous la forme d’un enregistrement distinct, dans un flux incrémental (en ajout uniquement).
| Exigence | Conséquence en cas de non-respect |
|---|---|
| Les données d’événements doivent être structurées sous forme d’enregistrements individuels horodatés et transmises de manière incrémentale | Lorsque les données d’événements sont agrégées dans un snapshot (par exemple, en stockant un attribut « heure du dernier envoi » plutôt que des enregistrements d’envoi individuels), vous perdez le timing précis de chaque événement. Il devient alors impossible d’attribuer correctement les résultats à des décisions spécifiques, ce qui rompt la boucle de rétroaction dont le modèle a besoin pour apprendre. Sans horodatages précis des événements, vous ne pouvez pas savoir exactement quand une conversion a eu lieu ni quelle recommandation l’a déclenchée. |
Consultez Snapshots et flux d’événements pour une explication complète de cette distinction, ainsi que des exemples de schémas corrects et incorrects.
Les données d’instantané doivent être mises à jour selon une planification régulière et temporelle
Les données d’instantané (comme les profils utilisateurs et les fonctionnalités) représentent l’état actuel d’un client à un moment donné. Mettez à jour les données d’instantané selon une planification régulière (par exemple, quotidienne) pour chaque client, y compris ceux qui n’ont aucun nouvel événement.
| Exigence | Conséquence en cas de non-respect |
|---|---|
| Les instantanés doivent être mis à jour pour tous les clients selon une planification régulière, qu’un client ait eu ou non un événement ce jour-là | Si les mises à jour d’instantanés ne sont déclenchées que lorsqu’un événement se produit, les fonctionnalités qui dépendent du temps écoulé (comme « jours depuis le dernier achat » ou « jours depuis l’inscription ») deviendront obsolètes pour les clients n’ayant pas eu d’événement récent. Le modèle s’entraînera alors sur des valeurs de fonctionnalités dépassées, ce qui réduit sa capacité à formuler des recommandations précises et pertinentes au bon moment. |
Tous les assets doivent respecter des exigences minimales de qualité et d’intégrité des données
Au-delà de la structure, les données elles-mêmes doivent être cohérentes et suffisamment complètes pour être exploitables.
| Exigence | Conséquence en cas de non-respect |
|---|---|
| Chaque ressource doit contenir les champs nécessaires pour établir une clé primaire et, le cas échéant, des clés de jointure vers d’autres ressources. Les enregistrements en double doivent être supprimés ou dédupliqués avant l’ingestion. | Les enregistrements en double ou impossibles à rapprocher ajoutent du bruit à l’entraînement du modèle et peuvent fausser l’attribution. L’absence de clés empêche le moteur de relier les événements tout au long du parcours client, de la recommandation jusqu’à la conversion. |
Pour les données de flux d’événements en particulier, chaque enregistrement doit inclure au minimum :
Champs obligatoires :
- Identifiant client
- Horodatage du moment où l’événement s’est produit (l’heure de l’action elle-même ; consultez Instantanés et flux d’événements pour comprendre en quoi il diffère de l’horodatage de création de l’enregistrement)
- Horodatage de création de l’enregistrement dans votre système (utilisé pour découper de manière fiable les exportations incrémentielles)
- Type d’événement
- Champs suffisants pour filtrer les événements spécifiques qui vous intéressent
Champs recommandés :
- Métadonnées d’événement supplémentaires permettant un rapprochement fiable entre les types d’événements (par exemple, relier un événement de conversion à l’activation spécifique qui l’a précédé)