Analyse des Données

Quelle architecture de tagging mettre en place pour relier analytics, crm et attribution sans perdre de données?

Quelle architecture de tagging mettre en place pour relier analytics, crm et attribution sans perdre de données?

Relier vos outils d'analytics, votre CRM et vos systèmes d'attribution sans perdre de données, c’est un défi technique mais surtout organisationnel. Dans cet article, je vous partage une architecture de tagging que j’ai mise en place pour plusieurs clients et qui marche : simple dans ses principes, robuste dans l’exécution. Je décris les composantes clés, les choix techniques, les pièges à éviter et des exemples concrets pour que vous puissiez l’adapter à votre contexte.

Pourquoi établir une architecture de tagging unifiée ?

Je ne compte plus les cas où les équipes marketing se retrouvent avec des chiffres divergents entre Google Analytics, le CRM (Salesforce, HubSpot...) et la plateforme d’attribution. Souvent, la cause est une absence de standardisation des événements, des paramètres UTM mal gérés, ou des identifiants utilisateurs non propagés. Une architecture de tagging unifiée permet de :

  • Garantir la continuité du suivi utilisateur entre devices et sessions.
  • Propager un identifiant commun (user_id / client_id) vers tous les systèmes.
  • Maintenir une taxonomie d’événements et de propriétés cohérente.
  • Faciliter les analyses multi-sources et l'attribution cross-channel.
  • Les 4 piliers de l’architecture

    Je structure toujours mes designs autour de quatre éléments clés :

  • Un schéma d’événements centralisé (event taxonomy).
  • Un identifiant unique et persistent (ID maître).
  • Une couche de collecte flexible (client-side + server-side).
  • Un mapping et une synchronisation vers les destinations (CRM, analytics, attribution, data lake).
  • Schéma d’événements : la taxonomie au cœur du système

    Avant de commencer à taguer, définissez une event taxonomy claire. Pour chaque événement, listez :

  • event_name (ex. product_view, add_to_cart, lead_submitted)
  • event_properties (ex. product_id, category, price, currency)
  • context_properties (ex. page_location, referrer, campaign_source)
  • user_properties (ex. user_id, email_hashed, lifetime_value)
  • Voici un petit modèle que j’utilise et que j’expose aux équipes produit et marketing :

    ChampsExempleCommentaires
    event_namelead_submittedNom standardisé, pas de variantes
    user_id12345ID interne persisté après login
    client_idGA1234567890Cookie / client id pour sessions non authentifiées
    utm_sourcegoogleUTM normalisés via URL Builder
    campaign_idcpa_spring23ID centralisé pour attribution

    Identifiant maître : comment l’obtenir et le propager

    Le choix de l’ID maître est crucial. Je recommande de :

  • Utiliser l’ID CRM (ex. contact_id) comme référence quand l’utilisateur est connu.
  • Maintenir un client_id (cookie ou équivalent mobile) pour les visiteurs anonymes.
  • Mapper client_id ↔ user_id dès que l’utilisateur s’authentifie, et pousser ce mapping à toutes les destinations.
  • Concrètement, lors d’un login ou d’un enregistrement, vous devez : stocker le user_id côté front, mettre à jour la cookie client_id, et envoyer un événement “identify” vers votre CDP (ex. Segment, RudderStack) qui va propager l’association vers Analytics, CRM, et l’outil d’attribution.

    Collecte : client-side + server-side (le duo gagnant)

    Le tracking uniquement côté client (GTM, pixels) est pratique mais fragile : bloqueurs, perte de cookies, latence. Pour réduire les pertes de données, je préconise une approche hybride :

  • Client-side : couche dataLayer (GTM) bien remplie pour interactions UI en temps réel.
  • Server-side : endpoint de collecte (ex. server-side GTM, API collector) qui reçoit les événements importants et peut enrichir les données (user_id, segmentation, données back-office).
  • Exemple de flux : un formulaire lead est rempli → le front envoie un événement à votre serveur (via fetch) → le serveur créé/associe le contact dans le CRM et renvoie le user_id → le serveur publie l’événement vers GA4 (measurement protocol), l’attribution tool et le data lake. Ainsi vous évitez les pertes liées aux bloqueurs et vous garantissez la cohérence CRM ↔ Analytics.

    Consents et règles de confidentialité

    Ne négligez pas la couche consent. J’ai vu des entreprises perdre des mois de données car leur CMP n’était pas intégrée à la couche de tagging. Assurez-vous que :

  • Le consentement utilisateur est centralisé (CMP) et accessible par la dataLayer.
  • Les destinataires (analytics, attribution, CRM) respectent les règles de consent (opt-in/out).
  • Un fallback server-side envoi des events anonymisés si nécessaire (hash des emails, suppression des PII).
  • Mapping vers les destinations : règles et transformations

    Chaque plateforme a ses propres noms de champs et limitations. Définissez un mapping central (document partagé) qui transforme la taxonomy interne vers :

  • Google Analytics / GA4
  • CRM (Salesforce / HubSpot)
  • Attribution (e.g. Adjust, AppsFlyer, Branch, ou solution SaaS d’attribution marketing)
  • Data Warehouse (BigQuery / Snowflake)
  • Exemple : vous pouvez choisir que event_name product_view en internal devienne view_item en GA4, et productViewed dans le CRM. Mais maintenez la correspondance dans un fichier JSON central pour éviter les confusions.

    Architecture technique — template détaillé

    Voici une architecture que je déploie souvent :

  • Front-end : dataLayer + GTM (web) / SDKs (mobile)
  • Edge / Server-side : Server-Side GTM / collector API → enrichissement (user_id, CRM lookup)
  • CDP / Event Router : Segment / RudderStack → routing vers Analytics, CRM, Attribution, Data Warehouse
  • Data Warehouse : BigQuery / Snowflake pour analyses et réconciliation
  • Ce flow permet un routage unique des événements et une réconciliation automatisée via le data lake.

    Tests, QA et monitoring

    Pour éviter les mauvaises surprises, mettez en place :

  • Playbooks de tests (navigations, conversions, erreurs réseau)
  • Un tableau de bord de qualité des données (par ex. volume d’événements, taux d’identification, latence)
  • Alertes en cas de chute de données (ex. diminution de 20% des events product_view)
  • J’utilise des snapshots quotidiens dans BigQuery pour comparer les volumes front vs serveur et détecter les pertes. Un autre incontournable : des tests automatisés qui simulent des parcours (Selenium + hits comparés entre front et server).

    Cas pratique : de la campagne UTM à l’enregistrement CRM

    Imaginons une campagne paid sur Google Ads :

  • Les URLs sont taguées via un gestionnaire d’UTM centralisé (campagne_id unique).
  • Un visiteur arrive, client_id est généré; la dataLayer collecte utm_* et campaign_id.
  • Lors de la conversion (lead), le front envoie l’événement au serveur qui créera ou mettra à jour le contact dans le CRM avec campaign_id.
  • Le CRM stocke la source d’acquisition et renvoie un user_id qui sera propagé vers GA4 et l’outil d’attribution via le CDP.
  • Résultat : vous pouvez faire de l’attribution last-click/first-click/multi-touch en ayant un mapping précis campagne_id ↔ contact.
  • Bonnes pratiques récapitulatives

  • Standardisez la taxonomy avant d’implémenter.
  • Choisissez un ID maître et gérez la jonction client_id ↔ user_id.
  • Utilisez server-side tracking pour réduire les pertes.
  • Centralisez le mapping et documentez chaque transformation.
  • Intégrez le consent dans la couche de données.
  • Automatisez les tests et surveillez les volumes.
  • Si vous le souhaitez, je peux vous fournir un modèle JSON de taxonomy, un template de dataLayer, ou un plan de déploiement pas-à-pas pour votre stack (GA4 + GTM + Salesforce + BigQuery par exemple). Dites-moi quelles plateformes vous utilisez et j’adapte le guide.

    Vous devriez également consulter les actualités suivante :

    Comment mesurer l'impact réel d'un test d'incrémentalité sur votre revenu publicitaire?
    Publicité en Ligne

    Comment mesurer l'impact réel d'un test d'incrémentalité sur votre revenu publicitaire?

    Lorsqu'on lance un test d'incrémentalité pour mesurer l'impact d'une campagne publicitaire sur le...

    Comment construire un playbook tiktok shopping qui multiplie les ventes des produits à moins de 50€?
    E-commerce

    Comment construire un playbook tiktok shopping qui multiplie les ventes des produits à moins de 50€?

    Si vous vendez des produits à moins de 50€, TikTok Shopping peut devenir l'un de vos leviers les...