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 a política. Ao buscar os dados, otimize o uso para não sobrecarregar os servidores do Google ou correr o risco de ter a taxa limitada. Para mais detalhes, consulte os guias sobre limitação de taxa e como manter um endereço de e-mail de contato atualizado.

Entenda a política de uso de recursos do Google para relatórios

Para garantir a estabilidade dos servidores, a API Google Ads limita GoogleAdsService.Search e GoogleAdsService.SearchStream padrões de consulta 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 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 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 vamos retornar 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 da API Google Ads.

Para ajudar você a acompanhar consultas caras, estamos publicando estatísticas agregadas iniciais sobre o consumo de recursos de vários padrões de consulta que vemos nos nossos servidores. Vamos publicar números atualizados periodicamente para ajudar você a ajustar suas consultas.

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

Por exemplo, suponha que você esteja executando um padrão de consulta da seguinte maneira, 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 clientes em várias datas individuais, modificando a consulta para substituir valores diferentes pelo filtro segments.date. A tabela a seguir mostra o número de relatórios que você pode executar em uma determinada janela de tempo para que o uso de recursos se ajuste a vários buckets de uso de recursos.

Janela de tempo Média Moderadamente alto Muito alto
Curto prazo (5 minutos) 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

É recomendável armazenar em cache os detalhes da entidade buscados nos servidores da API em um banco de dados local, em vez de chamar o servidor sempre que precisar dos dados, principalmente para entidades acessadas com frequência ou que mudam com pouca frequência. Use evento de mudança e status de mudança sempre que possível para detectar quais objetos foram alterados desde a última sincronização dos resultados.

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

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

Se você precisar atualizar as contas regularmente, recomendamos limitar o número dessas contas a um pequeno conjunto, por exemplo, apenas as 20 principais contas do Google Ads. O restante pode ser atualizado com uma frequência menor, 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 pequena conta de teste. 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.

Uma abordagem melhor seria executar um único relatório e processá-lo localmente. Uma dessas abordagens usando 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(customer_id, query);

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

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (long adGroupId in memoryMap.Keys())
  {
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

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, você também poderá dividir 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 executar 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 provavelmente mudam a cada hora são metrics.clicks e metrics.impressions. Todas as outras colunas são atualizadas com pouca frequência ou não são atualizadas, 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 mudança ou status de mudança 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ê faz o download aplicando filtros adequados.

Limpar contas não utilizadas

Se o aplicativo gerencia contas de clientes de terceiros, é necessário desenvolver o aplicativo pensando na rotatividade de clientes. Limpe periodicamente seus processos e repositórios de dados para remover contas de clientes que não usam mais o aplicativo. Ao limpar contas não utilizadas do Google Ads, tenha em mente as seguintes orientações:

  • Revogue a autorização que o cliente deu ao 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 jobs cron e pipelines de dados, que são projetados para serem executados sem intervenção do usuário.
  • Se o cliente revogou a autorização, o aplicativo precisa lidar com a situação e evitar o envio de chamadas de API inválidas para os servidores de API do Google.
  • Se o cliente cancelou a conta do Google Ads, detecte isso e evite o envio de chamadas de API inválidas para os servidores de API do Google.
  • Exclua os dados que você fez o download das contas do Google Ads do cliente do seu banco de dados local após um período adequado.