Post mortem de campanha de marketing: um método sem culpados baseado na linha do tempo

O que é um post mortem de campanha de marketing?

Um post mortem de campanha é um documento curto escrito depois que algo deu errado: as conversões caíram, o gasto estourou, os leads pararam ou o tracking quebrou. Ele explica o que aconteceu, quanto custou, por que aconteceu e o que muda para não se repetir.

O formato vem da engenharia de confiabilidade (SRE). O livro de SRE do Google descreve o postmortem como o registro escrito de um incidente, do seu impacto, das ações tomadas para mitigá-lo, das causas raiz e das ações de acompanhamento que evitam a repetição. Times de marketing podem usar quase a mesma estrutura, porque contas de anúncio, tags e sites falham do mesmo jeito: alguém publica uma mudança, algo quebra mais à frente e ninguém liga uma coisa à outra por dias.

Post mortem não é o mesmo que retrospectiva de campanha. A retrospectiva avalia a campanha inteira quando ela termina: o que funcionou, o que repetir, o que abandonar. O post mortem olha para um incidente e sua causa. Os dois têm valor; este artigo trata da análise de incidente. Para o método de diagnóstico mais amplo, veja análise de causa raiz em marketing.

Quando fazer um post mortem de campanha?

Faça quando um incidente passar de um limite combinado antes, e não quando alguém estiver irritado. O livro de SRE do Google recomenda definir os gatilhos antes dos incidentes e cita exemplos como degradação visível acima de um limite, perda de dados, rollback, tempo de resolução acima do limite e falha de monitoramento, quando o incidente foi achado manualmente.

No marketing, gatilhos razoáveis são:

• Desempenho: uma métrica-chave (conversões, leads, ROAS, CPA) sai da faixa combinada por dois dias ou mais sem motivo planejado.
• Dinheiro: o gasto passa do orçamento acordado ou vai para tráfego que você não queria comprar.
• Dados: conversões perdidas, contadas em dobro ou atribuídas errado em qualquer período.
• Rollback: uma mudança teve de ser desfeita, como uma landing page, uma estratégia de lances ou uma versão do contêiner de tags.
• Detecção: o cliente ou seu chefe percebeu o problema antes do time.

A Atlassian, por exemplo, faz post mortem para incidentes de severidade 1 e 2 e deixa opcional para os demais. Uma regra parecida funciona em agências e times internos: obrigatório quando o cliente percebeu ou houve prejuízo, opcional no resto. Qualquer stakeholder pode pedir um.

O que um modelo de post mortem de marketing deve ter?

Mantenha o modelo curto o bastante para as pessoas preencherem. O modelo de incidentes da Atlassian cobre resumo, contexto, falha, impacto, detecção, resposta, recuperação, linha do tempo, cinco porquês, causa raiz, recorrência, lições e ações corretivas. Para um incidente de campanha, estes campos bastam:

A linha do tempo de mudanças é o campo que a maioria pula, e é ele que decide se a análise vale alguma coisa. Sem ele, a causa raiz é um palpite com cara de conclusão. Se você ainda não registra as mudanças, comece com um modelo de change log de marketing e preencha as duas semanas anteriores ao incidente.

Como provar qual mudança causou o incidente?

Coloque em ordem todas as mudanças dos dias antes de a métrica mexer, descarte o tracking primeiro e teste uma hipótese por vez. O guia da Atlassian sobre post mortem sem culpados diz o mesmo: alinhe uma linha do tempo comum do que aconteceu antes de analisar causas.

Reúna mudanças de todas as fontes, não só da conta de anúncios:

• Edições do time no Google Ads e no Meta Ads: orçamentos, metas de lance, públicos, criativos.
• Automações da plataforma: recomendações aplicadas automaticamente, regras automáticas, scripts.
• Releases do site, mudanças em landing pages e checkout.
• Tracking: versões do Google Tag Manager, banner de consentimento, ações de conversão.
• Mudanças no CRM e no produto, além de eventos externos como feriados ou quedas de serviço.

