Product Analytics With PostHog

You can watch a thousand people arrive at your product and still have no idea what happened to them once they walked in the door. That is the gap most growth teams live in. The marketing dashboards are lit up with sessions, sources, and bounce rates, and none of it tells you whether a single one of those people did the thing your product exists to do. Traffic is the easy part to see. Behavior is the part that actually decides whether you have a business.

Product analytics is how you close that gap, and PostHog is the tool I reach for most often to do it. It answers a different question than your web analytics. It is not concerned with which campaign sent the visitor; it is concerned with what that person did across sessions, over days and weeks, tied to who they actually are. That shift, from pageviews to behavior, from anonymous traffic to identified users, is the whole point of product analytics, and it is where the durable growth advantages live.

I instrument products for a living. When I want to find the step where new users quietly give up, or the early action that separates the accounts that stay from the ones that vanish, I am not looking at a bounce rate. I am looking at funnels, retention curves, and session recordings inside a product analytics platform. This post is how I think about that work, and why PostHog in particular earns its place in a growth stack.

Product analytics is not web analytics

The cleanest way to understand product analytics is to contrast it with the web analytics most teams already run. A tool like GA4 is built around acquisition. It is fundamentally marketing analytics: where did traffic come from, which channel converted, how did a landing page perform, what did a session cost. It thinks in pageviews and sessions, and it is very good at the questions a demand-generation team asks every morning. I use GA4 and I am glad it exists.

But GA4 was never designed to tell you what a person does inside your product over their lifecycle. It is session-centric and largely anonymous by design, and its whole frame is acquisition rather than behavior. Product analytics is user-and-event centric. It treats the individual as the unit of analysis, stitches their activity together across every session and device, and records the specific events they trigger inside the product. The question changes from “how did this visitor get here” to “what did this user actually do, and did they come back.”

A growth team needs both, and they are not interchangeable. GA4 tells you the top of the funnel is working. Product analytics tells you what happens after the click, once the marketing has done its job and the product has to deliver. If you want the fuller picture of how web analytics fits a growth motion, I wrote about GA4 for growth separately. Here the focus is everything that starts the moment someone becomes a user rather than a visitor.

What PostHog actually is

PostHog is an open-source, self-hostable product analytics platform, and the part that matters most for a growth team is that it bundles several tools that normally live in separate vendors. In one product you get event analytics, session replay, feature flags, A/B experiments, and surveys. That combination is not a gimmick. It changes how fast you can move.

Think about the normal workflow. You notice a drop-off in your analytics tool. You want to see why, so you open a separate session-recording product, assuming the events line up. You form a hypothesis, so you go to a third tool to build a feature flag and run an experiment. You want qualitative signal, so you bolt on a fourth tool for surveys. Every handoff is a place where user identity gets lost, definitions drift, and the loop slows down.

When those capabilities share one event stream and one notion of who a user is, the loop tightens. You spot a funnel leak, watch the recordings of the exact users who leaked, ship a flagged change to a slice of them, and measure the experiment against the same events, all without leaving the platform or reconciling four definitions of “activated.” For a small growth team, that consolidation is the difference between running one clean experiment a week and running none.

Everything rides on the tracking plan

Before any of the analysis is worth trusting, the data underneath it has to be right, and this is where most product analytics efforts quietly fall apart. Garbage in, garbage out is not a cliche here; it is the single biggest determinant of whether your analytics are useful or actively misleading. A funnel built on inconsistently named events is worse than no funnel, because it looks authoritative while being wrong.

A tracking plan is the deliberate, documented answer to what events you capture, what you name them, and what properties travel with each one. It is the schema for your behavioral data, agreed before the code ships rather than reverse-engineered afterward. Without it, you get the classic mess: signup_completed, Signup Complete, and completed-signup all firing from different parts of the app, none reconciled, each telling a slightly different story. I treat this as foundational work and have written a full walkthrough of tracking plan design because it deserves the attention. Skip it and everything downstream in PostHog inherits the noise.

Autocapture, and its trap

PostHog offers autocapture, which automatically records clicks, pageviews, and interactions without you defining each event by hand. It is genuinely useful for getting started fast and for retroactively answering questions you did not think to instrument. You can turn it on, let it run, and explore what people are doing before you have written a single custom event.

