Uma das principais funções 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 compliance 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.
Entender 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 determinado padrão de consulta 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:
| Versão da API | Código do erro |
|---|---|
| <= v17 | QuotaError.RESOURCE_EXHAUSTED |
| >= v18 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
ou QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION, dependendo
da duração do uso intenso 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ê extrai nos 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 aparecem nos nossos servidores. Publicaremos números atualizados periodicamente para ajudar você a ajustar suas consultas.
| Janela de tempo | Média (p50). | P70 (moderadamente alta) | P95 (muito alta) |
|---|---|---|---|
| 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 em várias contas de cliente para 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 você pode executar em uma determinada
janela de tempo 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 minutos) | 10 | 50 | 3000 |
| Longo prazo (24 horas). | 26 | 150 | 14000 |
A execução desse padrão de consulta 10 vezes em 5 minutos seria considerada um uso médio, enquanto a execução de 3.000 relatórios em 5 minutos seria considerada 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ê extrai dos servidores da 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 infrequentemente. 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 relatórios em execução
O Google Ads publicou diretrizes sobre a atualidade 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 conjunto pequeno, 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 seus 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 conta de teste pequena. No entanto, o Google Ads oferece suporte a 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 de taxa e restrição.
Uma abordagem melhor seria gerar um único relatório e processá-lo localmente. Uma abordagem desse tipo 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 que estão sendo executados.
Se o relatório for muito grande para ser armazenado 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.
Otimize o que você busca
Ao gerar relatórios, preste atenção nas colunas que você inclui nas consultas. Considere o exemplo a seguir, que é 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 vão mudar a cada hora são metrics.clicks e metrics.impressions. Todas as outras colunas são atualizadas com pouca frequência ou nem
mesmo atualizadas, então é muito ineficiente buscá-las a cada hora. É possível 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 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 apropriados.
Limpar contas não usadas
Se o app gerencia contas de clientes de terceiros, é necessário desenvolvê-lo pensando na rotatividade do cliente. É necessário limpar periodicamente os processos e os repositórios de dados para remover contas de clientes que não usam mais o aplicativo. Ao limpar contas do Google Ads não utilizadas, considere as seguintes orientações:
- Revogue a autorização que o cliente concedeu ao seu app para gerenciar a conta dele.
- Pare de fazer chamadas de API para as contas do Google Ads do cliente. Isso se aplica principalmente 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 tiver revogado a autorização, seu aplicativo precisará 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 isso e evite enviar 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.