Considere estas diretrizes ao usar o BatchJobService.
Melhorar a capacidade de processamento
É preferível ter menos jobs maiores do que muitos jobs menores.
Ordene as operações enviadas por tipo de operação (exceto as operações interdependentes que precisam ser agrupadas consecutivamente em sublotes atômicos). Por exemplo, se o job tiver operações para adicionar campanhas padrão, grupos de anúncios e critérios de grupos de anúncios, ordene as operações no upload para que todas as operações de campanha sejam as primeiras, seguidas por todas as operações de grupo de anúncios e, por fim, todas as operações de critério de grupo de anúncios.
Nas operações do mesmo tipo, é possível melhorar o desempenho agrupando-as por recurso pai. Por exemplo, se você tiver uma série de objetos
AdGroupCriterionOperation, é mais eficiente agrupar as operações por grupo de anúncios do que misturar operações que afetam os critérios de grupos de anúncios em diferentes grupos de anúncios.
Atomicidade na divisão em lote
A API Google Ads divide as operações em um job em lote enviado em sublotes menores para processamento. Enquanto os sublotes padrão são executados com a falha parcial ativada, os sublotes de determinadas operações interdependentes são processados de forma atômica como uma única transação:
- Operações
AdGroupCriterionOperationconsecutivas (create,updateeremove) para critériosLISTING_GROUP(AdGroupCriterion.listing_group) visando o mesmoAdGroup(falha comCriterionError.LISTING_GROUP_ERROR_IN_ANOTHER_OPERATIONse alguma operação no grupo falhar). - Operações
AssetGroupListingGroupFilterOperationconsecutivas (create,updateeremove) que segmentam o mesmoAssetGroup(falha comBatchJobError.ASSET_GROUP_LISTING_GROUP_FILTER_TRANSACTION_FAILUREse alguma operação no grupo falhar). - Uma operação
AssetGroupOperation(create) imediatamente seguida por até 999 operaçõesAssetGroupAssetOperation(create) visando o mesmoAssetGroup(falha comBatchJobError.ASSET_GROUP_AND_ASSET_GROUP_ASSET_TRANSACTION_FAILUREse alguma operação no grupo falhar). CadaAssetGroupOperation(updateouremove) é executado no próprio sublote independente de operação única. - Uma operação de criação (
create) de campanha Performance MaxCampaignOperationcom as diretrizes de marca ativadas (brand_guidelines_enableddefinido comotrueou deixado sem definição, já que o padrão étrue, a menos que seja explicitamente definido comofalseou que uma campanha Performance Max para metas de turismo seja criada) seguida imediatamente por até 999 operações de criação (create) deCampaignAssetOperationsegmentando o mesmoCampaign(falha comBatchJobError.CAMPAIGN_AND_CAMPAIGN_ASSET_TRANSACTION_FAILUREse alguma operação no grupo falhar). As campanhas Performance Max de varejo (com um feed do Merchant Center) podem ser criadas sem vincular recursos de marcaCampaignAssetno mesmo sublote atômico.
Para sub-lotes de criação de AssetGroup e de campanhas Performance Max Campaign (até 1.000 operações no total por sub-lote; qualquer operação filha create além de 999 é transferida para o próximo sub-lote não atômico):
- A operação
createpai (resource_nameemAssetGroupouCampaign) e as operaçõescreatefilhas consecutivas (asset_groupemAssetGroupAssetoucampaignemCampaignAsset) precisam especificar o mesmo ID temporário negativo. - Coloque todas as operações de pré-requisito
AssetOperation(create) para novos recursosAssetantes do paiAssetGroupOperationouCampaignOperation(create), nunca entre o paicreatee as operações de link filhocreate(que fechariam imediatamente o sublote atômico e dividiriam a criação do recurso pai dos recursos vinculados).
Quando um sublote atômico falha, o
BatchJobResult.status da operação ofensiva contém o erro de validação
subjacente, enquanto as operações restantes nesse sublote são revertidas
com o erro de transação correspondente para esse sublote. Inspecione as entradas BatchJobResult adjacentes que compartilham o mesmo ID AdGroup, AssetGroup ou Campaign para identificar o erro de causa raiz.
Se as operações relacionadas em qualquer um desses grupos não forem adicionadas consecutivamente, a API Google Ads as dividirá em sublotes separados, fazendo com que a modificação não atenda aos requisitos mínimos de recursos ou deixando as árvores de grupos de produtos anunciados incompletas. Consulte Usar filtros do grupo de produtos anunciados em jobs em lote e Processamento em lote das campanhas Performance Max para mais detalhes.
Agrupamento lógico
Ao modificar uma hierarquia de segmentação de produtos (AssetGroupListingGroupFilterOperation em campanhas Performance Max ou AdGroupCriterionOperation em campanhas do Shopping) ou criar um novo AssetGroup ou Campaign Performance Max, agrupe todas as operações que segmentam o mesmo recurso pai (AssetGroup, AdGroup ou Campaign) consecutivamente. Isso reduz a contenção de bloqueio de back-end e
mantém as árvores interdependentes juntas.
Consistência de dados
Como as árvores de filtros do grupo de produtos anunciados e os requisitos de recursos das campanhas Performance Max são validados no final de cada transação de sublote atômico, evite dividir as atualizações do mesmo recurso pai em intervalos descontínuos em um job ou em jobs simultâneos.
Evitar problemas de simultaneidade
Ao enviar vários jobs simultâneos para a mesma conta, reduza a probabilidade de jobs operarem nos mesmos objetos ao mesmo tempo, mantendo jobs grandes. Muitos jobs inacabados com o status
RUNNINGque tentam modificar o mesmo conjunto de objetos podem levar a condições semelhantes a um impasse, resultando em lentidão severa e até mesmo falhas de job.Não envie várias operações que modificam o mesmo objeto no mesmo job, porque o resultado pode ser imprevisível.
Recuperar resultados de maneira ideal
Não consulte o status do job com muita frequência, ou você poderá receber erros de limite de taxa.
Deixe
page_sizesem definição (ou defina-o como o máximo de1000) ao chamarListBatchJobResultspara minimizar as idas e voltas de paginação e defina apenasresponse_content_typecomoMUTABLE_RESOURCEse o aplicativo inspecionar os campos de recursos retornados além deresource_name.A ordem dos resultados é a mesma do upload.
Orientações adicionais de uso
É possível definir um limite máximo para o tempo de execução de um job em lote antes que ele seja cancelado. Ao criar um job em lote, defina o campo
metadata.execution_limit_secondscom o limite de tempo de sua preferência, em segundos. Não há limite de tempo padrão semetadata.execution_limit_secondsnão estiver definido.Embora o limite do protocolo seja de 10.000 operações por solicitação, recomendamos adicionar no máximo 1.000 operações por
AddBatchJobOperationsRequeste usar osequence_tokenpara fazer upload do restante das operações para o mesmo job. Dependendo do tamanho das operações, o envio de muitas operações em um únicoAddBatchJobOperationsRequestpode causar um erroBatchJobError.REQUEST_TOO_LARGE. Para resolver esse erro, reduza o número de operações e tente novamente oAddBatchJobOperationsRequest.
Limitações
Cada
BatchJobaceita até um milhão de operações. Exceder esse limite ao chamarAddBatchJobOperationsretorna um erroResourceCountLimitExceededError.RESOURCE_LIMIT(comResourceLimitType.BATCH_JOB_OPERATIONS_PER_JOBemErrorDetails.resource_count_details).Cada conta pode ter até 100 jobs ativos ou pendentes ao mesmo tempo. Exceder esse limite ao criar um job em lote com
MutateBatchJobretorna um erroResourceCountLimitExceededError.RESOURCE_LIMIT(comResourceLimitType.BATCH_JOBS_PER_CUSTOMERemErrorDetails.resource_count_details).Os jobs pendentes com mais de 7 dias são removidos automaticamente.
Cada
AddBatchJobOperationsRequesttem um limite rígido de 10.000 operações de mutação por solicitação. Exceder 10.000 operações em uma única solicitação retorna um erroBatchJobError.REQUEST_TOO_LARGE.Para o campo
page_sizeemListBatchJobResultsRequest:- Se
page_sizenão estiver definido ou for0, o padrão será o máximo de1000. - Se
page_sizeexceder1000ou for menor que0, a API vai retornar um erroBatchJobError.INVALID_PAGE_SIZE.
- Se
Cada
AddBatchJobOperationsRequesttem um tamanho máximo de 41.937.920 bytes. Se você exceder esse limite, vai receber um erroBatchJobError.REQUEST_TOO_LARGE(ou umINTERNAL_ERRORse for rejeitado na camada de transporte). É possível determinar o tamanho serializado da solicitação antes de enviá-la e tomar as medidas apropriadas se ela for muito grande:Java
static final int MAX_REQUEST_BYTES = 41_937_920; // ... (code to get the AddBatchJobOperationsRequest object) int sizeInBytes = request.getSerializedSize();C#
const int MAX_REQUEST_BYTES = 41_937_920; // ... (code to get the AddBatchJobOperationsRequest object) int sizeInBytes = request.CalculateSize();PHP
const MAX_REQUEST_BYTES = 41937920; // ... (code to get the AddBatchJobOperationsRequest object) $size_in_bytes = $request->byteSize();Python
MAX_REQUEST_BYTES = 41_937_920 # ... (code to get the AddBatchJobOperationsRequest object) size_in_bytes = type(request).pb(request).ByteSize()Ruby
MAX_REQUEST_BYTES = 41_937_920 # ... (code to get the AddBatchJobOperationsRequest object) size_in_bytes = request.to_proto.bytesizePerl
use JSON::XS; use constant MAX_REQUEST_BYTES => 41937920; # ... (code to get the AddBatchJobOperationsRequest object) # The Perl client library uses REST/JSON; UTF-8 JSON byte length provides a # conservative upper-bound estimate of the serialized request size. my $json_encoder = JSON::XS->new->utf8->convert_blessed; my $size_in_bytes = length($json_encoder->encode($request));
Tamanho de uma única operação de mutação
Embora a solicitação geral possa ter até 41.937.920 bytes, o tamanho serializado de
um único MutateOperation no lote é limitado a
10.484.504 bytes (10 MiB menos 1.256 bytes). Exceder esse limite retorna um erro BatchJobError.REQUEST_TOO_LARGE. Embora a documentação de referência de BatchJobError.REQUEST_TOO_LARGE cite o limite de 10.484.504 bytes, AddBatchJobOperations retorna esse mesmo código de erro quando qualquer um dos três limites de solicitação (41.937.920 bytes de solicitação total, 10.484.504 bytes de operação única ou 10.000 operações por chamada) é excedido, com o campo message do erro especificando qual limite foi violado.