Meridian GeoX : préparer un test d'incrémentalité géo avec GA4

Google a annoncé la disponibilité générale de Meridian GeoX le 9 septembre 2026, sa bibliothèque open source de test d’incrémentalité géographique. Dans les jours qui viennent, tout le monde va écrire « qu’est-ce que Meridian GeoX ». Ce guide traite la seule partie qui bloque vraiment quand on passe à l’acte : d’où sortent les données, et sous quel format exact. Parce que GeoX ne tourne pas sur votre export GA4 tel quel, et parce qu’une erreur de maille géographique invalide silencieusement un test qui a coûté des semaines de diffusion.

Un avertissement d’entrée, si vous avez suivi mon guide Meridian MMM : préparer vos données GA4 et BigQuery : la requête hebdomadaire que vous y avez écrite ne marche pas ici. GeoX exige du quotidien et refuse l’agrégation hebdomadaire, soit l’exact inverse de ce que réclame le MMM. On y revient en détail, mais retenez-le tout de suite avant de recycler du SQL.

Pourquoi l’incrémentalité géo, et pourquoi maintenant

L’incrémentalité est devenue le sujet chaud de la mesure en 2026, pour une raison simple : les autres méthodes s’effondrent chacune de leur côté. L’attribution au niveau utilisateur perd son signal (fin du Privacy Sandbox, restructuration de l’attribution GA4, cf. Attribution GA4 2026 : ce qui a changé et Privacy Sandbox est mort). Le MMM seul, lui, reste suspecté de biais d’endogénéité : il corrèle dépenses et résultats sans jamais prouver la causalité. L’expérience géo est le seul chaînon réellement causal du lot. Vous coupez ou augmentez la diffusion dans certaines zones, vous laissez les autres intactes, et vous mesurez l’écart. C’est une randomisation, pas une corrélation.

GeoX arrive donc au bon moment, et Google le sait. La bibliothèque meridian-geox est passée en version stable 1.0.x début septembre 2026 (v1.0.1 au 3 septembre), elle repose sur JAX pour le calcul vectorisé, et elle s’intègre à Meridian MMM pour transformer un résultat d’expérience en prior bayésien. Le coût d’entrée d’un test géo, lui, a chuté : Google a abaissé son seuil minimal d’expérience à 5 000 $ fin 2025. La demande monte, l’outil est gratuit, et la fenêtre pour se positionner sur le sujet est ouverte.

Ce que GeoX change par rapport à l’existant

Si vous avez déjà fait des « matched markets » à la main dans un tableur, ou utilisé GeoLift de Meta, voici ce qui distingue GeoX, sans jargon inutile.

Le vrai apport, ce n’est pas la vitesse (Google annonce des runtimes « deux fois plus rapides », c’est son benchmark interne, on y reviendra). C’est la discipline : GeoX vous force à concevoir le test avant de le lancer, à estimer sa puissance statistique, et à valider hors échantillon plutôt qu’à ajuster une courbe sur le passé. Le multi-cellules natif est le second atout concret : comparer « couper YouTube » et « doubler YouTube » contre un même groupe de contrôle, dans une seule étude, au lieu de trois tests séparés.

Les trois types d’expérience (la décision qu’on prend en premier)

Avant toute donnée, vous choisissez un design. C’est la première décision, et personne ne l’explique clairement. Elle détermine si vous avez besoin de données de dépense, et surtout combien votre test va coûter.

Le holdback est le design le plus « propre » quand vous lancez quelque chose de neuf : pas de spend historique à fournir, pas de CA existant à couper. Le go-dark est le plus parlant pour prouver l’incrémentalité d’un canal déjà en place, mais c’est aussi le plus douloureux, car vous éteignez volontairement de la diffusion qui convertit. Le heavy-up sert à mesurer le rendement marginal d’un euro supplémentaire. Retenez la règle : holdback ne demande pas de données de dépense, go-dark et heavy-up en exigent (pour que GeoX estime le budget nécessaire à partir de vos stats de campagne).

