Account adoption and user adoption defined
Before calculating either rate, define four things: the entity, eligibility, the behavior that counts as adoption, and the time window. Without those choices, an adoption percentage is only a label.
Account adoption
Account adoption is the percentage of eligible active accounts that meet a predefined adoption threshold during a specified period.
Account adoption = eligible active accounts meeting the threshold ÷ all eligible active accounts × 100
An eligible account should be able to use the feature under analysis. An active account should have valid product activity during the period. The adoption threshold should represent the smallest account-level behavior that is meaningful for that feature: for example, a successful integration sync, a completed setup, or at least two team members repeatedly using a collaborative workflow.
Account adoption describes customer spread. It answers questions such as “How many eligible customers reached the feature?” and “How broadly is this capability distributed across our account base?” It does not reveal how many people inside those customers use it.
User adoption
User adoption is the percentage of eligible active users that meet a predefined adoption threshold during a specified period.
User adoption = eligible active users meeting the threshold ÷ all eligible active users × 100
The denominator should contain people who could realistically use the feature—not every user record ever created. For a dashboard intended for managers, eligible users may be active managers. For an administrator-only configuration screen, most contributors and viewers are ineligible and should not lower the user adoption rate.
User adoption describes spread among people across the full eligible population. It combines two effects: whether accounts have reached the feature at all and how many people use it inside those accounts.
User penetration inside adopting accounts
User penetration inside adopting accounts is the percentage of active users within adopting accounts who use the feature.
User penetration = adopting users inside adopting accounts ÷ eligible active users inside adopting accounts × 100
Penetration removes users from accounts that have not adopted the feature. It answers a more focused question: once a customer has reached the feature, how broadly has usage spread among the eligible people in that customer?
These three metrics should normally share the same underlying meaningful behavior. Their entity-level thresholds may differ—for example, one user action can qualify a user while two adopting users qualify an account—but the relationship must be explicit. If account adoption means “opened once” while user adoption means “completed the workflow three times,” the rates cannot be interpreted as two views of the same behavior.
For a deeper treatment of thresholds, eligibility, and denominator design, use the dedicated feature adoption rate guide.
Why B2B products need both account and user adoption
B2B software is usually bought, configured, and renewed by an organization, but used by people. That creates two valid units of analysis.
Account adoption can look healthy while usage depends on one specialist in every customer. User adoption can look healthy while nearly all adopting users belong to one large enterprise account. Neither metric is wrong; each is incomplete on its own.
Among B2B SaaS adoption metrics, this is why account-centric B2B product analytics separates customer reach from user distribution:
- Account adoption shows whether value has spread across customers.
- User adoption shows how many eligible people use the feature across the portfolio.
- User penetration shows how broadly usage has spread inside customers that already adopted.
- Concentration shows whether the apparent adoption depends on one account or one person.
- Repeated use or retention shows whether adoption persists beyond initial discovery.
The correct primary metric depends on the feature, not on a blanket rule that every B2B metric must be account-level.
When account adoption should lead
Account adoption should be the primary metric when one qualified person can create the intended value for the wider account.
Administrator-only integration setup
Suppose an administrator connects a data warehouse and the integration then supplies data to everyone. Requiring broad user penetration would misread the product model: most people should benefit without visiting the integration settings. The better account-level feature adoption threshold might be “the integration completed a successful sync,” with user activity used only to confirm ownership and continuity.
A specialist-owned data export
A finance analyst may export a monthly file that supports an account-wide process. One specialist can be enough. Low user penetration is healthy when the work is intentionally centralized, the workflow repeats at the right cadence, and the account has an appropriate backup owner.
Permission-limited configuration
Billing, security, provisioning, and compliance controls often have intentionally narrow permissions. Measure feature adoption by company or account first, then inspect which role completed the setup, whether it remains operational, and whether responsibility is dangerously concentrated.
Account adoption still does not prove value. Pair it with a feature-specific outcome or continuity signal: successful syncs, recurring exports, completed configuration, error rate, backup ownership, or downstream use.
When user adoption or penetration should lead
User adoption should lead when the intended value is created by individual use across an eligible role. User penetration should lead when broad participation inside each adopting account is part of the outcome.
A communication or task feature for the whole team
Comments, mentions, assignments, and shared task updates depend on other people participating. High account adoption with one active person per account is therefore not enough.
A collaborative reporting workflow
If analysts create reports, managers review them, and teammates discuss decisions in the product, adoption should be evaluated across the eligible roles. Account reach matters, but penetration shows whether the workflow has become shared rather than remaining a champion’s private process.
A dashboard intended for managers
The user adoption rate can be the primary metric, but the denominator should include eligible active managers—not every contributor in the account. Account adoption remains useful for customer spread, and penetration among managers shows rollout inside adopting customers.
Buying and renewal may happen at the account level, but that does not make every feature account-owned. The metric should follow how the feature creates value.
The four account-and-user adoption patterns
Read account adoption on one axis and user penetration on the other. “High” and “low” must be defined relative to the feature’s intended use, eligible population, lifecycle, and historical or segment baseline; there is no universal benchmark.
| Pattern | What it may mean | What it does not prove | What to inspect next |
|---|---|---|---|
| High account adoption, high user penetration | The feature has broad customer reach and broad use inside adopting accounts. Permissions, discovery, and rollout may be working across roles. | It does not prove that use is recurring, valuable, efficient, or causally related to retention. Mandatory or repetitive use can also look broad. | Repeated use, workflow completion, outcome quality, segment differences, support evidence, and whether activity remains healthy after initial rollout. |
| High account adoption, low user penetration | The feature may be specialist-owned, administrator-led, concentrated around champions, blocked by permissions, or only shallowly rolled out. | It does not prove failure. Low penetration can be correct for integrations, exports, billing, security, or other narrow-role workflows. | Intended roles, eligible seats, permission coverage, top-user concentration, backup ownership, second-user activation, and whether one person creates account-wide value. |
| Low account adoption, high user penetration inside adopting accounts | The feature may deliver strong value for a narrow segment, have limited eligibility, be poorly discovered outside that segment, require a prerequisite, or be intentionally specialized. | It does not prove the feature should be pushed to every customer. Broadening reach can be wasteful when relevance is genuinely narrow. | Plan and role eligibility, segment fit, prerequisites, onboarding exposure, discovery outside the strong segment, and whether adjacent segments have the same problem. |
| Low account adoption, low user penetration | Discovery, setup, relevance, permissions, instrumentation, or product value may be weak. The feature may also be too new or measured with the wrong window. | It does not prove the feature is inherently bad or that lack of use has a single cause. | Eligibility and tracking first, then onboarding, setup friction, lifecycle cohorts, segment relevance, qualitative feedback, and sessions around attempted use. |
The matrix is most useful as a routing tool. It tells the product or customer team what to investigate next; it does not diagnose the cause by itself.
Worked B2B example: account reach rises while user adoption falls
The accounts, people, and numbers below are illustrative and entirely fictional.
Imagine a team discussion feature intended for broad project participation. The analysis window is 30 days.
- An eligible active user is a project member who was active elsewhere in the product and had permission to comment.
- A user adopter posted or replied at least twice on two different days.
- An account adopter had at least two eligible users meet that user threshold.
- Qualifying actions are comments and replies from adopting users during the period.
Current-period data
| Account | Eligible active users | Adopting users | Qualifying actions | Most active user |
|---|---|---|---|---|
| Ardent Labs | 4 | 3 | 16 | Nia Cole — 8 actions |
| Beacon Ridge | 6 | 2 | 16 | Omar Singh — 12 actions |
| Cedar Cloud | 10 | 2 | 10 | Lea Martin — 6 actions |
| DeltaWorks | 20 | 0 | 0 | None |
| Everfield | 100 | 25 | 160 | Priya Novak — 90 actions |
| Total | 140 | 32 | 202 | Priya Novak — 90 actions |
1. Account adoption
Four of five eligible active accounts meet the account threshold:
4 ÷ 5 = 80% account adoption
This says the workflow has reached most customers in the small portfolio.
2. User adoption across all eligible users
Thirty-two of 140 eligible active users meet the user threshold:
32 ÷ 140 = 22.9% user adoption
This says fewer than one in four eligible people adopted the workflow across the full portfolio.
3. Penetration inside adopting accounts
The four adopting accounts contain 120 eligible active users: 4 + 6 + 10 + 100. Thirty-two adopted:
32 ÷ 120 = 26.7% penetration inside adopting accounts
This removes DeltaWorks, where the feature has not reached the account at all. It shows that rollout remains narrow even among customers counted as adopted.
4. Concentration in the top user
Priya Novak generated 90 of the 202 qualifying actions:
90 ÷ 202 = 44.6% top-user concentration
This concentration calculation is activity-based. A team could instead use engaged time or completed workflows, but it should choose one unit and label it consistently. Here, almost half of all measured activity comes from one person.
5. The trend tells a different story from any one metric
| Metric | Previous period | Current period | Change |
|---|---|---|---|
| Eligible active accounts | 5 | 5 | No change |
| Adopting accounts | 3 | 4 | +1 account |
| Account adoption | 60.0% | 80.0% | +20.0 percentage points |
| Eligible active users | 100 | 140 | +40 users |
| Adopting users | 35 | 32 | -3 users |
| User adoption | 35.0% | 22.9% | -12.1 percentage points |
| Eligible users inside adopting accounts | 70 | 120 | +50 users |
| Penetration inside adopting accounts | 50.0% | 26.7% | -23.3 percentage points |
| Qualifying actions | 122 | 202 | +65.6% |
Cedar Cloud crossed the account threshold, so account adoption rose from 60% to 80%. At the same time, Everfield’s eligible active population grew from 60 to 100 people while its adopting users fell from 30 to 25. Total actions still rose sharply because activity intensified around a small number of users, especially Priya.
A dashboard showing only account adoption would celebrate wider customer reach. A dashboard showing only total actions would celebrate 65.6% growth. The combined view is more useful: the feature reached one more account, but overall user adoption and penetration fell, and activity became highly concentrated. For a collaborative feature, that pattern deserves investigation.
It still does not prove the workflow is failing. The next questions are whether Everfield’s eligible population is defined correctly, whether permissions changed, whether the workflow is intended for every project member, whether other participants receive value without commenting, and whether the top user is a healthy coordinator or a fragile single champion.
How large accounts distort global user-adoption metrics
Everfield supplies 71.4% of the eligible-user denominator, 78.1% of adopting users, and 79.2% of qualifying actions in the current example. The global user adoption rate therefore describes Everfield more than it describes a typical account.
Without Everfield, the other four accounts have seven adopters among 40 eligible active users:
7 ÷ 40 = 17.5% user adoption
Inside the four adopting accounts, the user-weighted penetration is 26.7%. But if every adopting account receives equal weight, their average penetration is:
(75.0% + 33.3% + 20.0% + 25.0%) ÷ 4 = 38.3%
Neither result is universally “more correct.” The 26.7% rate answers, “What share of eligible people inside adopting accounts used the feature?” The 38.3% average answers, “What is the penetration of the average adopting account when every account receives one vote?” Report the view that matches the decision, and label it.
Same user total, different account distribution
Imagine six accounts with 120 eligible users in total. In both scenarios, 12 users adopt, so global user adoption is 10%.
- In the distributed scenario, two users adopt in each account: account adoption is 6 ÷ 6, or 100%.
- In the concentrated scenario, all 12 adopters belong to one enterprise account: account adoption is 1 ÷ 6, or 16.7%.
The user total is identical. The customer distribution is radically different.
Choose account weighting deliberately
| View | Calculation | Best used for | Main limitation |
|---|---|---|---|
| Unweighted account adoption | Adopting eligible accounts ÷ all eligible accounts | Customer distribution, rollout reach, and the question “How many customers adopted?” | A two-person account and a 2,000-person account receive the same weight. |
| Active-user weighted view | Adopting eligible users ÷ all eligible active users | The share of eligible people using the feature | Large accounts dominate; it can conceal weak customer distribution. |
| Revenue- or contract-weighted account adoption | Revenue from adopting eligible accounts ÷ revenue from all eligible accounts | Commercial exposure, prioritization, or understanding adoption among economically important accounts | One large contract can make adoption look commercially broad even when few customers adopted. It can also turn product measurement into an account-prioritization score. |
Revenue-weighted adoption can be useful for commercial prioritization, but it should not replace the unweighted product-distribution view. Show both under distinct labels rather than blending them into one composite percentage.
A practical minimum scorecard for a multi-user feature is: unweighted account adoption, global user adoption, penetration distribution across adopting accounts, top-account and top-user concentration, and a repeated-use or retention measure.
A practical framework for choosing the primary metric
Use these questions before choosing whether to measure adoption by account or user.
1. Who receives the feature’s value?
If one person performs the work but the whole customer receives the result, account adoption should usually lead. If value is personal, role-specific, or created through participation, user adoption or penetration should lead.
2. Who has permission to use it?
Build the denominator from realistically eligible users and accounts. A low user adoption rate is meaningless when most people cannot access the feature.
3. Does one user create value for the whole account?
If yes, use account adoption as the primary reach metric and inspect continuity, backup ownership, and repeated successful use. If no, do not let one user qualify the account as fully adopted.
4. Is collaboration or broad rollout part of the intended outcome?
If value depends on several people contributing, reviewing, responding, or coordinating, user penetration inside adopting accounts should be a leading metric. Account adoption remains the companion measure of customer reach.
5. Does the customer buy and renew at account level?
This makes account-level reporting commercially important, but it does not settle the feature-level metric. A company can buy at account level while a specific workflow succeeds or fails through user participation.
6. Is the feature optional or universally relevant?
Restrict account eligibility by plan, segment, lifecycle, prerequisite, or use case. A specialized export should not be judged against every customer, and a manager dashboard should not be judged against every seat.
7. What action qualifies as meaningful use?
Choose a behavior that represents the feature’s job: a successful sync, completed export, published report, resolved task, or repeated contribution. Avoid treating a page view as adoption when the workflow requires a meaningful action.
8. Which time window matches the workflow?
Daily windows can underrate monthly reporting or administration. Quarterly windows can hide a broken weekly habit. Match the period to the natural cadence and compare it with an equivalent prior period.
The resulting rule is simple:
- When one or a few authorized users can create account-wide value, make account adoption primary and use penetration as context.
- When broad participation is part of the value, make user penetration primary and use account adoption as the customer-reach companion.
- When the feature serves a specific role, make user adoption among that eligible role primary and keep account adoption to show distribution across customers.
Match the product question to the metric
| Product question | Primary metric |
|---|---|
| How many customers reached the feature? | Account adoption |
| How many eligible people used it? | User adoption |
| How broadly did it spread inside adopting customers? | User penetration inside adopting accounts |
| Does the account depend on one person? | Top-user concentration, backup ownership, and second-user adoption |
| Is global activity dominated by one customer? | Top-account concentration and account-level distribution |
| Did the feature become recurring? | Repeated use, stickiness, or retention at the relevant entity level |
| Is adoption strong only in a particular plan or lifecycle stage? | Segmented account adoption and segmented penetration |
| How much contracted revenue has reached the feature? | Revenue-weighted account adoption, shown alongside unweighted adoption |
Multi-workspace and multi-account products need an explicit entity model
In some B2B products, the commercial account and the operating group are different entities. One contract may contain several workspaces, teams, projects, or business units. A user may also belong to more than one account.
Choose the entity that matches the question:
- Use the commercial account for questions about customer reach, contract exposure, renewal context, or account-level rollout.
- Use the workspace, team, or project for questions about an operational workflow that happens inside that group.
- Report both levels when an account can contain many independent groups. “At least one of 12 workspaces adopted” should not be presented as complete account rollout.
The tracked event should retain the account or group context that was active when the behavior occurred. Do not rely only on a user profile’s current or default account, because the same person may perform the same action in different workspaces. Per-event context preserves where the behavior happened.
The user denominator also needs a declared grain. A global people metric may deduplicate the same human across accounts. An account-penetration metric usually needs user-account or user-workspace memberships, because the person can adopt in one context and not another. Keep the grain explicit in the metric name and documentation.
Common mistakes when comparing account and user adoption
Reporting only user adoption in an account-sold product
A global user number can be dominated by one enterprise customer and hide weak feature adoption by company. Pair it with unweighted account adoption and account distribution.
Reporting only account adoption for a collaborative feature
An account can cross a lenient threshold through one or two people while the intended team workflow never spreads. Add penetration and concentration.
Counting ineligible users or accounts
Users without the role, permission, plan, prerequisite, or realistic need should not lower the rate. Accounts where the feature is unavailable should not enter the denominator.
Allowing one large customer to dominate the global user metric
Always inspect contribution by account, median or distribution of account penetration, and the largest-account share.
Assuming one active user means organizational adoption
One user can indicate discovery, specialist ownership, or champion dependence. Define an account threshold that matches the value model rather than automatically using “at least one user.”
Assuming broad usage always means value
Usage can be mandatory, exploratory, repetitive because of friction, or disconnected from a successful outcome. Pair adoption with workflow completion, repeated use, outcome evidence, and qualitative investigation.
Comparing account and user rates built from different behaviors
“Account opened the page once” and “user completed the workflow twice” are not two levels of the same metric. Use the same underlying behavior or explain the intentional difference.
Using created users instead of realistically eligible active users
Invited, disabled, historical, service, or inactive users can make the denominator grow without representing a real adoption opportunity.
Treating account adoption as proof of renewal
Account adoption is a product-distribution signal. Renewal also depends on value, outcomes, satisfaction, price, procurement, alternatives, relationships, and other factors not established by an adoption rate.
How Hymetry combines account and user adoption
Hymetry connects the account, product, user, and session layers so a team can investigate an adoption pattern instead of stopping at one percentage.
- Start in Companies with an account-level signal, adoption breadth, active-user depth, or a customer whose usage needs review.
- Move to Pages to inspect the relevant product area or grouped page, including account adoption, users, penetration, visits, engaged time, and trend context.
- Open Users to see which people contribute to the pattern, whether usage is broad, and whether activity depends on a small number of champions.
- Use Visits when the metric needs session-level evidence: the path, timing, actions, and replay context behind the signal.
That investigation path supports both product teams deciding where rollout or workflow design needs attention and customer-success teams preparing a more evidence-based account review. The metrics still require human interpretation: Hymetry helps organize the source views; it does not make adoption proof of customer intent or future renewal.
Frequently asked questions
Should a B2B SaaS company measure adoption by account or user?
Usually both. Make account adoption primary when one or a few qualified users can create value for the customer. Make user adoption or penetration primary when value depends on individual or broad team participation. Keep the other metric as a diagnostic.
What is account-level feature adoption?
Account-level feature adoption is the percentage of eligible active accounts that meet a defined feature-use threshold during a specified period. The threshold can be a successful account outcome or a required number of adopting users, depending on the feature.
Is company adoption rate the same as account adoption rate?
Often, yes: “company adoption rate” is commonly used when the company is the commercial account. In multi-workspace products, however, company, account, workspace, and team may be different entities. Name the exact entity in the metric.
Can low user penetration be healthy?
Yes. Low penetration can be correct for administrator-only integrations, billing controls, security configuration, or specialist exports. It is more concerning for communication, task, and collaborative workflows intended for broad participation.
Can account adoption be higher than user adoption?
Yes, but the percentages use different denominators and should not be ranked as if they were the same scale. A feature can reach many accounts through a small number of users in each, producing high account adoption and low user adoption.
Should every licensed seat be included in the user-adoption denominator?
Not automatically. Use eligible active users: people who could realistically perform the meaningful behavior during the selected period. Keep licensed-seat coverage as a separate commercial or rollout metric when it is useful.
How should users who belong to multiple accounts be counted?
For global people adoption, a team may deduplicate the person. For penetration inside accounts, use the relevant user-account or user-workspace membership and preserve the active group on each event. State the grain so readers know what was counted.
Does account adoption predict renewal?
Not by itself. Adoption can contribute useful evidence, but it does not establish satisfaction, realized value, renewal intent, or causality. Treat it as one signal within a broader account review.
Sources
The entity-modeling and instrumentation guidance in this article was informed by the following first-party documentation. The definitions, decision framework, fictional example, calculations, and visual concepts are original to this guide.
- Mixpanel, “Group Analytics: Group users together as an aggregated unit of measurement” — https://docs.mixpanel.com/docs/data-structure/group-analytics
- PostHog, “Group analytics” — https://posthog.com/docs/product-analytics/group-analytics
- Twilio Segment, “Spec: Group” — https://www.twilio.com/docs/segment/connections/spec/group
- Twilio Segment, “Spec: Track” — https://www.twilio.com/docs/segment/connections/spec/track
- Twilio Segment, “Spec: B2B SaaS” — https://www.twilio.com/docs/segment/connections/spec/b2b-saas
- Hymetry, “Pages Analytics” — https://www.hymetry.com/product/pages/
- Hymetry, “Companies: Account Intelligence” — https://www.hymetry.com/product/companies/
- Hymetry, “User Intelligence for B2B SaaS” — https://www.hymetry.com/product/users/
- Hymetry, “Session Visits & Replay” — https://www.hymetry.com/product/visits/