Categoria: Automação

Monte um monitor que, uma vez por dia, lê gasto e vendas de cada campanha no dia fechado, compara com uma regra de corte escrita antes de ligar o anúncio e avisa quando ela é atingida. Ele propõe; quem pausa é você. As vendas vêm da plataforma onde o dinheiro entra, não do painel de anúncios.

Quem anuncia conhece a cena: abrir o painel às onze da noite, ver o gasto subindo e não saber se é hora de desligar ou de esperar. O problema quase nunca é falta de dado. É falta de uma régua decidida antes, e de alguém que leia essa régua todo dia sem ansiedade.

Por que não deixar o próprio Google ou a Meta pausar sozinhos?

As duas plataformas oferecem regras automáticas. No Google Ads, as regras automatizadas podem mudar status, orçamento e lance quando uma condição bate, e também podem só enviar os resultados por e-mail.

A Meta tem o recurso equivalente nas regras automatizadas do Gerenciador de Anúncios.

O risco de deixar a regra agir sozinha é que ela decide com o número do painel, e o número do painel pode estar errado. Por isso, no nosso monitor, a divisão é fixa: ler e alertar é automático; pausar, mudar lance ou orçamento exige confirmação, mostrando o valor atual e o valor novo lado a lado. Ativar anúncio, nunca.

Quando o monitor lê os números, e o que ele precisa ler?

Pouca coisa, mas na ordem certa. A primeira pergunta não é CPC (quanto custa cada clique), CTR (de cada 100 pessoas que viram o anúncio, quantas clicaram) nem impressão (cada vez que o anúncio aparece na tela). É quantas vendas aconteceram de verdade.

1. A planilha de controle — o registro que você mantém
2. A plataforma de anúncios — o que o Google ou a Meta dizem que converteu
3. A plataforma de venda — a página de pagamento, a empresa que processa o cartão, a loja: a fonte da verdade
4. Se as três divergem, o monitor não decide — pergunta

Só depois disso entra a conta de gasto contra margem. E a leitura é sempre do dia fechado: gasto e venda não chegam no mesmo momento, e decidir pela parcial da manhã é o erro mais caro dessa rotina.

O que é a regra de corte, e por que ela tem que ser escrita antes?

A regra de corte é um teto de gasto combinado antes: o valor que, gasto sem nenhuma venda, encerra o teste. Funciona como o limite que você decide antes de entrar numa loja, para não sair gastando no calor da hora.

A regra base que usamos é simples. Gastou o equivalente ao que se ganha numa venda e não vendeu? O monitor dispara o alerta de pausa.

Ela é escrita antes de ligar a campanha porque, depois, a ansiedade negocia. Com o anúncio rodando, sempre parece que falta “só mais um dia”. A régua muda conforme o histórico:

Situação do produto	Régua aplicada
Nunca vendeu	Régua de teste: gastou o ganho de uma venda sem vender, alerta de pausa
Vendeu de 1 a 3 vezes e parou	Régua de insistência: tolera mais uma ou duas margens antes de cortar
Já faturou de forma consistente	Régua de caixa, com um limite maior e decidido caso a caso

Usar a régua de produto novo num produto que já vendeu mata cedo demais o que estava funcionando.

Como a conversão mal medida engana o alerta?

Aconteceu com a gente. Numa operação de venda online, o painel do Google Ads mostrava 0 conversões, enquanto a plataforma de venda registrava 1 venda paga de R$ 27,06. A tag de conversão (o pedacinho de código que avisa o painel quando uma venda acontece) estava incompleta. Um alerta que confiasse só no painel teria mandado cortar uma campanha que já tinha vendido.

Por isso o monitor trata “0 conversões no painel” como pergunta, não como fato. Se a plataforma de venda discorda, quem ganha é ela — e a tag vai para conserto antes de qualquer veredito sobre o anúncio.

Métrica secundária pode derrubar um anúncio que vende?

Pode, e é o erro mais comum de quem corta por CTR. Num teste na Meta com um produto digital de entrada, o único anúncio que vendeu (3 compras) tinha CTR de 0,79%, o pior do conjunto. Outro anúncio, com CTR de 3,17%, quatro vezes melhor, vendeu zero. Cortar por CTR teria matado o vencedor.

Daí saiu a regra de imunidade: anúncio que já vendeu não é julgado por métrica secundária. Mas a imunidade expira — quando ele gasta duas vezes o custo por venda desejado sem uma venda nova, volta a ser julgado como qualquer outro. Para anúncio sem venda, usamos três portões:

Portão	Quando checar	Alerta se
Não chama atenção	1.000 impressões ou mais	CTR abaixo de 0,8%
Clique caro	8 cliques ou mais	CPC acima do teto e nenhuma venda
Não converte	gasto de 4× o custo por venda desejado	nenhuma compra

Abaixo de 150 impressões ou R$ 5 de gasto, o monitor não julga: ainda não há dado.

Todo gasto conta como teste?

Não. Se metade do dinheiro foi para buscas que nada tinham a ver com o produto, o produto ainda não foi testado — foi o público errado que gastou. O monitor desconta esse gasto sujo antes de comparar com a regra de corte, e só dá veredito quando praticamente todo o investimento (95% ou mais) caiu em busca realmente ligada à oferta.

Sem esse desconto, você mata produto bom por culpa de palavra-chave mal negativada. Negativar é dizer ao Google em quais buscas o anúncio não deve aparecer.

Quais armadilhas fazem o alerta ler errado?

Três aparecem sem aviso nenhum na tela:

• Pausa em vários níveis. Ao importar uma campanha por planilha com tudo marcado como pausado, a pausa fica em quatro camadas: campanha, grupo, palavra-chave e anúncio. Religar só a campanha deixa ela “Ativada” no painel e com zero impressão. Aconteceu em 05/08/2026.

Diante de zero impressão, a primeira checagem é o status das quatro camadas, antes de mexer em palavra ou lance

• Configuração que muda sozinha. O Google oferece aplicar recomendações automaticamente, e alguns convites trocam a estratégia de lance. Ao preparar uma das nossas contas, o convite para “otimizar para aquisição de novos clientes” vinha com a opção recomendada que eliminava o teto de CPC. Recomendação automática fica desligada, e a estratégia de lance entra na conferência

• Verba pulverizada. Com seis anúncios dividindo R$ 10 por dia, cada um levaria cerca de 48 dias para chegar ao terceiro portão. A regra existe, mas nunca dispara. Limitamos a três anúncios ativos por conjunto nesse orçamento

Como resolver isso com IA, passo a passo?

1. O que construir

Um agente de monitoramento: uma rotina escrita e executada com o Claude Code (uma IA que escreve e roda programas a partir de instruções em português). Uma vez por dia, ele lê as métricas das contas no dia fechado, cruza com a plataforma de venda e aplica a régua.

No fim, devolve um resumo: gasto acumulado, quanto da regra de corte já foi consumido, gasto sujo, vendas e as ações sugeridas, cada uma com motivo. Nenhuma ação de valor ou de pausa sai sem o “pode” de quem é dono do dinheiro.

2. O pedido pronto para copiar

O pedido que recomendamos colar no Claude Code:

“Monte um monitor diário de anúncios que só lê e avisa, nunca pausa, nunca muda valor e nunca ativa nada. Todo dia, ele deve: 1) ler gasto, cliques, impressões e conversões de cada campanha do dia fechado; 2) ler as vendas pagas na minha plataforma de venda, que é a fonte da verdade; 3) se o painel e a plataforma de venda discordarem, avisar a divergência em vez de decidir; 4) comparar o gasto com a minha regra de corte, que vou escrever abaixo; 5) não julgar anúncio com menos de 150 impressões ou R$ 5 de gasto; 6) nunca sugerir corte por CTR em anúncio que já vendeu; 7) me mandar um resumo com cada sugestão, o motivo e o valor atual ao lado do valor novo. Explique cada passo como se eu nunca tivesse programado. Minha regra de corte: [cole aqui].”

3. Como conferir se a IA acertou

Teste com os dois casos deste artigo. Primeiro: informe 0 conversões no painel e 1 venda paga de R$ 27,06 na plataforma de venda. O monitor certo aponta a divergência e não manda cortar.

Segundo: informe um anúncio com CTR de 0,79% e 3 compras, e outro com CTR de 3,17% e zero venda. O certo é proteger o primeiro e julgar só o segundo. Se ele sugerir pausar o que vendeu, reprova.

4. Custo e tempo

O Claude Code vem no plano Pro, que custa R$ 110 no mensal ou R$ 92 por mês no anual (R$ 1.100 de uma vez), segundo a página oficial de preços vista do Brasil em 02/10/2026; os preços não incluem impostos aplicáveis. O plano grátis não inclui o Claude Code. O tempo de montagem depende de quantas contas e plataformas de venda entram na leitura; a rotina, depois de pronta, roda uma vez por dia.

Quando o painel mostra um número e a realidade outro, o caminho é o mesmo de qualquer painel próprio — explicado em como juntar dado de várias fontes num painel só. E o limite do que o agente pode fazer sem perguntar está em como fazer o agente rodar sozinho sem aprovar cada passo.

