In Mixpanel, what does Group Analytics let you measure that user-level events cannot?
answer
- users are not always the paying unit
- B2B accounts have many seats
- a second counting unit for reports
- a declared key on the events
- account funnels, not seat funnels
basics
~10 sGroup Analytics counts accounts rather than individuals. With a group key such as company id on the events, funnels and retention report how many organisations converted or came back, not how many seats did.
solid answer
~50 sMixpanel's default unit of analysis is the user identified by `distinct_id`, which answers the wrong question for B2B products: a customer is a company with many seats, and one power user can make an account look healthy. Group Analytics adds a second unit. You nominate a group key in project settings — `company_id`, say — make sure events carry it, and Mixpanel can then compute funnels, retention and segmentation over distinct groups instead of distinct users. The client library helps: `mixpanel.set_group('company_id', 'acme')` attaches the key to subsequent events, and `mixpanel.get_group('company_id', 'acme').set({ plan: 'enterprise' })` writes properties onto a group profile the way `people.set` does for a user. It is a paid add-on rather than a core feature, and it only works retroactively for events that already carried the key — so instrument the group id early even if you are not licensed yet.
code
javascript · 9 lines// Declare company_id as a group key in project settings first
mixpanel.set_group('company_id', 'acme');
mixpanel.track('Workspace Created'); // carries company_id
mixpanel.get_group('company_id', 'acme').set({
plan: 'enterprise',
industry: 'logistics'
});go deeper
Know that Mixpanel normally counts users, and that Group Analytics adds an account-level counting unit driven by a group key on the events.
Explain the wiring — a declared group key, set_group attaching it to events, get_group().set() writing group profile properties — and why server-side events must set it explicitly.
Judge when the add-on earns its cost, insist the account id is instrumented from day one because attribution is not retroactive, and be careful presenting group-level conversion next to user-level.
Own the definition of the account across product, billing and analytics: one canonical identifier, an agreed position on hierarchies and account merges, and clarity on which unit executive reporting is denominated in.
## The problem it solves Mixpanel counts users. For a consumer product that is the right unit — one human, one account, one customer. For a business product it is misleading in both directions. An account with two hundred seats where one admin logs in daily looks, in a user-level retention report, like a handful of retained users among many dormant ones; the account itself is at risk and the chart does not say so. Conversely a single enterprise deal is worth more than ten thousand free individuals, but user-level counts weight them the other way round. Group Analytics introduces a second analysis unit alongside the user, so the same event stream can answer 'how many *accounts* completed onboarding' as well as 'how many *people* did'. ## How it is wired The mechanism is deliberately simple. You declare one or more **group keys** in the project's settings — a property name such as `company_id` or `workspace_id`. Any event carrying that property can be attributed to a group. Reports then offer the group as the counting unit, so a funnel measures distinct companies moving through the steps and retention measures companies returning. The client library provides the plumbing: ```javascript mixpanel.set_group('company_id', 'acme'); // attach to later events mixpanel.add_group('company_id', 'acme-eu'); // a user in several groups mixpanel.get_group('company_id', 'acme') .set({ plan: 'enterprise', industry: 'logistics' }); ``` `set_group` registers the key so it rides along on subsequent events from that client, in the manner of a super property. `get_group(...).set(...)` writes to a **group profile** — the account-level analogue of a user profile, with the same mutability caveat: one current value per key, no history, so a report segmented by a group profile property reads today's value for all past events. Server-side tracking has no client state, so the group key must be set explicitly on every event payload. Since the group id usually comes from the same session context as the user id, the practical pattern is a shared tracking wrapper that stamps both. ## What it changes in the reports A funnel counted by group asks whether *any* member of the account performed each step, in order — so the admin who creates the workspace and the engineer who invites the team together complete an account-level activation funnel that neither user completed alone. Retention by group asks whether the account showed any activity in a later period. Segmentation can break accounts down by group profile properties such as plan, industry or contract value. That difference in semantics matters when interpreting the numbers: group-level conversion is almost always higher than user-level conversion for the same funnel, because the account only needs one qualifying member per step. Presenting the two side by side without saying which is which is a reliable way to mislead a leadership review. ## Limits and cautions First, **it is a paid add-on** and its availability depends on the plan; do not design a reporting strategy around it without confirming entitlement. Second, **it is only as good as the instrumentation**. Events tracked before the group key was attached have no group and are invisible to group-level reports; there is no way to infer the account retroactively short of deleting and re-importing the range with the key attached. Adding the group id to every event from the start costs nothing and preserves the option. Third, **groups are not hierarchies**. A group key is a flat attribute. Modelling organisation → workspace → team means several group keys or a denormalised property, not a nested structure, and the more of them you declare the more instrumentation discipline you need. Fourth, group membership is an event-time fact when carried on events and a current-state fact when stored on a group profile — the same point-in-time versus current-value distinction that applies to users. A seat that moved between accounts is not retroactively re-attributed. ## When to reach for it If your commercial unit is an account — B2B SaaS, seats, workspaces, teams — group-level funnels and retention track the thing that actually renews, and the feature is worth the add-on. If you sell to individuals, it is overhead. Either way, put the account identifier on your events now: instrumenting it is cheap and reversible, and re-creating it later is not.
- Why is a group-level funnel conversion rate usually higher than the user-level one for the same steps?Because the account only needs one qualifying member per step. An admin who completes setup and an engineer who invites the team together complete an account-level funnel that neither finished individually. Presenting the two figures without labelling which unit is counted is a common way to mislead a review.
- You enable Group Analytics today. What can you say about last year's accounts?Nothing, unless those events already carried the group key. Attribution comes from the property on the event, and there is no retroactive inference — recovering the history would mean deleting and re-importing the range with the key attached. This is why the account identifier belongs on events from day one, licensed or not.
- How would you model an organisation containing several workspaces?With separate group keys, or by denormalising the parent identifier onto the events; a group key is a flat attribute and does not express a hierarchy. Each extra key adds instrumentation surface that must be populated consistently on client and server, so declare only the levels you will actually report on.
User-level analysis counts the individual visitors to a shop; group analysis counts the households they came from — and it is the household that holds the account.
saying these in an interview costs you the question
- Thinks Mixpanel infers the account from the user's email domain
- Expects group reports to cover events tracked before the key existed
- Treats group profile properties as point-in-time history
- Assumes group keys nest into a hierarchy
- Believes Group Analytics is included on every plan