Pergunta aos teus dados onde as pessoas desistem

O que é e porque importa

As pessoas descarregam a tua app, e depois? Uma parte chega ao primeiro uso a sério, outra perde-se pelo caminho. Onde, normalmente não sabes: abres as analytics, olhas para dez gráficos e fechas sem ter mudado nada.

Se usas o PostHog para as analytics, podes ligá-lo ao Claude Code com o servidor MCP dele. O MCP é a forma padrão de o Claude Code falar com um serviço externo: depois de ligado, o Claude consulta os teus dados sozinho, com as ferramentas do PostHog para funis, consultas, insights, feature flags e experiências. E como é a mesma sessão onde está o teu código, passa diretamente do número para o ecrã.

A volta completa: funil, o passo onde perdes mais gente, o código desse ecrã, uma alteração mostrada a metade dos utilizadores, o resultado uns dias depois. Ligar ao servidor MCP é grátis e o PostHog tem um plano gratuito generoso em cada produto, sem cartão de crédito. Só algumas ferramentas que usam a IA do PostHog podem ser faturadas à parte.

1. Liga o PostHog ao Claude Code

O servidor MCP do PostHog é alojado por eles, em https://mcp.posthog.com/mcp. No terminal, fora do Claude Code, corre:

claude mcp add --transport http posthog https://mcp.posthog.com/mcp -s user

-s user quer dizer «para mim, em todos os projetos». Sem isso, o servidor só vale no projeto em que estás, que é o âmbito predefinido. Depois abre o Claude Code, escreve /mcp, escolhe posthog e entra: abre-se o browser, fazes login no PostHog e autorizas. Nada de chaves para copiar, e é o PostHog que te leva à região certa, Estados Unidos ou Europa, consoante a tua conta.

Com o Claude Code o servidor dá uma só ferramenta, exec, com que o Claude encontra e chama as outras quando são precisas: poupas contexto. Primeiro, confirma o projeto:

Usa o PostHog: diz-me a que organização e a que projeto estás ligado, e dá-me os 20 eventos mais frequentes dos últimos 30 dias, com o número de pessoas únicas de cada um. Não cries nem alteres nada.

Se no início quiseres que o Claude só possa ler, em vez do comando anterior usa este, com ?readonly=true no fim do endereço: desaparecem as ferramentas que criam, alteram ou apagam. Para a parte do flag tira-o com claude mcp remove posthog e volta a pôr o normal. E, como diz o próprio PostHog, lê cada chamada antes de a aprovar.

claude mcp add --transport http posthog "https://mcp.posthog.com/mcp?readonly=true" -s user

2. O funil, da instalação ao primeiro uso a sério

Um funil é uma fila de passos por ordem, com quantas pessoas chegam a cada um. O primeiro uso a sério decides tu: o primeiro treino terminado, a primeira nota guardada. Não «abriu a app», mas o momento em que teve aquilo para que a descarregou. Nas apps de telemóvel, os SDK do PostHog podem registar sozinhos o evento Application Installed: confirma que está ativo.

Usa o PostHog. Constrói um funil dos últimos 30 dias desde a instalação até ao primeiro uso a sério da minha app: [Application Installed] → [registo concluído] → [onboarding terminado] → [primeiro treino concluído]. Primeiro confirma que estes eventos existem mesmo e diz-me se falta algum, sem os inventar. Depois dá-me, para cada passo, quantas pessoas lá chegam, a percentagem em relação ao passo anterior e quanto tempo costumam demorar.

Põe os nomes dos teus eventos no lugar dos que estão entre parênteses retos: se não os souberes, tira-os da lista de antes. E pede a percentagem em relação ao passo anterior: a documentação do PostHog explica que é essa que mostra onde há mais a ganhar.

3. Descobre onde desistem

No funil, qual é o passo onde perco mais pessoas? Dá-me o número e a percentagem. Depois divide esse passo por sistema operativo, versão da app e país, e diz-me se a queda é igual para todos ou concentrada num grupo. Por fim, encontra no código o ecrã onde acontece esse passo e mostra-me o ficheiro.

A divisão por grupos importa: se a queda está toda numa versão ou num sistema, talvez seja um bug e não um problema de design. E se gravas as sessões com o PostHog, pede ao Claude para listar algumas pessoas que pararam exatamente ali e vê as gravações delas: muitas vezes é a forma mais rápida de perceber porquê.

4. Uma alteração, para metade dos utilizadores

Agora pede uma proposta, não uma correção:

Abre o código do ecrã de [passo] e diz-me as 3 causas mais prováveis para as pessoas pararem ali, a partir do que vês no código e nos dados. Para cada uma propõe uma só alteração pequena. Não escrevas código enquanto eu não escolher uma.

