Nommage des campagnes et standardisation des UTM

Les noms de campagnes sont une source principale d’erreurs humaines dans le reporting cross-plateforme. Sans nommage cohérent, il n’existe aucun moyen fiable de regrouper les campagnes entre plateformes pour les comparer. La résolution nécessite l’adhésion de l’équipe media buying, pas seulement de l’équipe data.

Les trois approches (utilisez les trois)

En pratique, la plupart des équipes finissent par utiliser ces trois approches simultanément : les conventions pour les nouvelles campagnes, le regex pour la majorité des campagnes existantes, et les surcharges seed pour les exceptions.

1. Imposer des conventions de nommage à la création

L’approche la plus fiable. Définissez une convention qui incorpore les métadonnées dans les noms de campagnes :

{plateforme}_{objectif}_{audience}_{geo}_{date}

Exemples :

• google_conversions_retargeting_us_202603
• meta_awareness_lookalike_uk_202603
• linkedin_leads_decision-makers_global_202603

La convention doit être :

• Documentée dans un endroit que l’équipe media buying consulte réellement (pas enfouie dans un wiki)
• Appliquée via des modèles de nommage au niveau de la plateforme quand c’est possible
• Validée par l’équipe data via des vérifications automatisées sur les nouveaux noms de campagnes

Cela nécessite l’adhésion de l’équipe media buying. Si elle ne respecte pas la convention, l’équipe data ne peut pas analyser ce qu’elle ne peut pas parser. Faites valoir que le nommage cohérent est ce qui permet les insights cross-plateforme qu’ils demandent.

2. Parser les noms de campagnes avec du regex dans dbt

Lorsque les conventions sont globalement respectées mais pas parfaitement — ce qui est la réalité pour la plupart des équipes — le parsing regex extrait la structure des noms semi-structurés.

SELECT
  campaign__name,
  REGEXP_EXTRACT(campaign__name, r'^([a-z]+)_') AS campaign__parsed_platform,
  REGEXP_EXTRACT(campaign__name, r'_([a-z]+)_[a-z]+_') AS campaign__parsed_objective,
  REGEXP_EXTRACT(campaign__name, r'_([a-z]+)_\d{6}$') AS campaign__parsed_geo,
  REGEXP_EXTRACT(campaign__name, r'_(\d{6})$') AS campaign__parsed_date
FROM {{ ref('int__google_ads__campaign_report') }}

Cela fonctionne bien pour les campagnes qui suivent la convention et produit des NULL pour celles qui ne le font pas. Les NULL sont un signal — ils identifient les campagnes qui nécessitent un mapping manuel.

Quelques conseils pour le parsing regex :

• Mettez toujours en minuscules d’abord avant de parser, car les noms de campagnes peuvent avoir une casse incohérente
• Testez sur un échantillon de vrais noms de campagnes avant de déployer — les cas limites sont garantis
• Journalisez le taux d’échec du parsing pour savoir combien de campagnes passent aux surcharges seed

3. Table de mapping via fichier seed

Pour les campagnes qui ne suivent aucune convention — campagnes legacy, campagnes créées par des partenaires, campagnes d’agences qui utilisent leur propre nommage — un fichier seed dbt fournit des surcharges explicites.

platform,original_campaign_name,standardized_objective,standardized_audience,standardized_geo
google_ads,Brand - Summer 2025 [Exact],conversions,brand,us
facebook_ads,FB_Retargeting_old_format,conversions,retargeting,us
linkedin_ads,LI ABM Campaign - Enterprise,leads,enterprise,global

Référencez le seed dans votre modèle intermédiaire :

WITH campaign_base AS (
  SELECT
    campaign__id,
    campaign__name,
    REGEXP_EXTRACT(campaign__name, r'^([a-z]+)_') AS campaign__parsed_objective
  FROM {{ ref('int__google_ads__campaign_report') }}
),

overrides AS (
  SELECT * FROM {{ ref('campaign_name_overrides') }}
  WHERE platform = 'google_ads'
)

SELECT
  cb.campaign__id,
  cb.campaign__name,
  COALESCE(o.standardized_objective, cb.campaign__parsed_objective) AS campaign__objective,
  COALESCE(o.standardized_audience, NULL) AS campaign__audience,
  COALESCE(o.standardized_geo, NULL) AS campaign__geo
