Behavior qualifies only after context filters it
Behavior — any one pattern can qualify
Product-wide breadth is not mandatory. Several valid patterns qualify.
Context — all of it must hold
Peers need similar role, access, use case, tenure and cadence.
Result
An inspectable behavior pattern
For research, beta selection, enablement or account investigation — not a permanent prestige label.
A product may need analyst, dashboard-review, integration and administrator power-user types. Remove any context term and high activity starts qualifying on its own.
What is a B2B SaaS power user?
| Part | Requirement |
|---|---|
| Eligible | A real customer user with relevant access; exclude staff, support, test, and service identities. |
| Recurring | Behavior occurs across several expected Visits, active days, or periods—not one burst. |
| Role-appropriate | The workflow fits what an administrator, analyst, manager, approver, contributor, or viewer is expected to do. |
| Meaningful | Behavior represents progress, completion, or a useful output rather than an easy-to-count interaction. |
| Broad, deep, advanced, collaborative, or efficient | Several valid patterns can qualify; product-wide breadth is not mandatory. |
| Peer-relative | The comparison group has similar role, access, use case, tenure, account context, and cadence. |
A product may need analyst, dashboard-review, integration, and administrator power-user types. The purpose is an inspectable behavior pattern for research, beta selection, advanced enablement, workflow learning, or account investigation—not a permanent prestige label. Start with meaningful feature use.
Which adjacent roles must remain separate?
Five roles share one observable region and reach different distances past it
Observable from product events
Beyond what any event can establish
Power user
Completion, recurrence, breadth, depth, collaboration, and trend
Satisfaction, advocacy, influence, or authority
Administrator
Setup, integrations, permissions, maintenance, and governance
Business ownership, satisfaction, or budget responsibility
Expert
Advanced successful workflows can suggest skill
Knowledge quality or ability to teach
Champion
Possible clues such as sharing, invitations, and cross-team behavior
Promotion of adoption and internal credibility
Executive sponsor
Sometimes review or approval; sometimes almost no direct use
Budget authority, strategic support, or renewal intent
Solid shows how much of each role product events actually reach; hatched is what stays a claim no matter how much you instrument. Power user and Administrator sit mostly inside — Champion, Expert and Executive sponsor are defined largely by things outside it, which is why activity cannot promote a user into any of them. Bar lengths are editorial, not measured. A quiet specialist can be a power user without championing the product; a rarely active sponsor can be commercially important.
| Concept | What analytics supports | What activity alone cannot establish |
|---|---|---|
| Power user | Completion, recurrence, breadth, depth, collaboration, and trend. | Satisfaction, advocacy, influence, or authority. |
| Champion | Possible clues such as sharing, invitations, and cross-team behavior. | Promotion of adoption and internal credibility. |
| Administrator | Setup, integrations, permissions, maintenance, and governance. | Business ownership, satisfaction, or budget responsibility. |
| Executive sponsor | Sometimes review or approval; sometimes almost no direct use. | Budget authority, strategic support, or renewal intent. |
| Expert | Advanced successful workflows can suggest skill. | Knowledge quality or ability to teach. |
A quiet specialist can be a power user without championing the product. A rarely active sponsor can be commercially important. Keep labels precise when recruiting research or informing account teams. See champion concentration and backup champion identification for those separate questions.
Why do simple power-user rankings fail?
| Shortcut | Actually measures | Why it misleads |
|---|---|---|
| Top 10% by events or clicks | Interaction volume | Retries, navigation loops, repetitive work, automation, and friction inflate it. |
| Most logins or Visits | How often the product was opened | Access does not prove completion or advanced use. |
| Longest engaged time | Observed active time | Long time can mean deep work, difficulty, rework, or a slow process. |
| Most page views | Navigation volume | The user may be efficient, lost, or revisiting the same screens. |
| Broadest URLs | Distinct paths | Dynamic IDs, support, multi-account work, and permissions inflate coverage. |
| Highest one-event use | Concentration around one action | The event may be valuable, repetitive, automated, or over-instrumented. |
If someone can improve the ranking by clicking more, leaving a tab open, or repeating a failed step, the definition rewards activity rather than product capability. Control role, account workload, plan, access, session length, service identities, multi-account users, and instrumentation granularity.
Which dimensions and peer groups should you use?
| Dimension | Example evidence | Guardrail |
|---|---|---|
| Meaningful output | Reports, completed workflows, configured integrations, delivered projects, approvals | Define the outcome before events. |
| Recurrence and consistency | Use across expected Visits or periods | Match daily, weekly, monthly, or quarterly cadence. |
| Relevant breadth | Coherent use across eligible areas | Do not count areas unavailable or irrelevant to the role. |
| Workflow depth | Advanced or complete use inside one important capability | Do not penalize specialists. |
| Collaboration | Sharing, reviewing, approving, publishing, invitations, handoffs | Volume does not prove advocacy. |
| Cross-workflow connection | Import, analyze, publish, and share as one process | Do not reward random feature sampling. |
| Efficiency | Successful completion with few avoidable retries | Shorter is not always better. |
Define peer groups using role, responsibility, permission, plan, use case, account size and lifecycle, user tenure, cadence, and customer-versus-internal identity. See company-level product usage for the account model and peer baselines for cohort construction.
How should you report peer position?
- Show raw value, peer median, spread, peer count, period, role, eligibility, and history for every component.
- Use
IQR = 75th percentile - 25th percentileas one useful spread measure. - One transparent percentile method is
100 x (midrank - 1) / (eligible peers - 1)with average ranks for ties; follow the analytics stack's documented convention when it differs. - A percentile shows relative rank, not gap size. Use an insufficient-data state for few peers, short history, unknown role or eligibility, new features, weak identity, or a recent role or account change.
| Cohort dimension | Why it matters | Fallback when sparse |
|---|---|---|
| Role or responsibility | Creators, approvers, viewers, and administrators have different meaningful work. | Use a broader responsibility family and show the compromise. |
| Permission and plan | People cannot use capabilities they cannot access. | Compare only on shared eligible components. |
| User tenure | New users have fewer opportunities and may be onboarding. | Use an emerging state until minimum history is reached. |
| Account size and lifecycle | Workload and collaboration opportunities differ. | Use wider bands and keep raw values visible. |
| Use case and cadence | Daily operations and quarterly review should not share recurrence expectations. | Normalize by eligible expected periods. |
| Customer versus internal actor | Support and service identities can dominate volume and breadth. | Exclude them from human customer cohorts. |
Publish the eligible peer count after exclusions, not the total population before them. Percentile claims based on six peers should not look as stable as claims based on 200. Where cohort sizes are small, show raw distributions and a provisional interpretation instead of manufacturing precision.
How do you build a transparent power-user classification?
- Gate identity, company, human-customer status, feature access, role, cadence, and minimum history.
- Calculate raw role-specific dimensions.
- Normalize only within the relevant peer group while retaining raw values.
- Assign an explainable pattern such as workflow specialist, broad user, collaboration user, administrator, or emerging user.
- Use a composite score only if it materially helps a review queue.
| Component | Formula |
|---|---|
| Meaningful completion rate | qualified successful outcomes / eligible expected periods |
| Recurring-period rate | expected periods with a meaningful outcome / eligible expected periods |
| Relevant breadth | meaningfully used eligible areas / areas relevant to the role |
| Workflow depth | achieved role-relevant depth points / available depth points |
| Collaboration rate | qualified collaborative outcomes / eligible expected periods |
Depth points need a documented workflow rubric: viewing Reporting might earn none, creating a report one, comparing segments two, and publishing a reusable schedule three.
Optional illustrative composite
completion x 30% + recurrence x 20% + breadth x 20% + depth x 15% + collaboration x 15%, with peer-relative components normalized to 0–100. These are not Hymetry standards. Publish weights, raw values, peer cohort and count, period, cadence, eligibility, history, reasons, and failed conditions. Avoid double-counting correlated components.
| State | Minimum interpretation | Use |
|---|---|---|
| Excluded | Internal, test, service, bot, unsupported identity, or ineligible access | Keep for audit; do not rank with customer people. |
| Insufficient data | Too few eligible periods, peers, or reliable identity fields | Withhold the label and name the missing evidence. |
| Emerging pattern | Strong early role-appropriate behavior without enough history | Monitor or recruit only with human review. |
| Established pattern | Repeated qualifying behavior across enough expected periods | Use for the documented workflow and decision. |
| Changed pattern | One or more components moved outside the entry or exit rule | Investigate the component before relabeling intent. |
Keep the reason codes: for example, “analyst specialist; completion 94th percentile; recurrence 4 of 4 weeks; Reporting depth high; 42 eligible peers.” A bare score cannot explain why the person qualified or whether the label remains appropriate after a role change.
What does the AtlasOps example show?
All users, companies, cohorts, values, percentiles, and interpretations are fictional. The window is 28 days. Analysts and managers have four expected weeks; administrators have three expected periods. A stable label requires 21 days and three periods in this example only.
| User | Role | Observed behavior | Peer result | Interpretation |
|---|---|---|---|---|
| Maya | Analyst | 14 reports, 11 comparisons, 9 shared outputs; 4/4 weeks and areas | 94th of 42 peers | Analyst power user through advanced, recurring, collaborative work. |
| Alex | Administrator | 5 integrations, 8 governance updates, 5 issues resolved; 3/3 periods | 91st of 19 peers | Administrator power user; compare with admins. |
| Jordan | Contributor | 2,480 clicks and 9h40, but 12 completed records, one share, 1/4 areas | 47th meaningful; 99th clicks | Highly active, not currently a meaningful power user; inspect friction. |
| Priya | Manager | 8 reviews, 5 approvals, 3 summaries; 4/4 weeks and 3/3 areas | 89th of 31 peers | Role-appropriate manager power user despite low creation volume. |
| Sam | New analyst | 6 reports, 4 comparisons, 3 shares in two available weeks | Provisional 84th | Emerging; insufficient history for a stable label. |
| Chris | Vendor support | 93 operations across 26 customer accounts | Excluded | Internal support would distort breadth and volume. |
| Lee | Service account | 1,840 automated exports and syncs | Excluded | Automation is not human expertise or engagement. |
Illustrative: seven users, one 28-day window
Maya
Analyst
92.4
14 reports, 11 comparisons, 9 shared outputs · 4/4 weeks and areas
94th of 42 peers
Qualifies — advanced, recurring, collaborative
Priya
Manager
91.9
8 reviews, 5 approvals, 3 summaries · 4/4 weeks, 3/3 areas
89th of 31 peers
Qualifies — despite low creation volume
Alex
Administrator
89.0
5 integrations, 8 governance updates, 5 issues resolved · 3/3 periods
91st of 19 peers
Qualifies — compared with admins, not analysts
Sam
New analyst
86.4
6 reports, 4 comparisons, 3 shares · two available weeks
Provisional 84th
Withheld — insufficient history for a stable label
Jordan
Contributor
44.1
2,480 clicks and 9h40 — but 12 completed records, one share, 1/4 areas
47th meaningful · 99th clicks
Does not qualify — inspect friction instead
Chris
Vendor support
Excluded
93 operations across 26 customer accounts
—
Internal support would distort breadth and volume
Lee
Service account
Excluded
1,840 automated exports and syncs
—
Automation is not human expertise or engagement
All users, values, percentiles and interpretations are fictional. The contrast between Jordan and Priya is the point: raw activity and time can be high while role-relevant capability is ordinary. Scores are the illustrative composite, on one shared scale.
Under the illustrative composite, Maya scores 92.4, Alex 89.0, Jordan 44.1, Priya 91.9, and Sam 86.4 but remains withheld as stable. The contrast between Jordan and Priya is the point: raw activity and time can be high while role-relevant capability is ordinary.
Account context adds another question. Harbor may depend heavily on Maya; OrbitWorks has Priya and an emerging Sam; Cedar has strong human administration through Alex while Lee must remain excluded. A healthy individual pattern can coexist with fragile account concentration.
How do you validate a power-user definition?
Validate the framework before it drives research recruitment, beta access, enablement, or account workflows. Start with a labeled sample reviewed by product, data, customer-facing specialists, and people who understand the underlying job.
- Sample qualifiers, near-threshold users, ordinary users, excluded identities, and sparse-data cases.
- Trace each component to raw events, grouped features, Visit context, role, and eligibility.
- Check whether retries, required administration, automation, support work, or large account workload inflate the result.
- Compare the behavioral explanation with interviews, observation, or customer-team knowledge where appropriate.
- Measure how entry and exit change when the window, peer cohort, threshold, or component weight changes.
- Document false positives, false negatives, and groups systematically excluded by instrumentation.
| Validation question | Failure signal | Adjustment |
|---|---|---|
| Does the label identify successful role-appropriate work? | High-click failure loops qualify. | Strengthen completion or outcome requirements. |
| Can specialists qualify without broad use? | Deep expert users fail because they use one area. | Create a specialist pattern or role-specific breadth. |
| Do new users receive fair treatment? | Strong onboarding behavior is labeled stable too early. | Add minimum history and an emerging state. |
| Are administrators compared fairly? | Maintenance cadence looks inactive beside daily analysts. | Use admin peers and opportunity-based periods. |
| Can a reviewer explain every result? | Only a composite score is visible. | Expose raw components, peer context, and reason codes. |
A label that changes drastically under small reasonable choices is not ready for automation. Use it as an exploratory segment, gather more evidence, and stabilize the definition before expanding its operational use.
- Check consequences by role and account type. If nearly every administrator qualifies but few analysts can, privileged maintenance events may be winning. Large-account workload and incomplete assistive-technology instrumentation can create similar distortions.
- Test the intended decision. Research recruiting needs variety; a beta may require relevant permission and depth; enablement may need emerging capability instead of the highest existing expertise.
- Assign an owner and review date. Record taxonomy version, peers, minimum sample, window, entry and exit rules, blind spots, and override reasons.
- Monitor control counts. Eligible users, excluded identities, insufficient-data share, entries, exits, overrides, and cohort sizes often expose modeling change before behavioral change.
- Audit alternate workflows. Keyboard navigation, assistive technology, mobile use, APIs, delivered outputs, and efficient expert paths may emit fewer conventional interactions. Confirm that the meaningful completion evidence captures valid work across supported channels before interpreting lower event volume as lower capability.
- Review sparse cohorts manually. When role-specific comparison groups remain small, retain raw values and reason codes, withhold a precise percentile, and revisit the classification after more eligible periods or peers become available.
How should the segment be used and maintained?
- Recruit users for research only after a person reviews the evidence and role.
- Offer advanced onboarding or betas based on the matching workflow, not one global leaderboard.
- Investigate falling components without treating a daily label change as intent.
- Use entry and exit rules or multi-period confirmation so monthly and quarterly behavior is not relabeled every day.
- Validate expertise, satisfaction, advocacy, influence, and outcomes through interviews, account records, or direct observation.
| Change to monitor | Review |
|---|---|
| Role, permission, plan, account, or lifecycle change | Re-evaluate eligibility and peer cohort before interpreting behavior. |
| Feature launch or product-map change | Version breadth and depth rules; avoid an unmarked series break. |
| Instrumentation or event-volume shift | Reconcile components and check for duplicated or missing evidence. |
| Peer cohort becomes small or skewed | Broaden carefully, withhold a percentile, or use raw distributions. |
| User enters or exits the segment | Require the documented number of periods and record the component reason. |
Broad use, deep specialist use, collaboration, advanced administration, and efficient completion can all be valid. Track the component history, role changes, account moves, eligibility, and enough expected periods.
In Hymetry, begin in Users, inspect relevant areas in Pages, check distribution in Companies, and open selected Visits. That evidence supports a transparent team-defined framework; it does not prove psychology, authority, or business impact.
Frequently asked questions
What qualifies someone as a SaaS power user?
Recurring, role-appropriate, meaningful behavior that is unusually broad, deep, advanced, collaborative, or efficient versus relevant peers.
Is the top 10% of active users a good segment?
Not alone. The cutoff is arbitrary and raw activity can reflect friction, automation, support, and unequal access.
Is a power user the same as a champion?
No. Power use is behavioral; advocacy and influence require evidence beyond activity.
Can an administrator be a power user?
Yes, through advanced recurring setup, integration, permission, or governance work compared with relevant administrators.
How much history is required?
Enough to observe several expected workflow periods; daily, weekly, monthly, and quarterly products need different rules.
Should time spent enter the definition?
Only as supporting context. Long time can indicate deep work or avoidable difficulty.
Can a narrow specialist qualify?
Yes. Deep, successful, recurring use of one important workflow can be more meaningful than broad product use.
Sources
Methodology and limitations
Sources support measurement, cohort, distribution, and data-quality principles. The fictional framework does not establish that power users predict satisfaction, advocacy, retention, renewal, or expansion.
Source directory
- Hymetry demo Users view
- Hymetry workflow for product teams
- Hymetry workflow for UX research
- Google research on the HEART framework and author PDF
- OECD composite-indicator handbook and PDF
- NIST percentile guidance
- NIST measures of location
- NIST measures of scale
- Amplitude behavioral cohorts
- Amplitude stickiness guidance
- Mixpanel cohorts documentation
- Google Analytics cohort exploration
- Twilio Segment Group specification
- PostHog analytics best practices
- Google Analytics internal-traffic filtering
- Google Analytics bot-traffic exclusion
- Nielsen Norman Group product UX benchmarking
- Nielsen Norman Group on satisfaction and performance
