O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Gerenciar dados com eficiência

Uma função essencial de muitos aplicativos do Google Ads é recuperar dados da conta para casos de uso como análise de dados, consultas de clientes e verificações de conformidade com as políticas. Ao buscar os dados, otimize o uso para não sobrecarregar os servidores do Google ou correr o risco de ter a limitação de taxa. Para mais detalhes, consulte os guias sobre limitação de taxa e como manter um endereço de e-mail para contato atualizado.

Entender a política de uso de recursos para relatórios

Para garantir a estabilidade dos servidores, a API Google Ads limita os padrões de consulta GoogleAdsService.Search e GoogleAdsService.SearchStream que consomem quantidades excessivas de recursos da API. Se um padrão de consulta específico for limitado, outros serviços, métodos e padrões de consulta continuarão funcionando sem serem afetados. Os erros a seguir são gerados para solicitações limitadas:

Código do erro
`QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION` ou `QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION`, dependendo da duração do alto uso de recursos.

Se você encontrar esses erros, aguarde 5 minutos antes de tentar novamente as solicitações que falharam com QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION e 30 minutos para as solicitações que falharam com QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

Para ajudar você a identificar e monitorar seus relatórios caros, também retornamos uma métrica de custo para relatórios individuais:

Método	Campo de custo
`GoogleAdsService.Search`	`SearchGoogleAdsResponse.query_resource_consumption`
`GoogleAdsService.SearchStream`	`SearchGoogleAdsStreamResponse.query_resource_consumption`

A métrica de custo retornada por esses campos depende de vários fatores, como:

O tamanho das suas contas
As visualizações e colunas que você busca nos seus relatórios
A carga nos servidores de API Google Ads

A tabela a seguir lista estatísticas agregadas sobre o consumo de recursos de vários padrões de consulta em servidores da API Google Ads para ajudar você a rastrear e ajustar consultas caras:

Janela de tempo	Média (p50)	P70 (moderadamente alta)	P95 (muito alta)
Curto prazo (5 min)	6000	30000	1800000
Longo prazo (24 horas)	16.000	90000	8400000

Por exemplo, imagine que você esteja executando um padrão de consulta como o seguinte, que consome 600 unidades de recursos por relatório:

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = 'YYYY-MM-DD'

Você executa essa consulta para várias contas de cliente em várias datas individuais, modificando a consulta para substituir valores diferentes para o filtro segments.date. A tabela a seguir mostra o número de relatórios que você pode gerar em um determinado período para que o uso de recursos se encaixe em vários buckets de uso de recursos.

Janela de tempo	Média	Moderadamente alta	Muito alto
Curto prazo (5 min)	10	50	3000
Longo prazo (24 horas)	26	150	14000

Executar esse padrão de consulta 10 vezes em 5 minutos seria considerado um uso médio, enquanto executar 3.000 relatórios em 5 minutos seria considerado um uso muito alto.

Há várias estratégias para otimizar o consumo de recursos dos seus relatórios. O restante deste guia aborda algumas dessas estratégias.

Armazenar dados em cache

Armazene em cache os detalhes da entidade que você busca nos servidores de API em um banco de dados local, em vez de chamar o servidor sempre que precisar dos dados, principalmente para entidades que são acessadas com frequência ou que mudam com pouca frequência. Use change-event e change-status sempre que possível para detectar quais objetos mudaram desde a última sincronização dos resultados.

Otimizar a frequência de geração de relatórios

O Google Ads publicou diretrizes sobre a atualização de dados e a frequência com que eles são atualizados. Use essas orientações para determinar a frequência com que os relatórios serão buscados.

Se você precisar atualizar contas regularmente, recomendamos limitar o número delas a um pequeno conjunto, por exemplo, apenas as 20 principais contas do Google Ads. O restante pode ser atualizado com menos frequência, por exemplo, uma ou duas vezes por dia.

Otimizar o tamanho dos relatórios

Seu aplicativo precisa buscar grandes lotes de dados em vez de executar um grande número de relatórios pequenos. Um fator que influencia essa escolha são os limites da conta.

