Analytics de Produto: Como Medir o uso do seu App Feito com IA com PostHog [2026]

Colocar um app no ar com IA virou trabalho de uma tarde. Com Claude Code, Cursor ou Lovable, nós saímos de uma ideia para um produto publicado antes do café esfriar. A pergunta que vem logo depois é bem mais difícil: alguém está usando? E, se está, usando o quê? É exatamente esse buraco que o analytics de produto cobre, e é nele que a maioria dos projetos feitos com IA tropeça.

Na Marfin, nós aprendemos isso do jeito caro. Já lançamos ferramentas internas e MVPs que pareciam um sucesso pelo número de cadastros e, semanas depois, descobrimos que quase ninguém passava da primeira tela. Os cadastros cresciam enquanto a ativação ficava parada. Sem dados de uso, cada decisão de produto vira palpite, e palpite com código gerado por IA sai caro, porque você constrói rápido na direção errada. Isso vale para qualquer software, e pesa ainda mais num produto SaaS, em que a receita depende de o usuário voltar todo mês.

Este guia mostra como nós medimos o uso dos nossos apps com o PostHog: o que é analytics de produto, como instalar em projetos feitos com IA (inclusive Lovable e Supabase), quais eventos rastrear, quais métricas acompanhar toda semana, quanto custa e o que fazer para não se afogar em gráficos.

Link para esta seçãoO que é analytics de produto

Analytics de produto é a prática de registrar o que cada usuário faz dentro do seu software e transformar esses registros em respostas. Quantas pessoas criaram o primeiro projeto? Quanto tempo levaram entre o cadastro e a primeira ação útil? Quem voltou na semana seguinte? Em que passo do onboarding a maioria desiste? Cada clique relevante, cada formulário enviado e cada recurso usado vira um evento com data, usuário e propriedades. Juntando eventos, você monta funis, curvas de retenção, coortes e caminhos de navegação.

A unidade básica é o evento. Um evento tem nome (por exemplo, projeto_criado), um identificador de quem fez a ação e propriedades que dão contexto, como o plano do usuário, o template escolhido ou a origem do cadastro. Com algumas dezenas de eventos bem pensados, você enxerga o produto inteiro. Com centenas de eventos mal nomeados, você enxerga ruído.

Link para esta seçãoAnalytics de produto vs. Google Analytics

A confusão mais comum que vemos é achar que o GA4 resolve tudo. O Google Analytics nasceu para medir tráfego: de onde as visitas vieram, quais páginas foram vistas, quanto tempo a sessão durou. Ele responde bem perguntas de marketing e aquisição. Já o analytics de produto acompanha pessoas identificadas ao longo do tempo, dentro de uma aplicação que muitas vezes nem muda de URL quando o usuário faz algo relevante. Um app React feito no Lovable, por exemplo, pode ter o fluxo inteiro de criação de pedido em uma única rota. Para o GA4, isso aparece como uma pageview. Para o analytics de produto, são seis eventos diferentes, cada um com um significado próprio.

Na prática, as duas ferramentas convivem. O site de marketing continua no GA4 (ou na web analytics do próprio PostHog), e o app logado passa a ser medido por eventos. O que muda é a pergunta: o tráfego conta quem chegou, o produto conta quem ficou e o que essa pessoa fez.

Link para esta seçãoO problema de quem constrói com vibe coding

Quem constrói com vibe coding tem uma velocidade de entrega que times tradicionais nunca tiveram. Isso é ótimo, e também é uma armadilha. Como cada feature nova sai em uma hora, a tentação é seguir adicionando funcionalidades sem saber se as anteriores foram usadas. Em poucos meses o app tem trinta telas, metade delas abandonada, e o código ficou mais difícil de manter para você e para a IA que te ajuda.

Outro ponto: apps gerados por IA costumam nascer sem nenhuma instrumentação de produto. Lovable, Bolt.new e V0 até mostram visitas em alguns casos, mas nenhum deles monta um plano de eventos por você. Se ninguém pedir, o app vai para produção cego. Por isso, na Marfin, analytics entra no MVP junto com autenticação e banco de dados, no mesmo dia do primeiro deploy.

