Meridian MMM : préparer vos données GA4 et BigQuery (guide 2026)

Tout le monde parle de Meridian, le MMM open source de Google, et pourtant tous les tutoriels s’arrêtent au même endroit : le modèle bayésien, un pip install, et un notebook d’exemple qui tourne sur des données déjà propres. Personne n’écrit la seule partie qui bloque vraiment sur le terrain : transformer votre export GA4 BigQuery, événementiel et journalier, en la table hebdomadaire par géo et par canal que Meridian attend en entrée. C’est là que 90 % des projets MMM calent, et c’est exactement ce que ce guide résout, requête SQL comprise.

Si vous cherchez une définition du marketing mix modeling, vous êtes au mauvais endroit. Ici on part du principe que la décision est prise (par vous ou par votre direction), que l’export GA4 vers BigQuery tourne déjà, et que la vraie question est : quelles colonnes, quelle maille, et d’où viennent les coûts média. On va donc droit au format de table et au SQL qui le produit.

Pourquoi le MMM revient (et pourquoi maintenant)

Le MMM n’est pas neuf, il a juste été rangé au placard pendant l’âge d’or du cookie. Il en ressort parce que l’attribution user-level s’effondre. La fin du Privacy Sandbox, la règle des six mois du Digital Omnibus et la restructuration de l’attribution GA4 d’avril 2026 (fenêtre de rétrospection raccourcie, first-click supprimé) ont un point commun : elles cassent les modèles qui suivent un utilisateur d’un clic à une conversion. Le MMM, lui, est agrégé et sans cookie. Il ne regarde pas les individus, il regarde des séries temporelles de dépenses et de résultats. C’est précisément ce qui le rend robuste dans un monde qui perd ses identifiants.

Google l’a bien compris et pousse fort sur Meridian en 2026 : un Scenario Planner sans code au printemps, puis l’annonce de Meridian GeoX (géo-incrémentalité open source) et de Meridian Studio le 5 mai 2026, avant Google Marketing Live. Le sujet est en montée d’intérêt, pas encore saturé. Pour le contexte complet sur l’effondrement de l’attribution, j’ai détaillé les changements dans Attribution GA4 2026 : ce qui a changé et Privacy Sandbox est mort. Ici, on ne refait pas ces articles, on passe au concret.

Ce que Meridian attend exactement en entrée

Premier choc pour la plupart des gens : Meridian ne veut pas vos événements. Il veut une table agrégée, une ligne par combinaison de semaine et de zone géographique, avec les dépenses média en colonnes. Votre export GA4, c’est l’inverse : une ligne par événement, horodatée à la microseconde, sans notion de coût média. Tout le travail de préparation consiste à passer de l’un à l’autre.

Meridian charge ses données via un DataFrameDataLoader et un objet CoordToColumns qui mappe vos colonnes réelles vers les noms standard du modèle. Voici les colonnes qui comptent :

Trois points à graver dans le marbre. La maille temporelle est hebdomadaire, pas journalière : Meridian se comporte mal sur des données quotidiennes trop bruitées, et la semaine est le standard du secteur. Le format de date est strictement yyyy-mm-dd. Et si vous n’avez qu’un seul marché, vous faites du MMM national : une seule valeur de geo, c’est permis, mais vous perdez la puissance statistique que la dimension géographique apporte au modèle.

La requête BigQuery : de vos événements GA4 au KPI hebdomadaire

Voici le pont concret. Cette requête prend l’export GA4 standard (events_*), déduplique les achats, agrège au format Meridian, et sort directement une table time / geo / kpi / revenue_per_kpi. Adaptez le nom du dataset et la plage de dates.