E se o alerta disparar e eu não quiser cortar?

Então a régua estava errada, e isso também é informação. O que não vale é mudar a régua com a campanha rodando e sem registrar o motivo. Antes de declarar um anúncio morto, conferimos quatro causas: gasto sujo, negativas demais bloqueando busca boa, problema na conta e texto da página. Se nenhuma explica, corta.

Para quem serve esse alerta — e quando não se aplica?

Se aplica bem:

• Quem testa anúncio com verba limitada. A regra de corte diz quando parar antes de o prejuízo crescer.
• Quem vende numa plataforma separada do painel de anúncios. Foi nesse cenário que o painel mostrou 0 conversões e a venda de R$ 27,06 existia.
• Quem roda várias campanhas ao mesmo tempo. Ler uma por uma, todo dia, é justamente o trabalho que o monitor tira da sua mão.

Não se aplica tão bem:

• Verba muito pequena dividida em muitos anúncios. Com seis anúncios dividindo R$ 10 por dia, o terceiro portão levaria cerca de 48 dias. Antes do alerta, é preciso concentrar a verba.
• Quando você não tem acesso às vendas reais. Sem a plataforma de venda, o alerta fica refém do número do painel, que pode estar errado.
• Campanha que não busca venda direta. Anúncio para a marca ser lembrada não se mede por gasto contra venda.

O que a gente faria no seu lugar?

A gente escreveria a regra de corte antes de ligar o anúncio, com base no quanto se ganha numa venda. Com a campanha rodando, a ansiedade negocia, e sempre parece faltar “só mais um dia”.

A gente também contaria as vendas na plataforma onde o dinheiro entra, e não no painel. O motivo é o nosso caso: 0 conversões no Google Ads e 1 venda paga de R$ 27,06 na plataforma de venda. Quem faz essa leitura todo dia é o monitor com IA descrito acima — só depois de passar nos dois testes.

O que a gente não faria: cortar anúncio por CTR. O único que vendeu tinha 0,79%, o pior do conjunto. E não deixaria a regra automática da plataforma pausar sozinha, porque ela decide com o número do painel.

Em resumo

Um alerta confiável de “gasta e não vende” é uma rotina diária que conta as vendas na plataforma onde o dinheiro entra, desconta o gasto sujo e compara com uma regra de corte escrita antes do anúncio ir ao ar.

A máquina lê e avisa; pausar, mudar valor e ativar continuam sendo decisão humana, porque painel com tag quebrada, pausa escondida em quatro níveis e configuração alterada sozinha enganam qualquer regra automática.

Este artigo faz parte do pilar Operação e processo — como documentar sem virar burocracia.

Você só sabe fazendo uma auditoria antes de publicar, que pode ser somente leitura: olhar código, configuração e dependências sem mexer em nada. O roteiro mais usado é o chamado OWASP Top 10, a lista aberta dos dez riscos mais comuns em aplicações web. Em sistema feito com IA, comece por chave no código e rota sem login.

O sistema funciona na demonstração, o cliente consegue se cadastrar, o painel abre bonito. É justamente aí que mora o risco. A IA que escreveu o código foi otimizada para fazer funcionar, não para resistir a quem quer entrar sem convite.

O que é o OWASP Top 10 e por que ele serve de checklist?

O OWASP é uma fundação sem fins lucrativos que mantém, de forma aberta, a lista dos dez riscos mais frequentes em aplicações web. A edição atual é a OWASP Top 10:2025, e ela serve de checklist porque cada categoria vira uma pergunta que dá para responder olhando o sistema.

Não é norma nem certificação. É um mapa de onde os problemas costumam aparecer, montado a partir de dados de testes reais. Para quem não é da área, a utilidade prática é outra: ele impede que a revisão dependa da memória de quem está olhando.

Quais são as dez categorias da edição 2025?

A lista oficial, na ordem em que a própria fundação publica, com a pergunta que cada item vira na hora de revisar:

Código	Categoria	A pergunta na revisão
A01	Controle de acesso quebrado	Um usuário consegue ver ou mudar o que é de outro?
A02	Configuração de segurança errada	Ficou algo no modo “teste” ou aberto por padrão?
A03	Falhas na cadeia de suprimentos de software	As bibliotecas usadas têm falha conhecida?
A04	Falhas de criptografia	Senha e dado sensível estão protegidos?
A05	Injeção	O que o usuário digita pode virar comando?
A06	Design inseguro	O fluxo foi pensado para quem tenta burlar?
A07	Falhas de autenticação	Login e sessão resistem a abuso?
A08	Falhas de integridade de software ou dados	Dá para confiar no que chega de fora?
A09	Falhas de registro e alerta	Se alguém invadir, você fica sabendo?
A10	Tratamento incorreto de condições excepcionais	Quando algo dá erro, o sistema falha fechado?

O que costuma escapar num sistema construído com IA?

Os furos de sistema gerado por IA são previsíveis, porque o gerador sempre corta o mesmo caminho para o código rodar logo. No roteiro de auditoria que usamos, eles viraram uma lista própria, conferida antes de todo o resto:

• Chave de API (a senha que abre a porta de outro sistema) escrita direto no código ou exposta na parte que roda no navegador do visitante
• Rota sem autenticação: o endereço da API responde a quem não fez login
• Consulta que não confere o dono: basta trocar o número do cadastro na URL para ver o de outra pessoa
• Banco com regra de acesso desligada ou em modo de teste, como acontece em plataformas tipo Supabase e Firebase
• Chave de administrador no lado do cliente, que ignora qualquer regra de acesso
• Validação só na tela, sem conferência no servidor (o computador que guarda os dados e responde aos pedidos)

Quase todos caem no A01 da lista. Não por acaso, a página oficial dessa categoria registra que ela apareceu em 100% das aplicações testadas.

Por que a auditoria precisa ser somente leitura?

Porque o sistema que você quer proteger às vezes já está no ar, com dado de cliente de verdade. Uma revisão que testa ataque contra produção pode derrubar serviço, criar registro falso ou apagar informação — e aí o estrago veio da própria checagem.

A regra que seguimos separa duas coisas. Ler código, configuração, histórico de versões e lista de dependências é sempre seguro. Isso pode ser feito direto. Qualquer teste ativo contra produção, como enviar dados maliciosos a um formulário ou criar conta de teste, só acontece depois de montado, explicado e aprovado por uma pessoa.

Como resolver isso com IA, passo a passo?

1. O que construir. Uma skill de auditoria no Claude Code (uma skill é um conjunto de instruções salvas que a IA segue sempre do mesmo jeito), somente leitura, que confere o sistema contra o OWASP Top 10 e os seis furos típicos de código feito por IA. Ela entrega um relatório com cada achado, a prova (arquivo, linha ou configuração), a gravidade e a correção sugerida. É o desenho da auditoria que usamos.

A auditoria que rodamos foi construída com o Claude Code e vive como um roteiro fixo, não como pergunta solta a um chat. Ela olha o sistema em 3 camadas (código, dados e privacidade, servidor), percorre 8 fases e se apoia em 10 guias de referência, um deles só para os furos típicos de sistema feito com IA.

Peça	O que faz
Varredura de segredos	Procura chave e senha no código e no histórico de versões
Auditoria de dependências	Lista biblioteca com falha conhecida
Checagem de cabeçalhos	Olha de fora proteções do navegador, conexão segura e origens permitidas
Consulta de regras do banco	Lista tabelas sem regra de acesso por linha, rodada pelo próprio dono

São 4 scripts (pequenos programas que fazem a checagem sozinhos), todos de leitura. Cada achado sai com severidade, explicação em português simples e correção sugerida, e o conjunto fecha com uma nota de A a F.

2. O pedido pronto para copiar. O pedido que recomendamos colar no Claude Code, aberto na pasta do sistema:

“Crie uma skill chamada ‘auditar antes de publicar’, somente leitura: ela não pode alterar nenhum arquivo, nem enviar nada para o sistema no ar. Ela deve conferir o projeto contra as dez categorias do OWASP Top 10:2025 e, antes de tudo, contra estes furos: chave de API no código ou no histórico de versões, rota que responde sem login, consulta que não confere o dono do cadastro, banco com regra de acesso desligada, chave de administrador no lado do navegador e validação feita só na tela. Para cada item, mostre a prova: arquivo, linha ou configuração. Nunca mostre uma chave por inteiro; mascare. Termine com uma nota de A a F e um plano de correção em ordem de gravidade, sem corrigir nada sozinha. Explique tudo em português simples.”

Como conferir se a auditoria de IA acertou?

3. O teste da chave plantada. Faça uma cópia de teste do sistema e plante dois furos da lista deste artigo. Primeiro, escreva uma chave falsa no código, salve no histórico e depois apague a linha. Segundo, deixe uma rota respondendo sem login. A skill certa acha a chave mesmo apagada, porque ela continua no histórico, e mostra a chave mascarada. E classifica a rota aberta no A01, a categoria que a OWASP registrou em 100% das aplicações testadas. Se ela responder só “está seguro”, está reprovada.

Quanto custa e quanto tempo leva para montar a auditoria?

