PostHog

This guide gets you from a blank PostHog account to a working product-analytics setup that actually answers the questions you care about: where people drop off, what your best users do differently, and whether a change moved the needle. It is written for founders and growth operators who run a B2B product and want one tool that covers analytics, session replay, and experiments without stitching five vendors together.

Getting set up

The first real decision is which PostHog you run: the hosted cloud or a self-hosted instance. Unless you have a specific data-residency or compliance reason to self-host, take the cloud. Self-hosting PostHog is a real operational job, and the cloud removes that entire class of work so you can spend your attention on the product instead of the infrastructure.

The second decision is how you install it, and this is where most setups go wrong. PostHog can autocapture events (clicks, pageviews, form submissions) the moment you drop the snippet in, and that is genuinely useful for getting started fast. But autocapture is noisy, and noisy data quietly becomes useless data. So treat autocapture as your safety net, not your strategy. From day one, also send a small set of named, deliberate events for the moments that matter to your business: signed up, activated, invited a teammate, hit the paywall, upgraded. Those named events are what you will build every funnel and retention chart on later.

Get identity right before you have much traffic, because it is painful to fix afterwards. Call PostHog's identify the moment a user logs in, using your own stable internal user id, and for a B2B product set group analytics so events also attach to the company (the account), not only the individual. Without groups you can answer "how many users did this", but you cannot answer "how many accounts", and in B2B the account is the unit that pays you. Decide your id scheme once and keep it consistent across web, server, and any mobile surface.

How to actually use it

Work in this order, because each step depends on the one before it.

Start by confirming the data is real. Open the live events view, do the key actions in your product yourself, and watch the named events arrive with the properties you expect. If activated is firing on the wrong step, every chart downstream is wrong, so spend the ten minutes here.

Next, build your activation funnel. Pick the three to five steps a new account takes from sign-up to the moment they get value, and chart them as a funnel. This single view usually surfaces your biggest leak, and fixing the worst step is almost always higher leverage than any new feature.

Then build a retention chart on your core action, not on logins. "Came back and did the thing that matters" is the honest measure of whether your product sticks. Watch the curve flatten (or fail to), and segment it by how users signed up or what plan they are on.

With funnels and retention in place, turn on session replay and watch real sessions of users who dropped at your worst funnel step. Numbers tell you where the leak is; replays tell you why. This pairing, a funnel to find the leak and replays to explain it, is the core loop that makes PostHog worth its keep.

Power moves

Build cohorts, not one-off filters. Define "activated accounts", "power users", and "trial accounts that stalled" once as saved cohorts, then reuse them across every insight. A consistent definition of "power user" across the whole team is worth more than any single clever chart.

Run experiments through PostHog's feature flags so the test and the measurement live in the same place. Ship a change behind a flag, roll it to a percentage, and read the result against the same events you already trust. Because the flag and the analytics share one event stream, you avoid the classic trap of an A/B tool that disagrees with your analytics tool.

Use feature flags for safe rollouts even when you are not running an experiment. Releasing a risky change to five percent of accounts first, watching the events and replays, then widening, turns a scary deploy into a controlled one.

Lean on the SQL access for the questions the visual builder cannot phrase. When a stakeholder asks something oddly specific, querying the event data directly is faster than bending three filters around it, and it keeps you from exporting to a spreadsheet that goes stale the moment you close it.

Where it fits your stack

PostHog sits at the centre of the product side of a growth stack. Send the same named events from your backend as well as the browser, so server-side actions (a payment, a provisioning step, an API call) are captured even when no page is open. Wire your data warehouse in both directions: pull PostHog events into the warehouse for blended reporting, and enrich PostHog with revenue or CRM attributes so you can segment behaviour by plan and account value.

On the go-to-market side, the bridge is the company. If your CRM and PostHog agree on what an account is, you can route a product signal (an account hit its usage limit, a power user went quiet) to sales or success at the right moment. That is the join that makes product-led growth actually operable rather than a slogan.

