CDP & first-party data : frameworks et méthodologie

Avant d'assister à la moindre démo d'un éditeur, vous devez vous doter de trois documents : le ruleset de résolution d'identité, le schéma d'événements et le modèle de consentement. Rédigez-les et les démos deviennent courtes, parce que vous demandez aux éditeurs d'exécuter une spécification qui vous appartient déjà. Sautez cette étape et vous achèterez le modèle de données de quelqu'un d'autre, vous découvrirez au septième mois qu'il fusionne un foyer en une seule personne, et vous paierez pour démêler le tout. Cette leçon est la méthode pour rédiger ces trois documents, plus l'arithmétique qui vous dit à quelle vitesse vos profils doivent réellement se mettre à jour.

Partons du profil persistant décrit dans la leçon sur les fondamentaux. La question ici est de savoir comment il se construit, à partir de quelles clés, sous quelles permissions.

Framework 1 : le ruleset de résolution d'identité

La résolution d'identité, c'est une liste hiérarchisée de match keys et les règles qui s'appliquent quand deux d'entre elles se contredisent. Rédigez-la sous forme de tableau avant que quiconque configure quoi que ce soit.

Le matching déterministe joint sur un identifiant fort : email hashé, téléphone, numéro de fidélité, identifiant de compte. Même valeur, même personne. Confiance élevée, et cela ne couvre que les clients qui se sont identifiés.

Le matching probabiliste déduit l'identité à partir du device, de l'IP, du timing et des schémas comportementaux. Il étend le reachreachLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → au trafic anonyme et vous coûte de la certitude. Un modèle probabiliste réglé pour la couverture fusionnera sans hésiter deux personnes qui partagent un portable et un réseau domestique.

La règle pratique : le déterministe comme colonne vertébrale, le probabiliste uniquement là où vous pouvez mesurer le taux d'erreur contre un holdout de clients connus. Matcher correctement 60 % de vos clients vaut mieux qu'en matcher 95 % avec un modèle que vous ne pouvez pas auditer, parce que vous ne voyez jamais les mauvais matchs. Ils se manifestent quand un client reçoit la confirmation de commande d'un autre.

Ce que le ruleset doit spécifier :

• La priorité des clés. Quel identifiant l'emporte quand la fiche fidélité dit une chose et la session web une autre. En général celui capturé le plus récemment sous authentification.
• La normalisation avant hashage. Minuscules, suppression des espaces, retrait du plus-addressing si vous le décidez, et application des mêmes règles partout. Un hash de " Sarah@Example.com " ne matche rien. Ce seul détail casse plus d'onboarding pushes que n'importe quel choix de modélisation.
• Le plafonnement d'identifiants par profil. La profile unification de Segment (Segment vend le CDPCDPLogiciel qui unifie les données client de toutes les sources en un profil unique et durable, exploitable par le marketing, les ventes et le service.Voir la définition complète → dont il est question) permet de limiter le nombre de valeurs de chaque type d'identifiant qu'un profil peut contenir. C'est votre garde-fou contre le profil monstre : un iPad partagé en magasin ou une IP de bureau qui accumule des milliers d'identifiants anonymes jusqu'à ce qu'une seule fiche contienne la moitié de votre trafic.
• Un chemin de démerge. Fusionner est trivial ; séparer deux personnes fusionnées il y a six mois n'est possible que si vous avez conservé les événements bruts immuables et que vous pouvez re-dériver le graphe. Ne laissez jamais le CDP écraser les événements source avec le résultat fusionné. C'est la chose la plus coûteuse à rattraper après coup.
• Le traitement du guest checkout. Les retailers constatent régulièrement qu'une part importante des commandes sont passées sans compte. Décidez si l'email d'une commande crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée un profil, et si ce profil peut être sollicité en marketing avant qu'un consentement existe (en général non).

Deux cas limites à nommer dans le document : l'email de foyer partagé, fréquent dans l'alimentaire et les comptes familiaux, où un profil cache deux acheteurs très différents ; et les boîtes partagées B2B (orders@, accounts@), qui doivent être exclues de la résolution au niveau personne et rattachées à un compte.

Quand vous avez besoin que l'identité dépasse vos propres propriétés, c'est un autre outil. LiveRamp, qui vend de la résolution d'identité et de la data collaboration, résout des PII offline vers un RampID pseudonyme pour que vous puissiez matcher vos clients avec ceux d'un partenaire ou d'un éditeur sans échanger d'emails. Utile pour la mesure et le travail en clean room, et ce n'est pas un substitut à votre graphe interne.

Framework 2 : le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → que vous spécifiez

Tous les CDP veulent les mêmes formes : qui est la personne, ce qu'elle a fait, où elle l'a fait, et à quel compte elle appartient. La spec de Segment formalise cela en appels identify, track, page et screen, et group, et la plupart des plateformes concurrentes se calquent sur la même structure. Votre travail est de la remplir avec votre métier, par écrit, avant l'implémentation.

