Post mortem de campanhas de marketing: um método sem culpas assente na cronologia

O que é um post mortem de campanha de marketing?

Um post mortem de campanha é um documento curto escrito depois de algo correr mal: as conversões caíram, o gasto ultrapassou o previsto, os contactos pararam ou o tracking deixou de funcionar. Explica o que aconteceu, quanto custou, porque aconteceu e o que muda para não se repetir.

O formato vem da engenharia de fiabilidade (SRE). O livro de SRE da Google descreve o postmortem como o registo escrito de um incidente, do seu impacto, das ações tomadas para o mitigar, das causas raiz e das ações de seguimento que evitam a repetição. As equipas de marketing podem usar quase a mesma estrutura, porque contas de anúncios, etiquetas e sites falham da mesma forma: alguém publica uma alteração, algo mais à frente avaria e ninguém liga uma coisa à outra durante dias.

Um post mortem não é o mesmo que uma retrospetiva de campanha. A retrospetiva avalia a campanha inteira quando termina: o que funcionou, o que repetir, o que abandonar. O post mortem olha para um incidente e para a sua causa. Ambos são úteis; este artigo trata da revisão de incidentes. Para o método de diagnóstico mais amplo, consulte a análise de causa raiz em marketing.

Quando deve fazer um post mortem de campanha?

Faça-o quando um incidente ultrapassa um limite acordado antecipadamente, e não quando alguém está aborrecido. O livro de SRE da Google recomenda definir os critérios antes dos incidentes e dá exemplos como degradação visível acima de um limite, perda de dados, reversão, tempo de resolução acima do limite e falha de monitorização, quando o incidente foi detetado manualmente.

No marketing, critérios sensatos são:

• Desempenho: uma métrica-chave (conversões, contactos, ROAS, CPA) sai do intervalo acordado durante dois dias ou mais sem motivo planeado.
• Dinheiro: o gasto ultrapassa o orçamento acordado ou vai para tráfego que não pretendia comprar.
• Dados: conversões perdidas, contadas em duplicado ou mal atribuídas em qualquer período.
• Reversão: foi preciso desfazer uma alteração, como uma landing page, uma estratégia de licitação ou uma versão do contentor de etiquetas.
• Deteção: o cliente ou a chefia deu pelo problema antes da equipa.

A Atlassian, por exemplo, faz post mortems para incidentes de gravidade 1 e 2 e deixa-os opcionais nos restantes. Uma regra semelhante funciona em agências e equipas internas: obrigatório quando o cliente deu pelo problema ou houve prejuízo, opcional nos outros casos. Qualquer parte interessada pode pedir um.

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

Mantenha o modelo curto o suficiente para ser preenchido. O modelo de incidentes da Atlassian cobre resumo, contexto, falha, impacto, deteção, resposta, recuperação, cronologia, cinco porquês, causa raiz, recorrência, lições e ações corretivas. Para um incidente de campanha, estes campos chegam:

A cronologia de alterações é o campo que a maioria das equipas salta, e é ele que decide se a revisão vale alguma coisa. Sem ela, a causa raiz é um palpite com ar de conclusão. Se ainda não regista as alterações, comece com um modelo de registo de alterações de marketing e preencha as duas semanas anteriores ao incidente.

Como provar que alteração causou o incidente?

Ordene todas as alterações dos dias antes de a métrica mexer, exclua primeiro o tracking e teste uma hipótese de cada vez. O guia da Atlassian sobre post mortems sem culpas diz o mesmo: acorde uma cronologia comum do que aconteceu antes de analisar causas.

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

• Edições da equipa no Google Ads e no Meta Ads: orçamentos, objetivos de licitação, públicos, criativos.
• Automatismos da plataforma: recomendações aplicadas automaticamente, regras automáticas, scripts.
• Lançamentos no site, alterações a landing pages e ao checkout.
• Tracking: versões do Google Tag Manager, banner de consentimento, ações de conversão.
• Alterações no CRM e no produto, além de eventos externos como feriados ou falhas de serviço.

No Google Ads, abra o "Histórico de Alterações" no menu Campanhas. Cobre os últimos 2 anos e mostra o utilizador que fez cada alteração; as automáticas surgem com nomes como "Google Ads system". Para etiquetas, 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 alterações numa única cronologia, o incidente deixa normalmente de ser um mistério: vê-se que uma etiqueta foi publicada na noite anterior à quebra e que o objetivo de licitação 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 a equipa regista o resto na mesma cronologia do projeto.

Exemplo: na segunda-feira, o cliente pergunta: "Porque é que as compras do Google Ads caíram 40% no fim de semana?" A equipa alinha as alterações dos dias anteriores. Quinta: ROAS alvo de 400% para 500%. Sexta: novo checkout em produção e uma versão do GTM publicada. Sábado: as compras caem. Um teste mostra que a etiqueta de compra deixou de disparar na nova página de confirmação, por isso o tracking explica a quebra. A alteração do ROAS fica na revisão como fator a acompanhar quando os dados voltarem. Nomes e números são ilustrativos.

Para provar a causa em vez de a presumir, confirme três coisas: o momento bate certo (a métrica mudou depois da alteração, não antes), o âmbito bate certo (só mexeram as campanhas, páginas ou dispositivos afetados) e, sempre que possível, corrigir ou reverter a alteração faz a métrica recuperar.

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

Centre a reunião no sistema, não na pessoa que fez a alteração. O livro de SRE da Google resume assim: não é possível "corrigir" pessoas, mas é possível corrigir sistemas e processos. Quem subiu o objetivo de licitação ou publicou a etiqueta agiu com a informação que tinha; a pergunta útil é porque é que o processo deixou a alteração entrar em produção sem verificação.

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

1. Acordar a cronologia
2. Confirmar impacto e deteção
3. Perguntar porquê cinco vezes
4. Definir ações e responsáveis

Comece pela cronologia, porque elimina a maior parte das divergências: quando todos veem as mesmas alterações datadas, a conversa passa da opinião para a evidência. Depois use os cinco porquês: parta do impacto e pergunte porquê até chegar a algo que, se mudar, impede este tipo de incidente. A Atlassian define a causa raiz como aquilo que tem de mudar para que esta classe de incidente não se repita. "O analista esqueceu-se de testar a etiqueta" não é causa raiz; "as alterações de etiquetas entram em produção sem teste na página de conversão" é.

Convide quem fez as alterações e o responsável pela conta. Se o cliente deu pelo incidente, envie-lhe depois um resumo escrito em vez de o levar à discussão interna. O guia para explicar uma quebra de conversões ao cliente ajuda nessa mensagem.

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

Atribua a cada ação um responsável, um prazo e um local onde é acompanhada, e reveja as pendentes na reunião seguinte. A Atlassian regista cada ação como item no backlog da equipa responsável, separa ações prioritárias (que corrigem a causa raiz) de ações de melhoria e define um 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 a equipa os encontra, junto do registo de alterações do cliente. O livro de SRE da Google avisa que um postmortem não revisto é como se nunca tivesse existido, e o mesmo vale para um que ninguém encontra. Ao fim de um ano, a coleção mostra que tipo de alteração causa mais incidentes, o melhor ponto de partida para o seu processo de alterações. Um registo de alterações de marketing é o sítio natural para ambos. Nos planos pagos do Changeline, o relatório de alterações transforma qualquer período num PDF das alterações registadas ou importadas, que pode anexar à revisão.