Questions fréquentes

Ce document apporte des réponses détaillées aux questions fréquentes sur Meridian GeoX.

Concepts généraux de Meridian GeoX

Quelle est la différence entre GeoX et les solutions de mesure de l'impact basées sur les utilisateurs ?

GeoX et les solutions de mesure basées sur les utilisateurs adoptent des approches fondamentalement différentes pour trouver un équilibre entre précision des mesures et confidentialité des utilisateurs :

• GeoX regroupe les audiences par zone géographique et utilise des données globales, en ignorant complètement l'attribution au niveau de l'utilisateur.
• Le lift basé sur les utilisateurs suit les impressions d'annonces ou les cookies individuels pour attribuer les conversions.

Pourquoi utiliser GeoX ?

L'utilisation de Meridian GeoX offre les avantages suivants :

• Mesure de l'incrémentalité multi-éditeur : en configurant des conceptions multicellulaires, GeoX permet de mesurer l'incrémentalité multi-éditeur, par exemple les médias Google par rapport aux médias non Google. Cela n'est généralement pas possible avec le conversion lift basé sur les utilisateurs propre à chaque éditeur.
• Mesure hors connexion et omnicanal : GeoX est la principale méthode de mesure de l'impact hors connexion et omnicanal, par exemple les ventes en magasin et les conversions suivies dans le CRM. Comme cette méthode utilise des données de vente agrégées par région, elle évite la difficulté d'associer les impressions d'annonces en ligne au niveau des utilisateurs aux transactions en magasin hors connexion.
• Approche respectueuse de la confidentialité : GeoX s'appuie sur des conversions agrégées et non attribuées dans une région donnée, plutôt que sur le suivi des personnes. Par conséquent, GeoX n'est pas affecté par les lacunes au niveau des mesures causées par les problèmes de confidentialité modernes, tels que l'abandon des cookies et les restrictions iOS.

Remarque : Les tests géographiques présentent un bruit inhérent plus élevé, car ils incluent toutes les conversions de la région, qu'elles soient attribuées ou non. Par conséquent, ils nécessitent souvent un investissement financier plus important et davantage de temps pour atteindre une puissance statistique suffisante, par rapport au lift basé sur les utilisateurs.

Comparaison entre Meridian GeoX et les anciennes bibliothèques Google GeoX

Quelle est la différence entre la bibliothèque Open Source Meridian GeoX et les autres logiciels Open Source Google GeoX, tels que les marchés appariés par régression temporelle (TBRMM, Time-Based Regression Matched Markets) ?

La bibliothèque Meridian GeoX est une mise à niveau complète et unifiée qui offre les fonctionnalités suivantes :

• Solution tout-en-un : réunit dans une seule bibliothèque la conception des études (planification avant le test) et l'analyse (inférence après le test), en couvrant plusieurs méthodologies. GeoX est compatible avec la méthodologie de régression temporelle (TBR).
• Comparaison directe des conceptions : inclut une fonctionnalité compare_designs permettant de comparer directement différentes conceptions d'étude côte à côte afin de déterminer celle qui correspond le mieux aux exigences de budget et d'effet minimal détectable (MDE).
• Approche statistique moderne : utilise des calculs optimisés par JAX pour générer rapidement des candidats et effectuer une inférence placebo tenant compte de la conception, ce qui améliore la puissance et la précision de l'estimation des intervalles de confiance.
• Multicellulaire et flexible : assure la prise en charge native des conceptions multicellulaires et permet d'appliquer des contraintes flexibles, comme exclure certaines zones géographiques ou les affecter de force à un groupe de contrôle.

Pourquoi Meridian GeoX recommande-t-il un budget sensiblement plus élevé et un MDE plus important que TBRMM ?

Les différences de recommandations s'expliquent par des philosophies de conception et des techniques de validation différentes entre TBRMM et Meridian GeoX :

• TBRMM estime la puissance de conception en fonction de l'ajustement de l'échantillon de pré-test. Les mêmes données historiques sont utilisées pour ajuster le modèle et estimer sa variance. Dans une situation idéale, la variance estimée à l'aide de cette procédure doit converger vers sa variance réelle. Toutefois, dans la pratique, la variance avant le test peut souvent être sous-estimée par rapport à celle observée lors du test proprement dit. Si la variance réelle observée après le test est plus élevée, la puissance de l'étude peut se révéler insuffisante. Cette optimisation historique peut donc donner lieu à des recommandations de budget et de MDE optimistes ou plus faibles.
• Meridian GeoX remédie à ce problème en intégrant une validation hors échantillon ou une division honnête des données, ainsi que des tests placebo pendant la phase de conception. En évaluant la stabilité de la conception sur des périodes de validation qui n'ont pas été utilisées pour l'ajustement du modèle, il obtient une estimation plus réaliste de la variance après le test, ce qui se traduit par des recommandations de budget et de MDE plus prudentes.

