Skip to main content

​
Première activation CDP de bout en bout

Le CDP compte quatre phases — ingest, résolution d’identité, segmentation, activation — et chacune a son propre guide qui approfondit sa propre surface. Ce qu’aucun d’eux ne fait seul, c’est vous accompagner sur un passage continu : envoyer un événement, le regarder se coudre à une personne, construire une audience sur cet historique, et pousser l’audience vers une destination sur laquelle dépenser du budget. Ce tutoriel fait ce passage une fois, du début à la fin, en une seule séance. Commencez par ce parcours. Une fois la boucle en service, les guides de phase deviennent vos références d’approfondissement :

​
Pourquoi un seul passage de bout en bout compte

Chaque guide de phase suppose que les autres existent. Lus isolément, ils vous laissent coudre la boucle vous-même : le guide source explique comment accepter des événements mais pas quoi en faire une fois arrivés ; le guide segments suppose des profils résolus et des événements propres ; le guide activation suppose un segment qui vaut la peine d’être publié. Les nouveaux workspaces CDP échouent dans les interstices entre les guides — événements ingestés mais jamais cousus, segments construits sur des doublons non résolus, activations qui publient des memberships squelettiques que personne n’a diagnostiquées en amont. Déroulez ce passage contre une source de test et une destination de test avant d’ouvrir au trafic réel. Quand quelque chose déraillera plus tard, vous ré-entrerez dans le guide de phase de la phase concernée — mais vous y ré-entrerez en sachant quelle phase est cassée, parce que vous avez vu toute la boucle en bonne santé une fois.

​
1. Prérequis

Disposez des trois éléments suivants avant le premier événement :
  1. Un tracking plan publié. Déclarez les événements que votre application enverra et la forme des propriétés par événement, en mode d’application soft, sur la surface tracking plan. Le mode soft journalise les violations sans rejeter les événements : un nouveau producteur ne peut jamais caler sur une non-conformité pendant que vous itérez. Resserrez vers strict plus tard.
  2. Une source connectée. Un secret d’ingest émis sous Integrations → CDP → Source (inbound) et déployé dans votre application — le guide source et destinations détaille l’émission et la rotation. Votre application poste des événements signés vers https://api.orbit.devotel.io/cdp/v1/<ingest_id>/track.
  3. Une destination avec ses identifiants. Une audience de régie publicitaire jointe par une connexion OAuth, ou un sink webhook HTTPS que vous contrôlez. Branchez les identifiants avant d’en avoir besoin — la phase d’activation ne mappe un segment que vers une destination qui s’authentifie déjà.
Ayez aussi une clé API avec un rôle owner, admin ou developer. Chaque mutation de ce parcours (règles, segments, activations) est réservée à ces rôles ; les lectures en acceptent davantage.

​
2. Ingester une source

Choisissez un type de source sous Integrations → CDP — Segment, RudderStack, un webhook générique, ou votre propre SDK qui poste directement. Émettez le secret d’ingest depuis l’onglet Source (inbound), déployez-le dans l’application, et signez chaque requête selon le guide de signature d’ingest : les trois en-têtes X-Orbit-CDP-Timestamp, X-Orbit-CDP-Nonce et X-Orbit-CDP-Signature sur <timestamp>.<nonce>.<raw body>, keyed par le secret en clair. Tirez un événement track depuis l’application. Puis confirmez qu’il est arrivé — ne supposez jamais :
  1. Ouvrez Integrations → CDP → Event debugger.
  2. Filtrez sur Type = track et faites correspondre le nom de votre événement.
  3. Dépliez la ligne et lisez exactement les properties et le context que la passerelle a stockés.
Si la ligne manque, l’échec est dans la couche signature (un 401 que l’application a avalé) ou le tracking plan rejette le payload — le guide event debugger et DLQ traite les deux, y compris la lecture d’un corps de payload déversé ou perdu. N’avancez pas tant qu’un événement réel n’est pas visible ici.
Lorsque le consentement gouverne votre ingest — par exemple si des propriétés d’événement proviennent de champs de contact couverts par une limitation de finalité — enregistrez la base juridique par contact via l’API de consentement avant d’allumer la source. Orbit facilite l’enregistrement mais ne remplace pas un consentement valable : vous restez responsable de ce que vous ingérez, et de ce à quoi il sert. Cette page n’est pas un avis juridique.

​
3. Résoudre l’identité

Les événements arrivent avec la userId que votre SDK a envoyée, quelle qu’elle soit. Qu’elle se couse à un contact — et à quel contact — est décidé par les règles d’identité, pas par l’événement lui-même. La règle par défaut résout userId contre les identifiants externes uniquement ; une userId en forme d’e-mail ou de téléphone ne se coud pas tant que vous n’activez pas cette forme de correspondance.
  1. Ouvrez Integrations → CDP → Identity resolution et passez en revue les formes de correspondance : External ID (ensemencée, priorité 100), plus Phone, Email et Anonymous ID en opt-in.
  2. Si vos événements portent l’e-mail ou le téléphone comme identité, simulez d’abord sur Audience → Identity resolution — le tableau de bord refuse d’enregistrer une modification de ces formes tant qu’une simulation n’a pas tourné dans votre session, car une forme trop large coud ensemble de mauvaises personnes de façon irréversible. Lisez le nombre de fusions estimé ; s’il sur-fusionne, resserrez la forme ou montez sa priorité.
  3. Enregistrez le jeu de règles de retour sur la page CDP, puis réglez la politique de survivance (quelle valeur gagne une fusion par champ) dans le même constructeur.
  4. Confirmez que la résolution a pris : ouvrez Audience → Identity resolution et vérifiez que l’identité de votre événement de test s’est repliée sur un seul contact, pas sur un doublon en file de revue. Le guide catalogue de données et règles d’identité couvre les priorités, la porte de simulation et la séparation politique / file de revue.