4. Custo e tempo. A skill roda no Claude Code. A página oficial de preços do Claude, vista do Brasil em 02/10/2026, mostra o plano Pro a R$ 110 no mensal ou R$ 92 por mês no anual (R$ 1.100 de uma vez), com o Claude Code incluído. O plano Free é R$ 0 e não inclui o Claude Code. Os preços não incluem impostos aplicáveis. A lista do OWASP é aberta e não custa nada. O tempo para montar e rodar depende do tamanho do sistema; não medimos esse número à parte.

E quando a auditoria encontra um problema?

Primeiro, nada é corrigido automaticamente. O relatório lista os achados e um plano em ordem de gravidade; a correção acontece com aprovação, uma de cada vez, começando pelas críticas.

Segundo, segredo encontrado nunca aparece por inteiro no relatório: ele sai mascarado, com a recomendação de trocar a chave. Apagar a linha do código não basta, porque ela continua no histórico. É o que o guia de gestão de segredos da OWASP orienta: chave exposta deve ser revogada imediatamente e substituída por uma nova.

Quem pode fazer essa revisão se eu não sou técnico?

Você mesmo pode fazer a primeira passada, desde que você trate a IA como auditora e não como quem aprova o próprio trabalho. A diferença está em pedir a revisão contra uma lista fechada, como as dez categorias acima e os seis furos típicos, e exigir evidência para cada item: o arquivo, a linha, a configuração.

“Está seguro?” é uma pergunta que qualquer ferramenta responde com um sim confiante. “Mostre onde cada rota confere o login” só tem resposta se o trabalho foi feito. É o mesmo princípio de conferir o que a automação diz ter salvo, que contamos em o que fazer quando a automação que a IA construiu quebra.

Quando essa revisão deve acontecer?

Em dois momentos, e usamos os dois modos. O modo construir entra enquanto o sistema nasce: a regra da casa, desde julho de 2026, é que todo app, API ou página siga o OWASP Top 10 como padrão, com chave fora do código e autorização checada no servidor. O modo auditar entra antes de publicar, com nota de 0 a 10 por categoria.

Tratar segurança como etapa final, depois que “ficou pronto”, é o que faz o furo ir junto para o ar. Custa menos prevenir do que descobrir pelo cliente.

O que muda depois de ter esse checklist

Você deixa de publicar com base no “funcionou na tela” e passa a publicar com uma lista conferida item por item, com prova. A segurança do sistema construído é um assunto; a do dado que você manda para a IA é outro, e está em é seguro usar IA com os dados dos meus clientes.

Em quais casos essa auditoria se aplica bem — e quando não?

Ela se aplica bem nos seguintes casos:

• Sistema com login, em que cada pessoa só pode ver o que é dela. É o terreno do A01.
• Sistema que guarda dado de cliente, como cadastro, pedido ou contato.
• Sistema que conversa com outros serviços por chave, como pagamento ou envio de mensagens.
• Sistema que já está no ar e vai ganhar uma função nova.

Ela pede menos esforço num protótipo que só roda no seu computador, sem dado real e sem endereço na internet. Ali, o modo construir basta por enquanto.

Mas o protótipo não pula a auditoria. Ela só muda de hora: entra no dia em que ele for para o ar.

O que a gente faria no seu lugar?

Nós não publicaríamos nenhum sistema com login ou dado de cliente sem conferir primeiro o controle de acesso. O motivo está no próprio artigo. A categoria A01 apareceu em 100% das aplicações testadas, e quase todos os furos típicos de código feito por IA caem nela.

Faríamos a auditoria somente leitura antes de tudo, com a skill “auditar antes de publicar” do passo a passo acima e o teste da chave plantada feito uma vez para confiar nela. Qualquer teste ativo ficaria para depois, com aprovação de uma pessoa.

O que não faríamos: perguntar “está seguro?” para a mesma IA que escreveu o código e aceitar o sim. Também não deixaríamos a correção rodar sozinha. E não apagaríamos uma chave exposta sem trocá-la por uma nova.

Em resumo

Sistema feito com IA fica seguro para publicar quando passa por uma auditoria somente leitura, guiada pelas dez categorias do OWASP Top 10 e pelos furos típicos de código gerado, como chave no código e rota sem login. A revisão não corrige nada sozinha: ela aponta, dá nota e deixa a correção para depois de aprovada, começando pelo que é crítico.

Este artigo faz parte do pilar Eu não sou programador — dá pra construir com IA mesmo assim?.

Para saber de onde veio cada cliente, cada porta de entrada precisa carimbar o contato na chegada: o formulário aplica uma etiqueta, o WhatsApp aplica outra e o link da campanha leva parâmetros UTM (etiquetas escritas no próprio link). Etiqueta posta depois, à mão, se perde. E o telefone deve ser comparado sem depender do formato.

Quem abre o cadastro e vê uma lista de nomes sem nenhuma pista de origem não consegue responder a pergunta mais básica do negócio: qual canal está trazendo gente. Foi o que aconteceu num CRM (o sistema que guarda a ficha de cada cliente) próprio que mantemos em produção. E o conserto mostrou que a origem se perde em lugares que ninguém olha.

Por que o contato entra no cadastro sem dizer de onde veio?

Porque, na maioria dos sistemas, etiquetar a entrada é configuração, não comportamento padrão. No nosso caso, o CRM só etiquetava automaticamente quem comprava: a confirmação da plataforma de pagamento aplicava as etiquetas de compra, e isso estava escrito direto no código.

A etiqueta de entrada dependia de um campo no painel de cada formulário, chamado “tag inicial”. Seis formulários estavam com esse campo em branco. O sétimo apontava para uma etiqueta que tinha sido apagada — e o sistema aceitava isso sem reclamar. Na tela, só dois de sete contatos tinham alguma marca de origem.

Que etiqueta cada porta de entrada deve aplicar?

A regra que adotamos é simples: uma etiqueta por porta, aplicada pelo próprio sistema, na hora da entrada. Nada de etiquetar depois, olhando a lista.

Porta de entrada	Quem aplica a etiqueta	O que registra
Formulário de captura	o próprio formulário (campo de etiqueta inicial)	qual formulário, em qual página
Conversa no WhatsApp	uma automação “mensagem recebida → adicionar etiqueta”	que o contato chegou pelo WhatsApp
Compra	a confirmação da plataforma de pagamento	o que comprou
Campanha paga	parâmetros UTM no link	fonte, meio e nome da campanha

O nome da etiqueta deve dizer a porta, não o humor do dia: “formulário-página-de-vendas” é útil daqui a seis meses; “lead quente” não é.

Como etiquetar automaticamente quem chega pelo WhatsApp?

Com uma automação disparada a cada mensagem recebida, cuja única ação é adicionar a etiqueta de WhatsApp. No nosso CRM, ela foi criada sem mexer em código: não envia mensagem, não move o contato no funil e não mexe em quem já estava no cadastro antes de ela existir.

O detalhe que a torna segura é ser idempotente (fazer a mesma coisa duas vezes dá o mesmo resultado de fazer uma): ela dispara em toda mensagem, mas antes de gravar confere se o contato já tem aquela etiqueta. Mil mensagens do mesmo cliente geram uma etiqueta só. A própria etiqueta foi criada automaticamente na primeira execução.

O que os parâmetros UTM resolvem que a etiqueta não resolve?

A etiqueta diz por qual porta o contato entrou. O UTM diz qual anúncio ou link o levou até aquela porta. Se duas campanhas mandam para o mesmo formulário, a etiqueta das duas é igual; só o UTM separa uma da outra.

A documentação oficial do Google Analytics sobre URLs personalizados define três parâmetros que devem estar sempre presentes: `utm_source` (de onde), `utm_medium` (que tipo de mídia) e `utm_campaign` (qual campanha). Ela também avisa que os valores diferenciam maiúsculas de minúsculas: “google” e “Google” viram duas fontes diferentes no relatório. Padronizar tudo em minúsculas evita esse racha.

Para o WhatsApp, onde não existe formulário para receber o UTM, o recurso de conversa em um clique permite um link com mensagem pré-preenchida. Um texto diferente por campanha já indica a origem na primeira mensagem.

Por que o mesmo cliente aparece duas vezes no cadastro?

Porque o sistema compara telefones como texto, caractere por caractere. No nosso CRM, encontramos em produção a mesma pessoa cadastrada duas vezes: uma entrada vinda do WhatsApp, com 10 dígitos e sem etiqueta nenhuma; outra vinda do formulário, com 11 dígitos e as etiquetas de compra.

A diferença era só o 9 da frente do celular. O WhatsApp entregou o número sem ele; no formulário, a pessoa digitou com ele. Desde 2016 todo celular brasileiro tem nove dígitos, com o 9 acrescentado antes do número, como registrou a Agência Brasil na conclusão da mudança — mas o número continua chegando nos dois formatos, dependendo da porta.

Por que o telefone duplicado estraga a origem do cliente?

Porque a origem fica partida em duas fichas e nenhuma delas conta a história inteira. A ficha do WhatsApp diz que a pessoa chegou por lá, mas não sabe que ela comprou. A ficha do formulário sabe da compra, mas não sabe da conversa. Qualquer relatório de “qual canal vende” sai errado, e automações de recuperação podem mirar em quem já é cliente.

