Audit des données GeoX dans Google Ads : préparer une expérimentation géographique fiable

La préparation d’une expérimentation GeoX ne commence pas par une promesse d’incrémentalité. Elle commence par la vérification du rapprochement entre dépense, jour, zone et résultat interne. Google indique que les extractions automatisées ou volumineuses doivent récupérer les coûts et dépenses via l’API Google Ads, puis les associer à des conversions ou revenus bruts, non filtrés et non attribués issus d’un CRM interne, d’un point de vente ou d’une base de données commerciale. Les conversions attribuées par la plateforme ne constituent donc pas le résultat recommandé dans ce flux.

Selon la méthode CreatikLab, aucune interprétation ne devrait être validée tant que ce rapprochement n’est pas reproductible et auditable. Un formulaire envoyé n’est pas automatiquement un prospect qualifié : la qualification relève d’une règle commerciale approuvée et appliquée dans le système interne. GeoX désigne ici une expérimentation géographique Google Ads, et non le GEO associé à l’optimisation pour les moteurs génératifs. La documentation de Google ne garantit ni volume de prospects, ni hausse du chiffre d’affaires, ni ROAS. Un prestataire responsable doit conserver cette limite.

Avant de développer une requête, réunissez le responsable Google Ads, l’analyste, le propriétaire du CRM et la finance. Ils doivent approuver le périmètre des campagnes, la zone horaire, la devise, l’unité géographique, la date de référence, la source du résultat et la politique de correction. Cette étape évite qu’un fichier techniquement correct rapproche des concepts incompatibles.

Google demande une série quotidienne pour les conversions et un rattachement de chaque résultat à l’unité géographique exacte de l’expérimentation. Les valeurs doivent être absolues et non négatives, par exemple un revenu brut ou un nombre total de conversions. Lorsque le CRM comptabilise les remboursements comme revenus nets négatifs, Google demande d’utiliser les montants bruts pour l’expérimentation et d’appliquer ensuite le taux de remboursement. CreatikLab conserverait donc le brut et le remboursement dans des champs séparés, avec des transformations visibles. Pour les prospects, les statuts reçu, validé et accepté par les ventes doivent également rester distincts.

Google recommande GoogleAdsService, avec Search ou SearchStream, pour interroger les données. Les champs documentés comprennent campaign.id, segments.date, le segment géographique adapté tel que segments.geo_target_city, et metrics.cost_micros. La région ou le pays peut remplacer la ville lorsque l’expérimentation utilise une autre granularité.

Le choix de la vue modifie le sens de la donnée. geographic_view couvre la position physique de l’utilisateur ou une zone qui l’intéresse et constitue, selon Google, le choix habituel pour GeoX. location_view mesure les zones précisément ciblées par la campagne. Les dimensions géographiques renvoient des noms de ressources GeoTargetConstant, pas nécessairement des libellés directement lisibles. Il faut les résoudre avec geo_target_constant ou avec les données géographiques téléchargeables de Google.

Enfin, metrics.cost_micros doit être divisé par 1 000 000 pour produire une valeur monétaire standard. Une modification de ciblage exige l’identifiant GeoTargetConstant correct : les codes ISO de pays ou Nielsen bruts ne peuvent pas être envoyés à sa place.

Cette matrice est une méthode de contrôle CreatikLab. Elle transforme chaque anomalie observable en preuve, action et responsabilité sans attribuer à Google une capacité supplémentaire.

• Écart de dépense — Preuve : le total API ne correspond pas à l’extraction de contrôle — Action : revoir campagnes, dates et conversion des micros — Responsable : analyste média.
• Ressources non résolues — Preuve : présence de GeoTargetConstant sans libellé canonique — Action : compléter et versionner la table de correspondance — Responsable : ingénieur data.
• Zéros initiaux perdus — Preuve : identifiants postaux raccourcis — Action : imposer un stockage textuel — Responsable : qualité des données.
• Résultats sans zone — Preuve : part du CRM impossible à rattacher à l’unité testée — Action : améliorer la collecte ou revoir la granularité — Responsable : propriétaire CRM.
• Qualification incohérente — Preuve : ventes et marketing appliquent des statuts différents — Action : adopter un dictionnaire unique — Responsable : revenue operations.
• Cellules fusionnées — Preuve : plusieurs groupes partagent la même série de coûts — Action : séparer extraction et rapprochement — Responsable : pilote de l’expérimentation.

La livraison doit être acceptée sur des preuves enregistrées, et non parce qu’un fichier a été généré sans erreur apparente.

1. Périmètre — Archiver comptes, campagnes et période — Vérifier la requête contre la liste approuvée — Propriétaire : responsable de compte.
2. Vue — Motiver geographic_view ou location_view — Confirmer que son sens répond à la question — Propriétaire : expert Google Ads.
3. Coût — Garder la valeur brute en micros et la valeur convertie — Tester la division par 1 000 000 et rapprocher les totaux — Propriétaire : analyste.
4. Géographie — Conserver ressource, identifiant et nom canonique — Tester les correspondances GeoTargetConstant — Propriétaire : ingénieur data.
5. Dates — Préserver le format YYYY-MM-DD jusqu’au fichier final — Empêcher le tableur de le modifier silencieusement — Propriétaire : analytics.
6. Identifiants — Tester des codes postaux comportant des zéros initiaux — Forcer le texte ou un format de longueur appropriée — Propriétaire : data steward.
7. Résultats — Exporter les données internes brutes, non filtrées et non attribuées — Les rapprocher du système de référence — Propriétaire : CRM ou finance.
8. Cellules — Produire une série de coûts par groupe de traitement — Refuser un agrégat commun — Propriétaire : responsable mesure.
9. Validation — Consigner exception, correction et nouveau test — Bloquer la mise à disposition en présence d’un écart matériel — Propriétaire : directeur de l’expérimentation.

