QA de campanha antes de publicar: checklist que o time consegue seguir

A campanha sai às 18h40 porque o cliente pediu “ainda hoje”. O gestor duplica. A URL fica a do cliente anterior. O UTM traz o nome da marca vizinha. O pixel dispara para o dataset certo e o anúncio está na BM errada. Ninguém era o aprovador: o grupo “viu”. QA de campanha antes de publicar existe para esse quarto de hora, não para o PDF de 40 linhas que ninguém abre. O checklist que o time de tráfego pago consegue seguir é curto, nomeado e igual na segunda e na sexta.

Este texto é produtividade operacional. Não é teoria de criativo. Não é diagnóstico de conta desativada. É o rito na porta da publicação: URL, UTM, pixel, conta certa, aprovador. Cinco checagens. Uma pessoa que diz sim. Sem isso, o naming bonito e o isolamento de sessão não salvam o clique no anunciante vizinho.

Por que o checklist longo morre

Porque a sexta ganha. Sempre.

Roteiro com trinta itens ensina o time a pular o roteiro. O cérebro escolhe o atalho. O atalho é duplicar e publicar. O QA que sobrevive tem que caber na memória e na tela, no mesmo recorte em que o gestor já está: o perfil do cliente, a campanha aberta, o Slack do aprovador.

Três tamanhos, não um.

Curto. Duplicar, ajuste de lance, troca de criativo já aprovado. Cinco linhas. Obrigatório. Ninguém dispensa na pressa. A pressa é o motivo.

Médio. Campanha nova no mesmo anunciante, mesma landing conhecida. Curto mais: público, orçamento, fuso, nomenclatura.

Longo. Anunciante novo, vertical sensível, landing nova, pixel novo. Aí sim entra jurídico, brand, consentimento, o que o contrato pedir. Longo não se aplica ao duplicar das 18h40. Se aplicar, o longo não acontece e o curto também cai.

Escreva os três tamanhos. Diga qual o default. Default é o curto. O médio e o longo se anunciam. Não o contrário.

As cinco linhas que não negociam

URL. A do anúncio, a do destino, a do preview. Não a do briefing de três semanas. Clique. Veja o domínio. Veja o HTTPS. Veja se o path é o da oferta deste cliente. Copiar da campanha anterior é o modo clássico de anunciar a loja do vizinho.

UTM. Fonte, medium, campanha, conteúdo, termo — o que o dicionário da agência usa. Nomenclatura que o relatório entende. Nome do cliente certo. Nome da campanha que o time reconhece. UTM da marca A na conta B é o tipo de erro que o financeiro acha no mês seguinte.

Pixel. Qual dataset dispara na landing. Qual evento. Se o GTM do cliente ainda tem o fornecedor antigo. Perfil isolado não corrige tag no HTML. O QA abre a landing e confirma o disparo, ou confirma com o ops que o disparo foi conferido nesta landing nesta semana. “Deve estar certo” não é conferência.

Conta certa. BM certa, MCC certa, anúncio na identidade certa, perfil de browser certo. Publicar a campanha do cliente A logado no perfil do cliente B é o incidente que o isolamento existe para tornar difícil — e o QA existe para tornar visível. Olhe o nome no canto. Olhe a linha do inventário. Olhe o dono.

Aprovador. Um nome. Cliente, head, coordenador, quem o contrato disser. Horário. “O grupo viu” não assina. Se o aprovador não responde até o horário combinado, a campanha não sai. Sai no próximo horário. A pressa do comercial não substitui o nome.

Cinco linhas cabem num card, num comentário da campanha, num checklist da ferramenta de projeto. Não cabem num discurso. Se o time não consegue recitar as cinco, o rito ainda é PDF.

Conta certa é o item que o isolamento não substitui

O gestor opera vários anunciantes no mesmo dia. O rito de troca de perfil ajuda. O QA na porta confirma. São camadas. Quem confia só no perfil descobre o clique na BM que ainda estava aberta. Quem confia só no QA e trabalha num Chrome único descobre o cookie do vizinho.

No curto, a pergunta é binária: este anúncio está na identidade que o inventário chama de produção deste cliente? Sim ou não. Não é “parece a BM”. É o ID, o nome, o perfil.

Conta de teste e conta que fatura. Publicar o teste na que fatura é QA falho. Publicar a que fatura no perfil de teste também. O inventário marca produção. O QA lê a marca.

UTM e naming: o QA não inventa dicionário

Se a agência não tem dicionário, o QA de UTM vira gosto pessoal. Gosto pessoal quebra o relatório multi-cliente.

O QA aplica o padrão. Fora do padrão, bloqueia no curto ou escala no médio. Não reescreve o dicionário às 18h. Reescrita é procedimento, horário comercial, dono do padrão.

Naming de campanha segue a mesma lógica. O time precisa ler o nome daqui a 90 dias. O cliente também. O QA do curto verifica se o nome nasceu do template, não se o nome é poético. Poesia é briefing. Template é publicação.

Pixel: a checagem que o ads manager não faz

O painel de ads aceita publicar sem o dataset certo. A landing aceita dois pixels. O QA é o único momento em que alguém cruza anúncio, URL e tag.