Pitfalls to avoid

The biggest mistake is shipping inconsistent event names. "signup", "Sign Up", and "user_signed_up" for the same action will fragment every chart you build. Agree a naming convention before you instrument anything, write it down, and hold the line.

The second is relying on autocapture for the events that matter. Autocapture is great for exploration and terrible as the foundation for a funnel, because a button's text or position changes and your "event" silently shifts underneath you. Name the events you depend on.

The third is skipping group analytics in a B2B product, then trying to retrofit account-level reporting once you have months of user-only data. Set groups up front.

The fourth is treating session replay as something to binge. It is a targeted tool: watch the sessions behind a specific funnel drop or a specific bug, draw the lesson, and move on. Hours of aimless watching feel productive and teach you little.

INTERVIEW EWOUD: Which PostHog setup do you actually run (cloud or self-hosted), and how do you instrument events: pure named events, autocapture, or a deliberate mix? Walk me through your real identify and group setup for a B2B product.

INTERVIEW EWOUD: What is the one PostHog workflow you rely on most week to week, the funnel, retention chart, or replay loop you open first when you want to know if something is working?

INTERVIEW EWOUD: What is your hard-won tip, the thing you wish you had set up on day one, or the trap you fell into that you would now warn every founder about?

PostHog is an open-source product analytics platform that bundles several jobs into one tool. Beyond the core event-based product analytics (funnels, retention, paths, trends), it ships session replay, feature flags, A/B experimentation, surveys, and a data warehouse layer, so you can watch what users do, replay the session that explains why, and roll out a change behind a flag from the same place. It is developer-first: you instrument with an SDK, model your own events, and query the data directly when the prebuilt views run out of road.

Where it fits

PostHog suits B2B SaaS and product teams that want to understand in-product behaviour, not just marketing-funnel page views. If your questions are "where do new accounts drop off in onboarding", "which feature actually drives retention", or "did this experiment move activation", this is the right shape of tool. It rewards teams with at least some engineering capacity, because the value comes from clean event instrumentation and from being comfortable defining your own events and properties.

It is a weaker fit if you mainly want classic web traffic and channel reporting (a GA-style job), or if you have no one who can own the SDK install and the event taxonomy. Non-technical marketing teams who just want sessions-by-source dashboards will find it heavier than they need, and a pure content site gets less from it than a real application does.

The honest take

The big strength is consolidation: product analytics, session replay, flags, experiments, and surveys in one platform means one source of truth and far less glue between separate vendors. Being open-source (with a self-host option) is a genuine advantage for data ownership and for teams with privacy or residency constraints, and the SDK and API coverage is broad. The fact that you can drop into SQL when the canned reports stop answering your question is a real ceiling-raiser.

The trade-offs are equally honest. The breadth that makes it powerful also makes it sprawling: there is a learning curve, and the surface area can feel like a lot if you only wanted one of the modules. Good answers depend on good event design, so messy instrumentation produces messy analytics, and that is on you, not the tool. Self-hosting is real work, so most teams sensibly run the cloud version and accept that trade. It is a product-analytics engine first, not a replacement for everything in a marketing stack.

INTERVIEW EWOUD: What is your one-line verdict on PostHog, and your rating out of five?

INTERVIEW EWOUD: Is PostHog in your own stack, and if so what do you use it for (and if not, why not)?

INTERVIEW EWOUD: What is the one line you would tell a B2B peer who is weighing it up?

B2B product and engineering teams wanting analytics, replay, and feature flags in one developer-focused stack

PostHog is an all-in-one, open-source product analytics platform that combines product and web analytics, session replay, heatmaps, feature flags, A/B testing, surveys, error tracking, and a data warehouse in one stack. It is aimed at product and engineering teams who want to track user behaviour and ship features without stitching together multiple separate tools. It can be used on PostHog Cloud or self-hosted on your own infrastructure.