O agravante: o código do nosso CRM já tinha uma função pronta para comparar telefones ignorando formato. Ela só não era usada na hora de verificar duplicidade.

Por isso esse furo não tem contorno pelo painel: o conserto é uma alteração de código. No nosso caso, ele ainda está na fila — a mudança está entendida, mas depende de acesso ao servidor (o computador onde o sistema roda de verdade), e esse acesso não estava liberado. Enquanto isso, a ficha duplicada continua lá, e nós sabemos exatamente qual é.

E quando o mesmo cliente entra de novo por outra campanha?

Aqui mora uma pegadinha que parece defeito e não é. Quando um formulário recebe um telefone que já existe, o sistema não cria contato novo, não sobrescreve nome, e-mail nem origem, mantém a data de cadastro original e não abre card novo no funil. Mesmo assim, responde “enviado com sucesso”.

Na prática, o cadastro guarda a primeira origem. É uma escolha defensável — mas precisa ser conhecida. Quem testa o formulário com o próprio telefone repetido acha que “o lead não chegou”, quando ele chegou e foi fundido ao contato antigo. Se a segunda campanha importa, ela precisa virar uma etiqueta a mais, nunca uma troca da primeira.

Como testar se a etiqueta de entrada está funcionando?

Com um teste controlado, não com a conferência visual da lista. O que fizemos:

1. escolher um formulário sem funil ligado, para o teste não disparar nenhuma sequência de mensagens;
2. enviar com um telefone nunca usado antes — com telefone repetido, a regra de fusão esconde o resultado;
3. conferir o contador da etiqueta: foi de 0 para 1, e o contato apareceu com a etiqueta colada;
4. apagar o contato de teste e confirmar que o contador voltou a 0.

Logo depois da correção, as etiquetas novas ficaram zeradas por um tempo. Isso era esperado — nenhum contato novo tinha entrado ainda — e não era defeito. Contador zerado só é problema depois que alguém entrou.

Qual problema continua aberto mesmo com tudo etiquetado?

O contato que chega pelo WhatsApp não dispara o evento (o aviso interno que o sistema dá quando algo acontece) de “contato criado” no nosso CRM. A etiqueta resolve a origem. Mas uma régua de recuperação, a sequência automática de mensagens para quem não comprou, começa nesse evento e não enxerga quem veio pela conversa.

Colocar essas pessoas na régua exigiria disparar mensagens de verdade — decisão de gente, nunca da automação. Mais sobre esse tipo de falha silenciosa está em o que fazer quando a automação quebra e a tela dizia que estava tudo certo.

O que se ganha com a regra aplicada é concreto: abrir o cadastro e filtrar por porta de entrada, e juntar essa origem com os números de venda num lugar só. O custo e os tropeços de manter esse CRM estão em quanto custa construir um CRM sem contratar dev.

Quando conferir se a origem está sendo gravada?

Em três momentos, todos tirados do que deu errado no nosso caso:

• Ao criar um formulário novo. Foi assim que seis formulários ficaram com a etiqueta inicial em branco. O campo é opcional, e ninguém é obrigado a preencher.
• Ao apagar ou renomear uma etiqueta. O sétimo formulário apontava para uma etiqueta apagada, e o sistema não reclamou. Quem apaga etiqueta precisa conferir quem usava.
• Ao subir uma campanha nova. Antes de pagar o primeiro clique, faça o teste controlado descrito acima com um telefone nunca usado.

Fora desses momentos, basta olhar o contador de cada etiqueta de vez em quando. Contador parado enquanto entra gente é sinal de porta sem carimbo.

Isso faz diferença no meu negócio — ou só em quem tem várias portas de entrada?

Se aplica bem:

• Negócio com mais de uma porta de entrada. Formulário, WhatsApp e anúncio ao mesmo tempo. Sem carimbo, não dá pra comparar um canal com o outro.
• Quem paga anúncio. Só o UTM separa duas campanhas que mandam para o mesmo formulário.
• Quem usa mensagem automática de recuperação. Com ficha duplicada, a mensagem pode mirar em quem já comprou.

Não se aplica tão bem:

• Quando todo cliente chega pela mesma porta. Se só existe o WhatsApp, a etiqueta diria sempre a mesma coisa. Aí o que importa é o texto de campanha no link de conversa.
• Quando o cliente chega por indicação, sem link. Nenhum carimbo automático pega o boca a boca. Nesse caso, a origem só aparece se alguém perguntar “como nos conheceu?” e anotar.

Que skill montar para a IA vigiar a origem por você?

1. O que construir. Uma skill de auditoria de origem no Claude Code (uma skill é um conjunto de instruções salvas que a IA segue sempre do mesmo jeito). Ela faz duas coisas que, no nosso caso, ninguém tinha feito à mão. Primeiro, lista cada formulário e diz qual está sem etiqueta de entrada ou apontando para etiqueta apagada. Segundo, procura fichas duplicadas comparando só os dígitos do telefone, com e sem o 9 da frente. Ela mostra o que achou e não junta nem apaga ficha sozinha.

2. O pedido pronto para copiar. O pedido que recomendamos colar no Claude Code, dentro da pasta do seu CRM:

“Crie uma skill chamada ‘auditar origem dos clientes’. Ela deve: 1) listar todos os formulários de captura e marcar os que estão com a etiqueta inicial em branco ou apontando para uma etiqueta que não existe mais; 2) procurar contatos duplicados comparando só os números do telefone, tratando como a mesma pessoa um celular com e sem o 9 da frente, e me mostrar os pares lado a lado com as etiquetas de cada ficha; 3) conferir se o código já tem uma função que compara telefones ignorando o formato e me dizer se ela está sendo usada na checagem de duplicidade; 4) não juntar, não apagar e não disparar mensagem nenhuma sem meu ok. Me mostre o resultado numa tabela e explique em português simples.”

Como conferir se a auditoria acertou?

3. O teste dos sete formulários. Use o caso deste artigo como gabarito. Num cadastro como o nosso, a resposta certa é: seis formulários com a etiqueta inicial em branco e um apontando para etiqueta apagada. Cadastre de teste a mesma pessoa duas vezes, uma com 10 dígitos e outra com 11, como aconteceu aqui. A skill tem que mostrar as duas fichas como um par só. Depois da correção, repita o teste controlado da seção acima: o contador da etiqueta tem que ir de 0 para 1 e voltar a 0 ao apagar o contato de teste.

E se o meu CRM for um sistema pronto, e não próprio?

A parte da etiqueta por porta vale igual: na maioria dos sistemas, etiqueta de entrada é configuração de formulário e de automação, e dá para conferir pelo painel com o teste de 2 minutos.

A parte do telefone duplicado depende de como o fornecedor compara números. Pergunte ao suporte, com o exemplo deste artigo: “o mesmo celular com e sem o 9 da frente vira um contato só ou dois?”. Se a resposta for “dois”, exporte a lista de contatos e peça para a IA achar os pares comparando só os dígitos — sem apagar nada sozinha.

Quanto custa ter essa auditoria rodando?

4. Custo e tempo. O teste de 2 minutos do começo custa zero e não precisa de ferramenta nenhuma. A auditoria automática precisa do Claude Code, que vem a partir do plano Pro — R$ 110 no mensal ou R$ 92 por mês no anual, segundo a página oficial de preços conferida do Brasil em 02/10/2026 (sem impostos). Quanto tempo leva para montar, nós não medimos à parte; o que temos medido é o que o diagnóstico encontrou: 6 formulários com a etiqueta de entrada em branco e 1 apontando para uma etiqueta apagada.

Se o cadastro fosse começar hoje, por onde a gente começaria?

A gente consertaria a comparação de telefone antes de qualquer etiqueta. O motivo está no nosso próprio cadastro: a mesma pessoa em duas fichas, uma com 10 e outra com 11 dígitos. Etiqueta bem aplicada numa ficha partida continua contando meia história.

Depois, a gente poria uma etiqueta por porta, aplicada pelo sistema na hora da entrada. Nos sete formulários, só dois contatos tinham marca de origem. Isso mostra que depender de alguém lembrar não funciona. Por isso a gente deixaria a skill “auditar origem dos clientes” rodar a cada formulário novo e a cada campanha nova, nos três momentos listados acima.

O que a gente não faria: etiquetar à mão olhando a lista, nem trocar a primeira origem pela segunda campanha. E não jogaria contatos antigos numa sequência de mensagens só para completar a régua. Disparar mensagem de verdade é decisão de gente.

Saber de onde veio cada cliente exige que cada porta de entrada — formulário, WhatsApp, compra e link de campanha com UTM — carimbe o contato sozinha, no momento em que ele chega. E nenhuma etiqueta sobrevive a um cadastro que trata o mesmo celular, com e sem o 9 da frente, como duas pessoas diferentes.

Como este artigo foi feito: o caso é do CRM que mantemos em produção. O diagnóstico das etiquetas e o teste controlado foram feitos por nós em 28 e 29/07/2026; a automação de etiqueta do WhatsApp está ativa desde então; o conserto da comparação de telefone segue aberto. A IA ajudou a organizar o texto; os números e os testes são nossos.

