What Is PostHog? The Complete Tutorial for Product Teams

PostHog is an open-source, all-in-one platform that product engineers use to understand how people use their product and their website. It rolls more than eight tools into one: product analytics, session replay, feature flags, A/B testing, surveys, a data warehouse, and a customer data platform (CDP). Instead of paying for Google Analytics, a replay tool, a flag service, and a CDP separately, you get them in one place, built on the same event data. Quick context on why you should trust this one. I am JJ, founder of VisionLabs. My team and I have shipped more than 20 PostHog implementations for companies that range from teams of one to teams of 100, we manage around 30 PostHog accounts right now, and we run PostHog on our own site every single day (we eat our own dog food). So this is not a feature list copied off the docs. It is how I actually set PostHog up, what I switch off on day one, and the mistakes I watch teams make over and over. By the end you will know what PostHog is, how to install it, how to read your data, and roughly what it will cost you. What is PostHog used for? PostHog is used to capture user behavior and act on it in one system. You install one snippet, it starts collecting events, and from those events you build funnels, watch session recordings, ship features behind flags, run experiments, and pipe the data out to your ad platforms or warehouse. Here is what lives inside the platform: The reason teams pick PostHog over a single point tool is that all of this shares one event stream and one person profile. Watch a funnel drop off, jump to the replay of that exact user, then ship a fix behind a flag, without leaving the tab. You can read the full picture in our PostHog academy. How PostHog works: events, people, and the data model PostHog works by collecting events, attaching them to people, and rolling those people up into cohorts and groups. Once you understand that hierarchy, every feature in the product makes sense. Here is the structure we use to explain it to clients, from the bottom up: Everything in PostHog is some combination of those five layers. A dashboard is built from events. A feature flag targets a cohort. An experiment measures an event for people in a group. Keep the pyramid in your head and you will never get lost in the UI. 🎥 Watch: How cohorts and groups work in PostHog  Setting up PostHog: events, autocapture, and identifying users Setting up PostHog takes three moves: install the snippet, decide what events to capture, and identify your users so their journeys connect. Most teams get the first one right and the other two wrong, so this is where to spend your attention. Turn autocapture off (yes, really) When you install PostHog, autocapture starts recording every click, form submit, and pageview automatically. That feels great for about a week, until you hit your event limits. Autocapture can nearly double your event volume, and on top of pageviews it adds page-leave events, rage clicks, and web vitals. Our rule: if you do more than about 2,000 sessions a month, turn autocapture off. Every client we work with runs with autocapture off. You do it in Settings, then toggle off autocapture and the web vitals you do not need. Now you control what gets counted. Send custom events with posthog.capture With autocapture off, you send the events you actually care about. On the browser we deploy them through Google Tag Manager so marketing can manage them without a developer. The call is simple: Name events with the object-action framework: the object first, then what happened. cta_viewed, workshop_registered, lead_generated. Then add a property to describe the specifics, like cta_name or workshop_name. Good names are not cosmetic. They let you read your activity feed at a glance and break events down later. We go deeper on this in how PostHog events and autocapture work. For backend events, you send the same kind of call from your server, a webhook, or a low-code tool. The point is that PostHog takes events from the browser and the backend into the same stream. Identify users so their journey connects identify is how PostHog ties an anonymous visitor to a known person. Until someone gives you an email, they are an anonymous ID. When they convert, you call identify and PostHog stitches their whole history onto one profile. One setting matters here. By default, person profiles are created for identified users only. Change it to always, so PostHog stores a profile for every anonymous visitor and merges it the moment they identify themselves. Get this wrong and your funnels and retention will quietly lie to you, because anonymous and known sessions never join. 🎥 Watch: PostHog events, autocapture, and identify  Building your first dashboard (and a real conversion rate) A PostHog dashboard is a group of insights, and an insight is any chart you build from your events. To build your first one, create a dashboard, name it right away (it defaults to “new dashboard” and you will forget), then add insights one at a time. Here is the quick path we use for a launch or promotion dashboard: That covers 60 to 80 percent of what most product and marketing teams need. The trick is to know the answer you want first, then build the insight backward from it. 🎥 Watch: How to build dashboards in PostHog  Set up alerts so problems find you PostHog alerts watch a metric and message you when it crosses a line you set, so you learn that a conversion rate dropped before your boss does. It is one of the most underused features in the product, and it takes about a minute to set up. Build an insight first, like the conversion rate from the last section, and save it. Then open the three-dot menu on that insight and create an alert. Set a low and a high threshold. We alert when our lead