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 mesmo cuidado que aplico no Search Intelligence MCP, e que vale para qualquer operação em lote, como a negativação de palavras-chave em escala.

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.

Referências oficiais

Documentação consultada em 26 de setembro de 2026. Interfaces, permissões e campos de API podem mudar; confira a versão e os requisitos atuais antes de reproduzir os exemplos.

• Boas práticas de teste da Google Ads API
• Validação e execução de operações mutate
• Falha parcial na Google Ads API