Este artigo faz parte do pilar Do Excel ao sistema próprio — quando a planilha para de dar conta.

Dá para reativar uma base antiga pelo WhatsApp com baixo risco de bloqueio se três coisas andarem juntas: falar só com quem deu o número e aceitou contato, mandar devagar em lotes pequenos e parar quando alguém pedir para sair. E pelo caminho que os termos do WhatsApp permitem: a plataforma oficial.

Se você tem uma lista de contatos parada há meses e pensa em “mandar pra todo mundo de uma vez”, este é o texto que evita perder o número no primeiro dia.

Uma nota de vocabulário antes de começar. Quando falarmos em API (a porta que um sistema abre para outro conversar com ele), é a porta oficial que a Meta abre para empresas usarem o WhatsApp.

O que a política do WhatsApp permite, na letra?

A Política de Mensagens do WhatsApp Business exige duas condições para contatar alguém. A pessoa precisa ter passado o número para você. E precisa ter dado permissão para receber mensagens (o chamado *opt-in*). A mesma política manda respeitar qualquer pedido para deixar de receber comunicação, feito dentro ou fora do WhatsApp.

E avisa o mecanismo do bloqueio: usuários podem bloquear ou denunciar a empresa, e os sistemas do WhatsApp podem limitar quantas mensagens ela envia com base nesse retorno. Ou seja, o que derruba o número não é só o volume. É gente dizendo “não pedi isso”.

Qual a diferença entre API oficial e integração não oficial?

Circulam no mercado dois caminhos, e só um deles está dentro das regras:

	API oficial (WhatsApp Business Platform)	Integração não oficial
Como conecta	Pela plataforma da Meta, com número aprovado	Conecta o número como se fosse um WhatsApp Web
Mensagem para base antiga	Só por modelo aprovado, o template (texto fixo pré-aprovado)	Texto livre
Custo por mensagem	Modelo de marketing é cobrado	Sem cobrança por mensagem
Limite de envio	Definido pela Meta, por faixa	Nenhum oficial — você cria o seu
Risco principal	Queda de qualidade e limite reduzido	Banimento do número

Na oficial, fora da janela de 24 horas depois da última mensagem do cliente, só é permitido enviar modelo aprovado, segundo a documentação de preços da própria Meta. E todo modelo de marketing é cobrado.

Por que a integração não oficial arrisca o número?

A não oficial esbarra nos Termos de Serviço do WhatsApp, que listam como uso não permitido “mensagens em massa, mensagens automáticas” e acesso por “meios não autorizados ou automatizados”. A falta de custo por mensagem é o que atrai. Mas não existe plataforma oficial protegendo o número se ele cair.

Quantas mensagens por dia a API oficial deixa mandar?

A Meta conta por destinatários únicos em 24 horas, fora da janela de atendimento. Segundo a documentação de limites de mensagens, uma conta nova começa em 250 por dia. Sobe para 2.000 com verificação do negócio ou depois de 2.000 envios entregues em 30 dias com modelos de alta qualidade.

Daí em diante as faixas são 10.000, 100.000 e ilimitado, liberadas automaticamente quando a qualidade está alta e o negócio usou pelo menos metade do limite nos últimos 7 dias. A qualidade é o portão de todas as faixas: denúncia e bloqueio travam a subida.

Na prática, quanto tempo leva uma base de 1.890 contatos pela API oficial?

Com a nossa base limpa de 1.890 contatos válidos, a conta pela regra da Meta fica assim:

Situação da conta	Limite em 24h	Tempo para cobrir a base
Empresa verificada	2.000	1 dia
Conta nova, sem verificação	250	cerca de 8 dias

O limite conta pessoas diferentes contatadas pela empresa fora da janela de atendimento, num período móvel de 24 horas. Responder quem mandou mensagem não entra nessa conta. Ou seja: o volume raramente é o gargalo. O que decide é a qualidade do modelo, e é por isso que mandar tudo no primeiro dia, só porque o limite permite, continua sendo má ideia.

Como preparamos uma base de 2.482 contatos antigos antes de enviar

O caso é nosso: uma base de 2.482 contatos antigos de um produto digital de entrada, preparada para reativação por WhatsApp com automação própria. Antes da primeira mensagem, a base passou por uma limpeza. Ela mudou o tamanho real da campanha:

Etapa	Contatos
Base original	2.482
Descartados por telefone inválido	592
Com telefone válido	1.890
Com nome real no cadastro	425
Sem nome (mensagem sem saudação pelo nome)	1.465

Os 592 descartados eram números zerados, fixos sem o 9 e DDD inexistente. Mandar para número que não existe só gera erro e desperdiça envio, então saíram antes do primeiro disparo.

Que ritmo, lote e intervalo usamos?

O ritmo foi decidido para não atropelar uma base que esfriou, bem abaixo de qualquer limite de plataforma:

• 20 mensagens por dia, divididas em 4 lotes de 5
• Um a dois minutos entre uma mensagem e outra, para dar tempo de conferir o que saiu e parar a fila se algo der errado
• Janela das 9h às 18h, de terça a sexta
• Freio automático: a fila para sozinha depois de 3 erros seguidos

A fila e o freio foram montados como script (um pequeno programa que executa os passos sozinho) com o Claude Code. Eles rodam dentro do nosso CRM (o sistema onde ficam os contatos e o histórico de cada cliente).

A conta tem um custo claro: 1.890 contatos a 20 por dia são cerca de 95 dias de envio, ou uns seis meses na janela de quatro dias por semana. Lento é o preço de não perder o número.

Com a API oficial, ainda precisa de freio?

Precisa, mas o freio muda de função. Na oficial, o teto de volume é da Meta, pela faixa da conta. Ninguém precisa inventar um teto próprio. O que continua perigoso é a reação de quem recebe.

Segundo a documentação de qualidade de modelos, um modelo com feedback negativo de vários usuários ou baixa taxa de leitura pode mudar de status, e fora do status aprovado ele não pode mais ser enviado. Para base fria, o freio vira isto: mandar em ondas, olhar a qualidade do modelo antes da próxima e parar a fila depois de erros seguidos.

Por que não usamos o disparo em massa que o sistema já tinha?

O CRM tinha uma função de envio em massa pronta, e ela foi proibida de rodar nessa campanha: o intervalo entre mensagens era de 100 milissegundos, sem teto diário.

Com esse intervalo, os 2.500 contatos sairiam em uns 4 minutos. Para uma base que não fala com a empresa há meses, é a receita de denúncia em massa, e denúncia é o que derruba a qualidade do número. Ter um botão de disparo não significa que ele esteja calibrado para a sua base.

O que quebrou nos primeiros lotes?

Os dois primeiros lotes, de 5 mensagens cada, expuseram dois problemas que nenhum teste com o próprio número mostraria:

1. Número válido sem WhatsApp travava a fila. O telefone passava na validação, mas não tinha conta no aplicativo, e a fila tentava de novo sem parar.
2. Nome errado na saudação. Um contato tinha cadastrado como “nome” um DDD entre parênteses. Ele recebeu a saudação com esses números no lugar do nome.

Nasceu daí uma checagem tripla antes de cada lote: conferir telefone, conferir se o nome é mesmo um nome e conferir o texto final que vai sair. O lote seguinte saiu com zero erro.

Como evitar mandar duas vezes para a mesma pessoa?

O estado da campanha não fica na memória de ninguém nem numa planilha paralela. Cada envio bem-sucedido aplica uma etiqueta no contato dentro do CRM. A fila é recalculada a cada disparo, a partir de quem ainda não tem essa etiqueta.

Isso resolve dois problemas de uma vez. É impossível alguém receber a mesma mensagem duas vezes. E, se a conexão cair no meio de um lote, a fila retoma de onde parou sem ninguém recontar à mão.

E se o cadastro antigo estiver sujo?

Quase sempre está. Na nossa base, 1.918 registros tinham o e-mail gravado no campo do nome, defeito de uma importação antiga. A tentação é extrair o nome do e-mail, e ela erra feio: um endereço como “sobrinhoaparecida85” vira “Sobrinhoaparecida”.

A saída foi separar a base em duas fases. Primeiro, quem tem nome real, com saudação personalizada. Depois, o restante, com uma variante da mensagem que não usa nome. Saudação errada soa como spam, e spam gera denúncia.

O que colocar na mensagem para reduzir denúncia?

A política dá a direção, e a prática confirma:

• Lembrar de onde a pessoa conhece você logo na primeira linha. Contato antigo não lembra do cadastro
• Oferecer uma saída explícita, como “se não quiser mais receber, é só responder SAIR”, e cumprir na hora
• Tirar da fila quem pediu para sair, pelo mesmo mecanismo de etiqueta, para que nenhum lote futuro volte a falar com essa pessoa
• Uma mensagem só, sem sequência automática para quem não respondeu

Para quem respondeu e esfriou, o caminho é outro, detalhado em como fazer follow-up de orçamento que o cliente não respondeu.