Link para esta seçãoPor que usamos o PostHog para analytics de produto

O PostHog é uma plataforma open source de analytics de produto que foi crescendo até virar uma caixa de ferramentas completa para quem constrói software. Num mesmo painel você tem product analytics (eventos, funis, retenção, trends e paths), web analytics, session replay, feature flags, testes A/B, surveys, error tracking, data warehouse e até um módulo de analytics específico para chamadas de LLM. Para um time pequeno, isso significa uma conta, um SDK e uma fatura, no lugar de cinco ferramentas que não conversam entre si.

Três motivos fizeram o PostHog virar padrão nos nossos projetos. O primeiro é o plano gratuito, que cobre 1 milhão de eventos por mês e 5 mil gravações de sessão, o suficiente para validar praticamente qualquer MVP. O segundo é a instalação pensada para quem programa com IA: existe um wizard que lê o seu projeto e configura tudo sozinho, e um servidor MCP que deixa o Claude Code e o Cursor consultarem seus dados direto do editor. O terceiro é a flexibilidade de hospedagem. Dá para escolher a nuvem europeia, o que ajuda na conversa sobre LGPD, ou rodar a versão open source na sua própria infraestrutura.

Mixpanel e Amplitude continuam ótimos, e falamos deles mais abaixo. Para o perfil de app que mais sai das nossas mãos, um SaaS pequeno feito com IA e backend em Supabase, o PostHog entrega mais recursos por menos dinheiro e com menos atrito de configuração.

Link para esta seçãoComo instalar o PostHog no seu app feito com IA

Antes de instalar, crie uma conta em posthog.com e escolha a região (US ou EU). Cada projeto no PostHog tem uma chave de API pública, que pode ficar no frontend sem problema, já que ela só serve para enviar eventos. Para ler dados, o PostHog usa chaves pessoais separadas, e essas ficam sempre fora do código do cliente.

Link para esta seçãoO caminho mais rápido: o wizard com IA

O método que o próprio PostHog recomenda hoje é o wizard, um agente de linha de comando que você roda na raiz do projeto com npx @posthog/wizard. Ele autentica a sua conta, detecta o framework, instala os SDKs, cria as variáveis de ambiente no arquivo .env e escreve o código de inicialização tanto no cliente quanto no servidor. No fim, ainda oferece instalar o servidor MCP do PostHog no seu editor.

Nos nossos testes com projetos Next.js e Vite com React, o wizard acertou a configuração de primeira na maioria das vezes. O que fazemos depois é abrir o Claude Code, a ferramenta de programação com IA que mais usamos na Marfin, e pedir uma revisão do diff: conferir se a inicialização ficou duplicada, se o provider envolve a árvore inteira de componentes e se as variáveis de ambiente estão no lugar certo para o deploy.

Link para esta seçãoInstalando pelo Claude Code ou pelo Cursor

Se você prefere controle total, dá para pedir a instalação direto ao agente. Um prompt que funciona bem no Claude Code é algo como: "instale o posthog-js neste projeto, inicialize no layout raiz usando as variáveis NEXT_PUBLIC_POSTHOG_KEY e NEXT_PUBLIC_POSTHOG_HOST, ative a captura de pageviews para navegação client-side e crie um helper track() tipado com os eventos do arquivo docs/tracking-plan.md". Esse último detalhe faz diferença. Quando o plano de eventos vive num arquivo do repositório, a IA passa a respeitar os nomes definidos em vez de inventar eventos novos a cada feature.

No Cursor, que é a IDE que usamos para building no dia a dia, o fluxo é parecido. Deixamos o tracking-plan.md referenciado nas regras do projeto, e toda vez que o agente cria uma tela nova ele já sugere o posthog.capture correspondente. O código mínimo fica assim:

import posthog from 'posthog-js'

posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY!, {
  api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
  person_profiles: 'identified_only',
})

posthog.capture('projeto_criado', { template: 'landing', plano: 'free' })

A opção person_profiles com o valor identified_only faz o PostHog criar perfis só para usuários que você identificou. Eventos de visitantes anônimos ficam mais baratos e o painel de pessoas fica limpo, sem milhares de perfis de quem só passou pela home.

Link para esta seçãoApps feitos no Lovable, Bolt.new e V0

Projetos do Lovable são apps Vite com React, então o caminho mais simples é pedir no chat algo como "adicione o PostHog com a chave do projeto e capture os eventos de cadastro, criação de projeto e upgrade de plano". Como a chave do projeto é pública, ela pode ir direto no código. Com o GitHub sync bidirecional do Lovable, você também pode clonar o repositório, rodar o wizard localmente, commitar e deixar a mudança voltar para o editor visual. No Bolt.new e no V0 a lógica é a mesma: são projetos JavaScript comuns, e o posthog-js entra como qualquer outra dependência.

Link para esta seçãoIdentificando usuários com Supabase Auth

Evento anônimo serve para pouca coisa num app logado. O passo que mais gente esquece é chamar posthog.identify quando o usuário entra. Em projetos com Supabase, nós ouvimos o onAuthStateChange: no evento SIGNED_IN, chamamos identify com o id do usuário no Supabase e algumas propriedades como email e plano; no SIGNED_OUT, chamamos posthog.reset para que o próximo usuário do mesmo navegador comece com uma identidade nova. Usar o mesmo id do banco tem uma vantagem extra, porque depois você consegue cruzar eventos com tabelas do Postgres pelo data warehouse do PostHog.

Ações que acontecem no servidor, como um pagamento confirmado por webhook do Stripe, devem ser capturadas com o SDK de servidor (posthog-node) ou dentro de uma Edge Function do Supabase. Assim o evento sai do backend, independe do navegador do usuário e sobrevive a bloqueadores de anúncio.

Link para esta seçãoRastreamento de eventos: o plano de tracking que usamos

O PostHog tem autocapture, que registra cliques, envios de formulário e pageviews sem você escrever uma linha. É ótimo para começar e para responder perguntas que você não previu. O problema é que o autocapture descreve a interface, e a interface muda toda semana num app feito com IA. Um botão que troca de texto quebra o seu gráfico. Por isso, para as ações que definem o valor do produto, nós sempre criamos eventos customizados com nomes estáveis.

Nossa convenção é simples: objeto mais verbo no particípio, em snake_case e em português, como conta_criada, projeto_criado, convite_enviado e plano_assinado. Tudo minúsculo, sem espaço, sem variação. Parece detalhe até o dia em que você tem ProjectCreated, project_created e "projeto criado" no mesmo painel e precisa juntar os três à mão.

Link para esta seçãoOs eventos que contam de verdade

Para a maioria dos apps pequenos, de 5 a 10 eventos customizados respondem a maior parte das perguntas. O primeiro é o cadastro concluído, que marca o início da jornada. Depois vem o evento de ativação, o momento em que o usuário recebe o primeiro valor real do produto: num app de agendamento, é o primeiro horário reservado por um cliente; num CRM, é o primeiro contato importado. Em seguida vem a ação principal recorrente, aquela que você quer ver o usuário repetindo toda semana. Completam a lista os eventos de monetização (trial iniciado, plano assinado, plano cancelado) e os de expansão, como um convite enviado para um colega.

Definir o evento de ativação é a decisão mais difícil e a de maior retorno. Se você ainda não sabe qual é o seu, olhe para os usuários que continuam ativos depois de um mês e procure a ação que quase todos fizeram nos primeiros dias. Essa costuma ser a sua ativação. O nosso guia de onboarding para SaaS aprofunda como desenhar o caminho até esse momento com o mínimo de atrito.

Link para esta seçãoPropriedades que fazem diferença

