How should adoption breadth and depth be defined?
There is no single industry-standard formula. Google HEART separates adoption from engagement proxies such as frequency and intensity; Amplitude, Pendo, and Gainsight use breadth and depth in related but different ways. A defensible report therefore names its unit and definition.
| Dimension | Definition used here |
|---|---|
| Account breadth | Coverage of relevant product areas or grouped capabilities within one account. |
| User breadth | Coverage of capabilities relevant and available to one person. |
| Depth | Meaningful intensity, recurrence, completion, or quality inside an adopted capability. |
| User penetration | Share of eligible people participating in a capability. |
| Concentration | Share of activity dependent on one user or a small group. |
Frequency can sit within depth or remain separate. Keeping it visible helps distinguish one burst of activity from a recurring workflow.
Agree on the vocabulary before building a dashboard. If one team calls the number of adopted features depth while another calls it breadth, the chart may be numerically correct and still produce the wrong action.
| Report field | Minimum published context |
|---|---|
| Breadth | Entity, eligible area set, adopted-area count, percentage, threshold version, and window |
| Depth | Component values by area, expected cadence, completion rule, and any cap or normalization |
| Penetration | Eligible roles and users, adopting users, account treatment, and weighting |
| Concentration | Underlying activity measure, top-user share, contributor count, and exclusions |
How do you calculate adoption breadth?
Account adoption breadth
relevant product areas adopted by the account
/ relevant product areas available to the account
x 100
User breadth
relevant capabilities used by the person
/ relevant capabilities available to that person
x 100
Show the adopted-area count beside the percentage. “Three of five relevant areas” exposes the denominator and remains understandable when accounts have different eligible sets.
Build breadth from meaningful product structure:
Defensible hierarchy
Product area
→ Grouped page or feature
→ Normalized raw page
For example, Reporting may contain a Scheduled reports capability supported by paths such as /reports/:id/schedule. Counting list, detail, edit, and confirmation routes separately inflates breadth without proving more value.
What belongs in adoption depth?
Depth has no universal equation. Choose components that describe successful work inside the capability: meaningful actions, active days, recurrence, completion, useful outputs, and product-appropriate advanced use.
| Component | Question | Caveat |
|---|---|---|
| Meaningful-action volume | How much relevant work was completed? | Different workflows have different natural volumes. |
| Active days and recurrence | Did use repeat at the expected cadence? | A monthly workflow should not be judged daily. |
| Completion and outputs | Did the workflow reach a useful endpoint? | Not every outcome creates a saved object. |
| Advanced use | Did the account use specialized capability? | Advanced does not automatically mean valuable. |
| Engaged time | How much observed active time occurred? | More time can mean productive work or friction. |
A composite score can give equal totals to one-day volume, steady completion, and repeated failed attempts. Prefer a component profile. Pair intensity with completion or output evidence, and inspect selected sessions when the metric cannot explain the difference.
A compact depth profile can show four fields per area: meaningful outcomes, active or successful periods, completion rate, and contributors. Add engaged time or an advanced-use marker only when it answers a real product question. Keeping the fields separate makes a high-volume failure loop visibly different from repeated successful work.
- Use counts beside rates so small denominators remain visible.
- Report zero, unavailable, not applicable, and insufficient opportunity as different states.
- Retain the Visit or event evidence behind unusual depth so the aggregate can be checked.
How do eligibility and thresholds change the result?
The eligible set should contain capabilities genuinely available and applicable during the period. Exclude areas unavailable on the plan, irrelevant to the use case, intended for another role, blocked by prerequisites, or not yet released.
Eligible product areas
plan availability
∩ use-case relevance
∩ role or account access
∩ period availability
Version eligibility changes. An upgrade, new prerequisite, lifecycle step, or release can change the denominator and create a trend that is not behavioral.
A page opening proves reach, not adoption. Qualifying behavior might be a completed action, successful setup, use in multiple Visits, repeated active days, an end-to-end completion, or a saved, shared, scheduled, or exported output. Document the entity, eligible denominator, behavior, and window for every area. The feature adoption formula guide covers those choices in more detail.
| Product area | Illustrative adoption threshold | Why one rule would fail |
|---|---|---|
| Reporting | Create or materially edit a report and save, share, schedule, or export it in two expected periods. | A view can be passive; a one-time export can be exploratory. |
| Integrations | Complete a successful connection, or perform a documented maintenance check when already connected. | One-time setup should not require weekly recurrence. |
| Approvals | Complete an approval or rejection in at least two eligible workflow cycles. | Opportunity depends on role and incoming work. |
| Administration | Complete a required permission, policy, or governance task during an eligible period. | Low frequency is normal when no administrative change is needed. |
Store the threshold version with the result. A product-map change or newly released area can change both numerator and denominator even when customer behavior is identical.
What do the four breadth-and-depth patterns mean?
Narrow breadth
Broad breadth
Deep
Recurring meaningful work
Narrow breadth
Narrow and deep
Focused specialist value — or missed adjacent opportunities
Inspect: the customer's job, eligibility, use case, backup ownership
Broad breadth
Broad and deep
Several relevant areas produce recurring, meaningful work
Inspect: outcomes, role coverage, concentration, avoidable effort
Shallow
Entry without follow-through
Narrow breadth
Narrow and shallow
Early lifecycle, low cadence, setup issues, weak fit, or disengagement
Inspect: lifecycle, prerequisites, window, instrumentation, research
Broad breadth
Broad and shallow
Discovery or onboarding spread without follow-through
Inspect: completion, return use, setup friction, area relevance
None of the four is healthy or unhealthy on its own. Each one names a different next question.
| Pattern | Possible reading | Inspect next |
|---|---|---|
| Broad and deep | Several relevant areas produce recurring, meaningful work. | Outcomes, role coverage, concentration, and avoidable effort. |
| Broad and shallow | Discovery or onboarding spread without follow-through. | Completion, return use, setup friction, and area relevance. |
| Narrow and deep | Focused specialist value or missed adjacent opportunities. | Customer job, eligibility, use case, and backup ownership. |
| Narrow and shallow | Early lifecycle, low cadence, setup issues, weak fit, or disengagement. | Lifecycle, prerequisites, window, instrumentation, and research. |
Account breadth is not user breadth. Administrators, analysts, managers, and finance users can collectively cover a product while each person remains specialized. The reverse is also possible: one power user covers everything while the rest of the account is inactive. See the account versus user adoption guide for choosing the reporting grain.
What does a worked B2B example show?
All data below is fictional. Assume a 30-day operations product with six areas. An area qualifies after an area-specific action in two Visits, or after a successful one-time setup where recurrence is not expected. A page open does not qualify.
Top-user concentration
meaningful actions by the most active user
/ meaningful actions by all contributing users
x 100
| Account | Breadth | Depth evidence | Users / concentration | Interpretation |
|---|---|---|---|---|
| Atlas Labs | 5 of 6 (83%) | 1,260 actions; 18 days; four areas in three weeks | 14 / 31% | Broad and deep, with concentration still worth checking. |
| Northstar Works | 1 of 5 (20%) | 640 actions; 20 days; specialist workflow on 16 days | 3 / 58% | Narrow and deep; may match a focused use case. |
| Beacon Systems | 4 of 6 (67%) | 28 actions; four days; no reuse after week one | 11 / 18% | Broad exploration without recurrence. |
| Meridian Group | 1 of 4 (25%) | 12 actions; two days; only eight days into onboarding | 2 / 75% | Insufficient lifecycle evidence. |
Depth · recurring meaningful use →
Breadth · share of eligible product areas adopted →
Beacon covers more areas than Northstar and does far less with them. Meridian is only eight days into onboarding — the position is not yet evidence of anything.
Atlas's 83% does not show that Reporting and Integrations are deeper than Automations, or that 31% of actions came from one user. Northstar's low breadth does not establish poor health if Reporting is its intended job. Beacon needs investigation after discovery; Meridian needs onboarding context.
Atlas Labs
Breadth
83%
5 of 6 eligible areas
Contributing users
14
across five areas
Top-user share
31%
391 of 1,260 actions
Active days
18
of 30 in the window
What the 83% hides
Two areas carry 62% of the work, Automations and Administration barely recur, and one user produces nearly a third of everything. Same breadth number, three different conversations.
How should you track change and weighting?
- Newly adopted areas: current set minus previous set.
- Retained areas: intersection of current and previous sets.
- Dropped areas: previous set minus current set.
- Breadth change: current percentage minus previous percentage, reported in percentage points.
Use comparable periods and a window long enough for the slowest important cadence. A quarterly workflow can disappear from a 30-day view without being abandoned. Show absolute depth values beside percentage change; moving from five to eleven actions is 120% growth but only six additional actions.
Set transitions are often more actionable than one net percentage. If an account retained Reporting and Integrations, newly adopted Automations, and dropped Projects, the net area count may stay unchanged while the product mix changed materially. Show the current, retained, new, and dropped sets with the threshold version that produced them.
| Movement | Check before acting |
|---|---|
| New area | Was the capability newly available, newly relevant, or genuinely adopted? |
| Retained area | Did it maintain recurrence and completion, or only barely meet the threshold? |
| Dropped area | Did expected opportunity exist, and did taxonomy or eligibility change? |
| Unchanged breadth | Did one area replace another, or did depth and participation change? |
Unweighted breadth is easiest to audit. If areas genuinely differ, adjusting the eligible set by use case, role, or lifecycle is usually clearer than complex weights. When weighting is necessary, use sum of weights for adopted eligible areas / sum of weights for all eligible areas x 100, publish every weight, version changes, and keep the underlying areas visible.
How do you turn the profile into action?
- Define eligible areas and meaningful thresholds.
- Select a window that observes expected cadence.
- Show breadth count and percentage, then depth components by area.
- Inspect contributing users, roles, penetration, and concentration.
- Compare relevant lifecycle, use-case, plan, and prior-period context.
- Review selected Visits only when the aggregate pattern needs explanation.
Avoid raw-page counts, universal benchmarks, opaque scores, friction-rewarding time metrics, and taxonomy changes without a series break. In Hymetry, move from account breadth in Companies to areas in Pages, contributors in Users, and evidence in Visits. See the broader guides to B2B product analytics and company-level product usage, or the product-team and customer-success workflows.
Frequently asked questions
What is product adoption breadth?
The count or share of relevant capabilities that meet documented adoption thresholds for a named entity and period.
What is product adoption depth?
Meaningful intensity, recurrence, completion, or quality within a capability that has already qualified as adopted.
Is frequency part of depth?
It can be, but keeping it visible makes bursty activity easier to distinguish from recurring use.
Is low breadth bad?
Not automatically. It can reflect specialist value, lifecycle, cadence, or an intentionally focused use case.
Can one specialist represent deep account adoption?
Yes for a role-specific workflow, though operationally important work may still need backup coverage.
Should breadth and depth become one score?
Usually not. If a decision requires a summary, keep every component, weight, and underlying area inspectable.
How long should the period be?
Long enough to observe expected cadence, with comparable windows and lifecycle-aware rules.
Sources
Methodology and terminology
The sources use different breadth and depth definitions. This guide states its own account-breadth, user-breadth, depth, penetration, and concentration framework so calculations remain reproducible; the example and visuals are illustrative.
Source directory
- Hymetry demo product-adoption view
- Google research paper on the HEART framework
- Amplitude North Star workshop guide
- Amplitude North Star Playbook
- Pendo feature-adoption glossary
- Pendo breadth, depth, and frequency framework
- Gainsight product-adoption measurement article
- Gainsight health-score redesign article
- PostHog group analytics documentation
- Hymetry Pages documentation
- Hymetry Companies documentation
- Hymetry Users documentation
- Hymetry Visits documentation