Qual caminho escolher?

A recomendação é uma só: API oficial. É o caminho que a política protege. Você paga por modelo de marketing e respeita o limite da faixa, mas troca o risco de perder o número por uma regra clara e publicada. O custo mensal dessa conta está em quanto custa o agente de IA do WhatsApp Business.

A integração não oficial fica fora dos termos de serviço, e nenhum ritmo baixo muda isso: não é caminho para o número de que o negócio depende. E vale saber de antemão o que dá errado quando um agente de IA atende no WhatsApp.

Quando reativar a base se aplica bem — e quando não?

Se aplica bem a quem tem uma base que deu o número e aceitou contato. É a condição da política do WhatsApp citada no começo. Com ela, a reativação é contato com gente que já te conhece.

Também serve a quem aceita ir devagar. Na nossa base, o ritmo de 20 por dia levaria cerca de 95 dias de envio. Quem precisa de resposta em uma semana vai se frustrar.

Não se aplica a lista comprada, nem a número que nunca pediu contato. Falta o opt-in, e a política não abre exceção. Também não se aplica a quem já pediu para sair: esse contato sai da fila e não volta.

Como resolver isso com IA, passo a passo?

1. O que construir. Um agente de reativação ligado só à API oficial do WhatsApp. Ele faz em ordem tudo o que este artigo descreve: limpa a base, separa quem tem nome real, envia o modelo aprovado em ondas pequenas, confere a qualidade do modelo antes de cada onda e para a fila sozinho depois de 3 erros seguidos. Cada envio vira uma etiqueta no CRM, e quem responde SAIR sai da fila para sempre. Dá para montar com o Claude Code, a ferramenta da Anthropic que escreve e roda o código a partir de um pedido em português.

2. O pedido pronto para copiar. O pedido que recomendamos colar no Claude Code:

“Monte um agente de reativação de clientes antigos que use só a API oficial do WhatsApp (WhatsApp Business Platform, da Meta), com modelo de mensagem já aprovado. Antes de enviar: 1) descarte telefones inválidos, como número zerado, fixo sem o 9 e DDD que não existe; 2) separe quem tem nome real de quem tem e-mail ou números no campo do nome, e nunca tire nome de dentro de e-mail; 3) me mostre quantos contatos sobraram em cada grupo e espere meu ok. Ao enviar: mande em ondas pequenas, no horário comercial; antes de cada onda, confira se o modelo continua aprovado e com qualidade boa; pare a fila depois de 3 erros seguidos; marque cada contato enviado com uma etiqueta no CRM para nunca mandar duas vezes; e tire da fila na hora quem responder SAIR. Explique cada passo como se eu nunca tivesse programado.”

Como conferir se o agente acertou antes do primeiro envio?

3. O teste da base de 2.482. Rode só a limpeza, sem enviar nada, e compare com a tabela deste artigo. Na nossa base, a conta certa era: 2.482 na origem, 592 descartados, 1.890 válidos, 425 com nome real e 1.465 sem nome. Na sua base os números serão outros, mas a conta tem que fechar do mesmo jeito: descartados mais válidos igual ao total. Depois, plante dois cadastros-armadilha: um com um DDD entre parênteses no lugar do nome e outro com “sobrinhoaparecida85” no nome. Os dois têm que cair no grupo sem nome. Se algum receber saudação, o agente está reprovado.

Quanto custa e quanto tempo leva para rodar?

4. Custo e tempo. Há dois custos. O primeiro é a Meta: todo modelo de marketing é cobrado, e a conta mensal está em quanto custa o agente de IA do WhatsApp Business. O segundo é a ferramenta para montar o agente: a página oficial de preços do Claude, vista do Brasil em 02/10/2026, mostra o plano Pro a R$ 110 no mensal ou R$ 92 por mês no anual (R$ 1.100 de uma vez), com o Claude Code incluído. O plano Free não inclui o Claude Code, e os preços não incluem impostos aplicáveis.

O tempo de envio sai das contas deste artigo: 1.890 contatos levam 1 dia numa empresa verificada, cerca de 8 dias numa conta nova, ou cerca de 95 dias de envio no ritmo de 20 por dia. O tempo para montar o agente depende do seu CRM; não medimos esse número à parte.

O que a gente faria no seu lugar?

A gente limparia a base antes de qualquer envio. No nosso caso, 592 dos 2.482 contatos tinham telefone inválido. Mandar para eles só queimaria a qualidade do número.

A gente começaria pelos 425 contatos com nome real, pela API oficial. E olharia a qualidade do modelo antes de cada nova onda, como pede a documentação da Meta. Deixaríamos essa rotina inteira com o agente de reativação do passo a passo acima, com a limpeza conferida por uma pessoa antes do primeiro envio.

O que a gente não faria: apertar o botão de disparo em massa só porque ele existe. Nem tirar o nome do cliente de dentro do e-mail. As duas coisas geram mensagem com cara de spam, e spam gera denúncia.

Em resumo

Reativar clientes antigos pelo WhatsApp sem bloqueio pede a API oficial e três regras: só falar com quem deu o número e aceitou contato, mandar em ondas pequenas olhando a qualidade do modelo, e tirar da fila na hora quem pedir para sair. Na nossa base de 2.482 contatos, isso significou limpar 592 números inválidos antes de começar e travar o ritmo em 20 mensagens por dia, com freio automático após 3 erros seguidos.

Este artigo faz parte do pilar Atendimento que não escala — como automatizar sem virar robô chato.

Dá. O Google Ads tem uma API (a porta que o Google abre para outro sistema conversar com a conta). Ela deixa ler métricas, puxar termos de pesquisa e alterar campanhas por código. Exige projeto no Google Cloud com a API ativada, login autorizado e nível de acesso para contas reais. Orçamento, lance e pausa só mudam com aprovação humana.

Você anuncia no Google e passa o começo do dia abrindo aba por aba. Quer ver quanto gastou, que palavra puxou clique ruim e se a campanha ainda está no ar. Esse trabalho é o tipo que um script (um pequeno programa que faz a mesma tarefa sozinho) faz melhor. O que ele não deve fazer é decidir sozinho onde vai o seu dinheiro.

O que um sistema próprio consegue fazer com a API do Google Ads?

Na prática, três famílias de tarefa saem do painel e vão para o código:

Tarefa	Exemplo	Risco
Ler	gasto do dia, cliques, conversões, custo por conversão	nenhum, só consulta
Limpar	termos de pesquisa que geraram clique inútil, virando palavra negativa	baixo
Mexer em valor ou status	orçamento, lance, meta de custo por aquisição, pausar	alto: é dinheiro correndo

Ler é onde está quase todo o ganho de tempo. Um relatório que junta gasto, termos e conversões num lugar só substitui a volta diária pelo painel. Como montar esse tipo de visão consolidada está em como juntar dado de várias fontes num painel só.

O que a API exige antes da primeira chamada?

A regra mudou em 2026, e muito tutorial ainda descreve o modelo antigo. O token, ou seja, a espécie de senha técnica que identificava quem chamava a API, deixou de existir. Pela documentação oficial do token de desenvolvedor, esses tokens foram descontinuados em 9 de setembro de 2026.

O acesso passou a ser vinculado ao projeto do Google Cloud. E a conta de administrador, chamada MCC (a conta que gerencia várias contas de anúncio de uma vez), deixou de ser obrigatória para se inscrever.

O que sobra para configurar:

• um projeto no Google Cloud com a Google Ads API ativada;
• credenciais OAuth desse projeto, ou seja, o login em que você autoriza o sistema a agir na sua conta Google. Depois do login, elas viram um token de atualização (a chave que renova o acesso sem pedir login de novo);
• um nível de acesso que permita contas de produção;
• o identificador da conta de administrador em cada chamada, se o seu acesso à conta de anúncios passa por uma MCC.

O último item também está na documentação da API: quem acessa via conta de administrador e não informa esse cabeçalho recebe erro de permissão.

Quais são os níveis de acesso e qual basta para um negócio?

A página oficial de níveis de acesso lista quatro, todos gerenciados no projeto do Google Cloud:

Nível	Contas reais?	Limite diário em produção	Como se consegue
Teste	não, só contas de teste	—	vem ao ativar a API
Exploração	sim	2.880 operações	pedido no próprio console
Básico	sim	15.000 operações	exige verificação da marca
Padrão	sim	sem limite	análise de cerca de 10 dias úteis

Para quem administra as próprias campanhas, Exploração costuma bastar: libera conta real e o limite diário sobra para leitura e ajustes pontuais. Os níveis acima fazem sentido para ferramenta que atende muitas contas.

Como foi ligar isso numa conta real?

Montamos a conexão no fim de agosto de 2026 e ela só funcionou de ponta a ponta em 17 de setembro, contra uma conta real. No caminho houve três tropeços que nenhum passo a passo mencionava.

O que deu errado no caminho até a conta real?

O primeiro: um e-mail de aprovação de acesso básico chegou em 1º de setembro, e mesmo assim a chamada de teste falhava dizendo que o projeto não estava aprovado para produção. O motivo era a migração: o projeto do Google Cloud tinha nascido de novo no nível Teste, no sistema novo. Pedimos Exploração pelo console e a aprovação saiu em menos de um minuto.

