Como a análise de produto rastreia usuários, não visualizações de página

O que é análise de produto?

Um sistema de análise de produto mede o que as pessoas fazem dentro de um produto, evento a evento e usuário a usuário, para que o comportamento possa ser rastreado entre sessões em vez de contado por visita. A unidade de análise é a pessoa e a ordem das ações dela, não a página que ela por acaso carregou. Decida quais ações dentro do seu produto têm significado de negócio e registre cada uma com um identificador de usuário estável.

Essa mudança de unidade é a categoria inteira. Um relatório de visualizações de página pode dizer que 12.000 pessoas viram a página de cadastro. Só um fluxo de eventos pode dizer que 3.400 delas criaram uma conta, 900 terminaram a configuração em uma segunda visita quatro dias depois e 210 voltaram na semana três. A segunda resposta exige uma identidade que sobreviva ao limite da sessão. A primeira não.

Como é um evento de análise de produto?

Todo evento carrega quatro partes: um nome, um conjunto de propriedades, um id de usuário e um timestamp. O nome diz o que aconteceu, as propriedades dizem sob quais condições, o id de usuário costura o evento a tudo o mais que a pessoa fez, e o timestamp coloca a ação em sequência. Escreva os nomes como um objeto mais um verbo no passado, congele-os no release e versione o schema em vez de renomear.

{
  "event": "project_created",
  "user_id": "u_8f2c11",
  "timestamp": "2026-09-08T14:22:05Z",
  "properties": {
    "plan": "team",
    "template_used": true,
    "seats": 4,
    "source": "onboarding_checklist"
  }
}

As propriedades são onde a maioria das equipes perde um ano. Uma propriedade plan adicionada seis meses depois do lançamento não tem histórico por trás, então qualquer coorte mais antiga que seis meses fica inútil para esse corte. Adicione as propriedades pelas quais você espera segmentar no mesmo dia em que publica o evento.

Você deve usar autocapture ou instrumentação manual?

Use os dois, com funções diferentes: autocapture para cobertura, instrumentação manual para os eventos sobre os quais você reporta. O autocapture registra cliques, visualizações de página, envios de formulário e interações com elementos a partir de um único script, então você pode fazer perguntas retroativas sobre ações que ninguém pensou em definir. A instrumentação manual dispara um evento nomeado do seu próprio código no momento em que a lógica de negócio de fato tem sucesso.

A distinção importa no ponto da verdade. Um clique capturado por autocapture em um botão com o rótulo "Criar projeto" significa que alguém apertou um botão. Um evento manual project_created disparado depois que o servidor confirma a escrita significa que existe um projeto. Quando a requisição falha, esses dois números divergem, e o manual é o certo.

Defina de dez a vinte eventos manuais cobrindo cadastro, ativação, ações centrais de valor, upgrade e cancelamento. Deixe o autocapture cobrir todo o resto.

Quais perguntas a análise de produto responde que a análise web não consegue?

A análise de produto responde cinco famílias de perguntas que precisam de identidade e sequência: ativação, retenção, funis, coortes e caminhos. A análise web conta o que chegou; a análise comportamental conta o que as pessoas fizeram em seguida, e o que veio depois disso.

Ativação pergunta se um usuário novo alcançou o momento em que o produto começa a funcionar para ele. Retenção pergunta se ele voltou, e como isso cai semana a semana, que é o formato exposto por uma curva de taxa de retenção. Funis perguntam qual passo ordenado perde pessoas. A análise de coortes pergunta se usuários que se cadastraram em março se comportam de forma diferente de usuários que se cadastraram em agosto, e é assim que você separa uma mudança de produto de um efeito sazonal. Caminhos perguntam o que as pessoas fizeram de verdade em vez da rota que você desenhou.

Cada uma dessas perguntas exige unir eventos entre visitas. Nenhuma delas pode ser respondida a partir de um relatório limitado à sessão.

Como a análise de produto se compara com a análise web?

As duas disciplinas diferem na unidade que contam, e todo o resto decorre disso. A análise web mede o tráfego que chega a um site; a análise de produto mede o comportamento dentro de uma aplicação.

Nenhuma substitui a outra. A análise web diz que uma campanha paga entregou 4.000 visitas; a análise de produto diz que essas 4.000 visitas produziram 90 contas ativadas e que a campanha está perdendo dinheiro.

Como você calcula a taxa de ativação?

A taxa de ativação é a fatia de novos cadastros que alcançam o evento que você definiu como "o produto funcionando". Escolha um evento, mantenha-o fixo e dê a ele uma janela de tempo para que ativações lentas não distorçam o número.

Activation rate = (users who fired the activation event within N days / new signups in the period) x 100

Pegue 4.000 cadastros em agosto com uma janela de 7 dias e project_created como evento de ativação. Se 1.120 desses cadastros dispararam esse evento dentro de sete dias após o cadastro, a taxa de ativação é 1.120 / 4.000 x 100 = 28 por cento.

