Transformar a pergunta do negócio num plano de mensuração

Com o inventário feito, a Verde Vivo sabe o que a propriedade contém. Falta o inverso: o que a empresa quer saber. Uma propriedade com 27 eventos-chave e nenhuma pergunta escrita mede muito e não responde a nada, e é assim que a maioria das contas chega a 2026.

A conta chega no orçamento. Quando a diretoria pergunta se vale dobrar o investimento em Google Ads e o relatório devolve sessões, cliques e uma taxa de engajamento, alguém decide no palpite. Quando pergunta por que o clube de assinatura perde 4,1 por cento dos assinantes por mês e o GA4 só sabe contar visitas à página de cancelamento, a resposta vem do achismo com número decorativo.

Ao terminar, a pessoa tem um plano de mensuração: uma tabela em que cada linha começa numa pergunta de negócio e termina num evento com parâmetros, fonte, responsável e frequência de leitura. A Verde Vivo escreveu o dela para o e-commerce e para o B2B, e a tabela aparece inteira mais adiante.

Objetivo empresarial é a primeira palavra do plano, e ele se escreve em dinheiro ou em contrato: faturar mais com a mesma margem, reduzir o cancelamento do clube, fechar mais contratos de paisagismo por mês. Um objetivo que se escreve em métrica do GA4 ("aumentar o engajamento") já nasceu errado, porque ninguém paga folha com engajamento.

Entre o objetivo e o evento há uma árvore de quatro níveis, e cada nível responde a uma pergunta diferente. Objetivo: o que a empresa quer. Resultado: o número que prova que chegou lá. Processo: o que precisa acontecer no caminho para o resultado se mover. Diagnóstico: o que se olha quando o processo falha, para saber onde.

A árvore serve para descartar. Indicador que não cabe em nenhum nível não entra no plano, por mais fácil que seja de medir. Sessões totais, por exemplo, não são resultado (não provam nada), não são processo (não precisam acontecer para a compra acontecer) e só viram diagnóstico quando cruzadas com outra coisa.

Métrica de vaidade é o nome que essa categoria recebe: o número que sobe, agrada e não muda decisão nenhuma. Ela é reconhecível por um teste simples. Se o número dobrasse amanhã, alguém faria algo diferente? Se a resposta é não, a métrica pode ficar num relatório, mas fora do plano.

Pergunta analítica é diferente de pergunta de negócio, e o plano precisa das duas. A de negócio é aberta ("por que a receita caiu?"). A analítica é fechada e carrega uma hipótese: "a receita caiu porque o abandono no pagamento por boleto subiu depois da mudança do checkout em julho?". A segunda diz qual relatório abrir, qual filtro aplicar e o que contaria como resposta.

Hipótese boa tem três partes: a causa suspeita, o efeito esperado e o que a derruba. "Se o abandono no boleto subiu, o funil por meio de pagamento mostra a queda entre add_payment_info e purchase concentrada no boleto a partir de julho; se a queda é igual no Pix, a hipótese cai." Quem escreve assim já sabe quando parar de investigar.

O plano de mensuração é a tabela onde tudo isso vira contrato entre quem pergunta, quem implementa e quem lê. Sete colunas bastam: a pergunta, o indicador que a responde, o evento do GA4 que alimenta o indicador, os parâmetros que o evento carrega, a fonte (a tag, o servidor, o CRM ou a plataforma), o responsável pela leitura e a frequência com que alguém olha.

Nome de evento entra na tabela como vai entrar no código. purchase é a compra concluída; generate_lead é o orçamento enviado; close_convert_lead é o contrato assinado. Parâmetro entra do mesmo jeito: transaction_id é o número do pedido, value é o valor, currency é a moeda. A tabela é o primeiro lugar onde Marina e Caio leem a mesma palavra.

Duas linhas do plano só existem por causa do modelo de negócio. A primeira separa compra concluída de compra paga, porque 22 por cento dos pedidos da Verde Vivo são confirmados depois da sessão, e o purchase disparado na tela de obrigado conta boleto que nunca foi pago. A segunda leva o contrato do HubSpot de volta ao GA4, porque o formulário sozinho só sabe que alguém pediu orçamento.

Critério de sucesso fecha cada linha, e ele é o número que diz se a pergunta foi respondida a favor ou contra. A Verde Vivo fixou três. Taxa de conversão do e-commerce de 1,9 para 2,3 por cento em seis meses, sem cair a margem. Doze contratos B2B por mês, o que com 1 em cada 7 pede 84 orçamentos. Cancelamento do clube abaixo de 3,5 por cento ao mês até março de 2027.

Cada critério tem uma métrica de proteção ao lado. Conversão pode subir porque a promoção derrubou a margem; contratos podem subir porque o comercial aceitou ticket menor. A margem de 38 por cento e o ticket de R$ 42.000 entram no plano como o que não pode piorar enquanto o indicador principal melhora.

Armadilha comum: escrever o plano de mensuração como lista de eventos, sem a coluna da pergunta. A lista diz o que implementar e nunca diz por quê, então a equipe implementa tudo, o desenvolvedor gasta duas semanas em eventos que ninguém lê e, na hora de cortar, ninguém sabe qual evento pode sair. A pergunta é a coluna que permite dizer não.

A primeira versão do plano da Verde Vivo tinha 31 linhas, escritas em uma tarde a partir dos 27 eventos-chave que já existiam. Marina aplicou o teste da vaidade e a árvore de quatro níveis e ficou com 14 linhas: 6 do e-commerce, 5 do B2B e 3 do clube. As 17 linhas cortadas continuam sendo medidas pela propriedade; só deixaram de ter dono e frequência de leitura.

Esse corte teve efeito na semana seguinte. Caio recebeu uma lista de 9 eventos para implementar ou corrigir, em vez de 31, e a primeira entrega, o purchase disparado pelo servidor quando o Pix confirma, ficou pronta em cinco dias úteis. A diretoria recebeu um documento de uma página com três critérios de sucesso e duas métricas de proteção, e assinou embaixo.

O que mudou foi o sentido do trabalho: a propriedade deixou de ser um depósito de eventos e passou a ser a resposta a 14 perguntas com dono. Nenhum número melhorou ainda; o que existe é um critério para saber quando melhorou.

Escreva as cinco perguntas que a sua diretoria fez nos últimos três meses e preencha as sete colunas para cada uma. O critério de acerto é simples: toda linha precisa de um nome de evento que o desenvolvedor reconheça e de um número que diga quando a pergunta foi respondida. O próximo capítulo explica o que esse evento é por dentro, e por que usuários e sessões não somam como a planilha espera.