La table de pré-test : ce que GeoX exige exactement

Voici le cœur du sujet. GeoX attend un DataFrame pandas, une ligne par couple date × zone, avec quatre colonnes seulement dans le cas mono-cellule :

* spend est obligatoire pour un design go-dark ou heavy-up, inutile pour un holdback. En multi-cellules, vous fournissez une colonne de dépense par cellule (spend_cell_1, spend_cell_2), avec des valeurs identiques si les cellules modifient la même campagne, différentes si elles testent des tactiques distinctes.

Trois contraintes tuent la moitié des projets avant même le premier run :

D’abord, la maille est quotidienne, point. GeoX refuse l’agrégation hebdomadaire, contrairement à Meridian MMM. Si vous arrivez avec une table hebdo, elle est rejetée. C’est le piège le plus fréquent chez ceux qui enchaînent MMM puis GeoX.

Ensuite, l’historique minimum est de 3×N jours, où N est la durée du test. Un test de 4 semaines réclame donc au moins 12 semaines de pré-test. Si votre activité a une forte saisonnalité, visez un an ou plus, sinon le modèle contrefactuel apprend mal et introduit un biais.

Enfin, chaque couple date × zone apparaît exactement une fois dans la table de pré-test, sans trou. Les jours à zéro conversion doivent figurer avec un zéro, pas être absents.

La requête BigQuery qui produit la table

Votre export GA4 BigQuery est événementiel : une ligne par événement, horodatée à la microseconde. GeoX veut l’inverse, une table agrégée par jour et par zone. Voici la requête qui fait le passage, à adapter à votre projet. Si votre export n’est pas encore branché, commencez par Exploiter l’export GA4 dans BigQuery ; pour d’autres patterns SQL sur GA4, voir Les 10 requêtes BigQuery indispensables.

