Anti-Padrões de Métricas de Produto

Métricas de vaidade são métricas que parecem impressionantes em uma apresentação, mas estão desconectadas da saúde ou trajetória real do produto. Métricas de vaidade comuns em SaaS: total de usuários registrados (inclui todos que já se inscreveram, incluindo usuários que cancelaram, nunca ativaram e inativos há muito tempo — parece um número grande, mas é um péssimo indicador para a base de usuários ativos); visualizações de página (facilmente infladas por tráfego de baixa qualidade, bots ou UX confusa que faz os usuários clicarem várias vezes para realizar uma tarefa); total de downloads de aplicativos (para produtos móveis); seguidores no LinkedIn; e menções em comunicados de imprensa. Elas persistem porque são fáceis de aumentar, sempre crescem (são contagens cumulativas que só podem subir) e produzem gráficos narrativos satisfatórios para apresentações gerais. O antídoto é emparelhar cada métrica de vaidade com seu equivalente ajustado pela qualidade: em vez de usuários totais, relate MAU + taxa de ativação; em vez de visualizações de página, relate páginas com > 30 segundos de engajamento; em vez de downloads, relate retenção de 7 dias. A métrica ajustada pela qualidade revela se o crescimento da métrica de vaidade é significativo.

O viés de sobrevivência na análise de produto ocorre quando as equipes analisam apenas os usuários que ainda estão presentes nos dados, ignorando aqueles que saíram — produzindo conclusões sistematicamente otimistas. Exemplo clássico de SaaS: uma equipe quer entender quais ações de onboarding levam à retenção. Eles analisam o comportamento de seus usuários ativos atuais na semana 1 e descobrem que 85% dos usuários ativos adicionaram um membro da equipe durante o onboarding. Conclusão: "adicionar um membro da equipe cedo é o comportamento chave." Análise anti-viés de sobrevivência: analise a coorte de todos os usuários de 90 dias atrás (não os usuários ativos atuais) e compare o comportamento da semana 1 daqueles que ainda estão ativos versus aqueles que cancelaram. Isso revela se adicionar um membro da equipe realmente prevê a retenção ou se é simplesmente um comportamento comum para a maioria dos usuários, independentemente do resultado. A "análise de correlação de retenção" sem controle de coorte é quase sempre enviesada pela sobrevivência. Product Ops treina PMs na metodologia de análise controlada por coorte como prática padrão na interpretação de pesquisa de usuário.

O erro analítico mais perigoso e comum nas operações de produto: observar que duas coisas acontecem juntas e concluir que uma causa a outra. Exemplo real: uma empresa SaaS observa que usuários que configuram a notificação de e-mail de resumo diário têm 4 vezes mais retenção em 90 dias do que usuários que não o fazem. Eles concluem: "se forçarmos todos os novos usuários a configurar o resumo diário, melhoraremos drasticamente a retenção." Eles implementam a configuração obrigatória de notificação no onboarding. A retenção não melhora. A verdade: usuários que configuram voluntariamente as notificações de resumo diário já estão engajados e comprometidos — eles teriam retido de qualquer forma. A configuração da notificação é um sintoma de alto engajamento, não sua causa. Teste antes de concluir: a única maneira confiável de estabelecer a causalidade é um experimento controlado randomizado — atribua aleatoriamente alguns usuários a um grupo que é incentivado ao comportamento "correlacionado" e compare sua retenção com um controle randomizado. Se o grupo incentivado aleatoriamente melhorar, a causalidade é suportada. Product Ops deve exigir que cada "descoberta" da análise de produto passe por uma validação básica de causalidade — seja por meio de experimento ou de um mecanismo causal plausível — antes de informar uma decisão de produto.