Imagine a Casa Mirante, varejista fictícia criada só para este exemplo. O time sorteia mil clientes aptos a recomprar em dois grupos de 500 e envia uma mensagem a um deles. Trinta dias depois, o painel mostra 65 compradores únicos nesse grupo. A tentação é levar esse número à reunião como resultado da campanha, mas ele informa quantas pessoas compraram depois da mensagem, não quantas compraram por causa dela.
O que o controle acrescenta
No outro grupo, que não recebeu a mensagem, 50 pessoas compraram no mesmo período. A lógica é a dos experimentos de lift do Google Ads, que comparam um grupo exposto a um controle não exposto para estimar o efeito incremental. A página trata de campanhas de anúncios. Levar o raciocínio para o CRM é proposta nossa.
| Grupo | Pessoas | Compradores únicos em 30 dias | Taxa |
|---|---|---|---|
| Recebeu a mensagem | 500 | 65 | 13% |
| Controle | 500 | 50 | 10% |
| Diferença | Não se aplica | 15 | 3 pontos percentuais |
Como os grupos têm o mesmo tamanho, a conta é direta: 3 pontos percentuais aplicados a 500 pessoas resultam em 15 compradores estimados. Esse número descreve o grupo, portanto não dá para apontar quais 15 pessoas mudaram de comportamento. Os outros 50 compradores do grupo que recebeu a mensagem também não são prova de nada individual: indicam apenas quantos compradores seriam esperados sem a mensagem, se os grupos forem comparáveis.
Comprador não é evento
Na documentação de ecommerce do Google Analytics, purchase e refund são eventos distintos, e o transaction_id permite associar a transação. Nenhum deles equivale, sozinho, a uma pessoa. Quem compra duas vezes gera duas compras e continua sendo um comprador. E, se a sua regra ignorar reembolsos, um pedido devolvido segue contando como compra. Por isso, a contagem precisa ligar cada transação a um cliente do CRM.
Protocolo dos Cinco Cortes
Este é o roteiro que propomos para repetir o teste na sua operação:
- Elegibilidade: congele a lista de clientes e a janela de medição antes do envio.
- Sorteio: aleatorize por pessoa, não por disparo, e registre o grupo de cada cliente. O controle fica sem a mensagem testada.
- Regra de comprador: defina comprador único como a pessoa com ao menos uma compra válida na janela. Elimine transações duplicadas e decida de antemão como tratar reembolsos.
- Contagem pelo sorteio: mantenha no grupo tratado quem não abriu a mensagem ou não a recebeu. Excluir essas pessoas deixaria no grupo justamente as mais engajadas, e a comparação perderia o equilíbrio criado pelo sorteio.
- Decisão: calcule as taxas, a diferença e os compradores estimados. Depois, divida o custo total da campanha pelos compradores estimados e compare o resultado com um teto fixado antes do teste.
O que o exemplo não prova
- Significância: não fizemos teste estatístico nem calculamos intervalo. A diferença pode conter variação do acaso, e aqui não declaramos significância. Defina o critério estatístico antes de abrir os resultados.
- Tempo: trinta dias não distinguem uma compra nova de uma compra apenas antecipada.
- Dinheiro: contar compradores não revela ticket, margem nem o peso das devoluções.
- Contexto: se o controle recebeu outras ofertas, o teste mede a mensagem naquela combinação de contatos, não em um cenário sem comunicação.
Antes de aprovar a próxima régua, peça duas linhas no relatório: compradores únicos de quem foi sorteado para receber e de quem foi sorteado para ficar de fora. Sem a segunda linha, o CRM mostra que houve recompra, mas deixa em aberto o que a empresa queria saber ao pagar pelo envio.
Para aprofundar
- A Ciência do ROI: Calculando o Retorno Real de Campanhas de Marketing
- Como Publicidade Personalizada Pode Aumentar o Ticket Médio de Compras
Sinal / Crescimento & Receita. Reportagem explicativa produzida com auxílio de IA e revisão editorial automatizada.
