B2B Analytics: When to Measure by User and When by Account

In a B2B product, a single organization may have dozens of users, different roles, and very different activity patterns. That is why a metric such as “active users” cannot, by itself, tell you whether the product is delivering value to the customer. The number may rise because more people joined, even if no one uses a key feature. It may also fall while an account continues to get value through a small group of specialists.

Choosing the unit of analysis—user or account—is not a matter of presentation. It determines which question a metric can answer and which decisions it seems to support. A practical framework is to first define the decision you want to make, identify the entity that experiences the outcome, and establish how observations will be aggregated. In many cases, it makes sense to analyze both units, but not to combine them into a single indicator.

What changes when you measure by user or account

The user unit helps you observe individual behaviors: who logs in, which steps they complete, where they abandon a flow, or which features they use. The account unit, by contrast, represents the customer organization. It helps you assess whether the product has been deployed, whether different teams are adopting it, or whether there is a risk signal at the business relationship level.

Imagine two accounts with ten users each. In the first, nine people complete a useful action; in the second, one person accounts for all the usage. Both may have the same total volume of events, but adoption is different. If the goal is to evaluate breadth of use, total events hide information. If the goal is to understand the workload of a specialist, the average per account may hide it too.

The right metric depends on the question, not on how easy it is to instrument. Document what the numerator represents, the population in the denominator, and what decision would change based on the result.

What questions each unit can answer

Measuring by user is useful when the mechanism behind value or friction occurs for a specific person. For example, it can help you investigate whether people who start a setup process complete it, whether a particular role encounters difficulties, or whether a new experience makes an individual task easier. To compare groups, define them using reliable attributes, such as role or team, and check that the data is up to date.

Measuring by account is better suited to decisions that affect the customer as an organization: prioritizing support, evaluating deployment, or checking whether a capability is reaching the intended teams. Instead of adding up every action, you can build account-level signals such as “at least one user completed setup” or “users from two teams are participating.” The rule should reflect the outcome you want, rather than being chosen for convenience.

• Individual question: Which step in the flow makes activation difficult? Analyze users who started that flow and their completion rate.
• Organizational question: Which accounts have deployed the capability? Count the organizations that meet an explicit deployment criterion.
• Breadth question: Is usage widespread or concentrated? Look at active users per account alongside the size of the eligible group.

Activity, adoption, and friction are not the same

Activity describes actions observed over a period of time; adoption indicates the extent to which a person, team, or account incorporates a relevant capability. Friction occurs when behavior suggests difficulty, but a signal such as abandoning a form does not, by itself, prove why it happened. It may be due to an experience problem, an interruption, or the person not needing to continue.

For activity, define which event counts and over what period—for example, a meaningful action in the last 30 days. Avoid calling someone “active” just because they opened a session if that is not connected to the product’s value. For adoption, establish an action associated with an outcome and decide whether it must be completed by one person, a percentage of eligible users, or a set of roles. For friction, combine quantitative journey data with qualitative research when you need to understand the causes.

A user-level metric can diagnose where a task is failing; an account-level metric can show how many organizations reach the milestone. It is useful to preserve the connection between the two: this lets you move from an aggregated symptom to the people and journeys behind it, while respecting applicable permissions and data policies.

How to aggregate signals without erasing differences

Accounts vary in size, configuration, and distribution of roles. A simple average of activity per account gives a small organization the same weight as a large one; an average across all users can be dominated by accounts with more people. Neither approach is always wrong, but they answer different questions.

Before aggregating, decide what you want to weight:

• Average per account: Describes the typical account when every organization should carry the same weight. Also show the distribution, because a few accounts may be far from the central value.
• Average per user: Describes the typical person in the observed group, but larger organizations carry more weight.
• Share of accounts meeting a criterion: Useful for tracking milestones, provided the criterion and period are defined.
• Distribution within each account: Helps distinguish widespread use from activity concentrated in one person or role.

Avoid comparing rates without checking the denominators. An account with two eligible people is not as stable a measure as one with hundreds. For time series, watch for changes in customer composition: the overall indicator may shift because different accounts joined, not because behavior changed within each one.

Errors that lead to misleading conclusions

The first error is averaging users and presenting the result as if it described accounts. The second is counting an account as active whenever any superficial event meets the rule. That definition can confuse isolated activity with organizational adoption. It is also risky to combine user events with account attributes without a clear time relationship: a person may change teams or leave the organization.

Another problem is comparing accounts with different eligibility criteria. If a feature is available only on certain plans, to certain roles, or with certain configurations, accounts that cannot use it should not be counted as adoption failures. Similarly, excluding them without explanation can inflate the result. Document who is included in the analysis and why.

Finally, do not turn correlation into an explanation. The fact that accounts with more active users renew more often does not prove that increasing activity causes renewal. The relationship may depend on size, use case, or other differences. Use the metric to formulate hypotheses and test them before attributing causality.

A practical model for defining a metric

1. Write down the decision: Specify what action product, business, or operations would take if the value rose or fell.
2. Choose the entity: Identify whether the outcome belongs to a person, a team, or an organization.
3. Define the event or condition: Prioritize signals related to value, not just any recorded activity.
4. Set the population and time window: Clarify who is eligible, what period is observed, and how you handle sign-ups, departures, and role changes.
5. State the aggregation method: Explain whether you are counting, averaging, or calculating a proportion, and how much weight each account receives.
6. Validate edge cases: Check how the metric behaves for small and large accounts, accounts with concentrated usage, and accounts with several teams.
7. Review the interpretation: Ask whether two different business situations could produce the same value. If so, add a breakdown or a complementary metric.

Checklist before publishing

• Does the metric name make clear whether it measures users, teams, or accounts?
• Are the numerator and denominator defined, with a consistent eligible population?
• Does the time window match the product’s usage cycle?
• Are activity, adoption, and friction distinguished?
• Can you detect usage concentrated among a small number of people?
• Could changes in account composition or size affect the comparison?
• Does the metric lead to a concrete decision, and can it be investigated in more detail?

In short, measure by user when you need to understand individual behaviors and experiences; measure by account when the decision concerns adoption or organizational outcomes. For complex B2B products, keep both perspectives and explain how they connect. A well-defined metric does more than summarize what happened: it helps you know what to investigate, who is affected, and what decision makes sense.