Uma função principal de muitos aplicativos do Google Ads é recuperar dados de contas 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, é preciso otimizar o uso para não sobrecarregar os servidores do Google ou o risco de limitar a taxa. Para mais detalhes, consulte os guias sobre limitação de taxa e como manter um endereço de e-mail de contato atualizado.
Entender 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 uma quantidade excessiva 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 alterações. Os
erros a seguir são gerados para solicitações limitadas:
| Versão da API | Código do erro |
|---|---|
| Versão 16 ou anteriores | QuotaError.RESOURCE_EXHAUSTED |
| Versão 17 ou mais recente | 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 retornaremos 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 diversos fatores, como:
- Tamanho das suas contas
- Visualizações e colunas buscadas nos seus relatórios
- A carga nos servidores da API Google Ads.
Para ajudar a rastrear consultas caras, publicamos estatísticas iniciais agregadas sobre o consumo de recursos dos diversos padrões de consulta encontrados nos nossos servidores. Publicaremos periodicamente números atualizados para ajudar você a ajustar suas consultas.
| Janela de tempo | Médio (p50). | P70 (moderadamente alto) | P95 (muito alta) |
|---|---|---|---|
| Curto prazo (5 min) | 6.000 | 30000 | 1800000 |
| Longo prazo (24 horas). | 16.000 | 90000 | 8400000 |
Por exemplo, suponha que você esteja executando um padrão de consulta como mostrado a seguir, que consuma 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 de diversas 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 podem ser executados 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 | Relativamente alta | Muito alto |
|---|---|---|---|
| Curto prazo (5 min) | 10 | 50 | 3.000 |
| Longo prazo (24 horas). | 26 | 150 | 14000 |
Executar esse padrão de consulta 10 vezes em 5 minutos conta como um uso médio, enquanto gerar 3.000 relatórios em 5 minutos conta como 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 seus dados em cache
Armazene em cache os detalhes da entidade buscados nos servidores de 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 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 tem diretrizes publicadas sobre a atualização de dados e a frequência com que eles são atualizados. Use estas orientações para determinar a frequência de busca de relatórios.
Se você precisar atualizar as 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 a uma frequência menor, por exemplo, uma vez ou duas vezes por dia.
Otimize o tamanho dos seus relatórios
Seu aplicativo deve buscar grandes lotes de dados em vez de executar um grande número de relatórios pequenos. Um fator determinante para 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 do 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 Google Ads API, levando à limitação de taxa e à limitação.
Uma abordagem melhor seria gerar um único relatório e processá-lo localmente. É mostrada uma dessa abordagem usando um mapa na memória.
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 Google Ads API devido ao menor número de relatórios sendo gerados.
Se você achar que o relatório é muito grande para ser mantido na memória, 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 sobre rótulos para saber mais.
Otimizar o que você busca
Ao gerar relatórios, tenha em mente as 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 mudarão 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 é altamente ineficiente fazer a busca delas a cada hora. É possível armazenar esses valores em um banco de dados local e gerar um relatório de evento de mudança ou status de mudança para fazer o download das alterações uma ou duas vezes por dia.
Em alguns casos, é possível reduzir o número de linhas transferidas por download aplicando os filtros adequados.
Limpar contas não usadas
Se o seu aplicativo gerencia contas de anunciantes de terceiros, você precisa desenvolver o aplicativo tendo em mente a desistência de clientes. Limpe seus processos e armazenamentos de dados periodicamente para remover contas de clientes que não usam mais o aplicativo. Ao limpar contas do Google Ads não utilizadas, lembre-se das seguintes orientações:
- Revogue a autorização dada pelo cliente ao aplicativo para gerenciar a conta dele.
- Parar 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, projetados para serem executados sem intervenção do usuário.
- Se o cliente revogou a autorização, seu aplicativo deve 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 tiver cancelado a conta do Google Ads, detecte-o e evite o envio de chamadas inválidas aos servidores de API do Google.
- Exclua os dados transferidos por download das contas do Google Ads do cliente do banco de dados local após um período adequado.