How to Identify Power Users in B2B SaaS

What is a power user?

A practical B2B SaaS power user definition is:

Each part of that definition matters.

Not every product needs one universal power-user definition. A reporting platform may have analyst power users, dashboard-review power users, integration power users, and administrator power users. A specialist product may have valuable power users who work deeply inside one narrow capability and rarely visit the rest of the application.

The goal is not to create a permanent prestige label. The goal is to identify an inspectable behavior pattern that is useful for research, product learning, advanced onboarding, beta selection, workflow analysis, or account investigation.

For the underlying behavioral definition, start with meaningful feature use rather than whichever events are easiest to count.

Power user, champion, administrator, sponsor, and expert are not synonyms

One person can occupy several roles, but product activity alone should not be used to infer all of them.

A power user may also be an administrator and champion. Another power user may be a quiet specialist who never promotes the product. An executive sponsor may use the product once a month and still be crucial to the account. Preserve these distinctions when naming segments, recruiting research participants, and sharing findings with account teams.

For a separate treatment of advocacy and dependency, use the guides on champion concentration and finding backup product champions.

Why simple power-user definitions fail

The easiest definitions are often the least useful.

Raw activity is especially vulnerable to distortion. Official analytics guidance treats internal and bot traffic as explicit filtering concerns.¹²¹³ Other distortions include:

• different user roles;
• account size and workload;
• repetitive manual processes;
• interface friction or retries;
• long-running product sessions;
• background or programmatic behavior;
• internal support and implementation users;
• automated service identities;
• one high-volume workflow;
• different plans, permissions, or feature access;
• users who move between many customer accounts;
• instrumentation that emits several events for one outcome.

A useful diagnostic is simple: if a user can improve the “power-user” ranking by clicking more, leaving a tab open, or repeating a failed step, the definition is rewarding activity rather than value.

Research on large-scale UX metrics also supports separating engagement from satisfaction and task success. Increased activity may have more than one interpretation, and time can be positive or negative depending on the task.¹¹⁵ Treat volume and time as evidence to inspect, not as a verdict.

Candidate dimensions for identifying power users

A good framework begins with a small set of dimensions tied to the product’s real workflows. Not every product should use every dimension.¹¹

A mature definition usually combines several of these dimensions. For example, a user might qualify because they repeatedly complete a deep specialist workflow and share the resulting output, even though they use only two product areas. Another user might qualify through broad, coherent use across five areas without using the most technically advanced feature.

Power-user definitions should differ by role

Role context prevents a creation-heavy definition from misclassifying users who receive value through review, approval, governance, or administration.

Prefer a confirmed role from product or account data. When the role is unknown, preserve an unknown state or use a cautious behavioral cohort. Do not infer organizational authority from product activity.

Compare users with relevant peers, not the whole project

A percentile is only as useful as the group behind it. Comparing an administrator at a mature enterprise account with a new viewer at a small onboarding account says little about either person.

Useful peer dimensions include:

• role or responsibility;
• feature eligibility and permissions;
• plan;
• product use case;
• account size;
• account lifecycle or onboarding stage;
• user tenure;
• expected workflow cadence;
• region or operating model when it materially changes use;
• customer users versus internal, support, test, or service identities.

Behavioral cohort tools commonly combine actions with user or account properties for this reason.⁶⁸⁹ In B2B SaaS, user identity should also remain connected to the company or account rather than being analyzed in isolation.¹⁰ See how to measure product usage by company for the underlying account model.

Show the distribution, not only a rank

For each component, show at least:

• the user’s raw value;
• the peer median;
• an indication of spread, such as the interquartile range;
• the peer count;
• the comparison period;
• the role and eligibility conditions;
• whether the user has enough history.

Median and interquartile range are often more useful than mean and standard deviation when activity data has a long tail or a few extreme users.⁴⁵

Use the average rank for ties. This formula is illustrative; use the repository or analytics stack’s documented percentile implementation if one already exists. Published statistical guidance documents several percentile-estimation conventions, which is another reason to name and preserve the method a team chooses.³

A percentile describes relative position, not the magnitude of the difference. A user at the 90th percentile may be only slightly above the 80th percentile in a tightly clustered distribution, or dramatically above it in a long-tailed distribution. Keep the raw values and distribution visible.