Ne sautez rien ici : chaque segment ci-dessous lit des contacts résolus, donc les doublons non résolus survivent dans chaque compte d’audience que vous construisez.

​
4. Construire le segment sur les événements résolus

Avec des événements qui arrivent et des identités qui se cousent, construisez l’audience. Un segment est un filtre enregistré sur les attributs de contact, les champs personnalisés et les événements comportementaux ; créez-le avec POST /api/v1/contacts/segments. Deux exemples complets — un filtre simple et un trait SQL qui l’alimente.

​
Un filtre comportemental travaillé

Trois points à remarquer. Les événements sont référencés avec le préfixe event.<name> et s’apparient à un opérateur comportemental — performed_event, did_not_perform_event, event_count, ou performed_sequence pour les parcours ordonnés. La fenêtre within est relative, donc « les 14 derniers jours » ne demande aucun calcul d’horodatage. Et auto_refresh matérialise la membership sur une cadence — l’activation de l’étape suivante lit cette membership matérialisée, alors réglez-le. Dimensionnez le filtre avant de l’enregistrer. POST /api/v1/contacts/segments/preview évalue le même filtre contre les données live et renvoie un nombre de correspondances sans persister ; un compte de zéro ou « tout le tenant » signifient tous deux que le filtre est faux, pas les données.

​
Un trait SQL concret qui alimente le segment

Quand le fait dont vous avez besoin existe déjà en SQL d’entrepôt — une vue LTV côté finance, un modèle dbt — adoptez-le comme trait SQL au lieu de le reconstruire dans le DSL de prédicats. Un unique SELECT en lecture seule renvoyant (user_id, trait_value), exécuté à votre cadence, tamponne chaque valeur dans la map de traits du contact :
Une fois le trait matérialisé, il se segmente comme n’importe quel attribut — { "field": "traits.ltv_tier", "op": "equals", "value": "high" } se combine librement avec les conditions comportementales ci-dessus. L’arbre complet des choix de moteur (prédicat DSL, SQL, AI) est sur la page des traits SQL ; le vocabulaire complet des filtres est dans le guide segments.

​
5. Activer vers une destination

L’activation publie le segment là où il gagne du budget — l’audience d’une régie publicitaire ou votre sink webhook — sur une cadence que vous contrôlez. Déroulez-la en deux appels, selon le guide pipeline d’activation. Branchez la destination une fois. Pour une régie publicitaire (Google montré ; Meta, TikTok, LinkedIn et le reste du catalogue se comportent pareil) :
Pour votre propre sink HTTPS plutôt, PATCH /api/v1/cdp/audience/webhook avec target_url et un signing_secret ; les livraisons arrivent signées X-Orbit-Signature: t=<unix-sec>,v1=<hmac-sha256>, le même schéma que votre vérificateur de webhooks Orbit existant contrôle déjà. Dans les deux cas, les identifiants sont hachés en SHA-256 avant l’envoi aux régies publicitaires — jamais de PII en clair ne quitte le tenant. Lancez la première activation explicitement plutôt que d’attendre le planning :
Passez d’abord en dry-run avec POST /api/v1/cdp/audience/preflight/google chaque fois que le verdict est incertain — même porte, rien n’est dispatché. La porte de pré-activation bloque les audiences sous-dimensionnées, la faible couverture d’identifiants et les violations de consentement ou de suppression ; les ids des contrôles en échec reviennent dans la réponse. Si le maker-checker est actif pour cette org, l’exécution se met en file pour l’approbation d’une seconde personne — soumettez, faites approuver par un owner, re-soumettez avec l’id d’approbation renvoyé.

​
6. Relecture et dépannage

Confirmez que l’exécution a pris, puis apprenez le budget de latence pour distinguer le sain du bloqué. Confirmer. GET /api/v1/cdp/audience/activations liste l’historique des exécutions ; GET /api/v1/cdp/audience/activations/:id zoome sur une exécution avec les comptes requested / matched / skipped et les motifs de rejet par membre (jamais de PII). Un statut ok avec matched proche de requested est sain ; partial nomme son seau ; skipped signifie que rien n’a correspondu ou qu’aucune connexion n’a été résolue au dispatch. Pour une destination entrepôt plutôt qu’une régie publicitaire, lisez les mêmes verdicts sur le journal des exécutions de synchro — par exécution attempted / delivered / rejected / failed et les classes d’erreur (auth, validation, rate_limit, …) qui décident de la boucle de retry. Le budget de latence. Chaque phase a son propre délai attendu ; une réclamation ne devient un bug que lorsqu’une phase dépasse son budget : Lire le tableau de haut en bas convertit « l’audience est fausse » en « la phase N est hors budget » en un seul passage. Ré-entrez alors dans le guide dédié de cette phase — source et destinations, règles d’identité, segments, activation ou reverse ETL — avec la panne déjà localisée. Les quatre formes d’échec que vous rencontrerez réellement. Un 409 CONNECTION_NOT_CONFIGURED à l’activation signifie que la destination n’est pas entièrement branchée (audience_id ou id de connexion manquant). Un 422 AUDIENCE_PREFLIGHT_BLOCKED nomme son contrôle de porte en échec — redimensionnez le segment, corrigez la couverture d’identifiants, ou forcez délibérément. Zéro membre correspondant signifie que des lignes sont arrivées sans identifiant fort — corrigez le mapping à l’ingest, pas à l’activation. Une exécution partial dont le détail montre des seaux validation avec « missing or empty upsert identifier » signifie que la clé d’upsert n’est pas mappée — corrigez le field mapping, puis relancez. Les quatre sont couvertes par phase dans les guides liés ci-dessus.

​
Voir aussi