Chaque méthode est valide selon ses propres hypothèses techniques, mais Meridian GeoX est conçu pour intégrer une marge de sécurité face à une volatilité plus réaliste après la conception, afin que les tests aient une forte probabilité de produire des résultats concluants.

Exigences relatives aux données et ingestion

Puis-je utiliser comme métrique de conversion le revenu net, qui peut inclure des valeurs négatives dues aux remboursements ?

Non. Bien que la validation du schéma ne bloque pas explicitement les conversions négatives et vérifie uniquement que le nombre total de conversions est positif, des valeurs de conversion négatives peuvent perturber la génération de candidats (affectation gloutonne) et la modélisation statistique. Il est recommandé d'utiliser des valeurs absolues non négatives, telles que le revenu brut ou le nombre brut de conversions. Si les remboursements sont importants, effectuez l'analyse sur les ventes brutes et appliquez un ratio net/brut historique après le test.

Les données sur les dépenses de la campagne sont-elles toujours obligatoires pendant la phase de conception, et comment les obtenir ?

Les exigences concernant les données sur les dépenses de la campagne dépendent du type de test :

• Tests go-dark (suppression) et heavy-up (augmentation) : les données de dépenses quotidiennes par zone géographique sont obligatoires pour calculer les niveaux de dépenses de référence et prévoir les budgets de test. La validation échouera si la colonne des dépenses est absente pour ces types de tests.
• Tests de type holdback : facultatifs pour le lancement de campagnes entièrement nouvelles pendant la phase de conception. Toutefois, vous devez fournir une référence de coût par conversion incrémentale (CpIC) pour estimer le budget nécessaire.

Les données sur les dépenses que vous extrayez doivent être quotidiennes et agrégées au même niveau géographique que vos conversions (par exemple, zone de marché désignée, État ou code postal).

• Google Ads : extrayez les dépenses quotidiennes par zone géographique à l'aide de l'API Google Ads, via des rapports tels que campaign_location_target_report.
• Autres éditeurs : utilisez les API propres à chaque éditeur ou des exportations de l'interface utilisateur de reporting pour récupérer les dépenses quotidiennes par zone géographique ciblée.

Assurez-vous que les identifiants géographiques sont strictement identiques dans vos ensembles de données de conversions et de dépenses. Si vous utilisez des codes postaux, assurez-vous que les zéros initiaux sont conservés sous forme de chaînes lors de l'extraction et de l'exportation afin d'éviter les échecs de correspondance lors de la validation. Par exemple, vos codes postaux doivent être au format "02138" et non "2138".

Pour en savoir plus, consultez Préparer vos données de prétest.

Nos données de conversion quotidiennes sont très volatiles. Est-il possible d'importer des données hebdomadaires à la place afin d'atténuer le bruit ?

Non. GeoX exige des données de séries temporelles quotidiennes. Les données hebdomadaires ne sont pas acceptées et déclenchent des erreurs de validation. Pour gérer la volatilité quotidienne, tenez compte des points suivants :

• Prolonger la durée du test, par exemple de quatre à six ou huit semaines, pour recueillir davantage de points de données et potentiellement réduire le MDE.
• Utiliser un KPI de conversion situé plus haut dans l'entonnoir, comme les ajouts au panier ou les inscriptions, qui présente un volume plus élevé et moins de jours sans conversion.
• Augmenter la taille du groupe de traitement cible ou le pourcentage maximal de conversions.

La bibliothèque Meridian GeoX permet-elle d'inclure plusieurs KPI ?

Non. La bibliothèque Meridian GeoX n'accepte qu'un seul KPI de conversion par exécution, correspondant à la colonne conversions du schéma de données. Cela signifie que vous ne pouvez pas optimiser simultanément une conception pour plusieurs métriques distinctes, telles que :

• Conversions segmentées, comme le suivi des nouveaux acheteurs et des acheteurs déjà connus en tant que KPI cibles distincts lors de la même exécution.
• Différentes actions de conversion, comme le suivi simultané des visites en magasin et des ventes, ou des inscriptions et des achats.

Une conception distincte est requise pour chaque KPI, car chacun présente un volume, une tendance et une volatilité historiques qui lui sont propres. Si vous exécutez le moteur de conception séparément pour chaque KPI, il est probable que des répartitions géographiques et des budgets différents soient recommandés.

