Migration

La nouvelle infrastructure des scripts Google Ads est basée sur l'API Google Ads. En raison de l'architecture différente de cette API, vous devrez peut-être mettre à jour vos scripts existants. Nous avons fait tout notre possible pour assurer une rétrocompatibilité maximale. Ces modifications doivent donc être mineures.

Rapports

De nombreux rapports AWQL continueront de fonctionner. En arrière-plan, lorsque vous utilisez la nouvelle infrastructure, les scripts convertissent votre requête AWQL en GAQL (le nouveau langage de requête pour l'API Google Ads), l'exécutent sur le nouveau backend, puis reconvertissent les résultats au format utilisé à l'origine par les rapports AWQL. Les requêtes avec GAQL seront transmises telles quelles.

En raison de cette surcharge, nous vous recommandons de passer en revue vos scripts et de remplacer les requêtes AWQL par GAQL dans la mesure du possible. Vous pouvez utiliser l'outil de migration de requêtes, qui utilise la même logique que les scripts pour déterminer la requête GAQL pour une requête AWQL donnée. Vous pouvez également utiliser le générateur de requêtes interactives pour créer des requêtes.

Voici quelques limites qui s'appliquent à la traduction automatique de AWQL en GAQL:

  • Les requêtes AWQL ne sont pas toutes correctement traduites en requêtes GAQL. Dans ce cas, un message d'erreur contenant des informations sur le problème est consigné pour vous aider à les résoudre manuellement.
  • Tous les types de rapports AWQL ne sont pas acceptés dans GAQL.
  • Le langage GAQL n'accepte pas les "lignes sans impression". Si vous spécifiez qu'un rapport ne doit inclure aucune impression, une erreur est générée.
  • Certains champs ambigus ne peuvent pas être utilisés dans les filtres. Par exemple, "Titre" peut faire référence à n'importe quel nombre de champs d'annonce différents.
  • Certains champs peuvent renvoyer des résultats dans un format différent, par exemple en divisant un résultat en plusieurs colonnes.

Organiser les sélecteurs

Lors de l'extraction de ressources à l'aide de scripts, il est assez courant d'utiliser des appels withCondition et orderBy pour restreindre ou classer les résultats dans l'itérateur. Les champs de ces appels utilisent désormais les nouveaux noms de l'API Google Ads. Par exemple, pour filtrer par nom de campagne, vous auriez utilisé précédemment:

.withCondition('CampaignName = "SOME_CAMPAIGN_NAME"')

Vous devez maintenant utiliser les nouveaux noms de champs pour ces conditions dans la mesure du possible:

.withCondition('campaign.name = "SOME_CAMPAIGN_NAME"')

Cela dit, nous nous sommes efforcés d'inclure un mappage des anciens noms vers les nouveaux. Par conséquent, si votre script utilise toujours CampaignName, il sera automatiquement remplacé par campaign.name au moment de l'exécution pour s'assurer que le script fonctionne toujours. Si vous rencontrez des problèmes avec les anciens noms de style, mettez à jour vos scripts pour utiliser les nouveaux noms comme première étape de dépannage.

Limites

De nombreuses limites sont identiques à celles de l'ancienne infrastructure, et les modifications apportées ici contribuent généralement à améliorer les performances.

  • Les limites de temps sont les mêmes. Un script peut s'exécuter pendant 30 minutes.
  • Par défaut,un seul itérateur renvoie 50 000 entités, mais ce nombre peut être remplacé. Auparavant, cette limite de 50 000 n'était pas personnalisable.
  • Un seul sélecteur peut gérer au maximum 10 000 ID (non modifiés).
  • Dans la nouvelle infrastructure, le nombre d'entités pouvant être traitées dans un seul script n'est pas limité. Auparavant,la limite était de 250 000.
  • La nouvelle infrastructure ne limite pas le nombre de mots clés ou d'annonces pouvant être créés par exécution. Auparavant,la limite était de 250 000.
  • La sortie des journaux est tronquée à 100 Ko (aucune modification).
  • Les quotas des services Apps Script (SpreadsheetApp, MailApp, etc.) restent inchangés.
  • Les quotas pour Google Ads sont appliqués comme si vous utilisiez l'API. En d'autres termes, votre script sera soumis à des limites de débit des API, mais cela vous permettra d'accéder plus facilement à davantage de rapports ou d'apporter davantage de modifications par exécution.

Autres modifications

ExecutionInfo n'expose plus getRemainingCreateQuota() ni getRemainingGetQuota(), car ces quotas ne s'appliquent plus dans la nouvelle interface.