validateOnly: o dry-run que separa automação profissional de gambiarra no Google Ads

A pergunta que todo gestor de tráfego faz quando ouve “IA conectada à conta do cliente” é sempre a mesma: e se ela fizer besteira? A resposta técnica não é “confia no modelo”. É validateOnly.

O que é o modo de validação

A API do Google Ads aceita, em praticamente toda operação de escrita, um flag chamado validateOnly. Com ele em true, a requisição sai da sua máquina, chega ao Google, passa por toda a validação que uma requisição real passaria — e é descartada. Nada persiste na conta.

Isso é diferente, e muito melhor, do que validar localmente. Validação local só pega o que você programou para pegar. O validateOnly pega o que o Google considera inválido, incluindo regras que mudam sem aviso e restrições específicas daquela conta.

Num MCP bem construído, esse flag aparece em toda tool que escreve: criação de orçamento, campanha, grupo, keywords, anúncio, e também nas de alteração — status, orçamento, remoção de critério, segmentação. Se um servidor MCP de Google Ads não expõe validateOnly, é um sinal de alerta sobre o resto da implementação.

O que o dry-run pega de verdade

Na prática, esses são os erros que aparecem em validação e que teriam virado sujeira na conta:

Repare que quase nenhum desses é erro de raciocínio. São erros de formato e de estado da conta — exatamente o tipo de coisa que um modelo de linguagem erra com frequência, porque ele não tem como saber que já existe um orçamento chamado “Orçamento Principal” naquela conta.

O fluxo que eu uso

É sempre o mesmo, e vale escrever nas instruções do seu agente para ele seguir sozinho:

1. Monta a chamada completa com todos os parâmetros finais
2. Executa com validateOnly: true
3. Lê os erros retornados
4. Corrige e repete até a validação vir limpa
5. Executa a mesma chamada com validateOnly: false
6. Confere o retorno e o resourceName criado

O passo 5 é literalmente a mesma chamada com um flag trocado. Isso é importante: você não está validando uma versão da chamada e executando outra. É o mesmo payload.

Custo disso: uma chamada extra e alguns segundos. Benefício: você para de ter aquela conversa constrangedora sobre por que existem três campanhas de teste na conta do cliente.

partialFailure: o complemento indispensável

O validateOnly resolve “não escrever coisa errada”. Ele não resolve “escrever 47 de 50 coisas certas”. Para isso existe partialFailure.

Operações em lote — adicionar keywords, adicionar negativas, aplicar locais, aplicar idiomas — aceitam esse flag, normalmente ligado por padrão. Com ele ativo, um item inválido no lote não derruba os demais. A resposta volta separada: succeeded[] com o que entrou, failed[] com o que não entrou e o motivo de cada um.

Sem partialFailure, o comportamento padrão da API é all or nothing. Você manda 50 negativas, uma tem aspas mal fechadas, e nenhuma entra. Pior: dependendo de como o erro sobe, você pode não saber se entrou nada ou tudo, e vai conferir na mão.

A combinação dos dois flags é o que torna automação em lote viável:

• validateOnly antes → descobre quais itens são inválidos
• partialFailure na execução → garante que os válidos entrem mesmo se algum escapou

Quando o dry-run não protege

Aqui vale honestidade, porque tratar validateOnly como escudo absoluto é perigoso.

Ele valida sintaxe e estado, não estratégia. Uma chamada que triplica o orçamento diário de R$ 50 para R$ 150 passa na validação sem reclamar. Está tecnicamente correta. Se era o que você queria é outra história.

Ele não valida a intenção da sua instrução. Se você pediu “pausa as campanhas com CPA alto” e o modelo interpretou o período errado, o dry-run vai dizer que pausar aquelas campanhas é uma operação válida. Porque é.

E ele não existe para leitura. Chamadas de relatório não escrevem nada, então não têm o flag — mas também não têm risco de escrita.

A proteção contra erro de estratégia é outra: revisão humana nas operações irreversíveis e escopo limitado de permissão. É o mesmo princípio que discuto em segurança ao conectar IA a sistemas de produção: camadas, não uma trava só.

A hierarquia de reversibilidade

Um jeito prático de decidir o quanto exigir de validação e revisão é classificar a operação por quão fácil é desfazer:

Trivialmente reversível — status de anúncio, grupo e campanha; ajuste de orçamento. Você volta ao estado anterior em uma chamada. Aqui dá para operar com mais autonomia.

Reversível com trabalho — adicionar keywords ou negativas. Remover é possível via ads_remove_criterion, mas você precisa saber exatamente o que entrou. Guarde o succeeded[].

Reversível com sujeira — criar campanha, grupo, orçamento. Dá para remover, mas fica histórico e nome ocupado. Dry-run obrigatório.

Não reversível — o gasto. Se a campanha ficou ativa uma noite com segmentação errada, o dinheiro foi. Nenhum flag traz de volta. Por isso campanha nasce PAUSED por padrão nas implementações sérias.

Como isso muda a conversa com o cliente

Tem um efeito lateral que vale mencionar. Quando você explica para um cliente que existe um modo de validação, que campanha nasce pausada e que lote parcial não derruba o resto, a conversa muda de “você vai deixar uma IA mexer na minha conta?” para “como funciona o processo de revisão?”.

É a diferença entre vender automação como mágica e vender como engenharia. A segunda fecha contrato mais alto e gera muito menos ansiedade de parte a parte.

No próximo artigo eu abro o ads_query e o GAQL — a tool coringa que responde qualquer pergunta que a API do Google Ads sabe responder, sem depender de tool dedicada. Se você quer o panorama completo das operações disponíveis, o guia de Google Ads MCP mapeia tudo.