Des règles qui tiennent :

• Nommez les événements objet puis action, au passé : Order Completed, Product Added, Subscription Cancelled. Les conventions mélangées produisent trois événements pour le même comportement et des segmentssegmentsDécouper un marché en groupes distincts de clients partageant des besoins, des caractéristiques ou des comportements similaires, afin de traiter chaque groupe avec une approche dédiée.Voir la définition complète → qui sous-comptent en silence.
• Plafonnez la liste. La plupart des activités retail ou par abonnement ont besoin de 25 à 50 événements, pas des 300 qu'une équipe analytics enthousiaste proposera. Chaque événement supplémentaire est une chose à instrumenter, tester, versionner et payer.
• Stockez les faits bruts comme événements, dérivez les traits en aval. Gardez les achats comme des achats ; calculez la lifetime valuelifetime valueLifetime Value : le revenu total (ou le profit) qu'un client génère sur toute la durée de sa relation avec votre entreprise.Voir la définition complète →, la propension et le tier à partir d'eux. Les équipes qui écrivent des segments calculés directement dans les traits de profil perdent la capacité de recalculer l'historique quand la formule change, et la formule change toujours.
• Versionnez le schéma et bloquez les violations à l'entrée. Un tracking plan qui rejette les événements malformés vaut plus qu'un dashboard qui les signale après coup.
• Réservez sur chaque événement des champs pour la finalité de consentement, le système source et le timestamp de capture. Rattraper la provenance sur deux ans d'événements n'est pas réaliste.

Le mode de défaillance : le schemaschemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète → drift. Une release mobile renomme une propriété, personne ne le remarque pendant cinq semaines, et l'audience panier abandonné se vide en silence. Mettez un contrôle de volume hebdomadaire sur vos dix principaux événements et alertez sur les écarts.

Framework 3 : le modèle de consentement

Le consentement n'est pas un booléen sur le profil. C'est un ensemble de finalités, chacune avec son propre état, et il fait partie du schéma dès le premier jour. L'application du RGPD a désormais produit bien plus de cinq milliards d'euros d'amendes cumulées depuis 2018, et le risque opérationnel est plus proche de vous : une suppression qui ne se propage pas.

Spécifiez au minimum ces finalités séparément : messagerie transactionnelle, email et SMS marketing, personnalisation on-site, et partage avec les plateformes publicitaires. Un client peut accepter les deux premières et refuser la dernière, et votre couche d'activation doit respecter cela destination par destination.

Pour chaque enregistrement de consentement, stockez la finalité, le timestamp, le point de capture, la juridiction et la version du texte d'information que le client a vu. Sans la version de l'information, vous ne pouvez pas prouver ce qui a été accepté.

Définissez ensuite la propagation. Quand quelqu'un se retire, quel est le délai maximum avant que la suppression atteigne votre outil email, votre moteur de personnalisation et vos plateformes publicitaires ? Mettez un chiffre dessus, en heures, et testez-le chaque trimestre avec une fiche témoin.

Le cas limite qui piège : les audiences déjà poussées en sortie. Une fois que des emails hashés se trouvent dans une custom audience d'un walled garden ou chez un onboarder, ils se rafraîchissent au rythme de cette plateforme, pas au vôtre. Vos leviers sont une liste de suppression, une instruction de suppression et une clause contractuelle qui oblige le partenaire à l'exécuter. Rédigez la clause avant de signer, pas après la réclamation.

La juridiction ajoute une seconde dimension. L'UE veut le consentement avant que des identifiants non essentiels soient posés ; plusieurs États américains fonctionnent en opt-out, avec des signaux Global Privacy Control à honorer. La même personne peut porter des flags différents selon les régions, et votre ruleset doit dire lequel s'applique quand un profil a des adresses dans les deux.

Le budget de latence

Raisonnez à rebours depuis le cas d'usage plutôt que d'acheter du temps réel partout.

Prenez l'abandon de panier. La fenêtre comportementale est courte, donc la chaîne capture d'événement, mise à jour du profil, appartenance au segment et envoi du message doit se boucler en 30 à 90 minutes environ. Mesurez maintenant votre chaîne réelle. Si le recalcul des profils tourne toutes les heures et que la plateforme email se synchronise toutes les quatre heures, vous êtes hors fenêtre et aucune ingestion en streaming n'y changera rien, parce que le goulot est en aval.

Comparez avec une campagne de win-back pour des clients dormants depuis 120 jours. Un batch nocturne suffit. Payer des tarifs streaming pour ça, c'est du gaspillage.