Por exemplo, considere o código a seguir, que extrai as estatísticas de grupos de anúncios específicos e atualiza uma tabela de banco de dados de estatísticas:

  List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  foreach (long adGroupId in adGroupIds)
  {
    string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
        "metrics.cost_micros, metrics.impressions, segments.date FROM " +
        "ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
        $"ad_group.id = {adGroupId}";
    List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

Esse código funciona bem em uma conta de teste pequena. No entanto, o Google Ads aceita até 20.000 grupos de anúncios por campanha e 10.000 campanhas por conta. Portanto, se esse código for executado em uma conta grande do Google Ads, ele poderá sobrecarregar os servidores da API Google Ads, levando à limitação de taxa e à limitação de largura de banda.

Uma abordagem melhor seria gerar um único relatório e processá-lo localmente. Uma dessas abordagens que usa um mapa na memória é mostrada:

  HashSet<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
      "metrics.cost_micros, metrics.impressions, segments.date FROM " +
      "ad_group WHERE segments.date DURING LAST_7_DAYS";
  List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

Isso reduz a carga nos servidores da API Google Ads devido ao menor número de relatórios em execução.

Se o relatório for muito grande para ser mantido na memória, divida a consulta em grupos menores adicionando uma cláusula LIMIT como esta:

SELECT
  ad_group.id,
  ad_group.name,
  metrics.clicks,
  metrics.cost_micros,
  metrics.impressions,
  segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
  AND ad_group.id IN (id1, id2, ...)
LIMIT 100000

Os rótulos são outra maneira de agrupar entidades e reduzir o número de consultas de relatórios. Consulte o guia de rótulos para saber mais.

Otimizar o que você busca

Ao gerar relatórios, preste atenção às colunas incluídas nas consultas. Considere o exemplo a seguir, que está programado para ser executado a cada hora:

SELECT
  customer.id,
  customer.currency_code,
  campaign.id,
  campaign.name,
  ad_group.id,
  ad_group.name,
  ad_group_criterion.keyword.match_type,
  ad_group_criterion.keyword.text,
  ad_group_criterion.criterion_id,
  ad_group_criterion.quality_info.creative_quality_score,
  ad_group_criterion.system_serving_status,
  ad_group_criterion.negative,
  ad_group_criterion.quality_info.quality_score,
  ad_group_criterion.quality_info.search_predicted_ctr,
  ad_group_criterion.quality_info.post_click_quality_score,
  metrics.historical_landing_page_quality_score,
  metrics.search_click_share,
  metrics.historical_creative_quality_score,
  metrics.clicks,
  metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS

As únicas colunas que podem mudar a cada hora são metrics.clicks e metrics.impressions. Todas as outras colunas são atualizadas com pouca frequência ou nunca, então é muito ineficiente buscá-las a cada hora. Você pode armazenar esses valores em um banco de dados local e executar um relatório de evento de alteração ou de status de alteração para fazer o download das mudanças uma ou duas vezes por dia.

Em alguns casos, é possível reduzir o número de linhas que você baixa aplicando filtros adequados.

Limpar contas não usadas

Se o aplicativo gerencia contas de clientes de terceiros, é preciso desenvolvê-lo considerando a rotatividade de clientes. Limpe periodicamente seus processos e repositórios de dados para remover contas de clientes que não usam mais seu aplicativo. Ao limpar contas não utilizadas do Google Ads, lembre-se do seguinte:

Revogue a autorização que o cliente deu ao seu aplicativo para gerenciar a conta dele.
Pare de fazer chamadas de API para as contas do Google Ads do cliente. Isso se aplica especialmente a jobs off-line, como cron jobs e pipelines de dados, que são projetados para serem executados sem intervenção do usuário.
Se o cliente revogar a autorização, seu aplicativo precisará lidar com a situação de maneira adequada e evitar o envio de chamadas de API inválidas para os servidores de API do Google.
Se o cliente tiver cancelado a conta do Google Ads, detecte contas canceladas e evite enviar chamadas de API inválidas para os servidores de API do Google.
Exclua os dados que você baixou das contas do Google Ads do cliente do seu banco de dados local após um período adequado.

Monitoramento

Avançar

Limites de taxas