Recortes mínimos: ID do pixel ou do dataset neste anunciante; evento de conversão que o contrato usa; ausência óbvia de pixel de outro cliente na mesma página. Ferramenta de tag, preview, o que a mesa já usa. Não invente stack na porta da publicação.

Se a landing é nova, o tamanho do QA sobe. Curto não cobre landing nova. Médio ou longo cobrem. Duplicar criativo para a mesma URL conhecida permanece curto.

CAPI e server-side não se “conferem no feeling”. Se o evento depende disso, o ops confirma no recorte médio. O gestor no curto não finge que viu o servidor.

Aprovador: o nome que o jurídico pergunta depois

Quem autorizou o criativo. Quem autorizou o gasto. Quem autorizou a URL. Às vezes é a mesma pessoa. Às vezes não. O checklist pede o nome que o roteiro definiu para publicar.

Cliente que aprova no WhatsApp com um sticker: o rito pede recorte. Sticker pode valer se o procedimento diz que vale e se a mensagem fica arquivada. Grupo de 20 pessoas com “pode ir” no meio de 40 mensagens não vale.

Head que aprova tudo vira gargalo. Gargalo gera atalho. Atalho mata o QA. Delegue o recorte: coordenador aprova duplicar; head aprova anunciante novo; cliente aprova criativo de marca. Escreva. O QA só consulta a tabela.

Publicar sem aprovador no plantão: só se o plantão é o aprovador nomeado para aquele recorte. Senão a campanha espera. Mídia parado até segunda é melhor que anúncio no domínio errado até segunda.

O que o QA não é

Não é prova de que o criativo passa na política. Reprovado não é problema de fingerprint. Eixo diferente. O QA de publicação não substitui o revisor da plataforma e não substitui o olhar de brand.

Não é teste de leak. Leak se testa na entrada do cliente e na auditoria. Na porta da campanha, o gestor não abre o checker. Abre a URL.

Não é momento de heroísmo. Se o checklist curto falhou, a campanha não sai. Corrigir URL leva dois minutos. Corrigir reputação de anunciar o vizinho leva o trimestre.

Não é auditoria de verba. Orçamento absurdo pode ter um item no médio. No curto, o aprovador de gasto já deveria ter existido. Se não existiu, o problema é rito de verba, não de URL.

Time de dois versus mesa de dez

Em dois, o gestor é o aprovador de si mesmo se o roteiro não disser o contrário. Isso quebra o QA. A regra mínima: quem publicou não é o único nome no card. O segundo nome pode ser o sócio, o cliente, o coordenador de meia hora. Sem segundo nome, o curto ainda corre, mas o incidente não tem a quem apontar além do herói. Herói não escala.

Em dez, o risco é o contrário: fila. QA que depende do head em toda duplicação gera atalho. Delegue o curto ao coordenador do squad. Head fica no longo e no anunciante novo. Escreva a tabela. O card consulta a tabela, não o humor do Slack.

Agência com vários clientes na mesma mesa precisa do item “conta certa” mais do que a in-house de um anunciante só. O erro caro é o vizinho, não o fuso. O checklist curto existe para o vizinho.

Os erros que o curto pega — e os que não pega

Pega: URL da campanha anterior; UTM com nome da marca B; pixel do job antigo na landing nova; BM do cliente A com anúncio do cliente B; publicação sem nome no card.

Não pega: claim que a plataforma vai recusar; landing lenta; público mal construído; lance absurdo se o médio não rodou; consentimento de cookie. Quem espera o curto cobrir política está no eixo errado. Quem ignora o curto porque “o criativo já foi aprovado” está no eixo da pressa.

Um log simples no fim do mês: quantas publicações sem as cinco linhas; quantos incidentes de URL ou conta. Se publicação sem card continua alta, o coordenador cedeu. O rito morreu na exceção. A exceção vira default na sexta.

O cliente que pede “no ar em vinte minutos” ouve as cinco linhas em voz alta. Duas delas já estão prontas se o briefing foi sério. URL e aprovador. As outras três cabem no duplicar. Se não cabem, o briefing não estava pronto. Publicar briefing cru não é agilidade. É QA zero com verba.

Como implantar na semana, sem palestra

Imprima as cinco linhas no canal do squad. Literalmente. As cinco. Não o manifesto.

Na próxima campanha, o gestor cola as cinco respostas no card. URL. UTM. Pixel. Conta. Aprovador. O coordenador recusa publicação sem as cinco. Uma semana. O hábito pega ou o coordenador cede. Se ceder, não havia rito.

Ferramenta de projeto, comentário na campanha, planilha feia. Qualquer suporte serve. Nenhum suporte serve se o default continua sendo duplicar em silêncio.

Meça o que importa: incidentes de URL errada, conta errada, UTM de outro cliente. Se o número não cai em um mês, o checklist não está na porta. Está no Drive.

QA que o time segue é o que cabe na pressa. A pressa não vai embora. O PDF vai. Fique com as cinco linhas. Nomeie o aprovador. Publique. O resto é procedimento para o dia em que houver tempo. O dia em que houver tempo não é a sexta às 18h40.

Se o coordenador só cobra o QA quando o incidente já aconteceu, o rito nunca nasceu. Cobre na próxima publicação. Uma recusa pública e educada no canal do squad ensina mais que o PDF. A recusa é o produto. O checklist é o roteiro da recusa.