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é au maximum. Ces modifications devraient donc être mineures.
Rapports
De nombreux rapports AWQL continueront de fonctionner. En coulisses, lorsque vous utilisez la nouvelle infrastructure, les scripts convertissent votre requête AWQL en GAQL (nouveau langage de requête pour l'API Google Ads), l'exécutent sur le nouveau backend, puis convertissent les résultats dans le format initialement utilisé par les rapports AWQL. Les requêtes avec GAQL sont transmises telles quelles.
En raison de ce surcoût, nous vous recommandons d'examiner vos scripts et de remplacer les requêtes AWQL par des requêtes 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, ou le générateur de requêtes interactif pour vous aider à créer des requêtes.
Voici quelques limites de la traduction automatique AWQL vers GAQL :
- Toutes les requêtes AWQL ne se traduisent pas de manière propre en requêtes GAQL. Dans ce cas, un message d'erreur contenant des détails sur le problème est consigné pour vous aider à les corriger manuellement.
- Tous les types de rapports AWQL ne sont pas compatibles avec GAQL.
- GAQL n'accepte pas les lignes ne comportant aucune impression. Spécifier qu'un rapport doit inclure zéro impression entraînera une erreur.
- Certains champs ambigus ne peuvent pas être utilisés dans les filtres. Par exemple, "Titre" peut faire référence à un nombre illimité de champs d'annonces 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 des API Google Ads. Par exemple, pour filtrer par nom de campagne, vous deviez auparavant utiliser :
.withCondition('CampaignName = "SOME_CAMPAIGN_NAME"')
Dans la mesure du possible, vous devez désormais utiliser les nouveaux noms de champ pour ces conditions :
.withCondition('campaign.name = "SOME_CAMPAIGN_NAME"')
Toutefois, nous avons fait en sorte que les anciens noms soient mappés sur 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 que le script continue de fonctionner. Si vous rencontrez des problèmes avec les anciens noms de style, mettez à jour vos scripts pour utiliser les nouveaux noms de style en tant que première étape de dépannage.
Limites
De nombreuses limites sont identiques à celles de l'ancienne infrastructure, et les modifications apportées ici devraient généralement améliorer les performances.
- Les limites de temps sont les mêmes. L'exécution d'un script peut durer 30 minutes.
- Un seul itérateur renvoie 50 000 entités par défaut, mais ce comportement peut être ignoré. Auparavant, cette limite de 50 000 contacts n'était pas personnalisable.
- Un seul sélecteur peut gérer jusqu'à 10 000 ID (non modifiés).
- La nouvelle infrastructure ne limite pas le nombre d'entités pouvant être traitées dans un seul script. 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. La limite était auparavant de 250 000.
- La sortie de journalisation est tronquée à 100 ko (inchangée).
- Les quotas des services Apps Script (SpreadsheetApp, MailApp, etc.) restent inchangés.
- Les quotas Google Ads seront appliqués comme si vous utilisiez l'API. Autrement dit, votre script sera soumis aux limites de débit de l'API, mais cela vous permettra d'accéder à davantage de rapports ou d'effectuer 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.