Use an insufficient-data state

Do not force a mature classification when:

• the peer group is too small for a stable comparison;
• the user has not experienced enough expected periods;
• role or feature eligibility is unknown;
• a newly launched feature has too little history;
• identity quality is uncertain;
• the user recently changed roles or accounts.

Set a product-specific minimum history based on expected cadence. Do not use one universal number of days for daily, weekly, monthly, and quarterly products. Display the peer count and insufficient data state rather than manufacturing precision.

A top 5%, 10%, or 20% cutoff is a product choice, not a natural law. The threshold should follow the intended use, the cost of false positives, the size of the peer group, and the actual distribution. The same threshold does not need to apply to every role or power-user type.

For a deeper treatment of cohort selection and distributions, use peer baselines for B2B SaaS.

A transparent power-user evaluation framework

Use a staged framework so the classification can be explained and challenged.

Step 1: Apply identity and eligibility gates

Before calculating anything, verify:

1. The identity represents a human customer user.
2. The user belongs to the correct company or account.
3. Internal staff, vendor support, test users, and service accounts are excluded or placed in separate cohorts.
4. The user has access to the product areas being evaluated.
5. The role and expected cadence are known well enough to interpret behavior.
6. The user has enough history for the intended classification.

A score should never turn an ineligible identity into a power user.

Step 2: Calculate inspectable raw dimensions

Possible raw measures include:

Depth points should come from a documented workflow rubric. For example, opening Reporting might receive no depth credit, creating a basic report might receive one point, comparing segments two points, and publishing a reusable scheduled report three points. The exact rubric depends on the product and role.

Consistency can remain a separate visible check: did the behavior recur across the expected periods, or did one temporary burst produce most of the volume?

Step 3: Normalize components within relevant peers

Raw measures have different units. Convert them to comparable component values only after the peer cohort is defined. Percentile ranks are one option. A bounded role-specific rubric is another.

Do not normalize all users against one global distribution when roles, access, and cadence differ. Document the method and retain the original raw values.

Step 4: Classify a power-user pattern

Allow several inspectable power-user types instead of one universal leaderboard:

• Workflow specialist: unusually high meaningful completion and depth inside one important capability.
• Broad product user: recurring, coherent use across several relevant product areas.
• Collaboration power user: meaningful outputs repeatedly shared, reviewed, approved, or used by others.
• Administrator power user: advanced, recurring configuration, integration, permission, or governance work.
• Emerging power user: breadth, depth, or recurrence is growing quickly, but long-term history is still insufficient.

A person may match more than one type. The type should explain the behavior rather than act as a commercial status symbol.

Step 5: Use a weighted score only when it adds value

A composite score can help sort a review queue, but it should not replace the dimensions.

The following is an illustrative model only:

Each component in this example is normalized to a 0–100 peer-relative value.

These weights are not a Hymetry standard and should not be treated as a benchmark. Weighting is a product judgment. Equal weights are still weights, and different normalization or weighting choices can change rankings. Avoid double-counting two components that measure nearly the same behavior.²

Whenever a score is shown, also show:

• each component value;
• the raw metric behind it;
• the peer cohort and peer count;
• the period and expected cadence;
• eligibility and history status;
• the reason for the classification;
• which conditions were not met.

A user should never have to be reverse-engineered from one opaque number.

Worked B2B example

The following example is fictional. All names, companies, data, cohort sizes, percentiles, component scores, and interpretations are illustrative.

Assume a fictional B2B analytics product called AtlasOps. Its relevant product areas are Reporting, Dashboards, Collaboration, Data connections, and Administration.

The evaluation window is 28 days. Analysts and managers have a weekly expected cadence. Administrator recurrence is based on three expected administration periods in the window rather than daily use. A stable label requires at least 21 days of history and three expected periods in this example. Those settings are illustrative product choices, not universal thresholds.

Observed behavior

Fictional illustration

Peer comparison and interpretation

What the illustrative score would show

Using the optional example weights:

Fictional illustration

