O CRM que parecia valer 2% das ativações. Na real, valia 12%.

O contexto

Fretti é uma logtech. Uma plataforma onde pequenos e médios e-commerces e vendedores autônomos calculam frete, se cadastram e emitem etiquetas com desconto, pelo app ou pelo site. O produto é self-service. O usuário chega, calcula um frete, cria a conta e faz a primeira emissão. Essa primeira emissão é a ativação, o momento que importa.

O time de CRM trabalha esse funil com quatro canais: e-mail, WhatsApp, notificação no app (push) e banner dentro do produto. O objetivo é levar o cadastro até a primeira emissão.

O problema chegou pela dona do CRM. O indicador de contribuição do canal vinha de um relatório de último clique, tirado do Google Analytics. Esse relatório mostrava o CRM em torno de 2% das ativações. Abaixo da meta. E lateralizado, sem mexer de um mês para o outro.

A dúvida travava qualquer decisão. O CRM tinha piorado de verdade? Ou a conta estava medindo errado? Sem responder isso, não dava para defender investimento nem saber onde apostar.

Por que o último clique não servia

O modelo de último clique dá 100% do crédito para a última interação antes da conversão. Simples de calcular. Cego para o resto da jornada.

Na prática, o cliente recebe várias mensagens antes de ativar. Um e-mail que abre a jornada, um WhatsApp no meio, um banner no app. O último clique joga tudo isso fora e credita só o último toque. Pior: o clique de WhatsApp quase nunca entrava nessa conta, por limitação de rastreamento.

Some a isso o fato de o relatório vir de uma ferramenta amostrada, que não bate 100% com a base transacional real da empresa. O número estava subestimado por construção.

A hipótese

Se a jornada é feita de vários toques, um modelo que enxerga todos eles vai revelar uma contribuição bem maior que o último clique. E vai mostrar o papel de cada canal, não só quem fechou.

A proposta foi construir uma leitura de atribuição multi-toque em cima da base própria da empresa, em paralelo ao número oficial. Sem substituir nada. Uma segunda lente para entender o CRM.

Meu papel

Toquei o projeto de ponta a ponta, sozinho na parte técnica. Discovery com a liderança, arquitetura dos dados, extração das fontes, modelagem no data warehouse, definição da metodologia de atribuição, as validações, o painel de decisão e a comunicação para a liderança.

A metodologia

A ideia central é simples de explicar. Para cada ativação, olho todas as mensagens de CRM que a pessoa recebeu nos dias anteriores, dentro de uma janela. Se houve toque na janela, o CRM participou daquela ativação.

A janela de atribuição

Fixei 7 dias como padrão. É a referência de mercado e é conservador. Fiz duas checagens antes de bater o martelo. Uma foi de mercado. A outra foi olhar o comportamento da própria base: a maior parte de quem ativa faz isso dentro de sete dias do toque. A janela batia com o dado.

Costura de identidade

Cada toque de CRM precisa ser ligado à pessoa que ativou. O e-mail é a chave principal. Dentro do app, uso o identificador do usuário. No caso do push e do banner, que vêm do lado de analytics, resolvo a identidade por uma ponte determinística: pego o identificador mais recente associado ao dispositivo.

As quatro lentes de crédito

O mesmo dado, olhado de quatro formas. Influência (qualquer toque na janela conta, é o teto). Último clique (100% para o último toque, é o piso e equivale ao número antigo). Primeiro clique (revela quem abre a jornada). Linear (crédito dividido igualmente). Cada lente responde uma pergunta diferente de negócio.

Higiene do dado

Existe um e-mail que sai para quase todo mundo que se cadastra. Incluí-lo inflaria o número. Reporto a versão que exclui esse tipo de mensagem transacional, que é a leitura honesta. As duas visões ficam disponíveis, mas o número de capa é o conservador.

Uma nota que repeti em toda apresentação: as fatias por canal não somam o total. Um cliente pode ser tocado por vários canais, então cada um conta na sua fatia. O combinado é a contagem de pessoas distintas.

A arquitetura de dados

O fluxo vai das fontes até o painel, passando por camadas no data warehouse. As camadas seguem o padrão medalhão. Bronze guarda o dado cru, imutável. Silver mapeia os toques, resolve nomes de campanha e classifica objetivo. Gold tem as views de atribuição e as tabelas de reporte que o painel consome.

FONTES                         DATA WAREHOUSE (BigQuery)                 CONSUMO
────────────────────           ──────────────────────────────           ──────────────
HubSpot Events API   ─┐        bronze  (dados crus)                      Painel (app web)
(e-mail, WhatsApp)    │   ─▶    silver  (toques mapeados,                 ├─ macro
                      │                  de-para de campanha)             ├─ tático
GA4 / Firebase       ─┤   ─▶    gold    (views de atribuição,            └─ operacional
(push, banner)        │                  tabelas de reporte)
                      │        ┌ reconciliação com a base                 Decks / Confluence
Base transacional    ─┘        └ tabelas por uid e por toque
(cálculo, cadastro,
 emissão)

A extração roda em Python, num notebook. Puxo os toques de e-mail e WhatsApp pela API de eventos do HubSpot, dia a dia, particionando por data. O push e o banner vêm do export nativo do GA4 para o BigQuery. A base transacional (quem calculou, cadastrou e emitiu, com data e hora) é a fonte da verdade para as conversões.

O modelo de dados

Cinco objetos principais sustentam o painel e a auditoria. Uma tabela de reporte diária por etapa, com o denominador do dia, os influenciados com e sem transacional, e a quebra por canal. Uma tabela de campanhas (mês, régua, canal, objetivo) para o nível operacional. Uma tabela de segmento defasado, pra mostrar onde o canal mais pesa. E duas tabelas atômicas para o drill-down e a auditoria, uma por toque e outra por usuário e etapa, sempre consistentes entre si.

