How to Model Companies and Users in Product Analytics

A good B2B product analytics model is not the most complicated schema you can design. It is the smallest model that can answer both of these questions without contradiction:

1. Which account or workspace did this activity belong to when it happened?
2. Which person, service actor, or anonymous actor produced the activity?

The core entities in a B2B SaaS data model

The same words often mean different things across products. Define them explicitly before writing an instrumentation plan or choosing database tables.

Company or commercial account

A company or commercial account is the entity that buys, renews, expands, downgrades, or churns. It is usually the unit used by billing, sales, finance, customer success, and contract reporting.

A company might be a legal organization, a customer account in the application, a subsidiary, a franchise owner, or another commercial relationship. The important question is not what you call it. The important question is whether this is the entity whose commercial lifecycle you need to analyze.

Workspace, team, tenant, project, or operating group

A workspace is the environment in which users perform work. Depending on the product, the equivalent term may be team, tenant, organization, project, site, location, portal, or operating group.

One company may have several workspaces. An enterprise contract might cover ten regional workspaces, for example. In another product, each workspace may buy its own subscription and therefore be the commercially relevant account. Do not add a separate company layer merely because a generic data-model diagram includes one.

In this article, “workspace” means an operating context inside the product being measured. It does not imply that every customer must map that entity one-to-one to Hymetry’s own workspace or project administration.

User

A user is the person or service actor performing activity. A stable user record may represent an employee, contractor, consultant, external collaborator, administrator, integration, or another identified actor.

A user is not the same thing as a membership. “Maya exists” and “Maya is a manager in Workspace A from July 20 onward” are different facts with different lifecycles.

Membership

A membership is the relationship between a user and a company or workspace. In a relational model, this is the bridge that supports a many-to-many relationship.

Useful membership properties may include:

• role;
• permissions or permission set;
• status;
• invitation date;
• joined date;
• left date;
• source;
• access mode;
• valid_from and valid_to timestamps.

A membership can change without changing the user’s identity. It can also end while the user record remains valid because the person still belongs to another workspace.

Visit or session

A visit or session is a sequence of activity by one actor within a defined time window and, ideally, one active account or workspace context.

If a user switches workspaces inside the same browser session, either start a new visit for the new context or ensure that event-level workspace context is authoritative. A single visit ID must not cause events from two customer accounts to be blended accidentally.

Event

An event is one observed action with a timestamp, an actor identity when available, and the context needed to interpret the action. Examples include project_created, dashboard_shared, report_exported, or a grouped-page view.

Events are historical facts. Current user and company profiles can enrich those facts, but current profile values should not silently replace what was true at event time.

Product area and grouped page or feature

Product areas and grouped pages are not identity entities, but they are essential analytical dimensions. A product area describes a high-level capability such as Reporting or Administration. A grouped page or feature represents a meaningful workflow such as Dashboard, Reports, Billing, or API keys.

In an account and user analytics model, events connect identity context to the capability being used: who acted, for which account, in which workspace, during which visit, and in which part of the product.

Why one user-to-one-company fails

A static company_id stored only on the user profile is convenient, but it is not a reliable source of historical event attribution.

Consider common B2B cases:

Official group-analytics specifications reflect this separation. Segment’s Group specification distinguishes userId from groupId and explicitly allows one user to be associated with more than one group. Mixpanel requires the group key on an event for group attribution; a group value stored only on the user profile does not automatically attribute that user’s events to the group. PostHog likewise associates an event with a company or other group by passing that group context with the event. See Sources 1, 4, and 6.

The failure mode is subtle. Imagine that Alex worked for Northstar in January and joined Harbor in July. If every report joins January events to Alex’s current company_id = Harbor, January history moves to Harbor even though Harbor was not Alex’s account context when those actions occurred.

The inverse problem also occurs. If a user is currently attached to Northstar but briefly works in an external client workspace, a profile-only model assigns the client event to Northstar. The event may have been captured correctly; the later join corrupts its meaning.

A current company field can still be useful for directory views or defaults. It just cannot be the only source used to attribute historical events. This is the practical challenge behind product analytics for multi-account users: the person remains the same while the active account context changes.

