Sources de données pour l'attribution en entrepôt

L’attribution en entrepôt nécessite trois catégories de données : les interactions web, les dépenses des plateformes publicitaires et les conversions. Un modèle de Markov sophistiqué appliqué à des données de touchpoints incomplètes produit de moins bons résultats qu’un modèle last-touch simple appliqué à des données propres et complètes. Les trois catégories doivent être en place pour construire n’importe quel modèle d’attribution avec une visibilité complète cross-plateforme.

Données d’interactions web

L’export BigQuery de GA4 est la source la plus courante de données d’interactions web pour les équipes qui construisent l’attribution dans BigQuery. Il fournit des données au niveau événement dans des tables events_YYYYMMDD avec les champs dont les modèles d’attribution ont besoin : user_pseudo_id (identifiant d’appareil), user_id optionnel (authentifié) et les informations de source de trafic.

Les champs de source de trafic ont évolué au fil du temps. Le struct traffic_source original capture la toute première source de trafic de l’utilisateur. Pour l’attribution, on veut généralement les données de source de trafic au niveau session, provenant soit de collected_traffic_source, soit du champ plus récent session_traffic_source_last_click. Voir GA4 Traffic Source Fields pour la décomposition complète du champ à utiliser selon le contexte.

Le bug de mauvaise attribution des gclid GA4

Un bug connu dans GA4 fait que les paramètres gclid attribuent parfois des clics sur la recherche payante comme du trafic organique. Le gclid est présent dans les paramètres URL, confirmant que l’utilisateur est arrivé via un clic Google Ads, mais GA4 enregistre la source/medium comme organique.

Cela affecte l’attribution en transférant le crédit de la recherche payante vers la recherche organique — sous-estimant le ROI de la recherche payante et surestimant la contribution de l’organique. La correction est simple : dans le modèle base, vérifier la présence du gclid dans les paramètres d’URL de la page et corriger la source/medium lorsqu’il est trouvé :

CASE
  WHEN page_location LIKE '%gclid=%' AND source = 'google' AND medium = 'organic'
  THEN 'cpc'
  ELSE medium
END AS medium_corrected

Il s’agit d’un pattern défensif — l’appliquer même si le bug n’a pas encore été observé, car il peut apparaître de façon intermittente et corrompre silencieusement les données d’attribution.

Données des plateformes publicitaires

Les données de campagne et de coût sont nécessaires pour chaque plateforme sur laquelle des dépenses sont engagées. Sans données de dépenses, il est possible de calculer le chiffre d’affaires attribué par canal mais pas le ROAS — or le ROAS est ce qui détermine en définitive les décisions d’allocation budgétaire.

Le paysage du chargement varie selon la plateforme :

Le Google Ads Data Transfer Service est la voie la plus simple pour les données Google Ads — il est gratuit, natif et écrit directement dans BigQuery. Pour les autres plateformes, le choix se fait entre ETL managé (Fivetran, Airbyte) et des outils code-first comme dlt.

Le choix entre ETL managé et code-first dépend de la capacité d’ingénierie de l’équipe et de la tolérance à la dépendance aux fournisseurs. Pour une analyse complète, voir la discussion plus large sur l’intégration des données publicitaires dans l’entrepôt.

Stratégies de jointure entre données publicitaires et analytics web

La connexion des données de dépenses des plateformes publicitaires aux sessions web nécessite une clé de jointure fiable. Deux approches :

La correspondance par Click ID utilise des identifiants spécifiques à chaque plateforme (gclid pour Google, fbclid pour Meta, ttclid pour TikTok) qui sont ajoutés aux URL de landing page. Cela fournit une correspondance précise au niveau du clic entre l’événement de la plateforme publicitaire et la session web. L’inconvénient : cela ne fonctionne que pour les clics, pas les impressions, et le click ID doit survivre intact à la chaîne de redirections.

La correspondance par paramètres UTM utilise utm_source, utm_medium et utm_campaign pour joindre au niveau session ou campagne. C’est moins précis que les click IDs mais fonctionne sur toutes les plateformes et ne dépend pas d’identifiants spécifiques à chaque plateforme. Voir Campaign Naming and UTM Standardization pour les règles d’hygiène qui rendent les jointures basées sur les UTM fiables.