WITH purchases AS (
  SELECT
    event_date,
    event_timestamp,
    geo.country AS geo,
    (SELECT value.string_value
       FROM UNNEST(event_params)
      WHERE key = 'transaction_id') AS transaction_id,
    ecommerce.purchase_revenue AS revenue
  FROM `votre_projet.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20240101' AND '20261231'
    AND event_name = 'purchase'
),
dedup AS (
  SELECT * EXCEPT(rn) FROM (
    SELECT *,
      ROW_NUMBER() OVER (
        PARTITION BY transaction_id
        ORDER BY event_timestamp
      ) AS rn
    FROM purchases
    WHERE transaction_id IS NOT NULL
  )
  WHERE rn = 1
)
SELECT
  DATE_TRUNC(PARSE_DATE('%Y%m%d', event_date), WEEK(MONDAY)) AS time,
  geo,
  COUNT(*) AS kpi,
  SAFE_DIVIDE(SUM(revenue), COUNT(*)) AS revenue_per_kpi
FROM dedup
GROUP BY time, geo
ORDER BY time, geo

Trois choses méritent qu’on s’y arrête. Le PARSE_DATE('%Y%m%d', event_date) convertit la chaîne event_date de GA4 (au format 20260831) en vraie date, sans quoi DATE_TRUNC refuse de travailler. Le WEEK(MONDAY) cale la semaine sur le lundi : choisissez une convention et tenez-la sur toute la table, coûts média compris, sinon vos jointures hebdomadaires seront décalées d’un jour et fausseront tout. Enfin la déduplication par transaction_id évite le double comptage des achats renvoyés plusieurs fois, un grand classique du tracking e-commerce. Si vous n’avez pas de transaction_id fiable, dédupliquez au moins sur event_timestamp par utilisateur.

Pour aller plus loin sur l’export GA4 dans BigQuery, l’article Exploiter l’export GA4 dans BigQuery couvre la structure des tables, et les 10 requêtes BigQuery indispensables vous donne la boîte à outils SQL de base.

Raccrocher le coût média : la partie que tout le monde bâcle

Votre KPI hebdomadaire n’est que la moitié du modèle. Sans media_spend, Meridian n’a rien à corréler. Vous avez trois sources pour les coûts, et le choix n’est pas anodin.

L’import de données de campagne GA4 est la voie la plus simple si vos coûts non-Google (Meta, TikTok) sont déjà uploadés. Mais attention : cet import joint au moment de la requête sur utm_source, utm_medium et la date, et il casse silencieusement dès que votre taxonomie UTM dérape. J’ai écrit un guide entier sur ce piège dans Import données de campagne GA4. Un import cassé, ce sont des dépenses fantômes dans votre MMM.

Le Google Ads Data Transfer exporte vos coûts Google Ads directement dans BigQuery, à la source, sans passer par GA4. C’est la voie la plus propre pour le canal Google, parce qu’elle évite l’échantillonnage et les jointures fragiles. Vous rapprochez ensuite ces coûts de votre table KPI par semaine et par géo.

Les connecteurs tiers (Meta, TikTok, LinkedIn via un ETL, ou le Data Manager) alimentent le reste. Le Data Manager devient d’ailleurs le hub d’orchestration de ces flux en 2026 : voir Google Ads Data Manager. Ma recommandation : Ads Data Transfer pour Google, connecteurs ou ETL pour le reste, et vous alignez tout sur la même maille hebdomadaire lundi-à-dimanche avant de joindre.

Les variables de contrôle qu’on oublie systématiquement

Un MMM sans variables de contrôle attribue au média des variations qui n’ont rien à voir avec lui. Les controls sont là pour absorber tout ce qui bouge votre KPI sans être de la pub : la saisonnalité (soldes, fêtes, rentrée), les promotions et remises que vous avez lancées, le niveau de prix, et, très utile pour le retail, le Google Query Volume (le volume de recherches sur votre marque, proxy de la demande organique). Oubliez-les, et le modèle surestimera le ROI de vos canaux payants en leur créditant la hausse de décembre. Ajoutez-les, et vos courbes de réponse deviennent enfin crédibles.

Les 3 pièges qui invalident votre MMM en silence

Ces trois erreurs ne font pas planter Meridian. Elles produisent un modèle qui tourne, sort des chiffres, et se trompe. C’est le pire des cas, parce que vous prenez des décisions dessus.

Le premier piège, c’est le KPI déjà attribué. Si votre kpi vient d’un rapport GA4 basé sur l’attribution (conversions attribuées data-driven, par exemple), vous mélangez deux logiques incompatibles : le média est déjà crédité côté KPI, puis Meridian tente de le re-créditer côté média. Double comptage garanti. Le KPI d’un MMM doit être un total brut et non attribué : le nombre d’achats, point. C’est justement parce que l’attribution devient peu fiable qu’on passe au MMM, donc ne réinjectez pas l’attribution dans l’entrée.

Le deuxième, c’est l’absence de granularité géo. GA4 expose bien geo.country et geo.region, mais beaucoup d’implémentations n’ont qu’un pays exploitable, ou une donnée régionale trop lacunaire. Sans plusieurs géos, vous perdez la puissance du modèle hiérarchique de Meridian et vous retombez sur un MMM national, plus faible. Vérifiez la couverture de geo.region avant de promettre un modèle géo.

Le troisième, c’est l’historique trop court. En dessous de deux ans de données hebdomadaires, le modèle n’a pas vu assez de cycles saisonniers ni assez de variation de dépense pour être identifiable. Il sortira des intervalles de crédibilité si larges qu’ils ne veulent rien dire. Deux ans est un plancher pratique, trois ans est confortable. Si vous n’avez qu’un an d’export BigQuery, attendez, ou complétez avec un historique de coûts plus ancien.

Meridian Scenario Planner n’est pas le Scenario Planner de GA4

Attention à un piège de vocabulaire qui embrouille tout le monde. Meridian possède un Scenario Planner, sorti sans code au printemps 2026, qui simule des allocations budgétaires à partir des courbes de réponse du MMM. Le Scenario Planner de GA4, lui, est une fonctionnalité de budgétisation cross-canal intégrée à l’interface GA4, basée sur ses propres projections, pas sur un MMM bayésien. Même nom, deux outils, deux méthodes, deux niveaux de rigueur. Ne les confondez pas dans une recommandation client. J’ai traité le second en détail dans Budgétisation cross-canal GA4 : Scenario Planner, limites. Si un décideur vous parle de Scenario Planner, votre première question doit être : lequel des deux.

Quand ne PAS faire de MMM

Terminons par un conseil qui va à contre-courant de tout le battage : le MMM n’est pas pour tout le monde. En dessous d’environ 50 000 € de média mensuel, ou avec un seul canal actif, vous n’avez ni le budget ni la variation statistique nécessaires pour que le modèle apprenne quoi que ce soit. Vous passerez des semaines à préparer des données pour obtenir des intervalles de crédibilité gigantesques. Dans ce cas, une bonne discipline UTM, un tracking server-side propre et l’analyse d’incrémentalité par géo-test isolé vous rendront plus de service qu’un MMM complet.

Si en revanche vous cochez les cases (plusieurs canaux, un budget significatif, deux ans d’historique, plusieurs géos), alors la préparation des données est votre vrai chantier, pas le modèle. Le modèle, Meridian le fait pour vous. La table hebdomadaire propre, par géo et par canal, c’est vous. Commencez par la requête ci-dessus, validez la maille et la déduplication, raccrochez les coûts, et vous aurez fait 80 % du travail avant d’écrire une seule ligne de Python.