O segundo: montar a requisição à mão, direto no endereço da API, devolveu erro 404 (o código de “endereço não encontrado”) na nossa tentativa. Com a biblioteca oficial em Python (uma linguagem de programação), a mesma consulta trouxe as campanhas reais da conta.

O terceiro: o servidor local, ou seja, o programa no próprio computador que recebe a resposta do login, caiu depois do redirecionamento. O código de autorização continuava na barra de endereço por alguns minutos. Deu para trocá-lo por token sem refazer o consentimento.

O código foi escrito e depurado com o Claude Code, e as credenciais ficam num arquivo fora do repositório e fora do controle de versão.

Quem aprova cada mudança, e o que impede um erro caro?

Uma divisão escrita antes do primeiro comando de escrita, e não depois do primeiro susto. A nossa ficou assim:

• Pode fazer sem perguntar, e mostrar depois o que mudou: metas e ações de conversão, palavras negativas, correções técnicas de configuração.
• Sempre para e pede aprovação, mostrando valor atual e valor novo: meta de custo por aquisição, orçamento, lance ou teto de custo por clique, ajustes de lance por local ou dispositivo, pausar campanha.
• Nunca faz: ativar campanha ou anúncio. Toda campanha criada por código sai pausada, e quem liga é uma pessoa.

Em campanha ativa, a regra aperta: um “pode seguir” dado para um valor não vale para o próximo. Cada número novo passa por um OK novo. Como dar autonomia a um agente sem transformar isso em aprovação de cada passo está em como fazer o agente rodar sozinho sem aprovar cada passo.

Por que confirmar valor se a própria conta pode mudar sozinha?

Porque o número que o script leu ontem pode não ser o de hoje. O Google Ads tem a opção de aplicar recomendações automaticamente, e entre elas estão ajustar metas de custo por aquisição, trocar a estratégia de lance e adicionar palavras-chave. Além disso, outra pessoa com acesso à conta pode ter mexido.

Por isso a aprovação mostra o valor atual lido na hora, lado a lado com o novo. Se o valor atual já não bate com o que você esperava, isso é um alerta, não um detalhe: algo mudou na conta sem passar por você.

Qual armadilha o status de pausa esconde?

A pausa não mora num lugar só. Quando uma campanha é importada com tudo pausado, ela fica pausada em quatro níveis: campanha, grupo de anúncios, palavra-chave e anúncio. Ativar só a campanha faz o painel mostrá-la como ativada, e mesmo assim ela entrega zero impressão.

Descobrimos isso em agosto de 2026, conferindo campanhas recém-importadas. O diagnóstico natural seria culpar palavra sem volume ou lance baixo. O erro estaria três níveis abaixo.

Duas consequências para quem automatiza. O script precisa ler os quatro níveis antes de concluir qualquer coisa sobre veiculação. E ligar continua sendo decisão humana, nível por nível.

Quando vale automatizar o Google Ads — e quando não?

Se aplica bem:

• Quem abre o painel todo dia para as mesmas conferências. Gasto, termos e conversões num relatório só substituem essa volta.
• Quem limpa termos de pesquisa com frequência. Transformar clique inútil em palavra negativa é tarefa repetida e de risco baixo.
• Quem cuida de várias campanhas ou contas. Aí a leitura por código economiza mais, e a MCC organiza o acesso.

Não se aplica tão bem:

• Uma campanha pequena, olhada uma vez por semana. Projeto no Google Cloud, login autorizado e nível de acesso dão mais trabalho que a própria volta pelo painel.
• Quando não há ninguém para aprovar mudança no dia. A trava depende de uma pessoa dizer sim ou não. Sem ela, a automação só serve para ler.
• Quando ninguém vai cuidar das credenciais. O acesso precisa ficar guardado fora do código, e alguém tem que saber onde.

Como resolver isso com IA, passo a passo?

1. O que construir

Um relatório diário de leitura, montado pelo Claude Code (a ferramenta da Anthropic que escreve e roda o código a partir de um pedido em português). Ele usa a biblioteca oficial da Google Ads API e entrega, num arquivo só, o gasto do dia, os cliques, as conversões, os termos de pesquisa e o status de cada campanha nos quatro níveis de pausa. Não muda nada na conta: só lê. Mexer em valor fica para depois, e sempre com aprovação.

2. O pedido pronto para copiar

O pedido que recomendamos colar no Claude Code, depois de ter o projeto no Google Cloud com a API ativada e o nível Exploração aprovado:

“Monte um script em Python usando só a biblioteca oficial da Google Ads API, sem montar requisição à mão. Ele deve apenas LER a minha conta, nunca alterar nada. Quero um relatório diário com: gasto do dia, cliques, conversões e custo por conversão de cada campanha; os termos de pesquisa que geraram clique sem conversão; e o status de cada campanha nos quatro níveis — campanha, grupo de anúncios, palavra-chave e anúncio. Guarde as credenciais num arquivo separado, fora do código e fora do controle de versão. Se o meu acesso passa por uma conta de administrador, inclua o identificador dela em cada chamada. Explique cada passo como se eu nunca tivesse programado.”

3. Como conferir se a IA acertou

Use a armadilha da pausa descrita acima como teste. Escolha uma campanha que o painel mostra como ativada, mas que tenha um grupo de anúncios ou uma palavra-chave pausada. O relatório certo aponta exatamente em qual dos quatro níveis está a pausa. Se ele disser só “ativada”, reprovou. Confira também um número: o gasto do dia no relatório precisa bater com o do painel.

4. Custo e tempo

O Claude Code vem no plano Pro do Claude, que custa R$ 110 no mensal ou R$ 92 por mês no anual (R$ 1.100 de uma vez), conforme a página oficial de preços vista do Brasil em 02/10/2026; os preços não incluem impostos aplicáveis. O plano grátis não inclui o Claude Code. O nível Exploração dá 2.880 operações por dia, que sobram para um relatório diário. Quanto ao tempo, depende da conta: no nosso caso, a conexão levou do fim de agosto até 17 de setembro de 2026 por causa dos três tropeços acima, e o pedido do nível Exploração saiu em menos de um minuto.

O que a gente faria no seu lugar?

A gente começaria só lendo, com o relatório diário montado pelo Claude Code no passo a passo acima. Na tabela das três famílias de tarefa, ler é risco zero e é onde está quase todo o ganho de tempo. Um relatório diário já tira você da volta pelo painel.

Para acesso, a gente pediria o nível Exploração. Ele libera conta real, saiu em menos de um minuto no nosso caso, e 2.880 operações por dia sobram para quem administra as próprias campanhas.

O que a gente não faria: deixar o código mudar orçamento, lance ou pausa sem mostrar o valor atual e o novo. Não ativaria campanha por código. E não montaria requisição à mão quando existe biblioteca oficial, porque foi aí que tomamos o erro 404.

Em resumo

A API do Google Ads permite ler métricas, limpar termos de pesquisa e ajustar campanhas por código, desde que o projeto do Google Cloud tenha a API ativada, login OAuth e pelo menos o nível Exploração para contas reais.

O que separa automação útil de prejuízo é a trava: orçamento, lance, meta de custo e pausa só mudam com aprovação humana mostrando valor atual e novo, e nenhuma campanha é ativada por código.

Quando a automação quebra mesmo com a tela dizendo que está tudo certo, o caminho está em quem conserta a automação que a IA construiu.

Este artigo faz parte do pilar Operação e processo — como documentar sem virar burocracia.

Uma planilha vira sistema no momento em que algo além de uma pessoa digitando precisa ler ou escrever nela de forma confiável: outro programa, uma automação, um relatório automático. É aí que a interface feita para clique humano falha. A saída costuma ser gerar o arquivo pronto por código, ou trocar a planilha por um banco de dados de verdade.

Você reconhece o momento. A planilha que começou com dez linhas virou quinze abas, cada uma com uma fórmula que só uma pessoa entende. Toda atualização é feita à mão, com medo de mexer numa célula errada e derrubar um cálculo que ninguém mais sabe refazer.

E o problema raramente é o tamanho. É que, em algum momento, alguém tentou ligar aquilo a outra coisa. Pode ser um script (um pequeno programa que faz uma tarefa sozinho), um relatório automático, um processo que devia ler ou escrever ali sem ninguém. E foi exatamente aí que travou.

Quando uma planilha deixa de ser planilha e vira sistema?

Não é o número de abas nem a quantidade de linhas. O teste é outro: alguém além da pessoa que digita precisa confiar naquele dado sem abrir o arquivo e olhar?

Se a resposta é sim, a planilha já parou de ser planilha. Um script lê dali todo dia, um relatório puxa aquele número, uma automação decide algo com base numa célula. Ela virou peça de um sistema. Só que ainda com a interface e as regras de uma ferramenta pensada para uma pessoa clicar.

Por que a automação por clique trava justamente quando a planilha mais precisa dela?

Porque a interface de uma planilha na nuvem foi desenhada para dedo e mouse humano. Os alvos são pequenos, e os menus mudam de lugar conforme o zoom da janela.