-- Conversions brutes quotidiennes par région GA4, sur >= 3*N jours de pre-test
WITH conv AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS date,
    geo.region                        AS ga4_region,
    COUNT(*)                          AS conversions   -- brutes, NON attribuees
  FROM `projet.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260831'
    AND event_name = 'purchase'
    AND geo.country = 'France'
  GROUP BY date, ga4_region
),

-- On remappe la region GA4 vers la zone ciblable Google Ads
conv_mapped AS (
  SELECT
    c.date,
    m.google_ads_geo   AS location,
    SUM(c.conversions) AS conversions
  FROM conv c
  JOIN `projet.mapping.ga4_region_to_google_ads_geo` m
    ON c.ga4_region = m.ga4_region
  GROUP BY c.date, location
)

SELECT
  cm.date,
  cm.location,
  cm.conversions,
  COALESCE(s.spend, 0) AS spend
FROM conv_mapped cm
LEFT JOIN `projet.ads.daily_geo_spend` s
  ON s.date = cm.date
 AND s.google_ads_geo = cm.location
ORDER BY cm.date, cm.location

Deux points de vigilance sur cette requête. Le COUNT(*) sur event_name = 'purchase' compte des conversions brutes, ce que veut GeoX : ne le remplacez pas par un key event filtré par modèle d’attribution. Et la table daily_geo_spend est la partie fragile : GA4 ne connaît pas vos coûts média. Il faut les récupérer ailleurs.

Récupérer les coûts par zone

Pour un design go-dark ou heavy-up, la colonne spend est obligatoire, et c’est le maillon faible côté données. Trois sources possibles : l’API Google Ads via la méthode pull-geo-data, prévue exactement pour ça ; un import de coûts si vous les centralisez déjà (voir Import de données de campagne GA4, qui explique pourquoi vos coûts « manquent » dans GA4) ; ou une consolidation first-party via Google Ads Data Manager. Le point crucial : les coûts doivent être ventilés à la même maille géographique que vos conversions. Sinon, la jointure est fausse, et tout le test avec.

Le piège géo : geo.region GA4 n’est pas une zone Google Ads

C’est le vrai différenciateur de ce guide, et l’erreur qui invalide le plus de tests. GA4 et Google Ads ne parlent pas de la même géographie.

GA4 géolocalise côté serveur, par adresse IP, et range l’utilisateur dans geo.region ou geo.city. Google Ads, lui, cible par zone d’intérêt et de présence, avec ses propres identifiants de zone (les geo target constants). Les deux ne se recouvrent pas proprement : une région GA4 peut chevaucher plusieurs zones ciblables Google Ads, et inversement. Si vous fabriquez vos groupes de traitement et de contrôle sur la maille GA4, puis que vous configurez la diffusion sur la maille Google Ads, vos zones « fuient » l’une dans l’autre. Résultat : la diffusion du groupe de traitement touche des utilisateurs comptés dans le contrôle. On appelle ça du spillover, et ça contamine la mesure. Vous croyez mesurer un écart causal, vous mesurez du bruit.

La parade est une table de correspondance explicite, celle appelée ga4_region_to_google_ads_geo dans la requête ci-dessus. Vous la construisez une fois, en alignant chaque région GA4 sur la zone Google Ads réellement ciblable qui la contient, et vous excluez les zones ambiguës plutôt que de les répartir au jugé. GeoX aide d’ailleurs ici : son API permet de forcer l’exclusion de certaines zones du test, précisément pour éviter les grandes zones grises. Consultez la configuration de plateforme côté Google Ads pour connaître les zones réellement disponibles avant de figer votre mapping.

Les quatre règles qui font échouer un design

Au-delà de la maille, quatre règles de qualité de données conditionnent la validité du test. Chacune a un symptôme concret.

Pas de valeurs négatives. GeoX interdit les métriques qui peuvent devenir négatives, comme le chiffre d’affaires net de remboursements. Une valeur négative casse la randomisation du design et le modèle statistique. Travaillez sur du CA brut ou un comptage brut d’achats, et appliquez un ratio net-sur-brut historique après le test si les remboursements pèsent.

Pas de métriques ratio. Le ROAS est interdit. GeoX veut des métriques absolues : un revenu, un nombre de conversions. Une métrique en ratio n’a pas de sens dans le modèle contrefactuel.

Conversions brutes, non attribuées. N’envoyez pas des conversions filtrées par un modèle d’attribution. La logique d’attribution déforme le signal causal que le test cherche justement à isoler. Si le concept de fenêtre et de filtre attributif est flou pour vous, Fenêtre de conversion GA4 : quelle valeur choisir montre bien ce que ces réglages font aux chiffres, et donc pourquoi il faut les neutraliser ici.

Un seul KPI primaire par run. La bibliothèque optimise un design pour une seule métrique. Vous ne pouvez pas viser « nouveaux acheteurs » et « acheteurs récurrents » en même temps. Choisissez le KPI primaire, dimensionnez le test dessus, et n’analysez les KPI secondaires qu’ensuite, avec prudence, car leur puissance statistique n’est pas garantie.

Lire le MDE et savoir renoncer

À l’étape de design, GeoX vous renvoie un MDE, le minimum detectable effect : le plus petit effet que votre test pourra détecter de façon fiable, compte tenu de votre budget, de vos zones et de la durée. C’est votre garde-fou.

La règle est simple et beaucoup l’ignorent : si le MDE dépasse l’effet sur lequel vous agiriez, ne lancez pas le test. Exemple : GeoX vous dit que vous ne pourrez détecter qu’un effet d’au moins 15 %, mais une incrémentalité réelle de 8 % suffirait déjà à justifier une réallocation de budget. Alors le test ne vous apprendra rien d’exploitable, et vous aurez sacrifié de la diffusion pour rien.

Si le MDE ressort trop haut, trois leviers avant d’abandonner : allonger la durée du test (passer de 4 à 6 ou 8 semaines) pour accumuler du volume ; choisir un KPI plus haut dans le tunnel (add-to-cart plutôt que purchase), ce qui augmente le volume et réduit les jours à zéro conversion ; ou élargir le groupe de traitement. Si aucun ne suffit, le sujet n’est simplement pas mesurable chez vous à cette échelle, et le dire est plus utile que de lancer un test sous-dimensionné.

Ce que ça coûte vraiment

La bibliothèque est gratuite. L’expérience ne l’est pas. Sur un go-dark, le coût réel est le chiffre d’affaires que vous éteignez volontairement dans les zones de traitement pendant toute la durée du test. Personne ne devrait aller voir sa direction sans ce chiffre.

Vous pouvez l’estimer avant de lancer, à partir de vos propres données GA4 : prenez le CA quotidien moyen des zones que vous comptez couper, multipliez par le nombre de jours de test, et pondérez par la part de ce CA réellement attribuable au canal coupé (le reste continuera d’arriver via d’autres canaux). C’est une fourchette, pas une certitude, mais elle transforme une conversation abstraite en décision chiffrée. Un go-dark de 4 semaines sur des zones qui pèsent 200 000 € de CA mensuel n’engage pas le même arbitrage qu’un holdback qui ne coupe rien.

Boucler la boucle : calibrer Meridian

L’intérêt d’un test GeoX ne s’arrête pas au résultat brut. Son incrémentalité mesurée devient un prior bayésien qui calibre votre MMM. Concrètement, vous injectez le ROI causal mesuré par GeoX comme contrainte dans Meridian, ce qui recale les estimations du modèle sur une vérité terrain plutôt que sur une simple corrélation. C’est exactement la boucle décrite dans Meridian MMM : préparer vos données GA4 et BigQuery : le MMM identifie les canaux qui gagneraient à être testés, GeoX les teste, et le résultat recalibre le MMM. Les deux se nourrissent.

Côté restitution, les sorties d’analyse (counterfactual modeling, time-based regression) se visualisent volontiers dans un dashboard. Si vous exportez déjà vos données vers un outil de BI, Exporter ses données BigQuery vers Power BI, Tableau et Looker couvre les chemins possibles.

L’angle critique, en deux paragraphes

Soyons lucides sur ce que vous installez. Vous mesurez du média Google, avec une bibliothèque écrite par Google, dont le module de calibration des priors est fourni par Google. Le conflit d’intérêt structurel est réel, et il faut le nommer sans en faire un procès : un fournisseur qui mesure sa propre incrémentalité n’est jamais un tiers neutre, et les choix de modélisation embarqués ont des conséquences sur l’allocation de budget qui, elle, revient à Google.

La contrepartie est tout aussi réelle, et c’est la vraie différence avec les outils de mesure fermés du marché : le code est ouvert et auditable. Vous, ou votre équipe data, pouvez inspecter la méthodologie, comprendre l’échantillonnage stratifié et la régression temporelle, et challenger les hypothèses. Ce n’est pas une garantie de neutralité, c’est une possibilité de vérification, ce que les boîtes noires vendeurs ne permettent pas. À vous d’en profiter.

Faut-il lancer ce test ? Cinq conditions à cocher

Avant de vous lancer, vérifiez honnêtement ces cinq points. S’il en manque un, le test n’est probablement pas pour vous, et c’est une réponse acceptable.

1. Vous avez plusieurs zones géographiques exploitables et comparables, pas une seule région dominante.
2. Vous disposez d’au moins 3×N jours d’historique quotidien de conversions par zone, sans trous.
3. Vous pouvez récupérer les coûts média à la maille géo (si go-dark ou heavy-up).
4. Le MDE renvoyé par le design est plus petit que l’effet qui déclencherait une décision chez vous.
5. Votre direction accepte le coût réel du test (CA sacrifié sur un go-dark, budget supplémentaire sur un heavy-up).

Si les cinq cases sont cochées, vous avez un vrai test causal à portée de main, et le seul chaînon fiable pour trancher là où l’attribution et le MMM restent muets. Sinon, gardez GeoX en réserve : l’outil ne bouge plus, votre maturité data, si.