The contrast between Jordan and Priya is the point. Jordan has the most clicks and longest observed engaged time, but little depth, breadth, or collaboration. Priya creates less, yet repeatedly completes the manager workflow, covers every relevant area, and shares or approves outputs used by others.

The score does not establish that Maya, Alex, or Priya is satisfied, skilled enough to train others, influential inside the account, or willing to join a beta. It only summarizes the behavioral definition used in this fictional example.

Account-level interpretation

The same users also produce different account questions:

• Harbor Analytics appears dependent on Maya for advanced analysis. That may be a concentration issue even though Maya’s individual use is healthy. Maya’s activity does not prove that she is the account champion.
• OrbitWorks has a manager power user and a rapidly developing analyst. That suggests a more distributed workflow, but Sam still needs more history.
• Cedar Systems has strong human administration through Alex. Lee’s automated activity must be excluded so it does not inflate account adoption or user activity.

Power-user analysis becomes more useful when it leads to account investigation rather than a global leaderboard.

Breadth and depth are both valid

A power user does not need to use the entire product.

Treating broad use as universally superior can hide specialists who create substantial value. Treating deep use as automatically healthy can also be misleading if the user is trapped in repetitive work or lacks access to related capabilities.

The right question is not “How much of the product did this person touch?” It is “Does this pattern represent unusually capable, recurring use of the workflows relevant to this person?”

Inspect power users inside the account

B2B product use belongs to a company as well as an individual. A power-user label becomes more useful when paired with account context.

Questions to inspect include:

• Is the account dependent on one power user?
• Are several relevant users active?
• Does the power user cover the workflows expected at this lifecycle stage?
• Do other users receive outputs, collaborate, review, or approve?
• Is the user a likely workflow owner, or only a high-volume participant?
• Are backup users gaining breadth or depth?
• Is the account mature, newly onboarding, or changing its use case?
• Is broad account activity actually driven by an internal or automated identity?
• Did the account grant different users different feature access?

One power user can make an account look active while the rest of the team has not adopted the product. Several role-appropriate power users can indicate a more distributed operating model, but even that does not prove account health, renewal intent, or business impact.

Use product usage by company to connect individual behavior to account adoption. Use the separate guides on champion concentration risk and backup product champions when the main question is dependency rather than power-use definition.

Track change without making the label unstable

Power use changes over time. Useful states include:

• Emerging power user: meaningful breadth, depth, collaboration, or recurrence is growing, but the history is still short.
• Stable power user: the relevant pattern persists across enough expected periods.
• Declining power user: meaningful completion, depth, collaboration, or recurrence has fallen relative to the user’s own established pattern and relevant peers.
• Narrowing power user: the user remains active but stops using previously important workflows or product areas.
• Role-transition user: the person’s responsibilities changed, so the old peer group is no longer appropriate.
• Account-transition user: the person moved between companies, teams, or workspaces and should not have incompatible contexts blended together.

Compare equal-length current and previous periods. Preserve the role, feature eligibility, account, and cadence used in each comparison. For percentage metrics, use percentage-point changes where appropriate.

Do not automatically downgrade someone because a low-frequency workflow did not occur in one short period. A quarterly administrator task cannot be judged by one quiet week. Likewise, a temporary reporting deadline can create a burst that should not instantly become a stable label.

The classification should change when the underlying evidence changes—not whenever a single count moves.

How teams can use a power-user classification

A careful classification can support:

Product teams can use the segment to investigate sophisticated use cases through the product-team workflow. UX researchers can combine behavioral evidence with screening and consent through the UX research workflow.

Risks and guardrails

Avoid:

• repeatedly contacting the same visible users;
• assuming power users represent average or struggling users;
• designing only for experts;
• assigning customer-facing status or commercial value from behavior alone;
• exposing private individual rankings;
• rewarding event volume instead of meaningful outcomes;
• treating the label as proof of satisfaction or advocacy;
• using the label as a renewal or expansion prediction;
• triggering automated customer communication without human review;
• ignoring users who are new, low-frequency, or unable to access advanced features.

For research and beta recruitment, use the classification as one screening input. Confirm role, relevance, willingness, and availability before contacting anyone.

Validate the interpretation beyond analytics

Product data can directly show only what was captured and how the definition processed it. It cannot directly establish:

