Webclat / PostHog Practice

Setting up PostHog for B2B product analytics instead of forcing a B2C model

Person-level analytics answers "what did this user do" - B2B products need "what did this account do," often across a dozen users with different roles. PostHog's customer-analytics layer exists to answer the second question without a workaround built on cohorts alone.

The B2B problem person-level analytics doesn't solve

A B2C product's unit of analysis is usually the individual user. A B2B product's actual unit of analysis is often the account or organization - a deal expands or churns at the account level even though individual users generate the events. Analyzing B2B usage purely at the person level under-counts account health: one power user staying highly active can mask five other seats going dark, and neither shows up clearly in a person-level funnel.

What B2B mode and the customer-analytics layer add

CapabilityWhat it's for
B2B mode (group-level analytics)Rolling up person-level events to the account/organization they belong to, so usage, retention, and funnels can be analyzed at the account level, not just per-user
Customer journeysDefining and tracking the sequence of milestones an account moves through - onboarding, activation, expansion - as a structured object rather than an ad hoc funnel rebuilt each time someone asks
Customer profilesA consolidated view of one account's usage, health signals, and journey stage in one place, instead of a person-level profile that only shows one seat's activity
Dashboard metricsMetrics defined against the account-level model, so a health-score or usage dashboard reflects the same rollup as the rest of customer analytics rather than a separately-maintained person-level version

Cohorts and property filters underneath it all

Account-level analysis still depends on getting person and group properties right at the event level - which account a user belongs to, their role, their plan tier. Cohorts and property filters are how you slice the account-level views (accounts on a specific plan, accounts past a certain usage threshold), and they only produce correct results if those properties were captured consistently in the first place. This is event-architecture work, not a dashboard-configuration task.

How to verify it worked

  1. Pick one known account with multiple users and confirm its rolled-up usage in B2B mode matches the sum of what you'd expect from each user's individual activity - a broken group-identify call produces a rollup that silently under-counts.
  2. Walk one account through a defined customer journey milestone and confirm it advances stage correctly in the journey view.
  3. Check a customer profile against the account's actual known state (a real support ticket, a real usage pattern you already know about) rather than trusting the dashboard on faith the first time.
  4. Confirm a cohort built on account-level properties returns the accounts you'd manually identify as matching - test against a known list, not just a plausible-looking count.

Frequently Asked Questions

Do I need this if my product analytics already work at the person level?

If your product is B2B and you make decisions based on account health, expansion, or churn risk, person-level analytics alone under-represents what is actually happening at the account. B2B mode is worth setting up once that gap starts distorting the numbers stakeholders act on.

What has to be true in my event data before this works?

Every relevant event needs a reliable way to resolve to the correct account/group - typically a group-identify call or a consistent account-ID property. If that was never established consistently, this is an event-architecture fix first, not a dashboard-configuration one.

Get your B2B analytics modeled at the account level.

We fix the group-identify and property discipline first, then build journeys, profiles, and dashboards on top of data that actually rolls up correctly.

Model My B2B Analytics