TL;DR
- In B2B SaaS, PostHog setup should start from activation, retention, expansion, and account-level questions, not a generic event dump.
- The minimum viable setup is a documented tracking plan, account-level grouping, a standard property model, and a first dashboard set tied to actual review rituals.
- The most common failure is tracking lots of clicks but missing the events that define value delivery, team adoption, and account health.
- This guide covers the setup order ProductQuant uses: question map, event taxonomy, group analytics, implementation, QA, dashboards, and governance.
PostHog makes it easy to start collecting data. That is useful, but it also creates a trap. Teams end up with a large event stream and very few answers.
In B2B SaaS, the analytics job is not just to record activity. It is to make four decisions easier: are users activating, are accounts retaining, are key features being adopted, and which behaviors actually connect to expansion or contraction?
That is why the setup sequence matters. If naming, grouping, and dashboard design are left until after implementation, the team gets a technical install but not a usable analytics system.
What Good PostHog Setup Looks Like
For B2B SaaS, the target is not a perfect event universe on day one. The target is a decision-ready first layer that can support onboarding, product, customer success, and leadership reviews.
| Layer | What it includes | Why it matters |
|---|---|---|
| Question map | Activation, retention, adoption, and revenue questions | Prevents vanity instrumentation |
| Tracking plan | Named events, trigger rules, properties, owner, QA notes | Becomes the single source of truth |
| Group analytics | Accounts, workspaces, clinics, teams, or orgs as first-class entities | Without this, B2B analysis stays user-level and misleading |
| Dashboard set | Activation, retention, feature adoption, revenue signals, QA | Turns raw data into operating visibility |
| Governance | Change log, naming rules, quarterly taxonomy audit | Prevents the setup from degrading as the product evolves |
That is the difference between a PostHog install and a PostHog system. The first captures data. The second changes decisions.
The Setup Sequence We Use
1. Start with the operating questions
Before naming a single event, write down the questions each function needs answered every week. Product may need first-value drop-off and feature adoption. Customer success may need account-level risk signals. Leadership may need stickiness, activation by segment, and expansion-linked behavior.
If an event cannot eventually support one of those questions, it should not be priority-one instrumentation.
2. Define the core object model
Most B2B SaaS products have a user, an account, and one or more core objects such as projects, forms, workspaces, documents, submissions, or integrations. The tracking plan has to reflect that model. Otherwise, the data ends up describing clicks without describing product value.
3. Design the event taxonomy before implementation
The tracking plan should specify event name, trigger rule, properties, expected source, dashboard use, and QA notes. This is where most messy PostHog instances fail. Engineering builds what seems obvious, while product assumes the naming and properties will somehow be queryable later.
4. Set up group analytics early
In B2B SaaS, the account is often the real economic unit. An individual user can look inactive while the account is healthy, or vice versa. PostHog group analytics lets you attach events to companies, teams, clinics, or workspaces so retention and expansion analysis reflects the real customer structure.
The cleanest setups usually track fewer events initially than bad setups. They just track the ones that map directly to activation, adoption, account health, and revenue questions.
5. Build the first dashboards only after QA
Dashboards should be downstream of instrumentation and QA, not a substitute for them. If property null rates are high or events are firing inconsistently, the dashboard simply hides the tracking problem behind polished charts.
The Day-One Tracking Plan for B2B SaaS
The exact list changes by product, but the first usable PostHog setup usually includes these event groups.
Account and identity events
- User signed up
- User invited teammate
- Workspace or account created
- Plan changed
Activation path events
- First core object created
- First integration connected
- First workflow completed
- Activation milestone reached
Adoption and depth events
- Feature used
- Template saved or duplicated
- Dashboard or view customized
- Team collaboration event triggered
Account health and revenue events
- Usage threshold crossed
- Support issue tied to product friction
- Upgrade requested or plan expanded
- Billing failure or contraction signal recorded
The goal is not to max out event count. The goal is to make sure the entire value path is observable from first use to account-level outcomes.
Get the tracking plan sheet and setup checklist
The CSV gives you a ready-to-fill event tracking plan. The checklist gives you the sequence ProductQuant uses to move from blank PostHog instance to decision-ready setup.
Why Group Analytics Matters So Much in B2B SaaS
PostHog can show you person-level behavior quickly. That is useful, but it is not enough when buying, onboarding, adoption, and retention happen at the account level.
Without group analytics, teams usually make three mistakes:
- They judge retention based on a handful of active users instead of overall account health.
- They miss collaborative adoption, where value only appears after multiple roles are active in the same account.
- They cannot tie product behavior cleanly to expansion or contraction because billing happens at the account level, not the user level.
In practice, this means you should define a group key early, decide which account properties belong on that group, and make sure core events are consistently attached to both the user and the account entity.
The First Dashboards Worth Building
The first dashboard set should mirror the real operating cadence. In most B2B SaaS environments, that means:
- Activation dashboard: sign-up to first-value path, segmented by source, persona, and account type.
- Feature adoption dashboard: which major workflows are discovered, repeated, and retained.
- Retention and risk dashboard: cohort health, drop in usage, and leading churn indicators.
- Revenue signal dashboard: usage linked to plan movement, expansion triggers, and contraction risk.
- Data-quality dashboard: missing properties, event drops, and unknown events.
This is one reason the setup guide and the dashboard templates article are separate. The templates piece covers which dashboards to create. This guide covers what has to be true in the setup before those dashboards can be trusted.
The PostHog Setup Mistakes We See Most Often
Over-relying on autocapture
Autocapture is useful for discovery, QA, and some behavioral clues. It is not a substitute for a real taxonomy. If the value path depends on custom product actions, those actions need explicit instrumentation.
Event names without property discipline
Teams often debate event names and ignore property quality. But a clean event with inconsistent plan, role, segment, or object properties still produces weak analysis.
No link between dashboards and decisions
A dashboard nobody owns is not a dashboard. For each first dashboard, define who reviews it, how often, and what kind of decision it should support.
No taxonomy governance
As products evolve, analytics rots unless someone owns the change log, deprecations, naming conventions, and audit cycle. This is why the setup checklist includes governance, not just implementation.
Build the dashboards only after the setup can support them
If you want the practical dashboard layer that sits on top of this setup, start with the template pack.
FAQ
How many events should a B2B SaaS team track initially?
Enough to cover identity, activation, core workflow usage, adoption depth, account health, and revenue movement. For many teams, that means a focused initial set rather than a huge uncontrolled list.
Can PostHog work for account-level B2B analysis?
Yes, if group analytics is designed intentionally. If you stay only at the person level, the setup will miss how accounts actually adopt, retain, and expand.
What should be documented in the tracking plan?
At minimum: event name, trigger rule, owner, source, required properties, sample payload logic, dashboard use, and QA notes. Otherwise implementation and analysis drift apart.
Is autocapture enough for an initial setup?
No. It can complement the setup, but value moments, activation milestones, and account-health signals almost always require explicit instrumentation.
About the Author
Jake McMahon writes about product analytics, Product DNA, and the growth operating systems that make activation, retention, and expansion measurable. ProductQuant helps B2B SaaS teams turn messy instrumentation into decision-ready systems.
If PostHog is installed but still not settling the important questions, the setup is incomplete.
The fix is usually not more dashboards. It is a better tracking plan, cleaner grouping, stronger QA, and a first dashboard set tied to real decisions.