Escolhe uma. Para a testar precisas de um feature flag, ou seja, um interruptor que a app lê enquanto corre (falo disso no guia INTERRUTTORE, strikt.fit/interruttore). Para medir, o mais limpo é uma experiência do PostHog: cria ele o flag com duas variantes, control (como está agora) e test (a alteração), reparte as pessoas ao acaso, regista quem vê o quê e faz as contas estatísticas por ti.

Usa o PostHog. Cria uma experiência chamada [onboarding-mais-curto] com duas variantes, control e test, divididas 50 e 50, com o funil de [passo] a [primeiro treino concluído] como métrica principal. Depois põe a alteração escolhida atrás do seu flag: com control o utilizador vê o ecrã atual, com test o novo. Inclui só quem chega a esse ecrã pela primeira vez, e se o flag não puder ser lido, mostra a versão atual. Antes de a lançar, diz-me quantas pessoas são precisas e quantos dias demora com o tráfego que tenho.

«Pela primeira vez», porque o PostHog aconselha a incluir só quem é afetado pela alteração. «Se não puder ser lido», para que um problema de rede não mostre a toda a gente uma coisa a meio. «Quantas pessoas são precisas», porque a calculadora do PostHog te diz isso antes de começar. E no iPhone a alteração tem de estar já na versão publicada: o flag só liga código que existe.

Antes dos 50 e 50, o PostHog sugere uma volta de teste com uma pequena parte dos utilizadores, por exemplo 5%, durante uns dias: confirmas que os eventos chegam e que não há crashes. Se a experiência arrancar estragada e a relançares, os resultados deixam de ser fiáveis, porque muita gente já viu a alteração.

5. Lê o resultado

Quando passarem os dias que a calculadora te deu, por exemplo uma semana:

Usa o PostHog. Dá-me os resultados da experiência [onboarding-mais-curto]: quantas pessoas por variante, a conversão de control e de test, e se a diferença é estatisticamente significativa. Diz-me se chegámos às pessoas que eram precisas. Se não for significativa ou faltarem pessoas, diz-mo claramente e não declares um vencedor.

Se ganhar test, levas a alteração a toda a gente e fazes limpeza: o próprio PostHog diz que no fim de uma experiência se mantém o código da variante vencedora e se apaga o da perdedora. Se não houver diferença, isso também é um resultado: voltas à lista das 3 causas e experimentas a segunda.

Quem ganhou a experiência [onboarding-mais-curto] foi test. Termina-a no PostHog levando test a toda a gente, depois tira do código o flag e a versão antiga, corre os testes e diz-me o que mudaste.

6. Como não te enganares

• Decide antes quanto tempo dura. Olhar para os resultados todos os dias e parar no primeiro número bonito é o que o PostHog chama peeking problem: de tanto espreitar, mais cedo ou mais tarde alguma coisa parece ganhar por acaso.
• Pessoas suficientes. Com poucos utilizadores, uma diferença é muitas vezes só acaso. Para teres uma ideia, no exemplo da documentação do PostHog, com uma conversão de 10% e uma mudança a detetar de 20%, são precisas cerca de 3.600 pessoas por variante. Se tiveres muitas menos, testa alterações maiores.
• Uma alteração de cada vez. Se mudares o texto, a cor e o número de passos ao mesmo tempo, nunca vais saber o que funcionou.
• Vê também o que piora. Um ecrã mais curto pode levar mais gente ao passo seguinte e menos gente a voltar no dia seguinte. Escolhe antes uma segunda métrica para ir vigiando.

Os erros mais comuns

• Deixar o Claude adivinhar os nomes dos eventos. Pede primeiro a lista e só depois constrói o funil.
• Trabalhar no projeto errado. Uma ligação tem uma conta e um projeto ativo: confirma qual antes de criar alguma coisa.
• Ligar a alteração para toda a gente. Sem um grupo que veja a versão antiga, não tens com que comparar.
• Parar a experiência no primeiro dia bom. Espera pela duração que decidiste antes.
• Deixar o flag no código depois da decisão. Tira o flag e a variante que perdeu.

Checklist

• Servidor MCP do PostHog adicionado e login feito a partir do /mcp.
• Projeto certo confirmado, lista de eventos à mão.
• Funil até ao primeiro uso a sério, com as percentagens passo a passo.
• Pior passo dividido por grupos e ecrã encontrado no código.
• Uma só alteração, atrás de uma experiência 50 e 50, testada antes com poucos utilizadores.
• Duração e número de pessoas decididos antes de começar.
• Resultado lido com a significância, flag retirado no fim da experiência.

Perguntas frequentes