Separate the commercial account from the operating workspace

The company that pays and the workspace where users act are often the same. When they are, one stable ID may be enough. When they differ, forcing both meanings into one field makes billing, adoption, and product-usage reports disagree.

Use these scenarios as a decision guide:

Ask five questions before choosing the model:

1. Who signs, pays, renews, expands, or churns? That is the commercial-account candidate.
2. Where are permissions, data, and work isolated? That is the workspace or operating-group candidate.
3. Can one commercial account own several operating groups? If yes, preserve both IDs.
4. Can a workspace move, split, or be sold? If yes, model ownership as a relationship rather than overwriting workspace identity.
5. Do teams need current hierarchy, historical hierarchy, or both? The answer determines whether parent-child relationships need validity dates and separate reporting views.

Do not insist on a parent-child hierarchy when nobody needs it. A workspace analytics model should be only as complex as the product and reporting questions require.

A practical conceptual model

A useful starting model looks like this:

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 commercially relevant
Event ───> one User when identified
Event ───> one Product area and grouped page or feature when applicable

Likely relationships include:

• Company 1 → many Workspaces;
• User many ↔ many Workspaces through Membership;
• Workspace 1 → many Visits;
• Visit 1 → many Events;
• Event → one active Workspace context;
• Event → one User when the actor is identified.

The exact schema depends on the product. A workspace may be the account. A product may not need a commercial parent. Some service events may have no human user. Some page activity may remain anonymous. The conceptual rule is more important than the table names: identity, membership, operating context, commercial context, and observed behavior should not be collapsed into one mutable profile record.

Preserve event-time account context

Reliable account-level event tracking requires each important event to include, or be resolvable to, the context active when the action occurred.

Depending on the product, that context may include:

• tracking project or application ID;
• user ID;
• anonymous actor ID when the user is not identified;
• company or commercial account ID;
• workspace, tenant, team, project, or operating-group ID;
• membership ID or event-time role when needed;
• session or visit ID;
• event timestamp;
• environment;
• actor type or access mode;
• product area;
• grouped page or feature.

A concise fictional event might look like this:

{
  "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"
}

All values in this example are illustrative.

The company_id and workspace_id describe where this action belonged at occurred_at. They do not mean “whatever company is currently stored on usr_1842.” This distinction is the core of a reliable group analytics data model.

Mixpanel distinguishes event properties that describe a historical event from profile properties that describe a user or group. Its documentation states that tracked events and event properties are immutable. Snowplow similarly recommends keeping its atomic event table immutable and deriving mutable classifications separately. See Sources 5 and 9.

You do not have to copy every mutable membership attribute onto every event. Two patterns can both work:

1. Snapshot the required context on the event. This is useful for properties such as active workspace, access mode, or role when they are essential to common analysis.
2. Resolve context through an effective-dated relationship. Join the event timestamp to the membership or ownership record whose validity range covered that moment.

Whichever pattern you choose, the result must be reproducible later. A query run next month should not silently place the same event in a different account because a profile changed.

Account switching deserves a dedicated test. When a user changes workspace, update the active context before the next event. Do not rely on a stale super property, cached session value, or profile default. If one visit can contain several workspaces, event-level context must win during analysis.

Use stable IDs and keep attributes mutable

The safest join keys are stable identifiers controlled by the system of record.

Segment recommends a database ID rather than an email address or username for userId because emails and usernames can change. The same principle applies to company and workspace identifiers. See Source 2.

An account rename or a user email change should update current attributes without creating a new canonical entity or changing historical joins.

Treat the following as attributes or source-scoped aliases, not universal primary identity:

• display names;
• email addresses;
• email domains;
• workspace slugs;
• SSO subjects;
• CRM IDs;
• billing-system IDs;
• source-system IDs;
• legacy IDs;
• imported aliases.

External identifiers can be valuable, but store them with their source and canonical mapping. For example, an identity-alias record might contain source_system, external_id, canonical_user_id, valid_from, and valid_to. That makes an identity-provider migration, CRM merge, or legacy import auditable instead of turning one external key into a permanent assumption.

