Um checklist deve evitar erros caros, não criar conformidade cerimonial
Lançamentos de campanha falham de maneiras surpreendentemente comuns.
O país errado permanece selecionado.
Um evento de conversão dispara duas vezes.
O URL final aponta para uma promoção expirada.
Uma nova campanha é criada sob uma regra automatizada que altera seu orçamento imediatamente.
Um feed de produtos contém o preço errado.
Um teste é lançado sem uma hipótese documentada e, três semanas depois, ninguém consegue explicar o que estava sendo testado.
Nenhuma dessas falhas exige um algoritmo sofisticado.
Elas exigem disciplina operacional.
Este checklist foi projetado como um sistema preflight para equipes profissionais de mídia paga. Ele abrange restrições de negócio, mensuração, configuração de campanha, criativos, landing pages, feeds, automação, experimentação, monitoramento no dia do lançamento e documentação pós-lançamento.
A principal escolha de design é a severidade.
Nem todo item não verificado deve bloquear um lançamento.
Um rótulo de nomenclatura ausente não equivale a um evento de compra quebrado.
A planilha usa quatro níveis de severidade
P0 — Bloqueador de lançamento.
O problema pode causar danos materiais financeiros, de mensuração, de conformidade ou de experiência do cliente.
Exemplos: geografia errada, rastreamento de conversão quebrado, evento de compra duplicado, falha no checkout, alegação legal não aprovada.
P1 — Resolver antes do lançamento, a menos que explicitamente aceito.
A campanha pode tecnicamente ser lançada, mas o problema cria risco operacional significativo.
Exemplos: documentação ausente de controle de público, preservação incompleta de UTM, exclusões em nível de conta não revisadas.
P2 — Backlog de curto prazo.
Importante para a qualidade, mas normalmente não justifica interromper um lançamento limpo.
P3 — Higiene.
Itens de documentação e manutenção.
Isso é deliberadamente diferente de um checklist genérico que dá a cada linha a mesma caixa de seleção.
O risco operacional não é democrático.
Por que a severidade importa
Imagine uma campanha com 39 de 40 verificações concluídas.
Isso parece excelente.
Se o único item faltante é “a conversão de teste chega à plataforma de anúncios”, o lançamento não está 97,5% pronto.
Ele está bloqueado.
A aba Resumo da planilha, portanto, conta separadamente as verificações P0 e P1 não resolvidas e produz um estado de lançamento:
BLOQUEADO, CONDICIONAL ou PRONTO.
É um mecanismo simples com uma consequência útil: a porcentagem de conclusão não pode esconder um defeito crítico.
Comece pelo QA de negócio, não pelo QA de plataforma
As primeiras verificações ocorrem antes de a campanha ser construída.
A equipe deve documentar:
- objetivo principal do negócio;
- KPI principal;
- limite de CAC ou ROAS aceitável;
- responsável pelo orçamento;
- gasto máximo;
- ação de conversão;
- lógica de valor de conversão.
Isso captura um problema sutil, mas comum: uma campanha pode ser tecnicamente impecável e economicamente indefinida.
Se ninguém sabe o CAC máximo aceitável, “otimizar o desempenho” não é uma instrução operacional acionável.
Se o financeiro espera aquisição de novos clientes e a campanha otimiza todas as compras igualmente, a configuração pode estar correta na plataforma e errada para o negócio.
A mensuração é uma dependência do lançamento
O rastreamento costuma ser testado perto do fim.
Ele deveria ser especificado perto do início.
O checklist exige verificações explícitas de:
- ação de conversão principal;
- ID de evento/transação;
- deduplicação;
- valor e moeda;
- relação navegador/servidor;
- consentimento;
- conversão de teste chegando ao analytics;
- conversão de teste chegando à plataforma de anúncios.
O checklist de prontidão do GTM do Analytics Mania é uma referência útil porque trata planejamento, camada de dados, tags, ecommerce e implementação server-side como partes de um único processo de QA. Optmyzr e Adalysis mantêm igualmente sistemas extensos de auditoria de conta que cobrem rastreamento de conversão e erros estruturais.
Essas fontes são referências educacionais/de fornecedores. O checklist do Radar é intencionalmente mais amplo porque o risco de lançamento de campanha vai além da conta de anúncios.
O QA de criativos deve validar a promessa
A aprovação de criativos não é apenas verificar a proporção da tela.
A equipe deve verificar:
- a promessa corresponde à landing page;
- as alegações são defensáveis;
- a linguagem legal está presente;
- o produto mostrado está disponível;
- as restrições geográficas fazem sentido;
- as variantes de assets são de fato os arquivos de produção pretendidos.
Um anúncio bonito que promete algo que a landing page não pode entregar é um problema de taxa de conversão e um problema de confiança.
O checklist, portanto, trata a consistência de destino como uma verificação crítica.
O QA de landing page é QA financeiro
Um comprador de mídia pode não ser o responsável pelo site.
Ele ainda precisa de evidências de que o caminho de conversão funciona.
Para um lançamento de alto investimento, teste:
- carregamento no desktop;
- carregamento no mobile;
- envio de formulário ou checkout;
- código promocional;
- preço;
- lógica de frete;
- preservação de UTM;
- identificadores de clique quando relevante;
- confirmação pós-compra.
Uma campanha lançada em um formulário quebrado pode gastar milhares antes que um dashboard detecte isso.
O processo de lançamento deve descobrir o problema com uma transação de teste controlada.
O QA de feed exige contexto de negócio
Para Shopping, PMax, retail media e paid social baseado em catálogo, os feeds fazem parte da prontidão de lançamento.
Verifique:
- preço;
- disponibilidade;
- identificadores de produto;
- mapeamento de produto para landing page;
- lógica de categoria/rótulo personalizado;
- status da promoção.
Um feed pode ser aceito e ainda estar comercialmente errado.
Se uma campanha deve promover estoque de alta margem e a lógica de rótulo personalizado está errada, os diagnósticos da plataforma podem não sinalizar nada.
É por isso que o checklist inclui tanto QA técnico quanto QA de negócio.
A automação pode entrar em conflito com o lançamento
Contas modernas contêm agentes invisíveis.
Regras, scripts, estratégias de portfólio e automação de terceiros podem modificar uma campanha recém-lançada.
Antes da ativação, pergunte:
- Quais regras se aplicam?
- Quais scripts escaneiam esta conta?
- Há um otimizador de terceiros conectado?
- As recomendações automatizadas têm permissão para serem aplicadas?
- Uma campanha pode herdar um comportamento inesperado de orçamento ou lance?
- Há outro sistema controlando o ritmo de gasto?
Este é um modo de falha cada vez mais importante.
A campanha aprovada às 09:00 pode não ser a campanha que existe às 14:00.
Experimentos também precisam de QA
Uma campanha pode ser lançada com sucesso e produzir um experimento inutilizável.
Antes de um teste começar, documente:
- hipótese;
- tratamento;
- controle;
- KPI principal;
- limite de sucesso;
- condição mínima de execução;
- risco de contaminação.
Sem isso, a equipe pode encerrar o teste procurando a métrica que faz o resultado parecer favorável.
O checklist trata o design de experimentos como parte da prontidão de lançamento porque uma configuração fraca de experimento desperdiça orçamento mesmo quando a veiculação da campanha funciona perfeitamente.
Evidência é mais valiosa do que “concluído”
Para verificações P0 e P1, anexe evidências.
Exemplos:
- captura de tela da geografia;
- ID da transação de teste;
- URL de pré-visualização;
- evidência de depuração de rastreamento;
- aprovação jurídica;
- diagnóstico de feed;
- especificação do experimento.
Uma linha de checklist marcada como “Aprovado” pela mesma pessoa que a configurou é mais fraca do que uma verificação com evidência inspecionável.
O objetivo não é burocracia.
É reduzir a dependência da memória.
O dia do lançamento faz parte do checklist
A planilha inclui fases do dia do lançamento e pós-lançamento porque o preflight não consegue capturar tudo.
Monitore imediatamente após a ativação:
- ritmo de gasto;
- reprovações;
- disponibilidade da landing page;
- volume de sinais de conversão.
Em seguida, faça uma revisão de anomalias de 24 horas e uma revisão diagnóstica de 72 horas.
A primeira revisão pergunta: Algo está quebrado?
A segunda pergunta: O sistema está se comportando de forma plausível?
Não faça julgamentos estratégicos importantes com base em poucas horas de dados, a menos que a falha seja óbvia.
Modo de falha: automatizar todo o checklist
Fornecedores como Optmyzr e Adalysis podem automatizar muitas verificações de integridade de conta e executá-las continuamente. Isso é valioso, especialmente em muitas contas.
Isso não deve eliminar o preflight humano.
Um software pode detectar que uma campanha tem como alvo todos os países.
Ele pode não saber que o lançamento global é intencional.
Um software pode identificar uma anomalia de rastreamento.
Ele pode não saber qual evento o financeiro designou como autoritativo.
Automatize verificações determinísticas.
Mantenha a interpretação de negócio explícita.
Modo de falha: verificações demais
Um checklist de 300 linhas pode se tornar menos seguro do que um de 40 linhas se os operadores clicarem mecanicamente por ele.
O checklist incluído aqui é intencionalmente compacto o suficiente para ser operado.
Adicione verificações quando sua organização repetidamente passa por uma falha que o processo atual não evitou.
Remova verificações que não representam mais risco significativo.
O checklist deve evoluir a partir de incidentes.
Baixe o checklist
A planilha inclui:
- o checklist completo de preflight;
- menus suspensos de severidade;
- campos de responsável e status;
- campo de evidências;
- data de vencimento;
- resumo de prontidão para lançamento.
Use-o como um portão de lançamento controlado.
Uma equipe profissional deve conseguir responder, antes de uma campanha começar:
O que ainda pode dar errado, quem é responsável e qual evidência mostra que estamos prontos?
