PostHog bundles the tools a product team normally buys separately: product analytics, session replay, feature flags, A/B testing, surveys and error tracking, all reading from the same event stream. The practical effect is that a funnel, the recordings of the people who dropped out of it, and the flag controlling the feature they were using are three clicks apart instead of three vendors apart.
Analytics covers the standard questions: trends over time, funnels with drop-off at each step, retention cohorts, user paths and stickiness. Because events carry your own properties, the segmentation is as detailed as your instrumentation. Session replay records what a user actually did, with the option to mask sensitive inputs, and replays can be opened directly from a funnel step, which is the fastest route from "people are abandoning checkout" to seeing why.
Feature flags and experiments share the same identity layer, so a flag can be rolled out to a percentage of users, targeted at a cohort defined by behaviour, and measured against a metric without extra wiring. Being able to define the audience by what people have done, rather than by a static list, is the part teams keep.
The distinguishing choice is that PostHog is open source and can be self-hosted, which means event data containing personal information can stay inside your own infrastructure. That matters for healthcare, finance and European companies with data residency obligations. It is worth being honest that self-hosting a high-volume analytics platform is not trivial: the storage layer is ClickHouse, and running it well is a real operational commitment. Most teams take the cloud version, in the EU or US region, and treat self-hosting as an option they could exercise rather than one they do.
Pricing is generous at the low end and usage based above it, metered separately per product, so a team using only analytics is not paying for replay. The volume-based model rewards deliberate instrumentation and punishes firing an event on every mouse movement.
Who it suits: product teams who want analytics and the tools that act on it in one place, and any organisation with data residency requirements. Who should be careful: teams without engineering capacity, since instrumentation and self-hosting both need one.