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

Why pageviews do not answer this

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

When this earns its keep

You need this once you are guessing why users drop off instead of 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 run GA4 or a pixel and realize neither tells you what happens after the click, inside the actual product.

You do not need a full rollout for a simple marketing site with no real user flow. Basic web analytics and an ad pixel cover that case better. The tell that you need this: a product with steps, a signup, a checkout, an onboarding flow, where people can get stuck partway through.

What we actually set up

We start with a short audit: what tracking already exists, what it is missing, and whether the events that do fire actually mean what the dashboard implies. Duplicate events and double-counted sessions are common findings. The tracking plan gets built around your actual funnel steps, not a generic e-commerce or SaaS template. A fitness app’s funnel and a B2B tool’s funnel do not look the same.

Session replay gets configured with sensitive fields masked before recording starts, payment details, personal messages, not after a privacy review flags it. Consent handling is wired in before any event fires, so we respect a user’s choice instead of tracking first and asking forgiveness later. Where feature flags or experiments are planned, we set those up alongside the core tracking. A product team can then ship a change behind a flag and measure it right away, instead of retrofitting tracking after the fact.

We have done this exact kind of funnel audit and rebuild for a D2C store. The single biggest gap there was a tracking plan that never matched what the product actually did.

Where setups go wrong later

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. 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. A setup that tracks everything by default gets expensive fast, so we scope what gets recorded deliberately instead of defaulting to capture-all. Self-hosting avoids most vendor lock-in and keeps data on your own infrastructure, at the cost of maintaining that infrastructure yourself. We weigh that against the managed cloud option based on your data residency needs.

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

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 an AI analyst across two brands. Tell us where users are dropping off: get in touch.