Cómo usar filtros de grupos de fichas en trabajos por lotes

Cuando trabajes con filtros de grupos de fichas en el contexto de un AdGroupCriterion.listing_group o un AssetGroupListingGroupFilter, ten en cuenta las siguientes consideraciones cuando diseñes tu integración.

División por lotes

Punto clave: Te recomendamos que agregues operaciones AssetGroupListingGroupFilterOperation (create, update y remove) que segmenten para el mismo AssetGroup y operaciones AdGroupCriterionOperation (create, update y remove) para los criterios LISTING_GROUP (AdGroupCriterion.listing_group) que segmenten para el mismo AdGroup a un trabajo por lotes de forma consecutiva, de modo que el conjunto de operaciones se trate de forma atómica durante la división de lotes.

Si hay operaciones en un trabajo por lotes que contienen criterios de grupo de anuncios o filtros de grupos de fichas de grupos de recursos, las operaciones del trabajo por lotes se dividen en varios sublotes cuando las recibe el servidor de la API de Google Ads. A diferencia de las operaciones estándar en un trabajo por lotes, cada sublote que contiene operaciones de filtro de grupos de fichas se trata de forma atómica.

La forma en que los trabajos por lotes que contienen filtros de grupos de fichas se dividen en sublotes se determina según los siguientes factores:

1. Tipo de filtro de grupos de fichas
2. El AdGroup o AssetGroup al que se segmenta el filtro de grupo de fichas
3. Orden de las operaciones

Considera cómo se agrupan las operaciones:

• Todas las operaciones AssetGroupListingGroupFilterOperation consecutivas (create, update y remove) orientadas al mismo AssetGroup se agrupan en un sublote atómico (sin comportamiento de falla parcial).
• Todas las operaciones AdGroupCriterionOperation consecutivas (create, update y remove) para los criterios LISTING_GROUP (AdGroupCriterion.listing_group) que se segmentan para el mismo AdGroup se agrupan en un sublote atómico (sin comportamiento de falla parcial).
• Todas las demás operaciones consecutivas se agrupan en sublotes no atómicos (comportamiento de falla parcial).

Nota: Si también creas el AssetGroup en el mismo trabajo por lotes, coloca cualquier operación AssetOperation (create) de requisito previo para los nuevos recursos Asset antes de AssetGroupOperation (create), seguida inmediatamente por sus operaciones AssetGroupAssetOperation (create) (que se ejecutan juntas en un sublote atómico anterior) y, luego, las operaciones AssetGroupListingGroupFilterOperation consecutivas (que se ejecutan en el siguiente sublote atómico). Debido a que estos forman dos sublotes separados, un error en el sublote AssetGroupListingGroupFilterOperation revierte los filtros del grupo de fichas sin revertir los recursos AssetGroup y AssetGroupAsset recién creados.

Término clave: Consecutivo se refiere al orden de las operaciones en el trabajo por lotes. Si las operaciones orientadas al mismo AdGroup o AssetGroup se intercalan con operaciones orientadas a un grupo diferente, se dividen en sublotes separados y ya no se procesan como una sola transacción atómica.

En el siguiente diagrama, se ilustra este concepto. Cada uno de los cuadros grises representa un trabajo por lotes tal como se envió con la API de Google Ads. Dentro de los cuadros grises, las operaciones individuales se agrupan por color para representar los sublotes que crea el servidor de la API de Google Ads. El orden de las operaciones en cada uno de los cuadros grises corresponde al orden en el que se habrían agregado las operaciones al trabajo por lotes.

Limitaciones

Cuando trabajes con filtros de grupos de fichas en el contexto de trabajos por lotes, se aplicarán las siguientes limitaciones:

• Un solo sublote atómico de operaciones AdGroupCriterionOperation consecutivas (create, update y remove) para los criterios de LISTING_GROUP (AdGroupCriterion.listing_group) que se segmentan para el mismo AdGroup no puede superar las 20,000 operaciones de duración. Sin embargo, se recomienda no superar las 10,000 operaciones. Debido a que cada AddBatchJobOperationsRequest tiene un límite de 10,000 operaciones, un sublote de AdGroup de 10,001 a 20,000 operaciones se debe subir en, al menos, dos solicitudes AddBatchJobOperations consecutivas.
• Un solo sublote atómico de operaciones AssetGroupListingGroupFilterOperation consecutivas (create, update y remove) orientadas al mismo AssetGroup no puede superar las 10,000 operaciones.
• Si se incumple cualquiera de estos límites de recuento de operaciones (o se excede el límite interno del servidor para el tamaño de bytes serializados de un solo sublote), se anula el trabajo por lotes en ese sublote: los sublotes anteriores que ya se completaron permanecen confirmados, mientras que todas las operaciones del sublote infractor y los sublotes posteriores fallan con InternalError.INTERNAL_ERROR.

Solución de problemas

Las operaciones de filtro de grupos de fichas en un trabajo por lotes se procesan como una sola transacción, lo que puede generar situaciones en las que muchas operaciones fallen debido a una pequeña cantidad de operaciones erróneas. Además, debido a la forma en que se procesan las operaciones BatchJob, la causa raíz de las fallas puede aparecer en un índice antes o después de las fallas posteriores.

Por ejemplo, cuando se procesa una respuesta de ListBatchJobResults:

• En el caso de los grupos de fichas AdGroupCriterionOperation, es posible que las operaciones consecutivas orientadas al mismo AdGroup hayan fallado con CriterionError.LISTING_GROUP_ERROR_IN_ANOTHER_OPERATION (Product group operations are atomic within the same ad group. This operation failed because another operation targeting the same ad group ID was invalid.).
• En el caso de las operaciones AssetGroupListingGroupFilterOperation, es posible que las operaciones consecutivas orientadas al mismo AssetGroup hayan fallado con BatchJobError.ASSET_GROUP_LISTING_GROUP_FILTER_TRANSACTION_FAILURE.

Estos errores indican que se revirtió la operación en ese índice porque falló otra operación en el mismo sublote atómico. Para identificar la causa raíz del problema, itera los mensajes status en cada BatchJobResult, antes y después de la operation_index del error de transacción, para las operaciones que comparten el mismo ID de AdGroup o AssetGroup.