Product analytics that answers real questions
PostHog set up to track what matters

What it is

Product analytics tracks what a user actually does inside your product, which screen they land on, where they hesitate, which step of a signup or checkout they abandon, as opposed to marketing analytics, which tracks where they came from. PostHog combines event tracking, funnels, session replay and feature flags in one self-hostable tool, which matters because a product question, “why do 40% of people drop off at step 3,” usually needs more than a pageview count to answer.

When you need it (and when you do not)

You need this once you are guessing at why users drop off rather than seeing it, or once a product decision, cutting a signup step, redesigning a pricing page, needs evidence instead of an opinion in a meeting. It is also the right time if you already have GA4 or a pixel installed and realize neither one tells you what happens after the ad click, inside the actual product experience.

You do not need a full product analytics rollout for a simple marketing site with no real user flow to track, that is better served by basic web analytics and a pixel for ad platforms. The tell that you need this is a product with steps, a signup, a checkout, an onboarding flow, where people can get stuck partway through.

How we build it

We start with a short audit: what tracking already exists, what it is missing, and whether events that do fire actually mean what the dashboard implies they mean, duplicate events and double-counted sessions are common findings. The tracking plan is built around your actual funnel steps, not a generic e-commerce or SaaS template, because a fitness app’s funnel and a B2B tool’s funnel do not look the same. Session replay gets configured with sensitive fields, payment details, personal messages, masked before recording starts, not after a privacy review flags it. Consent handling is wired in before any event fires, respecting a user’s choice rather than tracking first and asking forgiveness later. Where feature flags or experiments are planned, we set those up alongside the core tracking so a product team can ship a change behind a flag and measure it immediately rather than retrofitting tracking after the fact. We have done this exact kind of funnel audit and rebuild for a D2C store and a trading app, in both cases the biggest single gap was a tracking plan that never matched what the product actually did.

What to watch

The most common failure after a PostHog setup is letting the event list grow unmanaged, every new feature adds three more events nobody reviews, and within a year the funnel view is cluttered with noise that makes the real signal harder to see. We recommend a lightweight review cadence, quarterly is usually enough, to retire events nobody queries. Session replay and event volume both drive PostHog’s usage-based cost, so a setup that tracks everything by default can get expensive fast; we scope what gets recorded deliberately rather than defaulting to capture-all. Self-hosting PostHog avoids most vendor lock-in concerns and keeps data on your own infrastructure, at the cost of maintaining that infrastructure yourself, which we weigh against the managed cloud option based on your data residency needs.

We also agree with you on a short list of events considered the source of truth for billing or reporting decisions, separate from the broader exploratory tracking, because conflating the two tends to produce a dashboard that looks precise but is not actually reliable enough to base a financial decision on.

Price and timeline

Related

Built as part of analytics and setup and integrations. Pairs well with server-side tracking and CAPI for the marketing side and feature flags and experiments once you start testing changes. See the funnel work behind the Thailand D2C store audit and rebuild and the trading app funnel audit. Tell us where users are dropping off: get in touch.