Automação de navegador que clica em coordenadas de tela depende de cada botão estar sempre no mesmo lugar. Isso já é um problema geral de automação de interface. Telas com escalas diferentes criam dois sistemas de coordenada, o físico e o lógico. Eles se desalinham conforme muda o DPI (quantos pontos a tela desenha por polegada) ou o zoom.

A documentação da Microsoft sobre escala de tela detalha esse desalinhamento. Numa planilha densa, com menus pequenos empilhados, o efeito aparece rápido.

Qual é a diferença entre editar a planilha ao vivo na nuvem e gerar o arquivo pronto?

Editar ao vivo depende da interface responder exatamente como esperado a cada clique: menu abrir, campo focar, seletor aparecer. Qualquer coordenada errada cai num lugar que não é o pretendido.

Gerar o arquivo pronto muda onde o risco mora. Em vez de simular clique numa tela, o código escreve direto na estrutura do arquivo — célula, fonte, cor, filtro. Nenhuma interface visual precisa responder.

Bibliotecas como o openpyxl fazem exatamente essa parte. Ele lê e grava arquivos `.xlsx` (o formato do Excel) em puro Python, com a formatação inteira pelo código, sem abrir programa nenhum.

Aspecto	Editar ao vivo por clique	Gerar o arquivo pronto por código
Depende de zoom/resolução da tela	Sim	Não
Onde o erro aparece	No clique errado, na hora	No código, antes de rodar
Quem confirma o resultado	Precisa reabrir a tela e olhar	O arquivo já sai pronto e formatado
Fonte da verdade	A planilha na nuvem	O arquivo gerado

Quando vale a pena trocar a planilha por um banco de dados de verdade?

Banco de dados é um arquivo ou serviço feito para guardar registros e deixar vários programas lerem e gravarem com segurança. Gerar o arquivo pronto resolve o caso mais comum: uma pessoa cuida do controle, e o que falta é confiabilidade na formatação e na atualização.

Não resolve quando várias pessoas ou vários processos precisam escrever ao mesmo tempo. Aí sim é hora de banco de dados de verdade, com controle de quem grava o quê e quando.

O sinal de que chegou essa hora não é o tamanho do arquivo, é a concorrência. Duas fontes tentando atualizar a mesma linha no mesmo minuto é o tipo de problema que arquivo e planilha não resolvem bem. Banco de dados existe justamente para isso. Isso pesa ainda mais quando o objetivo é juntar dado de fontes diferentes, como detalhamos em como juntar dado de várias fontes automaticamente num painel só.

Como resolver isso com IA, passo a passo?

Não saber programar não impede gerar o arquivo pronto. Impede fazer isso sozinho na hora. Mas o script se escreve uma vez e passa a rodar sempre que for preciso.

É assim que esse tipo de script normalmente nasce hoje. Alguém descreve o que a planilha precisa ter — colunas, formatação, filtro. Uma ferramenta de código, como o Claude Code, escreve o programa que gera aquilo. A diferença para contratar por fora é que o resultado é um arquivo de texto simples, que dá para reabrir e pedir para ajustar depois.

Como esse caminho se compara a montar a mesma automação numa plataforma visual está detalhado em Claude Code ou n8n/Make: qual resolve a automação do meu negócio.

1. O que construir

Um gerador de planilha: um script em Python, escrito pelo Claude Code (a ferramenta da Anthropic que escreve e roda o código a partir de um pedido em português), que lê o seu dado e grava o arquivo `.xlsx` já pronto com a biblioteca `openpyxl`. Ele entrega o arquivo formatado, com filtro e painel congelado, sem clicar em tela nenhuma. É o mesmo desenho da solução que ficou no caso deste artigo.

2. O pedido pronto para copiar

O pedido que recomendamos colar no Claude Code:

“Escreva um script em Python com a biblioteca openpyxl que gere a minha planilha de controle como arquivo .xlsx pronto, sem abrir programa nenhum e sem automação de clique. A planilha deve ter estas colunas: [liste aqui]. Quero: cabeçalho em negrito com cor de fundo, primeira linha congelada, filtro em todas as colunas e formatação condicional para [descreva a regra, ex.: linha em vermelho quando o status for ‘atrasado’]. O dado vem de [diga de onde]. Salve o arquivo numa pasta local e explique cada passo como se eu nunca tivesse programado.”

3. Como conferir se a IA acertou

Use a lista do caso real como teste. Abra o arquivo gerado e confira os cinco itens que o script precisa escrever sozinho: fonte, cor, painéis congelados, filtro e formatação condicional. Role a planilha para baixo: o cabeçalho tem que ficar parado. Mude uma linha para a condição da regra e gere de novo: a cor tem que mudar. Se algum dos cinco faltar, peça o ajuste antes de usar.

4. Custo e tempo

O Claude Code vem no plano Pro do Claude: R$ 110 no mensal ou R$ 92 por mês no anual (R$ 1.100 de uma vez), segundo a página oficial de preços vista do Brasil em 02/10/2026; os preços não incluem impostos aplicáveis. O plano grátis não inclui o Claude Code. A biblioteca `openpyxl` é de código aberto. Depois de pronto, o script do caso deste artigo gera o arquivo em segundos; o tempo de escrever o primeiro depende de quantas abas e regras a planilha tem.

O que deu errado quando tentei automatizar minha própria planilha?

Montei um controle de artigos em Google Sheets. Tentei automatizar a edição dele por automação de navegador: clicar em menus e digitar em células pela interface visual, do jeito que uma pessoa faria na tela.

Falhou 4 vezes seguidas. Na última, quebrou o próprio navegador — a captura de tela estourou o tempo de resposta. O que falhou, especificamente:

• clique no menu “Formatar” não abria;
• clique na caixa de fonte não abria o seletor;
• clique na “caixa de nome”, pra pular pra uma célula, caiu no botão errado e abriu um diálogo de “Importar arquivo”;
• clique pra fechar esse diálogo caiu no campo de busca de dentro dele.

O diagnóstico bateu com o que a automação de interface tem de frágil em geral. Alvos pequenos, empilhados, com coordenada de clique que muda de posição conforme o zoom da janela.

Vale registrar o que não generaliza. No mesmo dia, automação de navegador funcionou bem em outras ferramentas — WordPress, Gerenciador de Tags do Google, Search Console, YouTube. O problema foi específico da interface do Google Sheets, não uma regra de que toda automação de navegador falha.

Qual foi a solução que ficou disso?

Parei de tentar editar a planilha por fora. Passei a gerar o arquivo `.xlsx` já pronto por código, com a biblioteca `openpyxl`: fonte, cor, painéis congelados, filtro e formatação condicional, tudo escrito pelo script.

O arquivo cai numa pasta local, e eu mesmo arrasto pro Google Drive quando quero ver na nuvem. São dois cliques, sem passar pelo menu de importação que travava antes.

A regra que ficou: a fonte da verdade passou a ser o arquivo gerado, nunca mais a planilha na nuvem. Editar ao vivo na nuvem por automação de navegador deixou de ser algo que prometo nesse tipo de controle.

Hoje o controle de artigos não é mais editado por clique nenhum. Ele sai pronto — formatado, com filtro e painel congelado — de um script que roda em segundos. A planilha na nuvem virou só o espelho que abro pra consultar.

Para quem serve gerar o arquivo por código — e em quais casos não se aplica?

Se aplica bem nestes casos:

• uma pessoa só cuida do controle, e o que dói é formatar e atualizar à mão;
• o dado já existe em outro lugar e a planilha é só o jeito de mostrar;
• você tentou automatizar por clique e travou, como no caso acima.

Não se aplica quando:

• várias pessoas precisam digitar na mesma planilha ao mesmo tempo. Aí o caminho é banco de dados;
• a planilha é consultada poucas vezes e ninguém depende dela todo dia. O esforço não se paga;
• a equipe precisa editar ao vivo, célula por célula, na nuvem. O arquivo gerado é um retrato, não um lugar de trabalho.

O que a gente faria no seu lugar?

A gente pararia de tentar operar a planilha por fora. O caso deste artigo mostra o custo disso: 4 falhas seguidas e um navegador travado, só para mudar fonte e filtro.

A gente escolheria uma fonte da verdade — o arquivo gerado ou o banco — e trataria o resto como espelho. É a regra que sobreviveu ao caso.

Para o caso mais comum, uma pessoa só no controle, a gente pediria ao Claude Code o gerador de planilha do passo a passo acima e conferiria os cinco itens de formatação no primeiro arquivo.

O que a gente não faria: migrar direto para um banco de dados só porque a planilha ficou grande. O sinal certo é concorrência, não tamanho. Com uma pessoa só no controle, gerar o arquivo pronto resolve com menos peças.

Em resumo

Planilha vira sistema quando algo além de uma pessoa precisa ler ou escrever nela sozinho — e é nesse ponto que a interface visual, feita para clique humano, costuma falhar. A saída não é abandonar a planilha: é parar de tentar operá-la de fora para dentro e passar a gerar o arquivo pronto direto do dado.

Este artigo faz parte do pilar Do Excel ao sistema próprio.