Utiliser des filtres de groupes de fiches dans les jobs par lot

Lorsque vous travaillez avec des filtres de groupe de fiches dans le contexte d'un AdGroupCriterion.listing_group ou d'un AssetGroupListingGroupFilter, tenez compte des points suivants lorsque vous concevez votre intégration.

Fractionnement par lot

Si des opérations d'un job par lot contiennent des critères de groupe d'annonces ou des filtres de groupe de fiches de groupe de composants, les opérations du job par lot sont divisées en plusieurs sous-lots lorsqu'elles sont reçues par le serveur de l'API Google Ads. Contrairement aux opérations standards d'un job par lot, chaque sous-lot contenant des opérations de filtrage de groupes de fiches est traité de manière atomique.

La façon dont les jobs par lot contenant des filtres de groupe de fiches sont divisés en sous-lots est déterminée par les facteurs suivants :

  1. Type de filtre de groupe de fiches
  2. Le filtre de groupe de fiches AdGroup ou AssetGroup cible
  3. Ordre de priorité des opérations

Voici comment les opérations sont regroupées :

  • Toutes les opérations AssetGroupListingGroupFilterOperation consécutives (create, update et remove) ciblant le même AssetGroup sont regroupées dans un sous-lot atomique (aucun comportement d'échec partiel).
  • Toutes les opérations AdGroupCriterionOperation consécutives (create, update et remove) pour les critères LISTING_GROUP (AdGroupCriterion.listing_group) ciblant le même AdGroup sont regroupées dans un sous-lot atomique (aucun comportement d'échec partiel).
  • Toutes les autres opérations consécutives sont regroupées dans des sous-lots non atomiques (comportement en cas d'échec partiel).

Le schéma suivant illustre ce concept. Chacune des zones grises représente un job par lot tel qu'il a été envoyé à l'aide de l'API Google Ads. Dans les zones grises, les opérations individuelles sont regroupées par couleur pour représenter les sous-lots créés par le serveur de l'API Google Ads. L'ordre des opérations dans chacune des zones grises correspond à l'ordre dans lequel les opérations auraient été ajoutées au job par lot.

Schéma montrant les opérations par lot regroupées en sous-lots

Limites

Lorsque vous utilisez des filtres de groupe de fiches dans le contexte de jobs par lot, les limites suivantes s'appliquent :

  • Un sous-lot atomique unique d'opérations AdGroupCriterionOperation consécutives (create, update et remove) pour les critères LISTING_GROUP (AdGroupCriterion.listing_group) ciblant le même AdGroup ne peut pas dépasser 20 000 opérations. Toutefois, il est recommandé de ne pas dépasser 10 000 opérations. Étant donné que chaque AddBatchJobOperationsRequest est limité à 10 000 opérations, un sous-lot AdGroup de 10 001 à 20 000 opérations doit être importé dans au moins deux requêtes AddBatchJobOperations consécutives.
  • Un sous-lot atomique unique d'opérations AssetGroupListingGroupFilterOperation consécutives (create, update et remove) ciblant le même AssetGroup ne peut pas dépasser 10 000 opérations.
  • Si vous dépassez l'une de ces limites de nombre d'opérations (ou si vous dépassez la limite interne de taille en octets sérialisée du serveur pour un seul sous-lot), le job par lot est abandonné au niveau de ce sous-lot. Tous les sous-lots précédents qui ont déjà été traités restent validés, tandis que toutes les opérations du sous-lot incriminé et de tous les sous-lots suivants échouent avec le code d'erreur InternalError.INTERNAL_ERROR.

Dépannage

Les opérations de filtrage des groupes de fiches dans un job par lot sont traitées comme une seule transaction. Cela peut entraîner l'échec de nombreuses opérations en raison d'un petit nombre d'opérations erronées. De plus, en raison de la façon dont les opérations BatchJob sont traitées, la cause première des échecs peut apparaître à un index avant ou après les échecs en aval.

Par exemple, lors du traitement d'une réponse de ListBatchJobResults :

Ces erreurs indiquent que l'opération à cet index a été annulée, car une autre opération du même sous-lot atomique a échoué. Pour identifier l'origine du problème, parcourez les messages status de chaque BatchJobResult (avant et après le operation_index de l'erreur de transaction) pour les opérations partageant le même ID AdGroup ou AssetGroup.