Conséquence de second ordre : le temps réel multiplie le coût et la surface de défaillance. Les CDP se facturent au monthly tracked users ou au volume d'événements, donc pousser chaque interaction dans le chemin streaming gonfle à la fois la facture et le nombre d'endroits où un mauvais déploiement peut corrompre les profils. Choisissez les deux ou trois parcours qui ont réellement besoin de mises à jour en moins d'une minute et passez le reste en batch.

Un piège d'ordonnancement : si une fusion arrive après le déclenchement du message, le client reçoit la version visiteur anonyme d'un email que vous vouliez personnaliser. Décidez si vos déclencheurs attendent la résolution d'identité ou tournent sur le profil pré-fusion.

Cas réels

Nike montre ce que le ruleset vous achète. Nike Direct représentait environ un quart du chiffre d'affaires en FY2017 ; en FY2022 il atteignait 18,7 milliards de dollars, soit environ 44 % du total. Le mécanisme pertinent ici est l'accès aux lancements SNKRS : décider quels membres voient une sortie limitée exige un profil qui joint comportement in-app, activité d'entraînement et historique d'achat à une seule personne authentifiée, avec assez de confiance pour refuser tous les autres. Cette décision ne vaut que ce que valent les règles de matching en dessous. Nike a depuis reconstruit ses relations wholesale, et le moteur de first-party datafirst-party dataDonnées collectées directement auprès de vos clients et prospects via vos propres canaux : votre source la plus fiable et la plus conforme en matière de privacy.Voir la définition complète → est resté.

Starbucks montre le côté schéma. Rewards dépasse les 30 millions de membres actifs aux États-Unis, et le profil joint commandes mobiles, passages de carte en magasin, engagement dans l'app et signaux contextuels comme l'heure de la journée et la météo. Ce qui fait fonctionner les offres personnalisées n'est pas le volume : c'est que une transaction en magasin et une commande dans l'app se résolvent vers le même membre via un identifiant de fidélité déterministe au point de vente. Retirez cet identifiant et les mêmes données deviennent deux moitiés déconnectées.

Actions pour le CMO

• Rédigez le ruleset d'identité sous forme de tableau d'une page (clés, priorité, seuil de confiance, politique de démerge) et faites annoter votre tableau par chaque éditeur pendant la démo. Ceux qui n'y arrivent pas vous disent quelque chose.
• Choisissez cinq définitions d'audience avec un lien direct au revenu, puis remontez chacune jusqu'aux événements et identifiants précis qu'elle exige. Tout segment qui dépend de données que vous ne collectez pas est un projet de collecte, pas un projet CDP.
• Fixez un SLA de qualité de données avec l'engineering : taux de match contre les clients connus, obsolescence de profil acceptable par parcours, et ce qu'il advient d'un événement qui échoue à la résolution d'identité. Des chiffres dans un contrat, pas dans un slide.
• Créez une fiche de test et exécutez une demande de suppression complète de bout en bout, avant le go-live puis chaque trimestre.

Erreurs courantes qui tuent les résultats

Hériter du modèle de données de l'éditeur. Les règles de matching par défaut sont réglées pour la couverture en démo, pas pour votre structure de foyers ni pour votre taux de guest checkout. Si vous ne remettez pas de spec, vous adoptez la leur par défaut de silence.

Fusionner sans chemin de démerge. Écraser les événements source avec le profil fusionné paraît propre et transforme chaque correction future en projet data manuel. Gardez les événements bruts immuables et traitez le graphe comme dérivé.

Le consentement ajouté après coup. Dès lors que des profils existent sans flags de finalité ni versions d'information, vous choisissez entre un backfill que vous ne pouvez pas documenter et une liste de suppression qui grossit indéfiniment.

Ignorer la décroissance. Les listes email se périment à raison d'environ un cinquième des fiches par an, et les signaux d'intention vieillissent en quelques jours dans certaines catégories. Budgétez l'hygiène, la re-permission et le rafraîchissement, sinon votre personnalisation parlera au client qu'il était il y a 18 mois.

À retenir

• Apportez trois livrables écrits à la conversation avec l'éditeur : ruleset d'identité, schéma d'événements, modèle de consentement. La démo est un test de votre spec, pas de leurs slides.
• Déterministe d'abord, probabiliste uniquement là où vous pouvez mesurer l'erreur contre un holdout de clients connus. Les fausses fusions silencieuses coûtent plus cher que les matchs manqués.
• Plafonnez les identifiants par profil et gardez les événements source immuables, pour qu'une mauvaise fusion reste réversible.
• Nommez les événements objet-action au passé, limitez la liste à quelques dizaines, et dérivez les traits des faits bruts pour pouvoir recalculer quand la formule change.
• Modélisez le consentement comme des finalités avec timestamps, juridiction et version de l'information, et posez un SLA en heures sur la propagation de la suppression vers chaque destination en aval.
• Fixez le budget de latence par parcours. L'abandon de panier a besoin de minutes ; un win-back à 120 jours non, et tout passer en streaming gonfle la facture et la surface de défaillance.