Evento sem contexto vira só contagem. O que transforma contagem em resposta são as propriedades. Para cada evento, nós anexamos o que ajuda a segmentar depois: plano do usuário, origem do cadastro (orgânico, indicação ou anúncio), dispositivo, template ou recurso usado e, quando o produto é B2B, a empresa. Para apps B2B, o recurso de group analytics do PostHog agrupa usuários por conta, e aí você mede retenção por empresa, o que é bem mais fiel à realidade de um software vendido para times.

Um cuidado com a LGPD: evite mandar dados sensíveis como CPF, telefone ou conteúdo digitado pelo usuário em propriedades de evento. No session replay, o PostHog mascara campos de formulário por padrão, e vale ampliar o mascaramento para textos da página se o seu app exibe dados pessoais na tela.

Link para esta seçãoMétricas de produto que acompanhamos no PostHog

Com eventos chegando, o trabalho passa a ser olhar para os gráficos certos. Os insights do PostHog cobrem tudo o que um time pequeno precisa, e nós organizamos um dashboard semanal com quatro blocos. Essas métricas de produto conversam diretamente com as métricas de SaaS que todo founder deveria acompanhar, só que num nível mais granular, de comportamento.

Link para esta seçãoFunil de ativação

O funil mostra quantas pessoas passam de um passo para o outro e onde elas caem. O nosso padrão é cadastro concluído, onboarding concluído, evento de ativação e segunda sessão em até sete dias. O PostHog calcula a conversão de cada etapa e o tempo médio entre elas, e permite quebrar o resultado por qualquer propriedade. É o tipo de gráfico que revela, por exemplo, que quem chega pelo celular abandona o onboarding muito mais do que quem chega pelo desktop, porque o formulário gerado pela IA foi pensado para tela grande.

Link para esta seçãoRetenção por coorte

Retenção responde se o produto vale a pena a ponto de o usuário voltar. O insight de retenção do PostHog agrupa usuários pela semana em que fizeram o primeiro evento e mostra quantos repetiram a ação principal nas semanas seguintes. Uma curva que cai e depois se estabiliza indica que existe um núcleo de usuários que encontrou valor. Uma curva que desce até zero indica problema de produto, e campanha de aquisição nenhuma resolve isso. Quando a retenção some, o assunto vira churn em SaaS, e os dados de eventos mostram o que os usuários que cancelaram deixaram de fazer antes de sair.

Link para esta seçãoStickiness, lifecycle e paths

Stickiness mede em quantos dias por semana ou por mês o usuário faz a ação principal, um termômetro de hábito melhor do que o DAU sozinho. O insight de lifecycle separa usuários novos, recorrentes, ressuscitados e dormentes, ótimo para entender se o crescimento vem de gente nova ou de gente voltando. E o insight de paths mostra os caminhos reais de navegação, que quase nunca batem com o fluxo que você descreveu no prompt.

Link para esta seçãoSession replay para enxergar o comportamento

O gráfico mostra onde o usuário trava, e o session replay mostra o motivo. Com as gravações, você assiste à sessão de alguém que abandonou o funil e vê o clique repetido num botão que não responde, o modal que cobre o campo de email, o erro de JavaScript que só acontece no Safari. Em apps feitos com IA, que costumam ter bugs de interface que ninguém testou manualmente, isso vale ouro. Nossa rotina é filtrar gravações de usuários que entraram no funil e não completaram a ativação, e assistir a cinco delas por semana. Em geral, duas viram tarefa no backlog.

Combinado com o error tracking, que agrupa exceções do frontend e do backend e liga cada erro à gravação da sessão onde ele aconteceu, você chega à causa de um bug em minutos, com contexto suficiente para passar a tarefa inteira para o agente de código.

Link para esta seçãoFeature flags, experimentos e surveys

Analytics de produto fica mais poderoso quando você consegue agir sobre o que mediu sem sair da ferramenta. As feature flags do PostHog deixam você liberar uma funcionalidade nova para 10% dos usuários, só para um plano ou só para a equipe interna, e desligar na hora se algo der errado. Para quem desenvolve com agentes de IA, que às vezes entregam mudanças maiores do que o pedido, isso funciona como uma rede de segurança e tanto.