FROM campaign_base cb
LEFT JOIN overrides o
  ON cb.campaign__name = o.original_campaign_name

Le pattern COALESCE signifie : utilisez la surcharge si elle existe, sinon revenez à la valeur parsée par regex. Cette approche en couches gère le spectre complet des campagnes parfaitement nommées au chaos de nommage total.

Hygiène des paramètres UTM

Les paramètres UTM sont le pont cross-plateforme entre les dépenses publicitaires et les conversions en analytique web. Les paramètres utm_source, utm_medium et utm_campaign vous permettent de joindre les données de dépenses des plateformes publicitaires avec les données de session GA4, créant un modèle d’attribution indépendant des conversions auto-déclarées de chaque plateforme.

Règles critiques pour les UTM

Toujours en minuscules. Les UTM sont sensibles à la casse dans GA4. utm_source=Facebook et utm_source=facebook créent deux sources distinctes. Imposez les minuscules au niveau de la plateforme publicitaire et ajoutez un LOWER() dans vos modèles dbt comme filet de sécurité.

Utilisez des tirets, pas des espaces. Les espaces dans les URLs sont encodés en %20, ce qui est laid dans les rapports et crée des problèmes de matching. Utilisez des tirets ou des underscores de manière cohérente.

Maintenez un nommage cohérent des plateformes. Décidez une fois si vous utilisez “facebook”, “fb” ou “meta” comme valeur utm_source, et tenez-vous-y partout. Documentez les valeurs canoniques et faites-les respecter.

Utilisez des paramètres dynamiques quand c’est disponible. Google prend en charge {campaignid}, {adgroupid} et {creative} comme valeurs UTM dynamiques qui se remplissent automatiquement avec les IDs réels. Cela élimine les erreurs humaines pour les paramètres UTM les plus granulaires :

utm_source=google&utm_medium=cpc&utm_campaign={campaignid}&utm_content={adgroupid}&utm_term={keyword}

Meta prend en charge des paramètres dynamiques similaires : {{campaign.name}}, {{adset.name}}, {{ad.name}}. LinkedIn prend en charge {campaign_id} et {creative_id}. Utilisez-les partout où c’est possible — ils sont plus fiables que les valeurs saisies manuellement.

Les UTM comme clé d’attribution

Le modèle ad_reporting__url_report de Fivetran inclut nativement le suivi des paramètres UTM. Le dbt Labs Attribution Playbook utilise des sessions web jointes sur les paramètres UTM comme clé entre les dépenses publicitaires et les conversions pour les modèles d’attribution positionnels.

Le pattern de jointure :

-- Joindre les dépenses publicitaires avec les sessions GA4 via les paramètres UTM
SELECT
  ga4.date_day,
  ga4.utm_source,
  ga4.utm_medium,
  ga4.utm_campaign,
  SUM(ga4.sessions) AS sessions,
  SUM(ga4.conversions) AS web_conversions,
  SUM(ads.spend) AS ad_spend
FROM {{ ref('int__ga4__sessions') }} ga4
LEFT JOIN {{ ref('mrt__marketing__campaign_report') }} ads
  ON ga4.date_day = ads.date_day
  AND LOWER(ga4.utm_source) = ads.utm_source
  AND LOWER(ga4.utm_campaign) = ads.utm_campaign
GROUP BY 1, 2, 3, 4

Cela vous donne un modèle d’attribution indépendant de ce que chaque plateforme prétend avoir généré. Les paramètres UTM relient le clic publicitaire à la session web jusqu’à la conversion, en utilisant une méthodologie cohérente sur tous les canaux.

Pourquoi c’est important pour le reporting cross-plateforme

Sans noms de campagnes standardisés, un modèle unifié peut indiquer combien chaque plateforme a dépensé mais pas combien a été dépensé en retargeting sur toutes les plateformes. Sans paramètres UTM propres, les données de dépenses publicitaires ne peuvent pas être jointes aux analytiques web pour calculer le ROAS.

Le nommage des campagnes et l’hygiène UTM sont le prérequis pour la comparaison cross-plateforme. Le travail de modélisation technique — l’UNION, la normalisation des métriques, la couche intermédiaire — suppose que les campagnes peuvent être regroupées de manière significative et que les paramètres UTM peuvent être joints de manière fiable.