Uma função essencial de muitos aplicativos do Google Ads é recuperar dados da conta para uso como análise de dados, consultas de clientes e verificações de conformidade com as políticas. Ao buscar os dados, você deve otimizar seu uso para não sobrecarregar servidores do Google ou poderá haver limitação de taxa. Para mais detalhes, consulte os guias sobre limitação de taxa e manter uma 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 enormes de recursos da API. Se um determinado padrão de consulta for limitado, outros
serviços, métodos e padrões de consulta continuarão funcionando. A
os seguintes erros são gerados para solicitações limitadas:
| Versão da API | Código do erro |
|---|---|
| Versão 17 ou anterior | QuotaError.RESOURCE_EXHAUSTED |
| versão 18 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 um 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 buscadas nos seus relatórios.
- A carga nos servidores da API Google Ads.
Para ajudar você a rastrear consultas caras, publicaremos anúncios agregados estatísticas sobre o consumo de recursos dos vários padrões de consulta que vemos nossos servidores. Publicaremos periodicamente os números atualizados para ajudar você a ajustar suas consultas.
| Janela de tempo | Médio (p50). | P70 (moderadamente alto) | P95 (muito alto) |
|---|---|---|---|
| Curto prazo (5 min) | 6000 | 30000 | 1800000 |
| Longo prazo (24 horas). | 16.000 | 90000 | 8400000 |
Como exemplo, vamos supor que você esteja executando um padrão de consulta como mostrado a seguir, 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 esta consulta para várias contas de clientes por várias datas individuais.
modificando a consulta para substituir valores diferentes por segments.date.
filtro. A tabela a seguir mostra o número de relatórios que você pode gerar em um determinado
janela de tempo para que o uso dos recursos se encaixe em vários
buckets de armazenamento.
| 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 conta como uma média. uso. Já gerar 3.000 relatórios em 5 minutos conta como um uso muito alto.
Há várias estratégias para otimizar o consumo de recursos dos seus e detecção de ameaças. O restante deste guia aborda algumas dessas estratégias.
Armazene seus dados em cache
Você deve armazenar em cache os detalhes da entidade buscados nos servidores da API em uma em vez de chamar o servidor sempre que precisar dos dados, especialmente para entidades que são frequentemente acessadas ou que mudam com pouca frequência. Use change-event e change-status onde possível para detectar quais objetos foram alterados 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 como com frequência em que os dados são atualizados. Use essa orientação para determinar como frequentemente para buscar relatórios.
Se você precisar atualizar as contas regularmente, recomendamos limitar o número de contas a um pequeno conjunto, por exemplo, apenas as 20 principais contas do contas de serviço. O restante pode ser atualizado em uma frequência menor, por exemplo, uma vez ou duas vezes por dia.
Otimizar o tamanho dos seus relatórios
Seu aplicativo deve buscar grandes lotes de dados em vez de executar um grande quantidade de relatórios pequenos. Um fator importante nessa escolha é a conta limites de desempenho.
Por exemplo, considere o código a seguir que extrai as estatísticas de anúncios específicos grupos e atualizar 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. Então, se esse código for executado em uma conta grande do Google Ads, poderá sobrecarregar os servidores dessa API, levando à limitação de taxa e à limitação.
Uma abordagem melhor seria gerar um único relatório e processá-lo localmente. Um essa 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 API Google Ads devido ao menor número de relatórios. em execução.
Se você achar que o relatório é muito grande para ser armazenado na memória, também será possível
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 forma de agrupar entidades e reduzir o número de relatórios consultas. Consulte o guia de rótulos para saber mais.
Otimize o que é buscado
Ao gerar relatórios, você deve estar atento às colunas que inclui em suas 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 serão alteradas 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
então é altamente ineficiente buscá-los a cada hora. É possível armazenar
valores em um banco de dados local e executar um evento de alteração ou
change-status para fazer o download das mudanças uma ou duas vezes por dia.
Em alguns casos, você pode reduzir o número de linhas baixadas aplicando filtros adequados.
Excluir contas não usadas
Caso seu aplicativo gerencie contas de anunciantes de terceiros, você precisará desenvolver seu aplicativo pensando na rotatividade dos clientes. Você deve periodicamente limpar seus processos e repositórios de dados para remover contas de clientes que não seu aplicativo por mais tempo. Ao limpar contas do Google Ads não usadas, mantenha as seguinte orientação em mente:
- Revogar a autorização que o cliente concedeu ao aplicativo para gerenciar a conta.
- Parar de fazer chamadas de API para as contas do Google Ads do cliente. Isso se aplica especialmente para trabalhos off-line, como cron jobs e pipelines de dados, criados para execução sem intervenção do usuário.
- Se o cliente revogar a autorização, seu aplicativo deverá lidar normalmente 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 it e evite enviar chamadas de API inválidas para os servidores de API do Google.
- Exclua os dados baixados das contas do Google Ads do cliente da sua no banco de dados local após um período adequado.