La spécification CreatikLab distingue trois niveaux. Le premier mesure l’intégrité du pipeline : couverture quotidienne, doublons, zones non résolues, erreurs de format et écarts de rapprochement. Ces indicateurs disent si la donnée est exploitable, pas si la publicité est performante. Le deuxième niveau est le résultat interne choisi avant l’analyse. Pour la génération de prospects, il peut s’agir d’un prospect validé ou accepté par les ventes, à condition que le CRM applique une règle stable et que l’enregistrement soit rattachable à la zone testée.

Le troisième niveau facilite l’interprétation commerciale : opportunités acceptées, revenus bruts, remboursements et autres informations aval disponibles dans les systèmes de l’entreprise. Ces éléments ne doivent pas être réduits silencieusement à une conversion publicitaire unique. Il faut préciser le timestamp utilisé pour la journée, le traitement des données tardives, les retraitements autorisés et l’approbateur. Google décrit la structure attendue pour les entrées, mais ne fixe dans cette documentation ni budget, ni durée, ni seuil d’analyse, ni définition universelle du prospect qualifié. Ces choix nécessitent un plan adapté au cycle de vente.

Scénario prêt : les dépenses quotidiennes sont rapprochées, toutes les ressources géographiques utiles sont résolues, les résultats internes partagent la même unité et chaque cellule dispose de sa série. La décision consiste à passer en revue le plan expérimental tout en conservant le journal d’audit.

Scénario réparable : les coûts sont fiables, mais le CRM ne renseigne pas la zone pour une part significative des résultats. Il ne faut pas déduire cette zone du ciblage de campagne. Il convient d’améliorer la collecte, de choisir une unité plus large mais défendable ou de reporter l’implémentation.

Scénario à refuser : seules les conversions attribuées Google Ads sont disponibles, les dates ont été reformattées sans trace, ou plusieurs cellules utilisent une dépense combinée. La livraison doit être arrêtée jusqu’à la correction et au nouveau test. Ce refus ne signifie pas que GeoX ne peut apporter aucune information ; il signifie que le jeu actuel ne permet pas une analyse responsable.

• Ne pas confondre zone ciblée et position physique ou zone d’intérêt de l’utilisateur.
• Ne pas considérer un nom de ressource GeoTargetConstant comme un code géographique directement exploitable.
• Ne pas supposer qu’un tableur conserve les dates et les zéros initiaux. Google signale ces risques de format et recommande un contrôle via Google Sheets pour les dates.
• Ne pas remplacer le résultat interne par les conversions attribuées de l’API dans ce processus GeoX.
• Ne pas injecter un revenu net comportant des remboursements négatifs dans une mesure brute attendue non négative.
• Ne pas fusionner les dépenses de plusieurs cellules de traitement.
• Ne pas appeler prospect qualifié chaque formulaire reçu sans règle CRM approuvée.
• Ne pas inventer de prix, d’éligibilité, de périmètre de déploiement, de disponibilité ou de performance attendue : ces éléments ne sont pas précisés par Google dans cette documentation.

L’automatisation peut extraire, transformer et contrôler les enregistrements. Elle ne remplace pas la responsabilité humaine sur le sens d’une zone, la qualité d’un prospect ou l’acceptation d’une exception.

Commencez par un audit Google Ads consacré à la préparation GeoX. Le livrable concret doit couvrir les requêtes, la vue géographique, les correspondances GeoTargetConstant, les transformations de date et de coût, le dictionnaire des résultats CRM, les rapprochements, les anomalies, les propriétaires et une recommandation documentée : avancer, corriger ou arrêter. Il ne doit garantir ni ROAS, ni volume de prospects, ni incrément.

Lorsqu’un arbitrage de conception subsiste après l’audit, le conseil Google Ads peut cadrer l’unité géographique, le résultat interne et la gouvernance. La page Experts Google Ads permet d’évaluer le niveau de responsabilité stratégique proposé. Pour poursuivre le diagnostic avec du contexte, indiquez à Lia les comptes, zones, champs CRM et définitions de résultat déjà disponibles.

Quelles données Google prévoit-il pour GeoX ?

Google prévoit des coûts Google Ads ventilés par date et zone, associés à des conversions ou revenus bruts, non filtrés et non attribués provenant d’un CRM interne, d’un système de point de vente ou d’une base de ventes.

Les conversions attribuées par Google Ads constituent-elles le résultat à utiliser ?

Dans ce flux GeoX, Google indique que les données de conversion doivent provenir du CRM interne ou d’un système tiers plutôt que des conversions attribuées récupérées par l’API Google Ads.

Quelle vue géographique faut-il interroger ?

Google présente geographic_view pour la position physique de l’utilisateur ou une zone qui l’intéresse, et la décrit comme la vue généralement employée pour GeoX. location_view concerne les zones précisément ciblées par la campagne.

Pourquoi faut-il diviser le coût par 1 000 000 ?

metrics.cost_micros exprime le coût en micros. Google demande de le diviser par 1 000 000 afin d’obtenir l’unité monétaire standard nécessaire au fichier d’importation.

Un code ISO de pays suffit-il pour modifier un ciblage ?

Non. Google demande l’identifiant GeoTargetConstant correspondant à la région choisie. Un code ISO ou Nielsen brut ne remplace pas cet identifiant.

Que contient l’audit GeoX de CreatikLab ?

Il contient le périmètre d’extraction, le choix de la vue, les correspondances géographiques, les transformations, la définition du résultat CRM, les rapprochements, les responsabilités et une décision documentée. Il ne garantit pas de performance.