When an account or user is deactivated or deleted, do not casually reuse the identifier. Depending on privacy and retention requirements, a system may retain a tombstone or pseudonymized record that preserves referential integrity without retaining unnecessary personal attributes. This is a product, data-governance, and legal-policy decision—not a reason to erase the meaning of historical events accidentally.

Do not infer membership from email domain alone

Email domain can be a review signal, but it is a weak primary identity rule.

It fails for:

• public email providers;
• agencies and consultants working for clients;
• external collaborators;
• acquisitions and brand changes;
• subsidiaries with shared domains;
• companies with several domains;
• users who change email addresses;
• test or forwarding addresses.

A verified domain may help suggest a company during onboarding. It should not silently create a historical membership or overwrite event attribution. Membership should come from explicit application context, authorization data, a trusted source-system relationship, or a reviewed mapping.

Preserve historical memberships

Membership history answers a time-dependent question: which relationship was valid when the event happened?

A useful conceptual record may contain:

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

When a role changes, either version the membership row or keep a separate membership-history table. When a user leaves, close the validity range instead of deleting the relationship as though it never existed.

Type 2 slowly changing dimensions are one common implementation pattern for this problem. dbt’s snapshot documentation describes records that preserve how mutable source rows change over time. This article is not prescribing dbt or a specific warehouse design; the transferable principle is to retain previous states rather than overwrite them. See Source 10.

Past events should normally remain attributed to the company and workspace in which they occurred. If Alex leaves Northstar and joins Harbor, Alex’s earlier Northstar events should not move to Harbor solely because the current membership changed.

Keep current-state and historical-state questions separate:

• Current membership view: Where does Alex belong now?
• Event-time view: Which company and workspace owned Alex’s action on July 16?

Both are useful. They are not interchangeable.

Link anonymous behavior carefully

Before login or signup, an event may have an anonymous_actor_id, visitor ID, device ID, or session ID rather than a known user ID. After authentication, the application may link selected anonymous activity to the identified user.

A careful process is:

1. Assign a pseudo-unique anonymous identifier before identification.
2. Capture page or event activity under that identifier.
3. On a trustworthy authentication or signup event, link the anonymous identifier to the stable user ID according to the analytics system’s supported method.
4. Reset or rotate browser identity on logout when shared-device behavior could otherwise leak into the next user’s history.
5. Treat cross-device stitching as incomplete unless a reliable authenticated identifier connects the devices.

Segment’s Alias specification describes explicit merging of previously unassociated identities. Snowplow documents several user and session identifiers and warns that conflicting identifiers can cause incorrect merges when several users share a device or browser. See Sources 3, 7, and 8.

Do not promise perfect identity resolution. Several people may use one browser. One person may use several devices. Cookies may disappear. An anonymous identifier can be copied or reset. A careless merge can be worse than leaving activity unidentified.

Unidentified activity can still support aggregate page metrics where the methodology permits it. It should not be silently counted as a known company or user. If account context is unknown, keep it unknown rather than guessing from a domain, IP address, referrer, or later profile value.

Plan for account merges, splits, and hierarchy changes

Even a correct initial model will encounter organizational change.

Common cases include:

• duplicate account records are discovered;
• one account splits into several;
• two companies merge;
• a customer is acquired;
• parent-child relationships change;
• a workspace transfers to another company;
• an account is deleted or pseudonymized.

Historical reporting requires an explicit policy. Useful approaches include:

Preserve original event attribution

Keep each event attached to the account and workspace ID captured at event time. This provides the clearest historical record of what the application believed when the event occurred.

Maintain canonical IDs and aliases

Map duplicate or legacy IDs to a canonical entity for selected reports while retaining the original IDs and merge audit. Do not destructively replace every event without a recovery path.

Store effective-dated hierarchy

Represent parent-child ownership with valid_from and valid_to so a workspace or subsidiary can belong to different parents over time.

Provide current and historical reporting views

A current-portfolio view can roll old activity into today’s parent company. A historical-structure view can show the hierarchy that existed at the time. Label the views clearly because they answer different questions.

