PostHog

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.