The trap is treating autocapture as your whole strategy. Autocapture gives you a flood of low-level DOM interactions with no semantic meaning. It knows a button was clicked; it does not know that the click meant “user invited a teammate,” which is the thing you actually care about. Relying on it alone produces chaos: thousands of undifferentiated click events that are hard to build reliable funnels on and impossible to reason about six months later. The approach that works is to use autocapture as a discovery layer and exploratory net, while defining a small set of deliberate, well-named custom events for the actions that matter to your business. Those named events, governed by your tracking plan, are what you build the important analyses on.

Identify your users, or none of it holds together

The feature that makes product analytics different from web analytics is user identity, and it is worth getting right early. Most users show up anonymous. They browse, maybe sign up, and only then become someone you can name. PostHog handles this through identification: before signup, activity is tied to an anonymous identifier; at signup or login, you call identify and stitch that anonymous history to the now-known user.

This anonymous-to-identified stitching is what lets you answer questions that GA4 structurally cannot. You can see the full path from the first anonymous visit through signup, activation, and every returning session weeks later, as one continuous record for one person. Get the identify call wrong and you either fragment one user into several ghosts or, worse, merge different people together. I check this early in any instrumentation, because a broken identity layer silently corrupts every funnel and retention number built on top of it, and the corruption is hard to spot after the fact.

Funnels, retention, and paths

With clean events and solid identity, the core analyses are where product analytics pays for itself. Funnels are the first thing I build. A funnel in PostHog is a real product flow, signup to activation to first meaningful action, and it shows you exactly where users drop off between steps. Unlike a marketing funnel, this is behavioral and tied to identified users, so you can slice the drop-off by cohort, plan, or acquisition source and find not just that people leak but who leaks and where. That specificity turns a vague “activation is low” into “sixty percent of users who start onboarding never finish the second step,” which is a problem you can actually fix.

Retention analysis is the second pillar and, honestly, the one that matters most for a durable business. PostHog’s retention view shows you what fraction of a cohort comes back over subsequent days or weeks, and the shape of that curve tells you whether you have real product-market fit or a leaky bucket. A curve that flattens is a product people keep needing; a curve that decays to zero is a product they tried once. This connects directly to finding your activation aha moment: the early behavior that predicts long-term retention. I go deep on how to read and act on these curves in cohort analysis, which is the natural companion to the retention work here. Alongside funnels and retention, paths let you see the actual routes users take through the product, including the ones you never designed, which regularly surfaces both dead ends and unexpected power-user workflows.

Session replay gives you the why

Numbers tell you what happened and where, but they rarely tell you why, and this is where session replay earns its keep. PostHog records real user sessions, so when a funnel shows a brutal drop at one step, you can stop guessing and watch the recordings of the exact users who dropped there. This is the single fastest way I know to generate good hypotheses.

The quantitative and qualitative reinforce each other. The funnel points you to the precise moment worth investigating, and the replay shows you the confused clicking, the form field everyone abandons, the error message no one on the team knew was firing, the button that looks disabled but is not. Ten minutes of watching recordings often explains a drop-off that a week of staring at aggregate charts never would. Ignoring session replay when you have it is leaving the most direct evidence of user intent sitting untouched. When a metric surprises me, replay is the first place I go.

Feature flags and experiments in the same place

Because PostHog includes feature flags and A/B experiments natively, the loop from insight to shipped change to measured result stays inside one tool and one event stream. You find a problem in a funnel, build a feature flag to gate a change, roll it out to a controlled slice of users, and run the change as a proper experiment measured against the same events you already trust.

That shared foundation removes a whole class of integration pain. Your experiment’s success metric is a PostHog event you have already defined and validated, not a number you are trying to reconcile between an experimentation vendor and an analytics vendor that count things differently. The mechanics of designing experiments so they actually teach you something, sample size, holdouts, reading results honestly, are the same regardless of tool, and I cover them in an A/B testing program that works. PostHog’s contribution is removing the friction between noticing something and testing a fix for it.

Self-host or cloud, and the privacy question