Useful validation sources include:

• customer interviews;
• account-team knowledge;
• support history;
• research screening;
• confirmed role and permissions;
• observed workflow quality;
• relevant outcomes where measurable;
• session evidence reviewed in context.

Analytics can make the investigation more focused. It should not replace the investigation.

Common mistakes when identifying power users

1. Using event count alone. Replace raw volume with role-appropriate outcomes and inspectable dimensions.
2. Using time spent alone. Long engaged time can mean complex work, rework, delay, or friction. Interpret it with completion and task context.
3. Defining power users as a fixed top percentage. A percentile cutoff is a product decision, not a universal benchmark.
4. Comparing administrators with viewers. Build relevant peer groups and role-specific definitions.
5. Ignoring feature eligibility. Do not penalize users for capabilities they cannot access or are not expected to use.
6. Counting internal, support, test, or service users. Exclude them or analyze them in clearly separate cohorts.
7. Treating broad usage as universally better. Breadth matters only across relevant, coherent product areas.
8. Treating deep specialist use as narrow or unhealthy. A specialist may be a legitimate power user even with low breadth.
9. Equating power users with champions. Advanced use does not prove advocacy or influence.
10. Assuming power users are satisfied. Engagement, satisfaction, and task success are different measurement questions.
11. Selecting only current volume without recurrence. Require enough expected periods to distinguish a pattern from a burst.
12. Ignoring account concentration. One power user can coexist with weak adoption across the rest of the company.
13. Hiding the definition inside an opaque score. Keep components, peer context, history, and reason codes visible.
14. Treating new users as non-power users before enough history exists. Use an emerging or insufficient-data state.
15. Using the segment to design only for advanced users. Research novice, occasional, struggling, and role-limited users separately.

How Hymetry connects user behavior to account and product context

Hymetry’s connected product model can support power-user investigation without pretending that activity reveals a person’s psychology or organizational authority.

The investigation path is:

Start in Users to inspect an individual’s active days, Visits, observed engaged behavior, pages or product areas used, current and previous periods, and company context where those fields are available in the current implementation.

Then open Pages to see whether the behavior is broad across relevant product areas, deep inside one grouped workflow, or concentrated around raw activity that needs interpretation.

Next, open Companies to ask whether the pattern is distributed across the account, concentrated around one person, appropriate for the account’s lifecycle, or connected to missing workflows.

Finally, use Visits when session-level evidence is needed. A Visit is a user session and can show the path and captured interaction context behind an unusual pattern. One Visit should not be treated as proof of a general cause; use it to inspect evidence identified by the aggregate pattern.

Hymetry can show behavioral evidence such as:

• who was active;
• which grouped pages and product areas were used;
• how observed engaged behavior changed;
• how current and previous periods compare;
• which company the user belongs to;
• which other users contribute to the account pattern;
• which Visits are relevant to review.

That evidence can support a team-defined, transparent power-user framework. It cannot automatically prove expertise, advocacy, satisfaction, influence, or business impact.

A practical checklist

Before using a power-user segment

• Have we defined which human customer users are eligible?
• Have we excluded internal, support, test, and service identities?
• Are the behaviors tied to meaningful role-specific outcomes?
• Is recurrence measured at the product’s expected cadence?
• Can a specialist qualify through depth without artificial breadth?
• Is breadth limited to relevant, eligible product areas?
• Are users compared with an appropriate peer group?
• Do we show raw values, median or distribution, peer count, and history?
• Is there an insufficient-data or emerging state?
• Are component values and classification reasons visible?
• Have we separated power use from champion, sponsor, satisfaction, and influence?
• Is a human reviewing the label before research, communication, or account action?

Frequently asked questions

What qualifies someone as a power user in SaaS?

A SaaS power user is an eligible user whose recurring, role-appropriate behavior shows unusually broad, deep, advanced, collaborative, or efficient use compared with relevant peers. The definition should be tied to meaningful workflows rather than raw events.

How do you identify power users in product analytics?

First exclude ineligible identities. Define meaningful outcomes by role, measure recurrence, relevant breadth, depth, collaboration, and consistency, then compare those components within an appropriate peer cohort. Keep the raw values and reason for classification visible.

