Product analytics é a disciplina de medir como as pessoas usam um produto digital — quais eventos disparam, em que ordem, com que frequência e com que retenção — para decidir o que melhorar, construir ou remover. Diferente do web analytics, que mede aquisição e páginas, o product analytics mede comportamento de usuários identificados dentro do produto ao longo do tempo. Este guia cobre as métricas centrais, a taxonomia de eventos e o papel de cada ferramenta.
Antes das métricas, vale o alinhamento de base: em apps, a coleta acontece via telas, eventos e SDKs, como explicamos no artigo sobre analytics em aplicativos: telas, eventos e SDK. Sem essa fundação de coleta, nenhuma métrica de produto é confiável.
O que é product analytics
Product analytics é o conjunto de práticas, dados e ferramentas usado para responder perguntas como: os usuários novos chegam ao primeiro valor? Quais funcionalidades são adotadas e quais são ignoradas? Quem volta depois da primeira semana? Onde os usuários desistem no fluxo de checkout ou de ativação?
A unidade de análise não é a sessão nem a página — é o usuário identificado e os eventos que ele dispara. Por isso a identificação consistente entre dispositivos e sessões é pré-requisito, tema do nosso artigo sobre user ID e identificação de usuário nas ferramentas.
Product analytics vs web analytics
As duas disciplinas se complementam, mas respondem perguntas diferentes. Confundi-las gera relatórios bonitos e decisões ruins:
| Dimensão | Web analytics | Product analytics |
|---|---|---|
| Pergunta central | De onde vem o tráfego e o que ele faz nas páginas? | Como usuários identificados usam o produto ao longo do tempo? |
| Unidade de análise | Sessão, página, campanha | Usuário, evento, coorte |
| Horizonte temporal | Sessões e conversões pontuais | Semanas e meses (retenção, coortes) |
| Métricas típicas | Sessões, pageviews, taxa de rejeição, origem | Ativação, adoção de feature, retenção, stickiness |
| Ferramenta típica | GA4 | Amplitude, Mixpanel, PostHog |
O tracking, aliás, é o que conecta os dois mundos: a mesma instrumentação bem feita sustenta decisões de mídia, produto e growth, como mostramos em tracking como base para decisões de mídia, produto e growth.
As métricas centrais
Ativação
Ativação é a porcentagem de usuários novos que chegam ao primeiro momento de valor — o famoso aha moment — dentro de uma janela definida. Em um app de finanças, pode ser “conectou a conta bancária em até 7 dias”; em uma ferramenta de design, “criou e compartilhou o primeiro projeto”. Sem uma definição de ativação acordada entre produto e dados, cada área otimiza para um número diferente.
Adoção de features
Adoção mede quantos usuários ativos usam determinada funcionalidade em um período. Ela responde a pergunta mais dolorosa do roadmap: aquilo que construímos está sendo usado? Adoção baixa de uma feature cara é sinal para investigar descoberta (o usuário não acha), valor (achou e não serviu) ou usabilidade (tentou e desistiu).
Retenção e coortes
Retenção mede quantos usuários voltam ao produto depois do primeiro uso, agrupados por coorte — o grupo de usuários que começou na mesma semana ou mês. É a métrica que separa crescimento sustentável de balde furado. Exemplo numérico: em uma coorte de 1.000 novos usuários, 420 ativos na semana 1 significam retenção de 42,0%; 310 na semana 2, 31,0%; e 240 na semana 4, 24,0%. A curva importa mais que o ponto: o que se procura é onde a retenção estabiliza, porque é ali que mora a base real do produto.
Eventos e engajamento
Eventos são os verbos do produto: clicou, cadastrou, comprou, compartilhou. Deles derivam métricas de engajamento como DAU, MAU e stickiness — a razão entre usuários ativos diários e mensais. Um produto com 2.000 DAU e 10.000 MAU tem stickiness de 20,0%, ou seja, o usuário médio usa o produto em cerca de um quinto dos dias do mês. Para alguns produtos isso é excelente (app bancário); para outros, alarmante (rede social).
Taxonomia de eventos: a fundação invisível
Toda métrica acima depende de uma taxonomia de eventos consistente: nomes padronizados (verbo_objeto, como purchase_completed), propriedades documentadas (valor, método, origem) e um dicionário vivo que todo o time consulta. Sem isso, o mesmo comportamento vira três eventos com nomes diferentes em três plataformas — e a análise vira arqueologia.
A solução prática é manter um dicionário de eventos versionado e compartilhado entre ferramentas, como detalhamos no artigo sobre dicionário de eventos para múltiplas ferramentas. Regra de bolso: se um evento não está no dicionário, ele não existe para análise.
As ferramentas: papel de cada uma
Não existe a melhor ferramenta; existe o papel certo no stack:
- Amplitude: referência em análise de produto self-service — coortes, funis, jornadas e análise de retenção sem depender de SQL. Forte para times de produto que querem autonomia analítica.
- Mixpanel: concorrente direto, com foco semelhante em funis, retenção e segmentação por comportamento. Modelo orientado a eventos desde a origem.
- PostHog: alternativa open source e self-hostable, relevante quando há restrição de privacidade, soberania de dados ou necessidade de rodar dentro da própria infraestrutura.
- GA4: continua sendo a resposta para aquisição e web analytics — origem de tráfego, campanhas, integração com Google Ads. Seu modelo de eventos aproxima o GA4 do product analytics, mas sua força segue sendo a porta de entrada, não o comportamento profundo dentro do produto. Inclusive o ecossistema de implementação mudou: apps inteiros nascem com GA4 e GTM configurados por IA, como mostramos em GA4 e GTM em apps criados com IA (Lovable, Replit).
O erro comum é exigir que uma ferramenta faça o papel da outra: usar GA4 para análise de coorte profunda, ou Amplitude para atribuição de mídia. Cada disciplina tem sua ferramenta natural, e o dicionário de eventos é o que as mantém contando a mesma história.
Exemplo prático
Cenário típico de um app brasileiro de delivery: o time de growth comemora o recorde de downloads, mas o board pergunta por que a receita não acompanha. O product analytics responde em três camadas. Primeiro, ativação: só uma parte dos novos usuários conclui o primeiro pedido em 7 dias. Segundo, funil: a maior desistência está no cadastro de cartão, não no cardápio. Terceiro, coortes: as coortes recentes retêm pior que as antigas, porque uma campanha agressiva atraiu usuários desalinhados. A decisão muda de “mais mídia” para “simplificar o cadastro de pagamento e ajustar o targeting”. Nenhuma dessas três conclusões apareceria em um relatório de pageviews.
Fontes
- Amplitude — What is product analytics
- Amplitude — métricas de produto
- Mixpanel — What is product analytics
Perguntas frequentes
Qual a diferença entre product analytics e web analytics?
Web analytics mede aquisição e comportamento de navegação em páginas, com foco em sessões e origem de tráfego. Product analytics mede o comportamento de usuários identificados dentro do produto ao longo do tempo, com foco em eventos, coortes e retenção. O primeiro responde “de onde vêm os visitantes”; o segundo responde “o produto está entregando valor recorrente?”.
Por onde começar com product analytics?
Por três passos em ordem: definir o evento de ativação (o primeiro valor do seu produto), instrumentar uma taxonomia mínima de eventos com dicionário documentado, e montar o primeiro relatório de coorte de retenção. Ferramenta vem depois disso — começar pela ferramenta é como comprar a esteira antes de decidir o treino.
GA4 serve como ferramenta de product analytics?
Parcialmente. O modelo orientado a eventos do GA4 permite análises de funil e coortes básicas, e ele é indispensável para aquisição e integração com mídia. Mas para análise profunda de comportamento — coortes flexíveis, jornadas, segmentação comportamental self-service — ferramentas dedicadas como Amplitude, Mixpanel ou PostHog são mais adequadas.
Quantos eventos um produto deve rastrear?
O suficiente para responder às perguntas de negócio — e não mais do que isso. Times maduros costumam operar com dezenas de eventos bem definidos, não centenas de eventos improvisados. Se o dicionário não cabe na cabeça de ninguém, ele já falhou no seu propósito.
Artigos relacionados
- Analytics em aplicativos: telas, eventos e SDK
- Dicionário de eventos para múltiplas ferramentas
- User ID: identificação de usuário nas ferramentas
- Tracking como base para decisões de mídia, produto e growth
- GA4 e GTM em apps criados com IA (Lovable, Replit)
- Product Management: o que é gestão de produtos digitais
- Product Discovery: métodos, pesquisa e validação de oportunidades
- GA4: guia prático para analisar conversões e jornadas
Quer trocar experiências sobre métricas de produto, experimentação e CRO com outros profissionais brasileiros? Participe da comunidade CRO Brasil.