One of PostHog’s more distinctive properties is that you can self-host it, and this is a real decision rather than a footnote. PostHog Cloud is the fast path: no infrastructure to run, scales for you, sensible default for most teams that just want to get going. Self-hosting means running it on your own infrastructure, which is more operational work but buys you something specific and valuable.

That something is data control. When you self-host, user event data never leaves infrastructure you own, which is a meaningful advantage for privacy and for GDPR and similar regimes, especially if you operate in Europe as I do. You are not sending behavioral data about identified users to a third party; it stays under your governance, your retention rules, your access controls. For products handling sensitive data or teams with strict compliance requirements, that control can be the deciding factor. For everyone else, cloud is usually the right call, and you can start there and move later. The point is that the choice exists, which is rare among analytics tools.

Where PostHog fits with GA4 and a warehouse

PostHog does not replace your whole data stack, and pretending it does leads to disappointment. A mature growth setup usually runs three layers. GA4, or an equivalent, owns web and marketing analytics: acquisition, channels, campaign performance. PostHog owns product analytics: in-product behavior, funnels, retention, replay, experiments, everything about what identified users do. And a data warehouse becomes the long-term source of truth that joins product behavior with revenue, support, and sales data for the deep analysis neither of the first two tools does well.

These are complementary, not competing. Marketing wants attribution and channel performance and reaches for GA4. Product and growth want behavioral depth and reach for PostHog. Finance and analytics want everything joined together and reach for the warehouse. PostHog can export to the warehouse, so it feeds the source of truth rather than becoming a data silo. Trying to force one tool to do all three jobs is how you end up with analytics no team fully trusts.

Setup and your first analyses

The practical path is deliberately unglamorous. Write the tracking plan first, even a lightweight one covering signup, activation, and your handful of core actions. Install PostHog and turn on autocapture for exploration, but implement your named custom events by hand against the plan. Wire up identify at signup and login, then verify that events fire exactly once and that identity stitches correctly before you trust a single chart. That verification step is the one people skip and the one that saves you from confidently wrong conclusions later.

Once the data is clean, the first analyses almost pick themselves. Build the signup-to-activation funnel and find the biggest drop-off. Build a retention curve for recent cohorts and see whether it flattens or decays. Watch session replays of the users who dropped at your worst funnel step. Those three moves, in that order, will teach you more about your product in an afternoon than any dashboard of vanity metrics has in a quarter, and they set up every experiment worth running next.

Common mistakes

• No tracking plan. Instrumenting ad hoc so event names drift and nothing reconciles. Fix the schema before you write the code.
• Autocapture as the whole strategy. Drowning in undifferentiated click events with no semantic meaning. Use autocapture to explore, custom events to decide.
• Tracking everything, analyzing nothing. Capturing hundreds of events and never building a funnel or reading a retention curve. Data collection is not insight.
• Ignoring session replay. Staring at aggregate charts while the recordings that explain them sit unwatched. Replay is your fastest source of hypotheses.
• Not identifying users. Leaving everyone anonymous so you get pageview counts instead of behavioral lifecycles. Identity is the entire point of product analytics.

The short version

• Product analytics answers what users do inside your product across sessions, tied to identified people, which is a different question than the acquisition and pageview focus of web analytics like GA4. A growth team needs both.
• PostHog bundles analytics, session replay, feature flags, experiments, and surveys in one tool sharing one event stream, which tightens the loop from insight to shipped change dramatically.
• None of it works without a tracking plan. Use autocapture to explore and deliberate custom events to build the analyses that matter.
• Identify your users and stitch anonymous history to known accounts, or every funnel and retention number is built on broken identity.
• Funnels find where users drop, retention curves tell you if the product sticks, paths show real routes, and session replay explains the why behind all of it.
• Self-hosting keeps user data on infrastructure you own, a real privacy and GDPR advantage; cloud is the fast default for everyone else.
• PostHog sits alongside GA4 and a warehouse, not instead of them. Start with the activation funnel, the retention curve, and the replays of your worst drop-off.

---

I am Deepanshu Grover, a Growth Product Manager in Paris. If you can see traffic but not what users actually do in your product, connect on LinkedIn or get in touch.