Segmentação geográfica no Google Ads via MCP: o desperdício silencioso que quase ninguém audita

De todos os problemas que aparecem em auditoria de conta de Google Ads, a segmentação geográfica é o mais barato de corrigir e o menos auditado. Ela não aparece como erro no relatório. Não gera alerta na interface. Simplesmente drena verba em clique de gente que nunca ia comprar, porque está a mil quilômetros de distância.

Por que isso acontece tanto

A cadeia de criação de campanha, seja pela interface ou via API, não obriga você a definir localização. Se você não define, a campanha herda o padrão da conta — que costuma ser abrangente demais, quando não é literalmente todos os países.

Na interface, a tela de localização vem no meio do fluxo e tem um valor pré-preenchido. Muita gente clica “avançar” achando que já está certo. Via API é pior: se a chamada de criação não incluir os critérios de local, ninguém te avisa. A campanha sobe e roda.

Some a isso a configuração de “presença ou interesse”, que é o padrão do Google e inclui pessoas que apenas pesquisaram sobre a sua região sem estar nela. Para negócio local, isso quase sempre é ruído.

As duas tools que resolvem

Num MCP de Google Ads, a operação é em dois passos, porque o Google não aceita nome de cidade — só ID numérico.

Passo 1 — Descobrir o ID

ads_search_geo_targets recebe uma lista de nomes em texto livre e devolve os geoTargetConstant correspondentes. Parâmetros:

• locationNames — ex: ["Maringá", "Londrina", "Paraná"]
• countryCode — padrão BR, serve para desambiguar
• locale — padrão pt-BR

O countryCode não é detalhe. “Santa Catarina” existe no Brasil, no Chile e nas Filipinas. “São Paulo” pode ser o estado ou o município — e os IDs são diferentes. Sem desambiguação você aplica o alvo errado e só descobre pelo relatório de localização semanas depois.

Alguns IDs úteis para ter na cabeça: 2076 é o Brasil inteiro, 20106 é o estado de São Paulo.

Passo 2 — Aplicar na campanha

ads_add_campaign_locations recebe:

• campaignResourceName — o caminho completo da campanha
• customerId
• geoTargetConstantIds — a lista de IDs, ex: ["20106"]
• negative — se true, exclui esses locais em vez de incluir
• partialFailure — padrão true, um ID problemático não derruba o lote
• validateOnly — dry-run

O negative é o parâmetro subutilizado. Ele permite a estratégia mais precisa de todas: incluir amplo e excluir o que não interessa.

A estratégia de inclusão e exclusão combinadas

Exemplo real de escritório de advocacia que atende uma região metropolitana mas não quer processo de comarca distante:

1. Inclui o estado inteiro (uma chamada, negative: false)
2. Exclui as capitais e cidades onde não há interesse em atuar (segunda chamada, negative: true)

Isso é operacionalmente chato na interface — são dezenas de cliques em campos de busca. Via MCP são duas chamadas com listas. E é reversível: se a exclusão foi agressiva demais, você desfaz com ads_remove_criterion.

O mesmo vale para e-commerce que não entrega em certas regiões, prestador de serviço com raio de deslocamento, ou clínica que só atende presencialmente.

Idioma: a outra metade esquecida

ads_add_campaign_languages define os idiomas de segmentação. Aceita códigos (pt, en, es) ou IDs de languageConstant direto.

Sem isso, a campanha roda em “todos os idiomas” por padrão. Na prática, para negócio brasileiro, isso significa aparecer para gente com o navegador em outro idioma pesquisando termos em português — geralmente tráfego de baixa qualidade, às vezes fraude de clique.

É uma chamada. Faça sempre.

Como auditar toda a carteira de uma vez

Este é o ganho que só existe com MCP. A auditoria de geo em conta única é chata mas viável na mão. Em oito contas, ninguém faz.

Com ads_list_accounts você pega todas as contas acessíveis, incluindo as sob MCC. Para cada uma, uma query em GAQL revela a configuração atual:

SELECT campaign.name,
       campaign_criterion.location.geo_target_constant,
       campaign_criterion.negative
FROM campaign_criterion
WHERE campaign_criterion.type = 'LOCATION'

Campanha ativa que não aparece nesse resultado é campanha sem geo definido. Esse é o alerta. Se você quer entender melhor como montar consultas assim, escrevi sobre GAQL via MCP.

Cruze com o desempenho real por localização:

SELECT campaign.name, geographic_view.country_criterion_id,
       metrics.cost_micros, metrics.conversions
FROM geographic_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.cost_micros DESC

Gasto relevante em região onde o cliente não atende é dinheiro que você recupera na mesma tarde.

O que o MCP não decide por você

Vale ser claro sobre o limite. O MCP aplica a segmentação que você definir. Ele não sabe:

• Qual é o raio real de atendimento do cliente
• Se aquela cidade vizinha vale a pena apesar do CPA maior
• Se o cliente tem restrição contratual ou regulatória de atuação em certa região
• Se a exclusão de uma capital vai derrubar volume abaixo do mínimo viável

Isso é conversa com o cliente, não parâmetro de API. O que a automação faz é garantir que, uma vez decidido, seja aplicado corretamente em toda a carteira e conferido periodicamente.

Checklist de geo para campanha nova

• IDs resolvidos com countryCode explícito, conferidos antes de aplicar
• Nível certo: cidade, estado ou país — não misture sem intenção
• Exclusões aplicadas onde fizer sentido
• Idioma travado
• Configuração de presença revisada na interface (esse ajuste não costuma estar exposto nas tools)
• Tudo validado com validateOnly antes de executar
• Conferência no relatório geográfico após 7 dias de veiculação

O último item é o que fecha o ciclo. Configuração certa no papel e comportamento estranho no relatório é sinal de que algo escapou — normalmente presença/interesse ou uma campanha antiga com critério herdado.

Se você está montando campanha do zero, o artigo sobre criar campanha inteira via MCP mostra onde essas duas chamadas entram na cadeia. Elas vêm depois da criação e antes de ativar — nunca pule.