Os resultados

O número de capa mudou de 2% para perto de 12%. Cerca de seis vezes o que o modelo antigo mostrava. O CRM não tinha piorado. A conta é que enxergava só um pedaço da jornada.

(números representativos, anonimizados)

O WhatsApp fecha, o e-mail abre. Nas lentes de último clique, o WhatsApp lidera. Na lente de primeiro clique, o e-mail aparece na frente. O e-mail arma a jogada e o WhatsApp finaliza. Antes do projeto se achava que o e-mail liderava sozinho, o que era um efeito de rastreamento incompleto do WhatsApp.

O push é retenção. Essa foi a maior surpresa. O push aparece em torno de 0,3% na primeira ativação, mas em torno de 2% a 3% quando olho todas as compras. Nove em cada dez aberturas de push vêm de quem já é cliente, porque push exige app instalado e notificação ligada, coisa de quem já entrou.

O CRM brilha em quem demora a ativar. Quem calcula e emite no mesmo dia costuma fazer sozinho, e ali o CRM pesa perto de 1%. Em quem demora entre o cálculo e a emissão, a participação sobe para perto de 17%. É exatamente aí que o CRM trabalha, recuperando quem esfriou.

O CRM faz o cliente avançar. A participação cresce ao longo do funil. Pequena no primeiro cálculo, maior no cadastro, máxima na ativação.

O rigor por trás do número

Um número bonito sem validação não vale nada numa mesa de liderança. Duas checagens deram a confiança para defender o resultado.

Reconciliação com a base

Antes de qualquer conclusão, o volume de ativações do modelo tinha que bater com o relatório oficial da empresa. Bateu, no mês de referência, no número exato. Isso ancorou o resto.

O double-check do push

Quando mostrei que o push valia só 0,3% na ativação, a liderança estranhou. Push costuma ser um canal forte. Montei um diagnóstico com quatro frentes para testar se era erro ou realidade: se o push era recente demais, se estava perdendo eventos no rastreamento, se a identidade casava com a base, e a sensibilidade da janela esticando pra 30 dias. A conclusão fechou a porta para "é bug". O push tem alcance enorme, mas quase nada dele cai antes da primeira ativação. Ele fala com quem já é cliente, então funciona pra segurar quem já entrou, não pra trazer quem ainda não converteu.

O painel de decisão

O modelo virou um painel para a liderança usar sozinha, organizado em três níveis. No macro, o indicador principal contra uma meta, a variação do mês e a projeção de fechamento. No tático, a contribuição por canal ao longo do tempo e a participação por etapa do funil. No operacional, a tabela de campanhas com filtros por canal, objetivo e período. Filtros globais atravessam tudo, e a pessoa navega, acha a resposta e ainda vê uma nota fixa dizendo qual modelo de atribuição está por trás.

Limitações, com honestidade

O modelo mostra participação, não causa. Saber que o CRM esteve presente antes da ativação não é o mesmo que provar que o CRM gerou a ativação. Falei isso em toda reunião, e é o que dá credibilidade ao resto. A prova de causa vem de um teste controlado, e esse é o próximo passo.

Próximos passos

Primeiro, o teste controlado, para transformar "o CRM participa de 12%" em "o CRM gera X% de ativações a mais". Segundo, automatizar o pipeline, que hoje tem passos manuais. Terceiro, levar a mesma estrutura para outras partes da jornada, como retenção e recompra.

O que este projeto entregou para o negócio

A liderança de CRM saiu de um número que a fazia parecer irrelevante para uma leitura que sustenta investimento. Passou a saber onde apostar cada canal, em qual etapa e para qual perfil de cliente. E ganhou uma ferramenta para acompanhar isso sozinha, todo dia, sem depender de análise manual. Do lado técnico, ficou uma estrutura de dados reaproveitável, que serve para medir outras jornadas com pouco ajuste.

Stack de ferramentas

Estrutura do repositório

atribuicao-multitoque-crm/
├── README.md                        # este case
├── docs/
│   ├── tap-projeto.md               # termo de abertura, escopo, fases
│   ├── contexto.md                  # problema e discovery
│   └── metodologia.md               # janelas, lentes, identidade
├── extracao/                        # Python (Colab)
│   ├── extract_toques.py            # HubSpot Events API, particionado por dia
│   ├── bridge_contatos.py           # ponte contato para e-mail
│   └── reparo_bridge.py             # reprocesso de lotes com falha
├── modelagem/                       # SQL (BigQuery)
│   ├── views/
│   ├── materializacoes/
│   └── reporte/
├── validacoes/
│   ├── reconciliacao_volume.sql
│   ├── diagnostico_push.sql          # o double-check de 4 frentes
│   └── calibracao_janela.sql
├── painel/                          # app web (React via Lovable)
└── apresentacoes/                   # decks e material de liderança

Aprendizados

Último clique é uma armadilha confortável. Fácil de medir e péssimo para canais que atuam no meio da jornada, como o WhatsApp. Trocar de lente mudou a leitura inteira. Já vi essa desconfiança do dado de atribuição render outro tipo de achado: no case de antifraude mobile, o número escondia fraude, não um canal subestimado.

Nem todo canal é de ativação. O push parecia fraco e a tentação era chamar de bug. O double-check mostrou que ele é forte, só que em outra etapa.

Validação é o que dá voz na mesa de liderança. A reconciliação com a base e o diagnóstico do push foram o que transformaram um gráfico bonito em uma decisão de investimento. E separar participação de causa desde o começo evita promessa que o dado não sustenta.