Uma função principal 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 nem 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 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 vão continuar funcionando sem problemas. Os
seguintes erros 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. |
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 rastrear 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 alta) | 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"
Execute essa consulta para várias contas de clientes em várias datas individuais
modificando a consulta para substituir valores diferentes no filtro segments.date. A tabela a seguir mostra o número de relatórios que podem ser executados em um determinado período para que o uso de recursos se encaixe em vários intervalos de uso.
| Janela de tempo | Média | Moderadamente alta | 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
Armazene em cache os detalhes da entidade buscados dos 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 raramente. 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 dos dados e a frequência com que eles são atualizados. Use essas orientações para determinar a frequência de busca de relatórios.
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
O 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, resultando em limitação e restrição de taxa.
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 executados.
Se o relatório for muito grande para ficar na memória, divida a consulta em grupos menores adicionando uma cláusula LIMIT assim:
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 nas 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 nunca. Por isso, é muito ineficiente buscá-las a cada hora. Você pode armazenar esses valores em um banco de dados local e executar um relatório de mudança de evento ou mudança de status para baixar as alterações uma ou duas vezes por dia.
Em alguns casos, é possível reduzir o número de linhas baixadas aplicando filtros adequados.
Limpar contas não usadas
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 seu aplicativo. Ao limpar contas do Google Ads não utilizadas, siga estas orientações:
- 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 revogou a autorização, seu aplicativo precisa 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 isso e evite enviar chamadas de API inválidas aos servidores de API do Google.
- Exclua os dados baixados das contas do Google Ads do cliente do seu banco de dados local após um período adequado.