Répertorier des filtres de groupe dans les tâches 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 des lots

Point important : Nous vous recommandons d'ajouter les opérations AssetGroupListingGroupFilterOperation ciblant le même AssetGroup et les opérations AdGroupCriterionOperation contenant un listing_group ciblant le même AdGroup à un job par lot de manière consécutive, afin que l'ensemble des opérations soit traité de manière atomique lors de la division 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 composants, elles sont divisées en plusieurs sous-lots lorsqu'elles sont reçues par le serveur de l'API Google Ads. Notez que, contrairement aux opérations standards d'un job par lot, chaque sous-lot contenant des opérations de filtrage de groupes d'annonces 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 AdGroupCriterion ou AssetGroup cible
3. Ordre de priorité des opérations

Réfléchissez à la façon dont les opérations sont regroupées :

• Toutes les opérations AssetGroupListingGroupFilterOperation consécutives ciblant le même AssetGroup sont regroupées dans un sous-lot atomique (sans comportement d'échec partiel).
• Toutes les opérations AdGroupCriterionOperation consécutives contenant un ciblage listing_group sur le même AdGroup sont regroupées dans un sous-lot atomique (sans 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).

Terme clé : Consécutif fait référence à l'ordre des opérations dans le job par lot.

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.

Atomicité dans la répartition par lot

L'API Google Ads peut diviser les opérations d'un job par lot envoyé en sous-lots plus petits pour le traitement. Si vous ne regroupez pas les opérations associées, comme les modifications de groupes de fiches dans un AssetGroup et un AdGroup, consécutivement dans un job par lot, l'API Google Ads peut diviser ces opérations en différents sous-lots. Cette séparation peut entraîner l'échec de la modification ou laisser le compte dans un état incohérent.

Regroupement logique

AssetGroupListingGroupFilterOperation gère les groupes de fiches dans un AssetGroup, ce qui est courant dans les campagnes Performance Max. AdGroupCriterionOperation gère les groupes de fiches dans une AdGroup, ce qui est courant dans les campagnes Shopping standards. Les deux sont utilisés pour définir le ciblage produit. Si vous apportez des modifications qui affectent la hiérarchie du ciblage des produits dans les deux contextes, regroupez ces opérations de manière consécutive dans votre job par lot pour vous assurer qu'elles sont appliquées ensemble.

Cohérence des données

Pour assurer la cohérence des données et éviter les mises à jour partielles, ajoutez les opérations liées aux groupes de fiches consécutivement à votre job par lot. Cet ordre permet de les regrouper en sous-lots atomiques selon la logique de fractionnement des lots de l'API, ce qui évite que votre compte ne soit laissé dans un état incohérent.

Limites

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

• Un même lot d'opérations AdGroupCriterionOperation contenant un listing_group et ciblant le même AdGroup ne peut pas comporter plus de 20 000 opérations. Toutefois, nous vous recommandons de ne pas dépasser 10 000 opérations.
• Un même lot d'opérations AssetGroupListingGroupFilterOperation ciblant le même AssetGroup ne peut pas dépasser 10 000 opérations.
• Si vous ne respectez pas l'une de ces conditions, l'ensemble du job par lot échouera.

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, lorsque vous traitez une réponse de ListBatchJobResults, vous pouvez constater que plusieurs opérations ont échoué avec un message d'état Ad group is invalid due to the listing groups it contains. Ce message indique généralement que l'opération à cet index a été annulée en raison d'un échec d'opération à un autre index. Pour identifier la cause première du problème, nous vous recommandons de parcourir tous les messages d'état dans BatchJobResult, avant et après l'index du message d'erreur Ad group is invalid, afin de trouver des informations supplémentaires sur l'erreur.