Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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 de coût par segments géographiques, suivez cette architecture :

Service : utilisez GoogleAdsService, en particulier les Search ou SearchStream méthodes.
Ressource : interrogez geographic_view pour voir où l'utilisateur était physiquement situé ou intéressé, 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 ciblées par la campagne.

Remarque : N'utilisez pas campaign_location_target_report, car cet ancien rapport de l'API AdWords a été supprimé.
Champs à inclure :
- campaign.id
- segments.date
- segments.geo_target_city (ou région ou pays selon la précision de 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 des 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 votre série temporelle GeoX, effectuez une jointure externe gauche dans votre pipeline de données par rapport au produit cartésien complet des dates et des régions cibles.

Post-traitement et extraction des 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 rapport. 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 télécharger le fichier CSV des cibles géographiques statiques dans Cibles géographiques pour effectuer la jointure localement dans le code.
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

Lors de l'exécution de mutations de ciblage géographique de campagne ou de 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

Mise en forme des dates : le champ segments.date renvoie des chaînes de date ISO 8601 au format YYYY-MM-DD. Dans votre pipeline ETL, sérialisez les champs de date explicitement sous forme de 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îne (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 exécutez une étude multicellulaire, vous devez fournir des métriques de dépenses distinctes pour chaque groupe de traitement.
Association 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 présentent 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érie temporelle quotidienne : les données doivent être agrégées par jour.
- Niveau géographique : chaque conversion doit être associé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 groupe de codes postaux 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 le revenu net avec des valeurs négatives pour les remboursements, vous devez utiliser les chiffres bruts pour le test et appliquer un taux de remboursement ultérieurement.

Rapports

Erreurs asynchrones