Is the top 10% of active users a good power-user segment?

Not by itself. The top 10% is an arbitrary product choice, and activity volume can reflect repetitive work, friction, automation, support behavior, or different access. Inspect the distribution and meaningful component values before choosing a threshold.

Is a power user the same as a product champion?

No. A power user demonstrates high or advanced product use. A champion promotes adoption and may influence colleagues or stakeholders. One person can be both, but advocacy and influence require validation beyond activity data.

Can an administrator be a power user?

Yes. An administrator can qualify through advanced, recurring setup, integration, permission, or governance work. Compare administrators with relevant administrators, not with analysts, contributors, or viewers.

How much history is needed before labeling a power user?

Enough history to observe several expected workflow periods. The correct minimum depends on product cadence. Daily, weekly, monthly, and quarterly products should not use the same rule. Until enough history exists, show an emerging or insufficient-data state.

Should time spent be part of a power-user score?

It can be supporting context, but it should not determine the label. Long time may represent valuable complex work or avoidable difficulty. Short time may represent efficiency or shallow use. Interpret observed engaged time with completion, depth, and workflow context.

Can a narrow specialist be a power user?

Yes. In a specialist product or role, deep, successful, recurring use of one important workflow may be more meaningful than broad use across the entire product.

How often should a power-user classification update?

Update it on a cadence appropriate to the workflow and compare equal-length periods. Avoid daily label changes for monthly or quarterly behavior. Preserve role, account, eligibility, and history context when evaluating change.

Sources

These sources support the measurement, cohort, distribution, and data-quality principles in this guide. They do not establish that power users necessarily predict satisfaction, advocacy, retention, renewal, or expansion.

1. Google Research — Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications, Kerry Rodden, Hilary Hutchinson, and Xin Fu, CHI 2010. https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications/ Author PDF: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36299.pdf
2. OECD and European Commission Joint Research Centre — Handbook on Constructing Composite Indicators: Methodology and User Guide. https://www.oecd.org/en/publications/handbook-on-constructing-composite-indicators-methodology-and-user-guide_9789264043466-en.html PDF: https://www.oecd.org/content/dam/oecd/en/publications/reports/2008/08/handbook-on-constructing-composite-indicators-methodology-and-user-guide_g1gh9301/9789264043466-en.pdf
3. NIST/SEMATECH e-Handbook of Statistical Methods — 7.2.6.2. Percentiles. https://www.itl.nist.gov/div898/handbook/prc/section2/prc262.htm
4. NIST/SEMATECH e-Handbook of Statistical Methods — 1.3.5.1. Measures of Location. https://www.itl.nist.gov/div898/handbook/eda/section3/eda351.htm
5. NIST/SEMATECH e-Handbook of Statistical Methods — 1.3.5.6. Measures of Scale. https://www.itl.nist.gov/div898/handbook/eda/section3/eda356.htm
6. Amplitude Docs — Identify users with similar behaviors. https://amplitude.com/docs/analytics/behavioral-cohorts
7. Amplitude Docs — Stickiness: Identify the features that drive users back to your product. https://amplitude.com/docs/analytics/charts/stickiness/stickiness-identify-features
8. Mixpanel Docs — Cohorts: Group users by demographic and behavior. https://docs.mixpanel.com/docs/users/cohorts
9. Google Analytics Help — [GA4] Cohort exploration. https://support.google.com/analytics/answer/9670133?hl=en
10. Twilio Segment Documentation — Spec: Group. https://www.twilio.com/docs/segment/connections/spec/group
11. PostHog Docs — Product analytics best practices. https://posthog.com/docs/product-analytics/best-practices
12. Google Analytics Help — Filter out internal traffic. https://support.google.com/analytics/answer/10104470?hl=en
13. Google Analytics Help — Known bot-traffic exclusion. https://support.google.com/analytics/answer/9888366?hl=en
14. Nielsen Norman Group — 7 Steps to Benchmark Your Product’s UX. https://www.nngroup.com/articles/product-ux-benchmarks/
15. Nielsen Norman Group — User Satisfaction vs. Performance Metrics. https://www.nngroup.com/articles/satisfaction-vs-performance-metrics/