Documentação de marketing ops: o que registrar e onde entra o log de mudanças

O que é documentação de marketing ops?

Documentação de marketing ops é tudo o que uma pessoa nova no time precisaria para tocar o marketing sem te perguntar nada: como as ferramentas estão ligadas, como o trabalho recorrente é feito, quais regras valem e o que mudou e quando. Menos manual gigante, mais páginas curtas, fáceis de achar e atualizadas.

Quase todo time já tem pedaços disso espalhados entre wiki, Google Drive, configurações das plataformas e a cabeça das pessoas. O problema aparece em três momentos: quando alguém entra no time, quando uma conta troca de mãos e quando o cliente ou o chefe pergunta por que o resultado mudou. A Forrester resume o primeiro caso sem rodeios: a última coisa que alguém recém-contratado deveria fazer é sair clicando na plataforma de automação para entender como ela funciona.

Pense em quatro camadas: referência (o que existe), procedimento (como fazer o trabalho recorrente), regras (o que todos seguem) e histórico (o que mudou). A maioria dos times escreve as três primeiras e esquece a quarta, justamente a que você precisa quando uma métrica cai.

O que um time de marketing ops deve documentar?

Documente o que é difícil reconstruir de memória e o que quebra resultados quando duas pessoas fazem de jeitos diferentes. A tabela abaixo é um ponto de partida prático; cada linha precisa de um responsável e de um gatilho claro de atualização.

A lista da Forrester vai na mesma linha: cita programas de scoring, nutrição e distribuição de leads, processos de relatório e papéis como o que deve ficar escrito fora das plataformas. Nomenclatura merece página própria, porque uma troca de nome silenciosa divide um relatório em dois; veja o nosso post sobre padrão de nomenclatura de UTM para um modelo.

Como escrever um runbook de marketing que o time realmente usa?

Escreva um runbook por tarefa recorrente, na ordem em que alguém faria, com as verificações que provam que deu certo. Se um passo depende de julgamento, diga quem decide. Se der, caiba em uma tela.

1. Nomeie a tarefa e o responsável
2. Liste os passos em ordem
3. Inclua a checagem de cada passo
4. Diga o que registrar ao final

Um bom runbook para aumento de orçamento, por exemplo, diz onde alterar o valor, o tamanho máximo de aumento que o time combinou, o que olhar na manhã seguinte e que a mudança vai para o log com o motivo. Esse último passo é o que transforma um procedimento em histórico que você consegue ler depois.

O handbook de incidentes da Atlassian descreve playbooks que reúnem runbooks, checklists e templates para o time responder sempre do mesmo jeito. A ideia funciona igual no marketing: uma pasta por processo, páginas curtas e um link para onde o resultado fica registrado. Runbooks também aceleram a troca de agência; o nosso checklist de transição de agência lista o que passar adiante.

Onde o log de mudanças entra na documentação?

O log de mudanças é a camada de histórico: registra o que aconteceu de fato, enquanto runbooks e regras descrevem o que deveria acontecer. Sem ele, a documentação ensina a lançar uma campanha, mas não explica por que as conversões caíram em março.

Cada plataforma guarda uma parte desse histórico. O Histórico de Alterações do Google Ads mostra as mudanças dos últimos 2 anos, com o e-mail de quem editou pela interface e entradas como "Google Ads system" para as automáticas. O Google Tag Manager mantém um histórico de publicação com quem publicou cada versão e permite dar nome e descrição à versão. O GA4 deixa quem tem papel de Analista ou superior criar anotações (título de 60 caracteres, descrição de 150, até 1.000 por propriedade). Nenhuma enxerga a outra, nem as mudanças de landing page, CRM ou preço.

Por isso o log fica por cima de todas: uma entrada por mudança, com data, plataforma, responsável, motivo e efeito esperado. O nosso guia de log de mudanças de marketing explica o formato, e o modelo de log de mudanças traz as colunas para começar.

Exemplo: na quarta, o cliente pergunta por que os leads caíram na terça. Os runbooks mostram que os lançamentos seguiram o checklist, então o time abre o log. Ali estão um corte de CPA desejado no Google Ads na sexta, um formulário novo na landing page no sábado e uma versão do GTM publicada na segunda. O formulário perdeu o redirecionamento para a página de obrigado, e o evento de lead parou de disparar. No CRM, os leads seguiam estáveis; só a contagem rastreada caiu.

Como isolar qual mudança causou a queda usando a documentação?

Use a documentação numa ordem fixa: confirme o tracking pelo plano de tracking, liste todas as mudanças dos dias anteriores à queda e teste uma hipótese por vez. O mapa de ferramentas diz onde olhar; o log diz o que mudou.

1. Descarte o tracking primeiro. Compare o número da plataforma com a fonte de verdade definida no plano de tracking (CRM, pedidos, envios de formulário). Se só um lado caiu, é problema de medição.
2. Puxe todas as mudanças da janela. Pegue os 7 a 14 dias antes da mudança no log e complete as lacunas com o Histórico de Alterações do Google Ads e a lista de versões do GTM.
3. Compare com os runbooks. Uma mudança feita fora do procedimento (sem checagem no dia seguinte, sem motivo registrado) é suspeita número um.
4. Teste uma hipótese por vez. Reverta ou segmente pela mudança mais suspeita e acompanhe a métrica, em vez de desfazer tudo de uma vez.

Com todas as mudanças numa só linha do tempo, o exemplo acima se resolve em minutos: a versão do GTM aparece um dia antes da queda, logo depois da troca do formulário, e é ali que você olha primeiro. O Changeline mantém essa linha do tempo por projeto de cliente: as mudanças do Google Ads podem ser importadas automaticamente por uma conexão só de leitura, e o time registra o resto (site, tracking, CRM, preço) com responsável e motivo. Para o método completo, veja o guia sobre como explicar uma queda de conversões ao cliente.

Como manter a documentação de marketing ops atualizada?

Ligue cada documento ao evento que o deixa desatualizado e faça da atualização parte do fim da tarefa. A documentação envelhece quando vive separada do trabalho; ela se mantém viva quando o último passo de cada tarefa é atualizá-la.

Três hábitos resolvem a maior parte. Primeiro, um responsável com nome para cada página, para que "alguém precisa atualizar isso" tenha resposta. Segundo, uma revisão curta com ritmo fixo: mensal para o log e o plano de tracking, trimestral para runbooks e papéis. Terceiro, a regra de que nenhuma mudança entra no ar sem registro: quem muda o orçamento, a tag ou o formulário escreve uma linha com o motivo.

Se você já tem um processo de revisão, o nosso post sobre gestão de mudanças no marketing mostra como incluir aprovações sem travar lançamentos, e o post de post mortem de campanha mostra como transformar uma semana ruim em runbooks melhores.