There is no universal policy. Finance, customer success, product, legal, and data teams may need different views. Decide which interpretation each metric uses, document it, and make merges, splits, transfers, and deletions auditable.

Flag internal, support, and test activity explicitly

Support access can produce real product events in a customer workspace. So can staff impersonation, automated tests, demo accounts, bots, service users, and integrations. The events may be useful evidence, but they should not automatically count as customer adoption.

Useful context fields include:

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

Use the product’s existing naming conventions; the principle is explicit classification.

Do not rely on an ad hoc filter such as “exclude every email ending in our company domain.” That misses service actors, can exclude legitimate customer users, and breaks when staff use alternate identities. An employee supporting a customer should retain the customer workspace context and carry an employee or support flag. Analysis can then exclude the activity from customer metrics while preserving it for troubleshooting or audit.

Event and log data can contain sensitive information. Capture only what the analysis requires, and use masking, exclusion, sanitization, hashing, encryption, or other safeguards where appropriate. OWASP’s logging guidance recommends considering whether sensitive fields should be removed, masked, sanitized, hashed, or encrypted, and it recommends classifying known internal or automated actors rather than simply omitting their events. See Source 11.

Count companies and users correctly

Identity modeling and metric definitions must agree. “Companies” and “users” can refer to several different populations.

A period-level active-company query is conceptually:

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

The same rule applies to users and workspaces.

Do not sum daily unique counts

Suppose Monday has two active companies: Northstar and Lumen. Tuesday also has two: Northstar and Harbor.

• Monday daily unique companies: 2
• Tuesday daily unique companies: 2
• Sum of daily uniques: 4
• Distinct companies across both days: Northstar, Lumen, Harbor = 3

The period total is 3, not 4. The same entity can appear on several days, so daily distinct user or company counts must not be summed to create a distinct total for the selected period. Deduplicate identifiers across the complete period or use another method that is mathematically equivalent.

Multi-account users create another important distinction. Maya can count once in Northstar’s active-user total and once in Lumen’s active-user total, while counting only once in the global distinct-user total. Therefore, the sum of per-company active users can exceed the number of unique people across the product.

For a deeper distinction between account adoption and individual participation, link readers to Account vs. user adoption. For implementation planning, use the product analytics instrumentation plan after choosing the entity model.

Worked example: Northstar, two workspaces, and multi-account users

The following data is entirely fictional and exists only to illustrate the model.

The setup

Northstar is one commercial company with two operating workspaces:

• ws_northstar_ops — Operations;
• ws_northstar_research — Research.

Maya has one stable user ID, usr_maya, and three memberships:

• Northstar Operations, initially member and later manager;
• Northstar Research, viewer;
• Lumen Client Portal, external_collaborator.

Alex belongs to Northstar Research until July 18. Alex then joins Harbor on July 22.

Sam is a platform support employee who impersonates a customer session briefly. Sam’s event carries Northstar workspace context, but also actor_type = employee_support and access_mode = impersonated.

Illustrative timeline

Illustration only

What the simplistic model gets wrong

Assume the application exports events and later joins each event to one current company_id on the user profile.

At the end of the period:

• Maya’s one profile field happens to contain Northstar, even though Maya still has a valid Lumen membership.
• Alex’s current profile contains Harbor.
• Sam is not explicitly flagged as support.

That model would:

• assign Maya’s July 9 Lumen event to Northstar;
• assign Alex’s July 16 Northstar event to Harbor;
• count Sam’s support event as customer activity;
• lose Maya’s event-time role change;
• make Northstar, Lumen, and Harbor metrics depend on whichever company value is currently stored on each user.

The raw event timestamps may be correct, yet the account analysis is wrong because current profile state replaced historical context.

What the context-aware model preserves

The context-aware model keeps every action with its active company and workspace IDs and either snapshots or time-resolves the valid membership role.

For July, it reports:

Illustration only

This model supports both account-level and user-level questions without forcing them to agree artificially:

• Northstar was active in two workspaces.
• Two customer users contributed to Northstar activity.
• Maya also contributed to a different company without moving her Northstar history.
• Alex’s employment change did not rewrite earlier events.
• Support access remained inspectable without inflating adoption.

