How to Model Companies and Users in Product Analytics

The goal is the smallest B2B product analytics model that can answer, without contradiction: which account owned this activity when it happened, and which person or service actor produced it?

Which entities belong in a B2B product model?

Product area and grouped feature are analytical dimensions rather than identity entities. Together they answer who acted, for which account and workspace, during which Visit, and in which part of the product.

Write one sentence defining each entity in product language and one sentence defining its reporting use. If Company and Workspace always resolve to the same stable object, one identifier may be enough. Add a separate level only when the product or commercial relationship genuinely needs it.

Why does one user-to-one-company modeling fail?

A static company_id stored only on the user profile cannot reliably attribute historical events.

Segment, Mixpanel, and PostHog group models all separate the user from group context. A current company profile can still support a directory or default selection; it cannot be the only historical attribution source.

Also separate the commercial account from the operating workspace when they answer different questions:

• One company and one workspace may need only one ID.
• One enterprise contract with ten workspaces needs both company_id and workspace_id.
• One subscription per workspace may make the workspace the commercial account.
• Parents, subsidiaries, franchises, locations, or transferable workspaces need explicit, possibly effective-dated ownership.

Ask who pays and renews, where data and permissions are isolated, whether one buyer owns several groups, whether ownership can change, and whether reports need current hierarchy, historical hierarchy, or both.

What does a practical conceptual schema look like?

Company (commercial account)
  1 ---< many Workspaces

User
  many >---< many Workspaces through Membership

Workspace
  1 ---< many Visits

Visit
  1 ---< many Events

Event ---> one active Workspace context
Event ---> one Company context when relevant
Event ---> one User when identified
Event ---> one Product area or grouped feature

The names and tables can differ. The invariant is that identity, membership, operating context, commercial context, and observed behavior are not collapsed into one mutable profile.

How should events preserve account context?

Every important event should include, or be reproducibly resolvable to, the active company, workspace, actor, Visit, timestamp, environment, actor type, product area, and grouped feature.

{
  "event": "dashboard_shared",
  "occurred_at": "2026-07-29T10:14:22Z",
  "project_id": "project_014",
  "user_id": "usr_1842",
  "company_id": "company_0298",
  "workspace_id": "workspace_041",
  "membership_role": "manager",
  "visit_id": "visit_7711",
  "product_area": "Reporting",
  "grouped_page": "Dashboard",
  "actor_type": "customer",
  "environment": "production"
}

The IDs describe where the action belonged at occurred_at, not whatever company is currently stored on the user. Either snapshot essential context on the event or join to the effective-dated membership valid at that timestamp. The answer must remain reproducible next month.

When a person switches workspace, update context before the next event. If one browser Visit can cross workspaces, event-level context must be authoritative.

Define attribution precedence for disagreements. A trusted event-time workspace usually outranks the user's current default; a valid supplied Visit context outranks a stale browser property; and an effective-dated membership can enrich an event only when the membership was valid at that timestamp.

How should identity and membership history be maintained?

Names, emails, and domains are poor join keys. They change, collide, are shared, and do not represent memberships. Use them as attributes or reviewed onboarding suggestions, not silent historical attribution.

membership_id
user_id
workspace_id
role
permissions
status
source
invited_at
joined_at
left_at
valid_from
valid_to

Version a membership or keep a history table when role, access, or status changes. Close its validity range rather than deleting it. Type 2 slowly changing dimensions and dbt snapshots are possible implementation patterns; preserving the previous state is the transferable requirement.

Link anonymous behavior only after trustworthy authentication or signup, using the analytics system's supported identity method. Rotate browser identity on logout when devices may be shared. Do not merge people or companies from IP address, domain, or another weak signal.

How should organizational change and non-customer actors work?

Merges, splits, acquisitions, hierarchy changes, workspace transfers, and deletions need an audit policy. Preserve original event attribution; maintain canonical IDs and aliases for selected current reports; effective-date ownership; and label current-portfolio versus historical-structure views.

Do not destructively rewrite all events without a recovery path. Product, finance, customer success, legal, and data teams may need different views of the same organizational history.

actor_type: customer | employee_support | service | integration | bot | test
access_mode: normal | impersonated | support
environment: production | staging | demo | test
is_internal: true | false
is_test: true | false

Support and automation events can remain available for audit without entering customer adoption. Avoid an email-domain-only exclusion; it misses service identities and can remove legitimate customers. Capture only necessary data and apply masking, sanitization, hashing, encryption, or exclusion to sensitive fields.

How do you count companies and users correctly?

COUNT(DISTINCT company_id)
for eligible production customer activity
across the complete selected period

Do not sum daily uniques. If Monday has Northstar and Lumen and Tuesday has Northstar and Harbor, daily counts sum to four but the two-day distinct total is three.

One multi-account person can count in several company-level user totals but only once globally. State whether the grain is people, memberships, or account-user contributions. The account versus user adoption guide explains the analytical consequences; the instrumentation plan guide covers implementation.

What does the Northstar example prove?

All companies, users, events, and dates are fictional.

• Northstar has three customer events, two active customer users, and two active workspaces.
• Sam's support event is retained but excluded from customer usage.
• Alex's July 16 action remains Northstar history after Alex joins Harbor.
• Maya's July 3 event keeps the member role; July 21 keeps the manager role.
• Maya and Alex are two global people, but Northstar, Lumen, and Harbor contain four account-user contributions.

These results are possible only because events retain account context, memberships have validity, and actor classification remains separate from the workspace being supported.

How do you validate and use the model?

• Test account switching, multi-membership users, role changes, departures, and workspace transfers.
• Confirm every event's company, workspace, actor, Visit, environment, and timestamp are valid.
• Reconcile raw event counts with excluded support, service, bot, demo, and test activity.
• Verify current and event-time queries intentionally differ where history changed.
• Check uniqueness, orphan memberships, overlapping validity ranges, stale context, and daily-unique summation.

Run these cases in staging and on a small production sample after identity, account-switching, hierarchy, or tracking changes. Keep raw event IDs and attribution-source flags so a failed aggregate can be traced and corrected.

Hymetry connects Companies, Users, Pages, and Visits so an account total can be traced to people, product areas, and sessions. See the companion guides to company-level usage and the B2B instrumentation plan.

Frequently asked questions

Should company_id be a user or event property?

A current company can enrich a profile, but event-time company or workspace context must drive historical attribution.

Do we always need company and workspace IDs?

No. Use both only when commercial and operating entities differ or ownership can change.

How should a multi-account user be modeled?

Keep one stable person, one membership per valid relationship, and the active context on each event.

What happens when a user leaves?

Close the membership validity range; normally keep past events with the company and workspace where they occurred.

Can email domain identify a company?

It can suggest a reviewed mapping, but public domains, consultants, subsidiaries, acquisitions, and multiple domains make it unsafe as the identity model.

How should anonymous activity count?

It may enter anonymous aggregate metrics, but not a known user or company until a trustworthy identification process links it.

How do we count unique monthly companies?

Count distinct eligible company IDs across the whole month; never sum daily distinct values.

Sources