Conseil : Si vous devez mesurer deux KPI dans un même test, vous devez concevoir le test à l'aide d'un KPI principal pour vous assurer que la puissance statistique est suffisante. Il s'agit généralement du KPI de conversion présentant un volume plus faible ou une volatilité plus élevée. Vous pouvez ensuite analyser le KPI secondaire après le test en exécutant la fonction analyze sur les données de ce KPI. Notez que la puissance statistique du KPI secondaire peut être inférieure à celle prévue.

Conception et contraintes des études

Peut-on forcer l'affectation d'un marché spécifique au groupe de traitement ou au groupe de contrôle, et quelle incidence cela a-t-il sur la conception de l'étude ?

• Forcer l'affectation au groupe de contrôle : vous pouvez spécifier les zones géographiques à inclure de force dans le groupe de contrôle à l'aide de included_control_geos dans Constraints.
• Exclure des zones géographiques : vous pouvez exclure entièrement certaines zones géographiques du test, par exemple pour protéger des marchés essentiels en termes de revenus ou pour éviter de perturber la diffusion de médias, à l'aide de excluded_geos dans Constraints.
• Forcer l'affectation au groupe de traitement : non disponible dans la bibliothèque principale.

En l'absence de raisons propres à l'entreprise ou de zones géographiques aberrantes, exclure certaines zones géographiques ou forcer leur affectation au groupe de contrôle limite le pool de randomisation et peut dégrader l'ajustement du modèle. Cela peut se traduire par un MDE plus élevé pour atteindre la pertinence statistique.

Mes unités géographiques sont-elles trop peu nombreuses pour que GeoX soit efficace ?

Vous devez inclure au moins 10 zones géographiques pour une conception à cellule unique.

• Utilisez l'échantillonnage aléatoire pour 10 à 20 zones géographiques : dans les conceptions comportant moins de 20 unités géographiques, l'échantillonnage stratifié est moins efficace, car le clustering en strates est limité. Si l'échantillonnage stratifié ne permet pas d'obtenir une conception satisfaisante, vous devriez utiliser une méthode d'attribution aléatoire plus simple.
• Utilisez l'échantillonnage stratifié pour plus de 20 zones géographiques : lorsque votre conception comporte peu de zones géographiques, la puissance statistique risque d'être faible, ce qui entraîne des MDE élevés ou nécessite des budgets très importants. Pour des résultats optimaux, il est recommandé d'utiliser un plus grand nombre de zones géographiques (de 50 à plus de 100, par exemple) afin de permettre une stratification efficace et un appariement robuste.

Que se passe-t-il si je dispose d'un budget flexible et que je souhaite saisir un CPA incrémental ou un ROAS incrémental cible pour obtenir le budget requis ?

Cela dépend du type de test :

• Tests de type holdback : vous saisissez le CpIC cible à l'aide de cost_per_incremental_conversion dans DesignConfig. Si les conversions représentent le revenu, le CpIC équivaut à 1/iROAS. La bibliothèque calcule ensuite le budget nécessaire pour détecter le MDE avec la puissance souhaitée.
• Tests go-dark (suppression) et heavy-up (augmentation) : vous ne saisissez pas le CpIC cible. Cependant, le budget est déterminé par les dépenses historiques dans les zones géographiques de traitement sélectionnées. Vous pouvez appliquer une contrainte budget_pct (par exemple, -100% pour les tests go-dark ou une augmentation en pourcentage pour les tests heavy-up). La bibliothèque estime alors le CpIC implicite de la conception que vous pouvez détecter avec ce budget.

Précisions concernant le budget et le MDE

Le MDE statistique ou le pourcentage minimal de variation des conversions que le test peut détecter est déterminé uniquement par la volatilité historique et l'appariement des zones géographiques. Modifier le budget ne change pas cette limite statistique.

Bien que le MDE reste constant, les objectifs d'efficacité que vous pouvez mesurer varient en fonction du budget :

• Budget plus élevé : permet de détecter un CpIC plus élevé et moins efficace, ou un ROAS incrémental plus faible et plus prudent. Cela augmente la probabilité d'obtenir un test concluant pour les campagnes aux performances modérées.
• Budget inférieur : limite la mesure aux campagnes présentant un CpIC très faible ou un ROAS incrémental très élevé. Si les performances réelles de la campagne sont modérées, le test risque de ne pas être concluant.

Comment déterminer si une conception est viable, au-delà du budget requis et du MDE ?

Pour évaluer la viabilité, utilisez les éléments suivants :