That is the practical value of preserving event-time account context.

Data-quality checks for the model

Add validation before trusting account-level reports:

1. Every identified event has a valid stable user ID. Reject, quarantine, or explicitly classify malformed identities.
2. Every account-level event has the active account or workspace ID. Do not infer it later from the current user profile when the product already knew the active context.
3. A matching membership exists, or the exception is explicit. Support, service, integration, and administrative events should carry an explainable actor type or access mode.
4. IDs remain stable. Names, emails, slugs, and domains may change without changing canonical identity.
5. The environment is valid. Production, staging, demo, and test activity must be distinguishable.
6. Internal activity is flagged. Test users, bots, automated checks, staff impersonation, and support access should not depend on email-based cleanup.
7. Timestamps are plausible. Check future timestamps, impossible ordering, ingestion delays, and timezone handling.
8. Account switching is tested. The first event after a switch must use the new workspace; cached context must not leak.
9. Historical attribution is stable. Re-running a past-period report after a membership change should not move events unexpectedly.
10. Merges and aliases are auditable. Preserve the original identifier, canonical mapping, change reason, timestamp, and responsible process.

Also test denominators. A correct event model can still produce a misleading adoption rate if test accounts, ineligible plans, deleted accounts, or support-only activity enter the active-company denominator.

Common mistakes

1. Storing company only on the user profile

Problem: Current state replaces event-time context.
Better: Attach or resolve the active account or workspace for each important event.

2. Using email domain as company identity

Problem: Public domains, consultants, collaborators, acquisitions, and subsidiaries create false matches.
Better: Use stable IDs and explicit memberships; treat domain matching as a reviewed onboarding aid at most.

3. Assuming one user has one account

Problem: Multi-account users are forced into an arbitrary “primary” company.
Better: Model the company-user relationship through membership.

4. Rewriting past events after membership changes

Problem: A job change or role update alters historical metrics.
Better: Preserve event-time context or use an effective-dated join.

5. Merging accounts without a historical policy

Problem: Analysts cannot tell whether reports use original or current structure.
Better: Define canonical aliases, historical attribution, current rollups, and an audit trail.

6. Counting support activity as customer usage

Problem: Troubleshooting or impersonation inflates active users, adoption, and engagement.
Better: Retain customer context and add an explicit actor or access-mode flag.

7. Mixing commercial account and workspace

Problem: Renewal metrics and operating usage answer different questions under one ambiguous ID.
Better: Keep both when the buyer and operating unit differ.

8. Using mutable names as join keys

Problem: Renames, duplicate names, and localization break joins.
Better: Join on stable internal IDs and display current names as attributes.

9. Treating anonymous activity as identified

Problem: Guessed merges create false users and false company attribution.
Better: Keep unknown activity unknown until a trustworthy identification event links it.

10. Summing daily unique counts

Problem: The same company or user is counted again on every active day.
Better: Deduplicate IDs across the complete selected period.

11. Deleting identity records needed for historical interpretation

Problem: Past events lose referential meaning.
Better: Follow an explicit retention and pseudonymization strategy that preserves required historical relationships without retaining unnecessary personal data.

How Hymetry connects Companies and Users

Hymetry is account-centric product intelligence for B2B SaaS. Its connected product views reflect the analytical layers described in this article without claiming to solve every possible organizational hierarchy automatically.

• Companies provides the account-level perspective: adoption, active users, product areas, grouped pages, usage movement, and signals that may need review.
• Users shows the individual contributors behind those account patterns, including company context, product usage, and recent visits.
• Pages and product areas show which capabilities those companies and users actually use.
• Visits provides the session-level evidence behind a company, user, or page signal.

The important analytical principle is traceability. An account metric should remain connected to the users and visits that produced it. A user-level change should remain connected to the company, pages, and sessions that give it meaning. This is the same reason a B2B data model must preserve account context on the underlying activity.

Hymetry is designed for identified B2B product usage. Activity without valid company or user identity may still support some page-level analysis, but it cannot provide reliable account- or user-level intelligence. Correct instrumentation and identity context remain prerequisites; Hymetry should not be described as automatically resolving every complex parent-child structure, workspace transfer, or identity collision.

