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 objeto AdGroupCriterion.listing_group o AssetGroupListingGroupFilter, ten en cuenta las siguientes consideraciones cuando diseñes tu integración.

División por lotes

Punto clave: Recomendamos agregar operaciones AssetGroupListingGroupFilterOperation (create, update y remove) que segmenten AssetGroup y operaciones AdGroupCriterionOperation (create, update y remove) para criterios LISTING_GROUP (AdGroupCriterion.listing_group) que segmenten 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 por lotes.

Si hay operaciones en un trabajo por lotes que contienen criterios del grupo de anuncios o filtros del grupo de fichas del grupo 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 sub-lotes se determina según los siguientes factores:

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

Considera cómo se agrupan las operaciones:

• Todas las operaciones AssetGroupListingGroupFilterOperation consecutivas (create, update y remove) que tienen como objetivo el mismo AssetGroup se agrupan en un sub-lote atómico (sin comportamiento de falla parcial).
• Todas las operaciones consecutivas de AdGroupCriterionOperation (create, update y remove) para los criterios de LISTING_GROUP (AdGroupCriterion.listing_group) que 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 sub-lotes no atómicos (comportamiento de falla parcial).

Nota: Si también creas el objeto AssetGroup en el mismo trabajo por lotes, coloca las operaciones de AssetOperation (create) de requisitos previos para los recursos Asset nuevos antes de las operaciones de AssetGroupOperation (create), seguidas inmediatamente por sus operaciones de AssetGroupAssetOperation (create) (que se ejecutan juntas en un sublote atómico anterior) y, luego, las operaciones consecutivas de AssetGroupListingGroupFilterOperation (que se ejecutan en el siguiente sublote atómico). Como estos forman dos sublotes separados, si falla el sublote AssetGroupListingGroupFilterOperation, se revierten los filtros del grupo de fichas sin revertir los recursos AssetGroup y AssetGroupAsset creados recientemente.

Término clave: Consecutivo hace referencia al orden de las operaciones en el trabajo por lotes. Si las operaciones que segmentan el mismo AdGroup o AssetGroup se intercalan con operaciones que segmentan 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 una de las casillas grises representa un trabajo por lotes enviado 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 lote secundario atómico de operaciones AdGroupCriterionOperation consecutivas (create, update y remove) para criterios de LISTING_GROUP (AdGroupCriterion.listing_group) dirigidos al mismo AdGroup no puede superar las 20,000 operaciones de longitud. Sin embargo, se recomienda no exceder las 10,000 operaciones. Dado que cada AddBatchJobOperationsRequest tiene un límite de 10,000 operaciones, se debe subir un lote secundario de AdGroup de 10,001 a 20,000 operaciones en al menos dos solicitudes de AddBatchJobOperations consecutivas.
• Un solo lote secundario atómico de operaciones AssetGroupListingGroupFilterOperation consecutivas (create, update y remove) que se dirigen al mismo AssetGroup no puede superar las 10,000 operaciones.
• Si se incumple cualquiera de estos límites de recuento de operaciones (o se supera el límite interno de tamaño de bytes serializados del servidor para un solo lote secundario), se anula el trabajo por lotes en ese lote secundario: todos los lotes secundarios anteriores que ya se completaron permanecen confirmados, mientras que todas las operaciones del lote secundario infractor y los lotes secundarios posteriores fallan con InternalError.INTERNAL_ERROR.

Solución de problemas

Las operaciones de filtrado 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 fallan debido a una pequeña cantidad de operaciones erróneas. Además, debido a la forma en que se procesan las operaciones de 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 dirigidas 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 de AssetGroupListingGroupFilterOperation, es posible que las operaciones consecutivas dirigidas al mismo AssetGroup hayan fallado con BatchJobError.ASSET_GROUP_LISTING_GROUP_FILTER_TRANSACTION_FAILURE.

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