O número sozinho é inerte. Quebre o caminho em passos ordenados com a análise de funil e os 72 por cento que não ativaram se resolvem em quedas nomeadas: 900 nunca verificaram o e-mail, 1.400 verificaram mas nunca abriram o editor, 580 abriram o editor e pararam no seletor de templates.

Onde a análise de produto para e o session replay começa?

A análise de produto diz qual passo perdeu usuários e quantos; o session replay, a reprodução de sessões reais de usuários, mostra por que aquele passo falhou para uma pessoa específica. O fluxo de eventos é agregado e quantitativo, então consegue ordenar problemas por tamanho, mas não consegue mostrar o botão com rótulo errado, o erro de validação que ninguém lê ou o controle que parece desabilitado.

Essa passagem de bastão é o ponto. Assim que um funil nomeia o passo em que 1.400 usuários pararam, assistir às sessões a partir exatamente desse passo transforma um número em uma causa. A Flowsery grava cada sessão de usuário e detecta rage clicks, dead clicks, erros de JavaScript, quedas e fluxos quebrados automaticamente, depois agrupa sessões equivalentes em um único problema e ordena os problemas por quantos usuários foram atingidos. Cada problema chega no Slack, Linear ou Jira com a reprodução e os passos para reproduzir anexados.

Rode a análise de produto para achar o passo. Rode o session replay para achar a causa. Publique a correção e depois monitore o mesmo passo do funil para confirmar que o número mudou.

Perguntas frequentes

Análise de produto é a mesma coisa que análise web?

Não. A análise web conta sessões e visualizações de página de visitantes anônimos, e a contagem zera quando a visita termina. A análise de produto anexa um id de usuário persistente a cada evento, então as ações de uma pessoa se unem entre sessões e dispositivos em uma única jornada.

Quantos eventos um produto deve monitorar?

De dez a vinte eventos instrumentados manualmente cobrem a maioria dos produtos: cadastro, ativação, as duas ou três ações centrais de valor, convite, upgrade e cancelamento. O autocapture cuida da cauda longa de cliques e visualizações de página sem código extra. Um plano de tracking com 200 eventos escritos à mão fica impossível de manter e ninguém confia nos nomes.

Qual é a diferença entre um evento e uma propriedade?

Um evento é a ação em si, como project_created. Uma propriedade é um campo anexado a essa ação que descreve as condições, como plan: team ou template_used: true. Eventos são o que você conta; propriedades são como você fatia a contagem.

A análise de produto funciona sem contas de usuário?

Em parte. Ids anônimos guardados no navegador permitem unir eventos dentro de um mesmo navegador, o que basta para funis e caminhos no mesmo dispositivo. Jornadas entre dispositivos e curvas reais de retenção precisam de uma identidade que você define no login, para que ids anônimos sejam mesclados na conta quando a pessoa entra.

A análise de produto exige mudança de código?

O autocapture funciona a partir de uma única tag de script, sem código por evento. Os eventos sobre os quais você reporta, como ativação e upgrade, precisam de uma linha de código no ponto em que a lógica de negócio tem sucesso, porque só o seu servidor sabe se a ação realmente foi concluída.

Quando uma equipe deve adicionar análise de produto?

Adicione assim que o produto tiver um momento de ativação definido e cadastros suficientes para que padrões de queda sejam visíveis em vez de anedóticos. Antes disso, instrumente mesmo assim os eventos de cadastro e ativação, porque perguntas de retenção e coortes só podem ser respondidas com histórico que você já coletou.

Como você deve nomear eventos em análise de produto?

Nomeie cada evento como um objeto mais um verbo no passado, como project_created. Congele o nome assim que o evento entrar em produção e versione o esquema para mudanças, em vez de renomear o evento. Só um nome consistente permite contar e comparar ao longo do tempo.

Por que adicionar uma propriedade tarde causa problemas?

Uma propriedade adicionada meses depois de um evento ser lançado não tem histórico por trás, então tudo o que foi registrado antes dessa data não pode ser segmentado por ela. Uma propriedade plan adicionada seis meses após o lançamento, por exemplo, torna qualquer coorte com mais de seis meses inutilizável para esse corte. Adicione as propriedades que você planeja usar para segmentar no dia em que o evento é lançado, não depois.

Por que um clique capturado por autocapture pode superestimar ações reais?

O autocapture registra apenas o clique em si, então um botão rotulado "Create project" pressionado é tudo o que ele consegue confirmar. Um evento manual project_created só dispara depois que o servidor confirma que a escrita foi concluída, então quando uma requisição falha, os dois números divergem. O número manual é o correto para tudo o que você reporta.

O que o session replay mostra que a análise de produto não consegue?

A análise de produto é agregada e quantitativa, então consegue ranquear qual etapa de um funil perde mais usuários, mas não explicar o motivo. O session replay mostra a causa específica: um botão rotulado errado, um erro de validação que ninguém lê, ou um controle que parece desativado. O fluxo comum usa a análise de produto para achar a etapa e o session replay para achar a causa exatamente nessa etapa.