Extraire des données géographiques pour les tests

Pour les extractions de données automatisées ou à grande échelle pour les tests GeoX, vous devez utiliser l'API Google Ads pour extraire les données de coût et de dépenses. Vous combinez ensuite ces données avec des données de conversion ou de revenus brutes, non filtrées et non attribuées provenant de votre CRM interne, d'un point de vente ou de bases de données de ventes internes.

Architecture de workflow d'API recommandée

Pour extraire avec précision les données de campagne et les données de coût par segment géographique, suivez cette architecture :

• Service : utilisez GoogleAdsService, en particulier les méthodes Search ou SearchStream.

• Ressource : interrogez geographic_view pour voir où l'utilisateur se trouvait physiquement ou ce qui l'intéressait, ce qui est généralement la norme pour les tests GeoX. Vous pouvez également interroger location_view pour afficher les performances en fonction des cibles géographiques spécifiques de la campagne.

  Remarque : N'utilisez pas campaign_location_target_report, car ce rapport de l'ancienne API AdWords a été abandonné.

• Champs à inclure :

  • campaign.id
  • segments.date
  • segments.geo_target_city (ou région ou pays, selon la précision GeoX)
  • metrics.cost_micros

• Exemple de requête GAQL : pour GeoX, les annonceurs extraient les métriques de coût à l'aide de l'API Google Ads plutôt que les conversions attribuées (qui doivent provenir d'un CRM interne ou de systèmes tiers). Vous pouvez utiliser la requête suivante :

  SELECT
    campaign.id,
    segments.date,
    segments.geo_target_city,
    metrics.cost_micros
  FROM geographic_view
  WHERE segments.date DURING LAST_30_DAYS
  

  Remarque : geographic_view ne renvoie que les lignes des segments géographiques qui ont enregistré des impressions ou des dépenses à une date donnée. Pour inclure les jours et les régions sans dépenses dans vos séries temporelles GeoX, effectuez une jointure externe gauche dans votre pipeline de données sur le produit cartésien complet des dates et des régions cibles.

Remarque : Si vous extrayez des métriques de conversion de Google Ads, vous extrayez des conversions attribuées, ce qui signifie que vous ne tenez compte que des ventes pour lesquelles l'algorithme de Google s'est déjà attribué le mérite. L'utilisation de données attribuées est fortement déconseillée dans GeoX, car la logique d'attribution biaise la mesure causale.

Post-traitement et extraction de données

• Mappage des segments géographiques : l'API ne renvoie pas de noms en texte brut (comme "New York") ni de codes courts (comme "501" ou "ES") dans les vues de rapports. Les champs tels que segments.geo_target_city ou segments.geo_target_country renvoient une chaîne de nom de ressource pointant vers un GeoTargetConstant (par exemple, geoTargetConstants/1023191). Extrayez l'ID numérique (1023191) et interrogez la ressource geo_target_constant :

  SELECT
    geo_target_constant.id,
    geo_target_constant.name,
    geo_target_constant.canonical_name
  FROM geo_target_constant
  WHERE geo_target_constant.id = 1023191
  

  Vous pouvez également effectuer la jointure localement dans le code en téléchargeant le fichier CSV des cibles géographiques statiques sur la page Cibles géographiques.

• Conversion des coûts : l'API renvoie les valeurs de coût en micros. Vous devez diviser metrics.cost_micros par 1 000 000 pour obtenir la valeur de devise standard requise dans votre fichier d'importation.

ID de zone géographique pour les mutations de ciblage

Lorsqu'ils effectuent des mutations de ciblage géographique au niveau d'une campagne ou d'un groupe d'annonces, les annonceurs doivent rechercher et transmettre l'ID GeoTargetConstant exact (geoTargetConstants/ID) pour les régions sélectionnées. Vous ne pouvez pas transmettre de codes ISO ou Nielsen bruts.

Type de région	ID d'API requis (GeoTargetConstant)	Ancien format (ne pas utiliser)
Région DMA	ID 200501 (pour New York)	Code Nielsen (par exemple, 501 pour New York)
Pays	ID 2724 (pour l'Espagne)	Code ISO (par exemple, "ES" pour l'Espagne)

Bonnes pratiques et erreurs de mise en forme courantes

• Formatage de la date : le champ segments.date renvoie des chaînes de date ISO-8601 au format YYYY-MM-DD. Dans votre pipeline ETL, sérialisez explicitement les champs de date en tant que chaînes YYYY-MM-DD et évitez d'ouvrir les fichiers CSV exportés dans des applications de feuille de calcul qui reformatent automatiquement les colonnes de date.
• Zéros non significatifs dans les codes postaux : traitez les codes postaux (par exemple, 01234) comme des types de chaînes (VARCHAR ou STRING) dans l'ensemble de votre pipeline de données plutôt que comme des entiers, afin que les zéros non significatifs ne soient jamais supprimés.
• Agrégation : si vous menez une étude multicellulaire, vous devez fournir des métriques de dépenses distinctes pour chaque groupe de traitement.
• Associer des données de conversion : lorsque vous associez des données de conversion provenant d'un système CRM interne ou de bases de données de ventes internes, assurez-vous que les données de conversion possèdent les propriétés suivantes pour garantir un traitement fluide des données avec les données de l'API Google Ads et GeoX :
  • Séries temporelles quotidiennes : les données doivent être agrégées par jour.
  • Niveau géographique : chaque conversion doit être mappée aux unités géographiques exactes que vous testez (par exemple, en faisant correspondre le code postal de livraison du client à la zone de marché désignée ou au cluster postal utilisé dans la conception).
  • Valeurs brutes : les données doivent être des valeurs absolues non négatives, telles que le revenu brut ou le nombre brut de conversions. Si votre CRM suit les revenus nets avec des valeurs négatives pour les remboursements, vous devez utiliser les chiffres bruts pour le test et appliquer un ratio de remboursement ultérieurement.