Os experimentos usam as mesmas flags para rodar testes A/B, com a significância estatística calculada pelo próprio PostHog. E as surveys permitem perguntar direto ao usuário, dentro do app, o que o fez parar numa etapa ou o que quase o fez desistir. Juntando o dado quantitativo do funil com o qualitativo da survey, a priorização do backlog fica bem menos subjetiva.

Link para esta seçãoPostHog com IA: MCP e consultas em linguagem natural

A parte mais nova, e a que mais mudou a nossa rotina, é conectar o PostHog aos agentes de código. O servidor MCP oficial do PostHog funciona no Claude Code, no Cursor, no Windsurf e no VS Code. Com ele conectado, você pergunta no terminal coisas como "qual foi a conversão do funil de ativação na última semana, quebrada por origem?" e o agente monta o insight, consulta os dados e responde. Também dá para pedir que ele crie feature flags, liste os erros mais frequentes ou confira se um evento novo está chegando depois do deploy.

Esse último uso é o nosso favorito. Depois de implementar uma feature com o Claude Code rodando o Opus 4.8, pedimos para o próprio agente disparar a ação no ambiente de teste e verificar no PostHog se o evento chegou com as propriedades certas. O ciclo de instrumentar, testar e validar fica todo dentro da mesma conversa. Dentro do painel do PostHog também existe um assistente de IA que transforma perguntas em linguagem natural em gráficos e queries SQL, útil para quem do time não programa.

Se o seu app chama modelos de linguagem, o módulo de LLM analytics registra custo, latência, tokens e respostas de cada chamada. Isso ajuda a descobrir qual feature de IA está queimando orçamento sem retorno e qual modelo vale trocar por um mais barato, como o Haiku 4.5 nas tarefas mais simples.

Link para esta seçãoPostHog vs Mixpanel, Amplitude e GA4

Existem outras boas ferramentas de analytics de produto, e a escolha depende do momento do seu projeto.

O Mixpanel é o veterano da categoria. A interface de relatórios é das mais rápidas e intuitivas do mercado, e o plano gratuito também mede por eventos. O ecossistema em volta, com replay, flags e testes, é menos completo que o do PostHog. É uma boa escolha para times que querem só analytics e valorizam a facilidade para pessoas de negócio montarem relatórios sozinhas.

O Amplitude é forte em empresas maiores, com recursos avançados de governança de dados, previsões e personalização. Para um MVP, costuma ser mais ferramenta do que você precisa, e os planos pagos sobem rápido quando você sai do gratuito.

O GA4 continua indicado para medir o site de marketing e as campanhas, especialmente se você já roda Google Ads. Para o app logado, a modelagem de eventos e a retenção por usuário são bem mais limitadas, e a interface foi pensada para perguntas de tráfego.

Há também as opções minimalistas, como o Vercel Web Analytics e o Plausible, que medem visitas com foco em privacidade. Elas resolvem bem o site e ficam na porta do app, sem acompanhar o usuário depois do login. Se você hospeda na Vercel, faz sentido usar as duas camadas juntas.

Resumindo a nossa recomendação: para um app feito com IA, com backend em Supabase e um time de uma a cinco pessoas, o PostHog cobre analytics, replay, flags e erros num lugar só, com custo zero até a tração aparecer. Foi por isso que ele virou o padrão dos nossos projetos.

Link para esta seçãoPreços e planos

O PostHog cobra por uso, produto a produto, e cada produto tem uma cota gratuita mensal que se renova. Você só paga o que passar da cota e pode definir um limite de gasto por produto para evitar surpresa na fatura. Os valores abaixo são da página oficial em outubro de 2026, e o preço unitário cai conforme o volume aumenta.

