When to adopt PostHog product analytics
Deciding when product analytics with PostHog earns its place, framed as four needs past plain traffic analytics: events, feature flags, session replay, and experiments.
The marketing site already runs Vercel Web Analytics. Traffic is flowing, you can see which pages people land on, and Core Web Vitals are green. That cookieless floor shipped last lesson, and for a while it’s the whole stack.
Then three asks land in the same week, from three different people:
- Product: “Did the new onboarding flow improve trial-to-paid conversion?”
- Engineering: “Let’s roll the new billing UI out to 10% of orgs first, before everyone.”
- Support: “Three users say the dashboard just broke this week. No console error, every log is a clean 200. What happened on their screens?”
None of these is answerable from Vercel Web Analytics, which counts visits and measures how fast pages load. It can’t tell you who a user is, what they did across several sessions, which version of a feature they saw, or what their screen looked like the moment it broke. Those are product-analytics questions.
This lesson is about the decision to adopt product analytics, not how to wire it up: where the threshold past the cookieless floor sits, which platform you reach for, and why one platform instead of four. The aim is to decide “PostHog, or not yet?” on a real product.
The four needs that justify PostHog
Section titled “The four needs that justify PostHog”Last lesson framed the floor’s edge as five signals: needing to know who a user is, what they did, across sessions, gated by a flag, or in replay. “What they did” and “across sessions” are one need, so the five collapse into four that a team budgets for, one per ask above plus one more.
1. Event-level analytics (the product team’s onboarding ask). Answers what users do across sessions: not “how many people visited” but “of the people who started onboarding, how many finished step two, and how many upgraded a week later.” You record an event for each meaningful action with properties like plan: 'pro' or org_seats: 12, then build a funnel to find where people leak out, group users into a cohort , and chart retention .
2. Feature flags (engineering’s “10% of orgs first” ask). A switch you flip from a dashboard, without a deploy, to decide who sees what feature and when: roll a feature out to 10% of orgs, kill a broken one instantly instead of shipping a revert, or turn one on only for pro-plan users. Flags are also what A/B tests run on.
3. Session replay (support’s “the dashboard broke with no error” ask). A privacy-masked, video-like playback of what a user did in the browser, with sensitive content blanked out. It’s the tool for the UX bug that throws no error and leaves every log a clean 200: the button that looks disabled, the modal that traps focus, the form that silently rejects valid input.
4. Experiments (the disciplined onboarding question). A statistical A/B test with a primary metric and an automated call on whether the difference is real or noise. Not “I think variant B feels better” but “variant B lifted trial-to-paid by 4%, and here’s the confidence it isn’t random.”
What do users do across sessions?
Who sees what feature, when?
What did they do before they bailed?
Did this change move the metric?
Try the boundary on a few cases. The hard ones sound like traffic but are really about identified behavior.
Sort each question by which tool answers it. A few are trickier than they look. Drag each item into the bucket it belongs to, then press Check.
That last one is the trap. Raw referrer counts are traffic data, so Vercel answers it. But “which referrer sends signups that turn into paying customers” crosses the line: it ties an anonymous referrer to an identified user’s later conversion across sessions, which only product analytics can stitch together. The boundary isn’t the word “signup” or “referrer,” it’s whether the answer needs to know who the user is and what they did over time.
One platform, or four vendors
Section titled “One platform, or four vendors”Suppose you have a real need, say events and flags, the two most products hit first. The naive next move is one tool per need: an events tool (Mixpanel or Amplitude), a flags tool (LaunchDarkly or Statsig), a replay tool (FullStory or Hotjar) when replay shows up, an experiments tool (Statsig again, or Optimizely) once you run experiments. Each is excellent, but four things go wrong, and they compound:
- Four contracts to evaluate, negotiate, and renew: four vendor relationships, four invoices, four security reviews.
- Four SDKs in your client bundle, each one JavaScript the browser downloads and runs before your app feels fast. The performance floor you just measured with Speed Insights sinks under the weight of your own analytics.
- Four dashboards to switch between: the funnel in one tab, the flag in another, the replay in a third.
- Four identity models to keep aligned, and this one quietly breaks everything. The same user has a different ID in Mixpanel, LaunchDarkly, and FullStory, so the cross-tool question, “did the users who saw variant B finish the funnel, and can I watch one struggle?”, needs a join across three export formats that nobody builds. The question just doesn’t get asked, and you paid four times for the privilege.
PostHog folds those four needs into one platform, one SDK, one identity, one dashboard. All four primitives hang off the same identifier, so “the users who saw variant B (a flag) completed the funnel (events), let me watch one struggle (replay)” is a single query against a single dataset.
When you’d actually pick something else
Section titled “When you’d actually pick something else”Folding usually wins, but each credible competitor has one trigger that would send you to it instead:
- Mixpanel / Amplitude are the deepest event-analytics tools there are, with no flags and no replay. Reach for one when event analytics is your only need and that depth outweighs having everything in one place, as it does for a data-heavy team whose whole job is funnels and cohorts.
- Statsig has strong experiments and flags, weaker event UX, and replay that’s still maturing. Reach for it when experiments are the daily load-bearing primitive and the team’s rhythm is “ship a test, read the result, ship the next.”
- LaunchDarkly is the flag specialist, with no events and no replay. Reach for it when flag scale outgrows PostHog: thousands of flags, complex targeting trees, enterprise governance and approval workflows.
- Plausible / Fathom / June.so are privacy-first traffic analytics, the same tier as Vercel Web Analytics. They are not product analytics and don’t touch the four needs. Don’t let the word “analytics” pull you toward one of these for a funnel question.
PostHog is the default because the typical SaaS hits two to four of these needs at once, and folding more than one onto a shared identity wins decisively.
What PostHog costs, and why you adopt it one primitive at a time
Section titled “What PostHog costs, and why you adopt it one primitive at a time”PostHog bills per ingested event, per replay session, and per flag request , with a generous free allowance that resets monthly on every primitive. At the time of writing that’s roughly 1M product-analytics events, 5k session replays, and 1M feature-flag requests per month, far more than a pre-PMF SaaS will touch, so it’s effectively free until product-market fit and scales per primitive after.
A generous free tier tempts you to turn on all four primitives the day you sign up, but free to ingest isn’t free to maintain. Each primitive is something someone has to instrument and watch: an event taxonomy nobody reads still rots, and replay you never watch is wasted storage. So adopt incrementally:
- Pick the two primitives that earn their weight right now. For most products that’s events plus flags.
- Add replay when a specific bug-class demands it, like the no-error UX bug or the rage-click report. Not before.
- Reserve experiments for the metric-led moment, the first time someone asks “is this change real, statistically?” rather than “does this feel better?”
Three shapes can quietly burn through your quota; recognize them now so you don’t write them in, and the wiring lessons show the guardrail for each:
- A
capture()call inside a React render. Every re-render fires another event, and React re-renders a lot. - A missing identity stitch, where the same action is recorded twice, once anonymous and once identified, because PostHog couldn’t tell they were the same person.
- Recording every anonymous session on a high-traffic B2C site, which drains your replay quota on visitors who never sign up.
Two setup decisions: region and the consent gate
Section titled “Two setup decisions: region and the consent gate”Two non-code choices are cheaper to get right now than to undo later: which region you run in, and how consent gates what PostHog sees.
Pick the region: PostHog Cloud EU
Section titled “Pick the region: PostHog Cloud EU”PostHog Cloud comes in two regions. EU Cloud runs in Frankfurt and disables IP capture by default for new projects, which covers your data residency posture without a DPA . US Cloud is the equivalent for teams whose users are mostly outside the EU. There’s also a self-hosted, open-source PostHog, but operating it pulls in Postgres, Redis, Kafka, and ClickHouse , and the on-call cost outweighs the savings for any team under tens of millions of events a month.
The course default is PostHog Cloud EU. Region is load-bearing: picking US Cloud when your users are mostly in the EU means a data migration and a fresh project to switch later, so if your users are in the EU, choose EU now.
The consent gate is non-negotiable
Section titled “The consent gate is non-negotiable”PostHog handles personal data: distinct IDs (its identifier for one user or browser, the key every event, flag eval, and replay hangs off), IP addresses, and event properties that can carry user state. Under GDPR and ePrivacy, that makes it non-essential: nothing PostHog does may fire before the user actively accepts. The cookie consent gate you shipped already exposes a boolean per category, and PostHog reads one:
const { analytics } = useConsent();Every PostHog call in this chapter routes through useConsent().analytics.
While it’s false, the SDK isn’t even imported; when it flips to true, the SDK is dynamically imported and capture begins.
As a safety floor, the SDK is initialized with capturing opted out by default, so nothing leaks even if the gate is bypassed.
That makes consent a budget input too: consented users are the only population PostHog ever sees, so event volume is gated by your accept rate, not your total traffic.
PostHog also does not replace Sentry. Sentry catches thrown errors, the exceptions and stack traces that crash; PostHog captures behavior, including the bug-class that throws no error, the user stuck on a screen the code thought was fine. You want both; they answer different halves of “something’s wrong.”
What the install pulls in
Section titled “What the install pulls in”A preview of what the next lesson installs. Don’t type it yet.
pnpm add posthog-js posthog-node @posthog/nextposthog-jsis the browser SDK: it captures events, evaluates flags on the client, and records session replay.posthog-nodeis the server SDK: it captures events from server code and evaluates flags before a page reaches the browser.@posthog/nextis the official App Router wrapper that ties the two together: a server-component provider that bootstraps SSR-evaluated flags, distinct-ID cookie seeding in middleware, a built-in same-origin proxy, and automatic event flushing.
The adoption decision as one procedure
Section titled “The adoption decision as one procedure”One procedure you can run on any future product: clear the marketing-page stage, check the four needs, read the verdict.
The cookieless floor is the whole stack until a product question becomes unanswerable from traffic data. Don’t maintain an event taxonomy nobody is reading yet. Revisit once you have signed-in users doing things worth measuring.
Zero of the four needs being real is the answer. Come back when the first one becomes genuinely true.
The events need is your trigger: funnels, cohorts, retention. One platform covers this plus the other three primitives when they arrive, so you don’t re-decide per need. The consent gate and EU region apply to everything you capture.
Gradual rollouts and kill switches are your trigger, on the platform that also covers events, replay, and experiments on one identity.
The no-error bug-class is your trigger: you need to see what the user actually did, on the platform that also covers events, flags, and experiments. Replay especially must be privacy-masked.
Statistical A/B testing against a metric is your trigger. Experiments ride on flags, on the platform that also covers events and replay, one identity across all four.
Every “add PostHog” branch lands on the same platform: any one need decides all four at once.
External resources
Section titled “External resources”The free-tier numbers in this lesson move, so verify them before you budget. PostHog’s overview is also a good way to check whether the four primitives match your needs.
How PostHog frames events, flags, replay, and experiments as one platform.
The current per-primitive free-tier allowances. Check these before committing a budget, because the numbers move.
What replay actually shows: clicks, rage-clicks, and a synced DevTools timeline for the no-error bug-class.
The folding-vs-best-of-breed argument made concrete, with feature matrices and pricing for the 'pick something else' decision.