No Google Ads, abra o "Histórico de Alterações" no menu Campanhas. Ele cobre os últimos 2 anos e mostra o usuário que fez cada mudança; as automáticas aparecem com nomes como "Google Ads system". Para tags, o histórico de versões do GTM mostra quem publicou cada versão. O guia do histórico de alterações do Google Ads explica os filtros.

Com todas as mudanças em uma única linha do tempo, o incidente costuma deixar de ser mistério: você vê que uma tag foi publicada na noite anterior à queda e que a meta de lance mudou no dia antes. No Changeline, as edições do Google Ads podem ser importadas automaticamente com os valores antes → depois e a origem, e o time registra o resto na mesma linha do tempo do projeto.

Exemplo: na segunda-feira o cliente pergunta: "Por que as compras do Google Ads caíram 40% no fim de semana?" O time alinha as mudanças dos dias anteriores. Quinta: ROAS desejado de 400% para 500%. Sexta: checkout novo no ar e uma versão do GTM publicada. Sábado: as compras caem. Um teste mostra que a tag de compra não dispara na nova página de confirmação, então o tracking explica a queda. A mudança de ROAS entra na análise como fator a acompanhar quando os dados voltarem. Nomes e números são ilustrativos.

Para provar a causa em vez de supor, confira três coisas: o tempo bate (a métrica mudou depois da alteração, não antes), o escopo bate (só mexeram as campanhas, páginas ou dispositivos afetados) e, quando possível, corrigir ou desfazer a mudança traz a métrica de volta.

Como conduzir uma reunião de post mortem sem culpados?

Foque no sistema, não na pessoa que fez a mudança. O livro de SRE do Google resume assim: não dá para "consertar" pessoas, mas dá para consertar sistemas e processos. Quem subiu a meta de lance ou publicou a tag agiu com a informação que tinha; a pergunta útil é por que o processo deixou a mudança ir ao ar sem checagem.

Uma pauta de 30 minutos que serve para a maioria dos incidentes:

1. Alinhar a linha do tempo
2. Confirmar impacto e detecção
3. Perguntar por quê cinco vezes
4. Definir ações e responsáveis

Comece pela linha do tempo, porque ela elimina a maior parte das discussões: quando todos veem as mesmas mudanças com data, a conversa sai da opinião e vai para a evidência. Depois use os cinco porquês: parta do impacto e pergunte por quê até chegar a algo que, se mudar, impede esse tipo de incidente. A Atlassian define a causa raiz como aquilo que precisa mudar para que essa classe de incidente não se repita. "O analista esqueceu de testar a tag" não é causa raiz; "mudanças de tag vão ao ar sem teste na página de conversão" é.

Chame quem fez as mudanças e o responsável pela conta. Se o cliente percebeu o incidente, mande depois um resumo escrito em vez de levá-lo à discussão interna. O guia para explicar uma queda de conversões ao cliente ajuda nessa mensagem.

Como transformar o post mortem em ações que acontecem?

Dê a cada ação um responsável, um prazo e um lugar onde ela é acompanhada, e revise as pendentes na reunião seguinte. A Atlassian registra cada ação como item no backlog do time dono, separa ações prioritárias (que corrigem a causa raiz) de ações de melhoria e define prazo de 4 ou 8 semanas para as prioritárias, conforme o serviço.

Boas ações de marketing são específicas e delimitadas, por exemplo:

Guarde os post mortems onde o time vai encontrá-los, junto do change log do cliente. O livro de SRE do Google avisa que um postmortem não revisado é como se nunca tivesse existido, e o mesmo vale para um que ninguém acha. Em um ano, a coleção mostra que tipo de mudança causa mais incidentes, o melhor insumo para o seu processo de mudanças. Um change log de marketing é o lugar natural para os dois. Nos planos pagos do Changeline, o relatório de mudanças transforma qualquer período em um PDF das mudanças registradas ou importadas, que você pode anexar à análise.