GitHub

A maioria dos times monta um funil de conversão como quem faz uma reforma: contrata a ferramenta, instrumenta os eventos, monta o dashboard bonito e considera o trabalho concluído. Três meses depois, ninguém mais abre o dashboard. O funil virou um quadro na parede que ninguém olha.

O problema não foi a ferramenta. Foi tratar funil de conversão como projeto, quando ele é rotina. Um funil que funciona não é o que tem o melhor gráfico, é o que está integrado ao ritmo de trabalho do time, semana após semana.

Este texto é sobre a operação. Não é sobre qual ferramenta escolher nem sobre exemplos de diagnóstico, é sobre como fazer a ferramenta render no dia a dia, que é onde quase todo investimento em analytics morre.

Instrumentar é decisão de produto, não de engenharia

Tudo começa errado quando a instrumentação do funil é jogada para a engenharia como tarefa técnica. "Adiciona um evento aqui" sem um plano de medição produz um funil cheio de eventos inúteis e sem os que importam.

Antes de tocar no código, o time precisa de um plano de tracking: quais são as etapas do funil, qual evento marca cada uma, quais propriedades cada evento carrega. Esse documento é responsabilidade de produto, com a engenharia validando viabilidade. Sem ele, você instrumenta no escuro e descobre, meses depois, que falta justamente o evento que responderia a pergunta de negócio.

Uma convenção de nomes consistente, verbo no passado, minúsculo, padrão único, parece detalhe, mas é o que separa um funil legível de uma sopa de eventos onde Checkout_Click, checkout-clicked e tapCheckout convivem rastreando a mesma coisa.

A rotina semanal que mantém o funil vivo

O funil só rende se houver um ritual. Na prática, isso significa uma reunião semanal curta onde o time olha as taxas de conversão entre etapas e responde a uma pergunta: o que mudou e por quê.

Não é uma reunião de admirar gráficos. É uma reunião de decisão. Cada etapa do funil com queda relevante vira ou uma hipótese a investigar ou um experimento a rodar. Sem esse fechamento de ciclo, observar, hipotetizar, testar, medir de novo, a ferramenta vira contemplação.

Times que operam bem o funil tratam o dashboard como pauta viva. A métrica de cada semana é comparada com a anterior, com o mesmo período do mês passado e segmentada por versão do app. Esse último ponto é crítico no mobile: um número que despenca pode ser simplesmente uma versão nova com bug, não uma mudança de comportamento do usuário.

Lidar com o atraso e a sujeira dos dados mobile

Operar funil no mobile tem dores que o web não tem. A adoção de uma nova versão é gradual, parte da base ainda está na versão antiga por dias ou semanas. Isso significa que o dado de hoje mistura comportamentos de versões diferentes do produto. Quem não filtra por versão lê ruído como sinal.

Há também o atraso de envio. Eventos disparados offline chegam ao servidor horas depois, quando o usuário reconecta. Na prática, isso significa que o dado de ontem ainda está mudando hoje. Olhar conversão do dia anterior como número fechado leva a conclusões erradas. A rotina madura espera o dado estabilizar antes de reagir.

Esses não são problemas que a ferramenta resolve sozinha. São disciplinas que o time precisa internalizar para não tomar decisão sobre dado meio-cozido.

O erro operacional mais comum

O erro número um na operação de funil é reagir a ruído. Conversão caiu três pontos numa terça e o time já está em pânico montando força-tarefa. Mas variação pequena de um dia para o outro quase sempre é ruído estatístico, não tendência.

A maturidade operacional está em saber distinguir o que merece reação do que merece paciência. Olhar a tendência de semanas, não o solavanco de um dia. Times que reagem a cada oscilação se esgotam e perdem credibilidade quando o problema de verdade aparece.

O segundo erro é não fechar o loop. Um experimento roda, traz resultado, e ninguém documenta nem aplica o aprendizado. Na prática, o funil só melhora quando cada ciclo deixa um registro: o que testamos, o que aprendemos, o que mudou por causa disso.

No contexto brasileiro, toda essa operação manipula dados de comportamento de usuários reais. Ter na rotina uma revisão periódica de quais dados você ainda coleta e por quê não é burocracia de LGPD, é higiene de dados que também deixa o funil mais limpo.

Quem cuida do funil quando todo mundo está ocupado

O maior inimigo de um funil saudável não é a falta de ferramenta, é a falta de dono. Quando a responsabilidade pelo funil é de todos, ela acaba sendo de ninguém. O dashboard funciona até a primeira mudança de prioridade, e então é abandonado em silêncio.

A operação madura nomeia um responsável claro pela saúde do funil. Não significa que essa pessoa faz tudo; significa que existe alguém que garante que a instrumentação continua correta quando uma feature nova entra, que percebe quando um evento parou de disparar, e que mantém a reunião semanal acontecendo mesmo nas semanas corridas.

Esse papel é especialmente importante porque o funil se degrada de forma invisível. Um desenvolvedor renomeia um evento numa refatoração, e de repente uma etapa do funil zera, não porque o usuário sumiu, mas porque a medição quebrou. Sem um dono atento, o time pode passar semanas tomando decisões sobre um funil que está medindo errado.

Vale também ter um ritual periódico de auditoria da instrumentação: alguém checa se os eventos ainda batem com a realidade do produto. Produto muda o tempo todo; o tracking precisa mudar junto, ou a ferramenta passa a mentir com confiança. Esse cuidado operacional, chato e pouco glamouroso, é o que mantém o funil confiável ao longo dos meses.

O que separa operação de teatro

A diferença entre um time que opera o funil e um que faz teatro de dados está na consequência. No time que opera, o número da semana muda uma decisão. No teatro, o número é apresentado, todos concordam que é interessante, e nada acontece.

Ferramenta de funil é cara, em licença e, principalmente, em tempo de instrumentação. Esse custo só se paga quando o dado vira decisão de forma recorrente. Um funil que não muda comportamento do time é um custo sem retorno, por mais bonito que seja o dashboard.

Se o funil do seu app está virando enfeite e você quer transformá-lo em rotina que de fato move o produto, vale conversar. Há outro artigo aqui no blog sobre as ferramentas de funil com exemplos de diagnóstico, além de textos sobre métricas de produto e cultura data-driven.