En pratique, utiliser les deux. Les click IDs pour la correspondance précise des canaux payants quand ils sont disponibles, les paramètres UTM comme solution de repli et comme couche de normalisation cross-plateforme.

Standardisation des paramètres UTM

Les paramètres UTM sont le pont cross-plateforme entre les dépenses publicitaires et les analytics web. Ils doivent être standardisés sinon la couche de jointure s’effondre :

• Toujours en minuscules. Les UTM sont sensibles à la casse dans GA4. utm_source=Facebook et utm_source=facebook créent deux sources distinctes.
• Nommage cohérent des plateformes. Décider une fois pour toutes si l’on utilise “facebook” ou “meta” comme valeur de utm_source, et s’y tenir partout.
• Paramètres dynamiques là où c’est disponible. Google prend en charge {campaignid} et {adgroupid} comme valeurs UTM auto-renseignées. Meta prend en charge {{campaign.name}} et {{adset.name}}. Les utiliser pour éliminer les erreurs humaines dans les paramètres les plus granulaires.
• Inclure les click IDs des plateformes. Ajouter gclid, fbclid, etc. aux côtés des paramètres UTM pour avoir les deux stratégies de jointure disponibles.

Documenter la taxonomie UTM à un endroit que l’équipe d’achat média consulte réellement. Si elle ne respecte pas les conventions, l’équipe data ne peut pas construire des jointures fiables, et l’attribution cross-plateforme se brise au niveau de la couche données.

Données de conversion

Les conversions peuvent provenir de la plateforme e-commerce, du CRM, de la base de données applicative, ou d’une combinaison. L’exigence clé : avoir un moyen de relier les conversions aux touchpoints marketing qui les ont précédées.

Pour l’e-commerce, l’événement purchase dans GA4 porte généralement un transaction_id qui renvoie au système de gestion des commandes. Cela crée une boucle fermée : les touchpoints GA4 se joignent aux conversions GA4 via user_pseudo_id, et les conversions GA4 se joignent aux données de chiffre d’affaires via transaction_id.

Pour le B2B, les conversions sont souvent des événements CRM — création d’opportunités, deals clôturés-gagnés — qui n’ont pas de lien direct avec les données analytics web. La jointure nécessite une résolution d’identité : relier l’user_pseudo_id anonyme de GA4 au contact connu dans le CRM. C’est plus difficile que le tracking de conversion e-commerce et constitue souvent le goulot d’étranglement pour la précision de l’attribution B2B.

Pour le SaaS, les conversions peuvent être des inscriptions, des débuts d’essai ou des paiements d’abonnement. Si le produit capture l’email de l’utilisateur à l’inscription et le transmet à GA4 comme user_id, il existe un lien direct. Sinon, on revient à la résolution d’identité.

Ce qui compte comme conversion

C’est une décision métier, pas technique. Choix courants :

• E-commerce : événement d’achat (avec chiffre d’affaires)
• B2B SaaS : demande de démo, début d’essai, abonnement payant
• Lead gen : soumission de formulaire, lead qualifié (MQL)
• Contenu/médias : inscription à la newsletter, téléchargement de contenu

Choisir des conversions suffisamment significatives pour fonder des décisions budgétaires, mais suffisamment fréquentes pour produire des données d’attribution statistiquement utiles. Si la conversion choisie ne survient que 10 fois par mois, les données ne seront pas assez nombreuses pour que les modèles multi-touch soient fiables.

Assembler le tout

Ces trois sources de données alimentent la table de touchpoints, qui est le modèle intermédiaire unique que tous les modèles d’attribution consomment. La table de touchpoints joint les interactions web (touchpoints) aux conversions dans une fenêtre de rétrospective, produisant une ligne par paire touchpoint-conversion.

La qualité de chaque modèle d’attribution, classement de canaux et calcul de ROAS en aval dépend de la qualité de ces trois jeux de données sources.