• Coefficient de détermination (\(R^2\)) : \(R^2\) une valeur supérieure ou égale à 0,8 est recommandée. Une valeur \(R^2\) faible (inférieure à 0,5, par exemple) indique que les zones géographiques de contrôle ne prédisent pas correctement les zones géographiques de traitement, ce qui rend l'analyse après le test peu fiable.
• Valeur p du test A/A : la bibliothèque filtre les conceptions à l'aide de simulations placebo. Assurez-vous que la conception sélectionnée réussit le test A/A (valeur p ≥ \(\alpha\)) afin de minimiser le risque de faux positifs.
• Faisabilité du MDE : assurez-vous que le MDE prévu est viable sur le plan commercial, c'est-à-dire que vous estimez que la campagne peut réellement atteindre un lift supérieur au MDE.

Ajustement du coefficient de détermination

La valeur minimale requise \(R^2\) est contrôlée par le paramètre min_r2 dans geox.DesignConfig. Par défaut, la valeur \(R^2\) minimale requise est de 0,8. Si la recherche de conceptions ne renvoie aucun candidat viable avec une valeur de 0,8, vous pouvez assouplir ce seuil, en l'abaissant par exemple à 0,75 ou 0,70 :

      design_config = geox.DesignConfig(
        experiment_duration=datetime.timedelta(days=28),
        experiment_types=geox.ExperimentType.HEAVY_UP,
        methodology=geox.Methodology.TBR,
        min_r2=0.7,  # Adjust threshold if 0.8 yields no candidate designs
        )
    

Avertissement : Abaisser min_r2 permet à davantage de conceptions candidates de passer le filtre. Toutefois, il est déconseillé de définir une valeur trop faible, par exemple inférieure à 0,5, car un mauvais ajustement avant le test compromet la fiabilité du modèle et amplifie l'erreur d'inférence.

Implémentation du test et analyse post-test

Si j'exécute GeoX pour la première fois, quelles sont les consignes générales pour implémenter mon test ?

Si vous utilisez GeoX pour la première fois, consultez les recommandations générales ci-dessous :

• Choisissez votre méthode de configuration :
  • UI de la plate-forme (configuration manuelle) : idéal pour les études standards.
  • Éditeur de la plate-forme (configuration groupée) : idéal pour les études complexes ou multicampagnes. Pour cela, vous devez générer et importer un fichier de sauvegarde de l'éditeur.
  • API de la plate-forme (configuration automatisée) : idéal pour une gestion programmatique au niveau de l'entreprise. Notez que le ciblage par code postal n'est pas possible via l'API.
• Déterminez la stratégie de configuration de la campagne :
• Modifier directement (conserver la même campagne) : utilisez cette option lorsque les budgets ne sont pas limités. Limiter directement les zones géographiques permet de préserver les acquis du machine learning.
• Dupliquer (copier-coller la campagne) : obligatoire lorsque les campagnes ont des budgets quotidiens plafonnés. Si vous vous contentez de limiter les zones géographiques d'une campagne dont le budget est plafonné, l'algorithme dépensera le budget économisé dans les zones géographiques de contrôle restantes, ce qui contaminera le groupe de contrôle. La duplication isole les budgets.
• Configuration du ciblage : appliquez strictement la répartition des zones géographiques en utilisant le ciblage par présence afin que les annonces soient diffusées uniquement dans les zones géographiques de traitement et exclues des zones de contrôle.
• Prévoyez une période d'attente : une fois le test terminé, maintenez une période d'attente d'une à deux semaines avant de reprendre le fonctionnement habituel, afin de capturer les conversions différées.

Pour savoir comment exécuter votre test dans Google, consultez le guide d'implémentation de campagne par étapes dans le centre d'aide Google Ads.

Peut-on laisser les tests au niveau de l'utilisateur actifs sur les mêmes campagnes pendant un test GeoX ?

Non. Toutes les études de mesure au niveau de l'utilisateur, telles que le conversion lift et le brand lift, doivent être désactivées sur les campagnes évaluées pendant le test. Les études au niveau de l'utilisateur créent des groupes témoins randomisés cachés au sein de vos zones géographiques, ce qui contamine la répartition entre groupe de traitement et groupe de contrôle, réduit la puissance statistique et biaise l'analyse après le test.

Une conception multicellulaire me permet-elle de tester la pertinence statistique de la différence entre deux groupes de traitement actifs ?

Non. Les résultats de chaque cellule de traitement sont évalués indépendamment par rapport au groupe de contrôle partagé. La bibliothèque ne fournit pas de métrique statistique permettant de tester directement si la différence entre deux groupes de traitement actifs est significative.