Produto	Grátis por mês	Depois da cota (a partir de)
Product analytics	1 milhão de eventos	US$ 0,00005 por evento anônimo (identificados custam até 4x mais)
Session replay	5 mil gravações	US$ 0,005 por gravação
Feature flags	1 milhão de requisições	US$ 0,0001 por requisição
Surveys	1.500 respostas	Cobrança por resposta
Error tracking	100 mil exceções	Cobrança por exceção

Além do uso, existem pacotes de plataforma opcionais. O Boost custa US$ 250 por mês e adiciona projetos ilimitados, white label e suporte a HIPAA. O Scale custa US$ 750 por mês e inclui SAML e suporte prioritário. O Enterprise sai por US$ 2.000 por mês, com controle de acesso por papéis, suporte dedicado e treinamento. Para MVP e SaaS em fase inicial, nenhum desses pacotes faz falta.

Para ter uma ideia de escala: um app com 2 mil usuários ativos por mês, cada um gerando uns 300 eventos, fica em 600 mil eventos, dentro do plano gratuito. Na nossa experiência, a conta só começa a aparecer quando o app passa de alguns milhares de usuários ativos ou quando o autocapture fica ligado sem filtro, gerando eventos que ninguém olha.

A versão open source para hospedar por conta própria é gratuita, mas exige manter ClickHouse, Kafka e Postgres rodando. Só recomendamos esse caminho para quem já tem alguém de infraestrutura no time ou uma exigência forte de manter os dados em servidor próprio.

Link para esta seção8 dicas para fazer analytics de produto sem se afogar em dados

1. Escreva o plano de eventos antes do código. Mantenha um arquivo tracking-plan.md no repositório com nome, descrição e propriedades de cada evento. O Claude Code e o Cursor leem esse arquivo e passam a instrumentar no padrão certo sem você repetir as regras a cada prompt.

2. Defina um único evento de ativação. Escolha a ação que melhor representa o primeiro valor entregue e use essa ação como norte do funil. Trocar a definição toda semana impede qualquer comparação histórica.

3. Identifique o usuário no login e resete no logout. Sem identify, cada sessão vira uma pessoa diferente e a retenção fica errada. Sem reset, dois usuários do mesmo computador acabam fundidos num perfil só.

4. Capture eventos críticos no servidor. Pagamento confirmado, assinatura cancelada e qualquer ação ligada a cobrança devem sair do backend. Bloqueadores de anúncio derrubam uma parte dos eventos do navegador, e são justamente esses os eventos em que você menos pode perder dado.

5. Configure um proxy reverso. Mandar os eventos do frontend pelo seu próprio domínio reduz bastante a perda causada por bloqueadores. No Next.js é um rewrite de poucas linhas, e o PostHog documenta o passo a passo para os frameworks mais comuns.

6. Separe os ambientes. Use um projeto do PostHog para produção e outro para desenvolvimento, ou desative a captura em localhost. Eventos de teste misturados com os reais estragam qualquer funil.

7. Assista a gravações toda semana. Cinco sessões de usuários que travaram no funil ensinam mais do que uma reunião inteira de priorização. Transforme o que encontrar em tarefas para o agente de código resolver.

8. Revise o dashboard em ritual fixo. Nós olhamos ativação, retenção e erros toda segunda-feira, em 20 minutos. Métrica que ninguém olha vira custo, e dashboard sem dono envelhece em um mês.

Construir com IA tirou o gargalo do código. O gargalo agora é saber o que construir em seguida, e essa resposta vem de quem usa o produto. Analytics de produto é a forma de ouvir esses usuários em escala, todos os dias, sem depender só de pesquisa ou de intuição.

Se você tem um app no ar hoje sem nenhum rastreamento, o próximo passo é pequeno: rode o wizard do PostHog, defina o evento de ativação e identifique os usuários no login. Em uma tarde você sai do escuro, e na semana seguinte já tem o primeiro funil para discutir com o time. O resto, de experimentos a surveys, vem naturalmente quando os dados começam a contar a história do seu produto.

Leia também:

TL;DR