Un modèle Customer 360 unifie les coordonnées de contact CRM, l’historique des deals, le comportement de navigation web et l’utilisation du produit en une seule ligne par personne. Le défi technique central est l’identité : les systèmes CRM et d’analytique web ne partagent aucune clé commune, donc les connecter nécessite de construire un pont d’identité dans le warehouse. Ce hub connecte les concepts impliqués dans la construction d’un Customer 360 à partir de données CRM (Salesforce, HubSpot) et GA4 dans BigQuery avec dbt.
La séquence
1. Résoudre les identités entre systèmes
Résolution d’identité pour le Customer 360 couvre le problème central : GA4 suit les appareils avec des valeurs user_pseudo_id basées sur des cookies, tandis que le CRM suit les personnes avec des emails et des IDs internes. La note parcourt les trois stratégies pour créer des clés de jointure (champs de formulaire cachés, user_id basé sur la connexion, correspondance d’ID de transaction), les compromis entre matching déterministe et probabiliste, la construction de la table de mapping d’identité dans dbt, et les outils open source pour des graphes d’identité plus complexes.
2. Rattacher la navigation anonyme aux utilisateurs connus
Backstitching des utilisateurs GA4 adresse le fossé entre la navigation anonyme et l’authentification. GA4 applique user_id à la session courante mais pas aux précédentes. Le backstitching lie rétrospectivement les sessions pré-connexion à la personne qui s’est finalement connectée, récupérant le parcours de découverte complet pour l’attribution et l’analyse Customer 360. Inclut le pattern SQL, la gestion des appareils partagés, et les conseils de matérialisation.
3. Gérer les données conflictuelles entre sources
Résolution des conflits multi-sources couvre ce qui se passe quand le CRM dit une chose et la base de données produit en dit une autre. Trois patterns — basé sur la priorité (COALESCE), basé sur la récence (la mise à jour la plus récente l’emporte), et champs spécifiques à la source (tout garder) — gèrent la majorité des cas. Inclut des recommandations de stratégie par champ et une approche hybride pragmatique.
4. Structurer le DAG dbt
Architecture DAG dbt pour le Customer 360 montre comment assembler les pièces dans dbt. L’architecture standard en trois couches gagne une couche de résolution d’identité entre les modèles base et mart. La note couvre la structure DAG complète, les choix de matérialisation modèle par modèle, la table Customer 360 large, et la connexion des points de contact aux revenus via le pont d’identité.
5. Se conformer aux exigences de confidentialité
Contraintes de confidentialité pour les données analytiques liées adresse les implications RGPD et CNIL que la plupart des guides Customer 360 ignorent. Lier un identifiant cookie à un contact CRM crée une activité de traitement avec des exigences de consentement spécifiques. Pour les équipes soumises à la CNIL, l’exemption de consentement pour le cookie analytique disparaît dès lors qu’on le lie aux données CRM. La note couvre la chaîne de consentement, la cascade du droit à l’effacement, les limites de conservation des données, et les patterns architecturaux pour séparer les chemins de données avec et sans consentement.
Connexions
- Analyse d’attribution — La résolution d’identité liant les sessions web aux deals CRM permet des chronologies de points de contact et des modèles d’attribution
- Hub de sessionisation GA4 — Les événements sessionisés alimentent le résumé d’analytique web dans le Customer 360
- Hub Consent Mode v2 — L’implémentation du consentement qui détermine quels événements GA4 portent le consentement pour le lien CRM
En lien
- unifier-crm-ga4-modeles-customer-360 — Article source : récit complet sur la résolution d’identité, le DAG dbt, la gestion des conflits, l’intégration de l’attribution, les exigences de confidentialité et les choix de matérialisation.