The Cohort Retention Analyzer: Descubra Onde os Usuários Desistem e Por Quê

Dashboards de retenção estão por toda parte nas ferramentas de product analytics, mas um dashboard só mostra que um número mudou — nunca diz por quê. A maioria das equipes reage a uma curva de retenção ruim puxando os dados para uma planilha, olhando fixamente para eles e especulando em voz alta durante uma reunião. Esse processo é lento, desestruturado e fortemente tendencioso para a teoria que a pessoa mais sênior na sala prefere mencionar primeiro.

Este prompt foi criado para substituir esse exercício de adivinhação por uma análise causal estruturada, usando os mesmos passos de raciocínio que um growth analyst experiente percorreria — mas comprimidos em uma única solicitação.

Por que o prompt foi construído dessa forma

A instrução de Role — "senior product analytics consultant" — é mais importante do que parece. Sem ela, modelos de uso geral tendem a descrever os dados ("A Coorte A reteve melhor que a Coorte B") em vez de diagnosticá-los. Enquadrar o modelo como um consultor que precisa justificar recomendações a um cliente o empurra para um raciocínio causal, em vez de reafirmar números que você já tem diante de si.

A seção de Context pede deliberadamente mais do que apenas os números de retenção. Incluir mudanças conhecidas no produto, redesigns de onboarding e campanhas de marketing ocorridos no mesmo período é o que transforma isso de um exercício de descrição de dados em um diagnóstico real — o modelo só consegue propor hipóteses fundamentadas se tiver algo em que se basear. Um prompt de retenção alimentado apenas com números produzirá explicações genéricas ("os usuários podem estar perdendo interesse") que são verdadeiras para qualquer produto SaaS e inúteis para tomar ações concretas.

O bloco de Constraints faz três tarefas específicas. Primeiro, força a classificação por impacto no negócio, e não por ordem alfabética ou de confiança, o que importa porque a hipótese de maior confiança nem sempre é a de maior impacto para corrigir. Segundo, limita a lista de hipóteses a cinco — sem isso, os modelos tendem a gerar palpites de baixo valor para parecerem completos, o que enterra a única ou duas ideias realmente dignas de ação. Terceiro, a instrução explícita de sinalizar problemas de qualidade dos dados captura um modo de falha específico dos dados de retenção: curvas não monotônicas (onde a retenção da semana 4 é maior que a da semana 1, o que é matematicamente impossível para uma curva de retenção adequada) quase sempre indicam um bug de tracking, e não um padrão comportamental real — e um analyst que não verificar isso construirá toda uma narrativa em cima de dados quebrados.

Como é uma boa saída

Uma execução útil deste prompt deve produzir algo que você poderia colar diretamente em uma mensagem do Slack antes de uma reunião de liderança: uma descoberta principal apresentada como afirmação (não descrição), uma pequena tabela comparativa, o ponto específico onde a curva quebra e — criticamente — uma próxima ação, e não apenas mais análise. Se a saída do modelo parecer uma versão mais longa dos dados de entrada, o prompt falhou e provavelmente precisa de uma restrição mais forte para evitar reafirmações.

Onde esse padrão se estende além da retenção

A mesma estrutura de Role + Context fundamentado + Constraints de hipóteses classificadas funciona para qualquer problema do tipo "por que essa métrica mudou" — picos de churn, quedas na taxa de conversão, aumentos no volume de tickets de suporte. Os campos específicos mudam, mas a forma — forçar raciocínio causal, fundamentá-lo em eventos conhecidos, limitar o número de hipóteses, sinalizar qualidade dos dados — é reutilizável sempre que você estiver entregando uma série temporal a um modelo e perguntando "por quê".