Together, these views form a connected investigation path from account-level signals to individual contributors, product capabilities, and session evidence. See Sources 12–15.

For the broader analytical workflow, read How to Measure Product Usage by Company. It explains how account-level usage becomes useful after the identity and event model is trustworthy.

Frequently asked questions

Should company_id be a user property or an event property?

A current company can be a useful user-profile attribute, but it should not be the only source for historical attribution. Each important event should include the active company_id or workspace_id, or the pipeline must be able to resolve that context as of the event timestamp. If users can switch accounts, event-time context is authoritative.

Do we always need both a company ID and a workspace ID?

No. Use one ID when the commercial account and operating workspace are truly the same analytical entity. Use both when one company owns several workspaces, when billing and permissions operate at different levels, or when workspace ownership can change. Add hierarchy only when real reporting questions require it.

How should a user who belongs to several accounts be modeled?

Keep one stable user record and create one membership per valid account or workspace relationship. Store role, status, and validity on the membership. Attach the active account or workspace context to each event. Do not duplicate the person into unrelated user records merely to preserve a one-to-one schema unless the product intentionally treats those identities as separate.

What happens to past events when a user leaves a company?

Past events should normally remain with the company and workspace in which they occurred. Close the membership’s validity range and update current-state views, but do not reassign history solely because the user joined another company.

Can email domain be used to identify a company?

It can be a suggestion or review signal, especially during onboarding, but it should not be the primary identity model. Public domains, consultants, agencies, subsidiaries, acquisitions, external collaborators, and multiple corporate domains all create exceptions. Use explicit account context and stable IDs.

How should anonymous activity be counted?

Anonymous activity may contribute to aggregate page or session metrics when the methodology allows it. It should not count as a known user or company until a trustworthy identification process links it. Avoid silent merges based on weak signals such as IP address or a later profile value.

How do we count unique companies for a month?

Count distinct eligible company IDs across the complete month. Do not sum daily distinct-company values. The same company may be active on many days and should still count once in the monthly total.

See Companies and Users connected in the Hymetry demo

Open the Hymetry demo to move from a company-level view to the users, pages, and visits behind the same activity.

Sources

The entity-modeling guidance and external product behavior described in this article were checked against the following first-party documentation. The conceptual framework, fictional examples, calculations, and visual concepts are original to this guide.

1. Twilio Segment — Spec: Group
   https://www.twilio.com/docs/segment/connections/spec/group
2. Twilio Segment — Spec: Identify
   https://www.twilio.com/docs/segment/connections/spec/identify
3. Twilio Segment — Spec: Alias
   https://www.twilio.com/docs/segment/connections/spec/alias
4. Mixpanel — Group Analytics FAQ
   https://docs.mixpanel.com/docs/data-structure/group-analytics/group-analytics-faq
5. Mixpanel — Data Model: How Mixpanel data is organized
   https://docs.mixpanel.com/docs/data-structure/concepts
6. PostHog — Group analytics
   https://posthog.com/docs/product-analytics/group-analytics
7. Snowplow — User and session identifiers
   https://docs.snowplow.io/docs/events/identifiers/
8. Snowplow — Unique identifiers and merge conflicts
   https://docs.snowplow.io/docs/identities/concepts/unique-identifiers/
9. Snowplow — Introduction to the atomic events table
   https://docs.snowplow.io/docs/fundamentals/warehouse-tables/
10. dbt Developer Hub — Add snapshots to your DAG
    https://docs.getdbt.com/docs/build/snapshots
11. OWASP Cheat Sheet Series — Logging Cheat Sheet
    https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
12. Hymetry — Companies
    https://www.hymetry.com/product/companies/
13. Hymetry — Users
    https://www.hymetry.com/product/users/
14. Hymetry — Pages
    https://www.hymetry.com/product/pages/
15. Hymetry — Visits
    https://www.hymetry.com/product/visits/
16. Hymetry demo — Companies
    https://app.hymetry.com/projects/demo/companies/
17. Hymetry demo — Users
    https://app.hymetry.com/projects/demo/users/