A feature is more plausibly underused when discovery, progress, completion, or expected recurrence falls below a stated expectation for comparable accounts and opportunities. That conclusion requires context: who was eligible, which roles owned the job, whether the prerequisite or trigger occurred, which period was observed, and whether users completed the work elsewhere or through automation. Low frequency can reflect healthy cadence—or conceal weak discovery, poor fit, friction, or a missing need.
What counts as an underused feature?
An underused feature is used less often, by fewer eligible entities, or less meaningfully than expected given realistic opportunities and the value the feature is intended to create.
The important word is expected. Underuse is a comparison between observed behavior and a declared model of appropriate behavior. That model should identify:
- the accounts or users for whom the feature is relevant;
- the circumstances in which they have a realistic reason to use it;
- the action or outcome that represents meaningful use;
- the cadence at which the opportunity normally recurs; and
- the lifecycle stage in which the workflow applies.
A feature cannot be called underused merely because another feature produces more events. A dashboard intended for daily monitoring will naturally generate more activity than an annual compliance workflow. A frequently opened page can also be underused when most visitors never complete its intended job.
For the general entity-and-denominator calculation, see Feature Adoption Rate for B2B SaaS. The narrower question here is how to interpret low activity when the number of realistic usage opportunities varies by feature, account, role, and period.
What is a low-frequency workflow?
A low-frequency workflow is a capability whose expected use is naturally periodic, event-driven, role-specific, or one-time. It is not a weak workflow by definition. Its job simply does not require constant human interaction.
Common B2B SaaS examples include:
- monthly invoice reconciliation;
- quarterly planning or business reviews;
- annual compliance reporting;
- user offboarding;
- incident investigation;
- data migration;
- initial integration setup;
- contract-renewal configuration;
- occasional exports; and
- workflows triggered by an external customer, operational, legal, or security event.
A successful low-frequency feature may show almost no daily activity while achieving high completion whenever the relevant opportunity occurs. An annual compliance report can be healthy even if most accounts do not touch it for eleven months. A CRM integration can be healthy after one successful setup if the resulting connection continues to deliver data.
This is why a daily or 30-day activity window can severely misrepresent monthly reporting, quarterly planning, annual compliance, renewal administration, one-time setup, incident response, and externally triggered workflows. Usability research also distinguishes frequent from occasional use and notes that an infrequent scenario can still be important to the user.
However, “low-frequency” is not a defense against contrary evidence. When relevant users repeatedly reach a workflow but abandon it, fail to complete it, or resort to a manual alternative, cadence alone does not explain the problem.
Measure frequency against opportunity
Eligibility and opportunity are related but different.
- Eligibility asks who can and should use the feature.
- Opportunity asks whether an eligible entity encountered a realistic reason to use it during the measured period.
Every account administrator may be eligible to offboard users, but only accounts with a departing user have an offboarding opportunity. Every supported account may be able to export incident data, but only accounts experiencing a relevant incident have an immediate production need.
For recurring or triggered workflows, an opportunity-normalized rate can be more informative than raw feature activity:
Opportunity-normalized use rate
Opportunity-normalized use rate =
eligible opportunities with meaningful workflow completion
÷ total eligible opportunities
× 100
Count a qualifying completion against the opportunity it serves. Do not allow retries, repeated page loads, or multiple exploratory Visits to inflate the numerator.
The denominator may be expressed as an account-period, account-event, user-event, or another reproducible unit. Examples include:
- account-months in which month-end reporting was due;
- accounts entering a defined renewal window;
- offboarding events assigned to users with the required permission;
- incidents that met the product’s investigation criteria;
- accounts that completed prerequisite setup and became eligible for the next workflow; and
- newly eligible accounts given the same amount of time to complete one-time configuration.
Opportunity-normalized use and account adoption answer different questions. Account adoption asks whether an eligible account crossed a declared threshold. Opportunity-normalized use asks whether the account completed the workflow across the occasions when it was realistically needed. A monthly reporting feature may have broad account adoption but weak completion across repeated month-end cycles, or narrower adoption with excellent completion among the accounts for which it is relevant.
The meaningful action should represent the intended job rather than simple entry. Depending on the workflow, it might be a report successfully generated and shared, an offboarding process completed, a plan approved, an export produced, or an integration’s first data sync confirmed. See How to Define Meaningful Feature Use for the broader distinction between reach, first use, and a value-bearing action.
When opportunity data is unavailable
Many teams do not yet capture a clean opportunity event. That does not justify pretending the denominator is known. Use the best transparent proxy available and label it as a proxy.
Possible proxies include:
- report-enabled accounts that were active at month-end;
- accounts whose CRM record entered a renewal stage;
- permissioned users assigned an offboarding task;
- accounts that reached the prerequisite page or setup state;
- support or incident records that indicate a relevant trigger; and
- accounts in a documented use-case segment for which the workflow is expected.
A permissioned user is only a proxy for opportunity because permission does not prove need. A page visit is only a proxy for discovery because it does not prove that the user recognized the feature or intended to use it. State these limitations in the metric definition.
If no defensible opportunity signal or proxy exists, report the raw counts and say that the opportunity denominator is unknown. That is more useful than a precise-looking percentage with an invented denominator.
Choose an observation window that includes the expected cadence
There is no universal “good” feature usage interval. Official product-analytics guidance similarly treats the appropriate interval as dependent on how and when users receive value. The observation window should normally contain enough complete, realistic opportunities for the workflow to occur.
| Cadence | Example | Useful analytical lens | Common interpretation risk |
|---|---|---|---|
| Continuous | Integration sync, API processing, background automation | Configuration adoption plus output health, freshness, failures, or delivery | Calling low UI activity low value when the system is working without human input |
| Daily | Operational checklist or daily monitoring | Eligible account-days or user-days | Counting page opens instead of completed daily work |
| Weekly | Team review or recurring collaboration | Eligible account-weeks or distinct active weeks | Using a daily threshold that penalizes an intentionally weekly job |
| Monthly | Invoice reconciliation or monthly reporting | Eligible account-months and completed reporting cycles | Judging the workflow from a partial month or from daily activity |
| Quarterly | Planning, business review, or capacity allocation | Eligible account-quarters or trigger-aligned planning cycles | Calling a quiet mid-quarter 30-day period inactivity |
| Annual | Compliance filing or yearly configuration review | Account-year, due-date cohort, or compliance cycle | Observing accounts before their actual due date |
| One-time | Initial integration, migration, or workspace setup | Eligible cohort conversion, time to completion, failure rate, and persistence | Expecting weekly returns after the job is successfully finished |
| Event-driven | Offboarding, incident investigation, or renewal administration | Eligible trigger events and completion per trigger | Using all active accounts as though every account experienced the event |
| Irregular but critical | Emergency export, recovery, or exceptional escalation | Qualifying production events plus readiness tests when appropriate | Assuming no production use proves the capability is unnecessary or unusable |
Seven days may be suitable for a daily operational workflow because the window can contain several expected usage opportunities. Thirty days may be suitable for one complete monthly reporting cycle. A 180-day or 365-day view may be required to observe multiple quarterly cycles or one annual cycle. These are examples, not universal rules.
A longer calendar window is not automatically better. It can combine different releases, customer stages, plan changes, staffing changes, and seasonal cycles. The better requirement is: include enough complete opportunities while keeping the compared entities and context interpretable.
One-time setup often needs a cohort or event-triggered analysis instead of a calendar activity window. Start the clock when an account becomes eligible, give comparable accounts the same opportunity duration, and measure whether they complete the setup. A recently eligible account should not be judged against an account that has had six months to finish.
For periodic workflows, compare like cycles where possible: month-end with month-end, quarter-end with quarter-end, renewal cohorts with previous renewal cohorts, and annual due periods with comparable due periods. In statistical analysis, seasonality refers to recurring calendar-related variation. Product teams do not need to begin with formal seasonal adjustment, but they do need to avoid interpreting a recurring calendar pattern as a product failure.
A diagnostic framework for low feature adoption
Diagnose the workflow in sequence. A recurrence question is premature when no realistic opportunity occurred, and a completion problem cannot be interpreted until discovery and progress are understood.
1. Eligibility: who can and should use the feature?
Define eligibility at the same entity level as the decision. For account-level analysis, consider plan access, enabled modules, lifecycle stage, prerequisites, use case, geography, and whether the account is active. For user-level analysis, consider role, permission, assignment, and responsibility for the job.
An administrator-only billing workflow should not be judged against every active user. An advanced export intended for integration-heavy customers should not be judged against accounts without that use case. Eligibility should be observable and declared before looking at the result.
2. Opportunity: did a realistic reason to use it occur?
Access does not prove opportunity. Identify the business event, calendar cycle, prerequisite state, or task that should cause the workflow to become relevant.
For monthly reporting, the opportunity may be an account reaching month-end with required data available. For renewal administration, it may be an account entering the renewal window. For an incident export, it may be a qualifying incident. Without that trigger, inactivity is weak evidence.
3. Discovery: did relevant users reach or notice the feature?
Discovery can include exposure to an entry point, navigation into the grouped page, use of search, or another observable route to the workflow. It is useful evidence, but reaching a page is not the same as adopting the feature.
Low discovery may reflect weak placement, insufficient onboarding, missing permission, no current need, a role mismatch, or users completing the job elsewhere. Compare discovery only among entities that had an opportunity to notice and use the feature.
4. Progress: did users begin the workflow?
Separate opening the feature from starting its substantive steps. A user may read a report page without creating a report, open integration settings without authenticating, or enter an offboarding flow without selecting the person to remove.
Instrument or otherwise identify the first intentional step and useful intermediate states. Progress evidence shows where discovery turns into an attempt and where the attempt stops.
5. Completion: did they complete the meaningful action?
Completion should correspond to the workflow’s intended outcome. A button click can happen before an export succeeds. A page can load despite a failed data request. Retries can create multiple events for one unsuccessful attempt.
Prefer confirmed state changes or successful outputs where instrumentation permits. Keep the interpretation narrow: a completed workflow is stronger evidence than a page view, but it does not prove satisfaction, business impact, or causal value.
6. Recurrence: did use return at the expected cadence?
Recurrence applies only when the job itself repeats. Ask whether another eligible opportunity occurred and whether the account or relevant user completed the workflow again.
For a monthly workflow, distinct completed months may matter. For a quarterly workflow, separate planning cycles matter. For a one-time integration, weekly recurrence is usually the wrong measure; persistence of the connection and downstream data delivery are more relevant.
7. Distribution: who inside the account performed the work?
Account completion can be healthy even when one specialist owns the workflow. A finance administrator may be the correct user for reconciliation, while broad participation may be required for collaborative planning.
Inspect whether concentration is role-appropriate or represents dependence on one champion. Compare account breadth, user penetration, role coverage, and continuity risk rather than assuming that every feature should spread to every user. See Adoption Breadth vs Depth for the broader account-distribution question.
8. Substitution: was the same job completed another way?
Users may complete the job through another product feature, an integration, an API, a manual spreadsheet, a support request, or an external tool. Low usage of one interface can therefore represent substitution rather than an absent need.
Substitution may be healthy, inefficient, or evidence that the feature does not fit the workflow. Inspect the quality, cost, and reason for the alternative before labeling the product feature underused.
9. Seasonality: does the workflow follow a recurring cycle?
Look for month-end, quarter-end, annual audit, renewal, budgeting, tax, staffing, or industry cycles. Compare current activity with a period containing a similar opportunity mix rather than automatically comparing a busy cycle with a quiet one.
Seasonal product usage does not make every decline harmless. The test is whether the opportunity changed in a way that explains the movement. Stable opportunities with declining completion deserve a different investigation from declining opportunities with proportionally stable completion.
10. Friction: what happened in successful and unsuccessful attempts?
Review selected Visits from comparable users and accounts. In unsuccessful attempts, look for repeated abandonment, unclear steps, failed requests, permission problems, loops, or users leaving to find information elsewhere. In successful attempts, identify the path, prerequisites, role, and context that differ.
A single Visit is evidence, not a general conclusion. Look for repeated patterns across relevant accounts, roles, opportunities, and periods before attributing the result to interface friction.
Common diagnostic patterns
| Observed pattern | Possible interpretation | What it does not prove | Next evidence to inspect |
|---|---|---|---|
| Low discovery and low completion | The feature may be difficult to find, irrelevant to the measured segment, unavailable, or rarely needed. | It does not prove poor product-market fit or an interface problem. | Eligibility, permissions, opportunity triggers, navigation exposure, onboarding, and use-case segments. |
| High discovery and low completion | Users may be exploring, encountering missing prerequisites, misunderstanding the workflow, or abandoning after friction. | It does not prove that UI friction is the cause. | Start and progress events, successful versus unsuccessful Visits, errors, permissions, support evidence, and alternative workflows. |
| Low raw frequency but high completion per opportunity | The workflow may be healthy and naturally periodic, event-driven, or role-specific. | It does not prove that the experience is efficient, satisfying, or free of avoidable friction. | Time to completion, failures, comparable cycles, user distribution, output quality, and missed opportunities. |
| High use concentrated in one role | The feature may be correctly owned by a specialist, or the account may depend on one champion. | It does not prove broad underadoption or healthy continuity. | The intended job owner, permission model, backup coverage, account size, collaboration requirements, and role-specific eligibility. |
| Declining use with declining opportunity | Activity may be moving with seasonality, fewer renewals, fewer incidents, or a lifecycle change. | It does not prove retention loss or feature deterioration. | Opportunity counts, comparable prior cycles, account mix, trigger volume, and completion per opportunity. |
| Declining use despite stable or rising opportunity | Underuse, substitution, friction, changed role ownership, or weaker fit becomes more plausible. | It does not identify the cause. | Discovery-to-completion stages, release changes, segment differences, manual alternatives, support issues, and selected Visits. |
| Low UI interaction but healthy automated outputs | Configuration may be delivering ongoing value without frequent human interface use. | It does not prove that configuration, output quality, or exception handling is healthy. | Job success, delivery freshness, API or integration failures, notification delivery, configuration state, and human review when exceptions occur. |
| Strong use in one segment and near-zero use elsewhere | The workflow may have segment-specific fit, access, role ownership, prerequisites, or implementation quality. | It does not prove that the low-use segment should adopt it. | Plan, industry, lifecycle, company size, use case, permission, prerequisite, and whether the same job exists in both segments. |
Worked B2B SaaS example: raw volume versus opportunity
The following data is entirely fictional and illustrative. It is not Hymetry customer data, a benchmark, or evidence of expected performance.
Assume a fictional B2B operations product called LedgerPeak serves 48 customer accounts. The team reviews six months of activity from January 1 through June 30, 2026. The product contains five workflows with very different jobs:
- Daily Operations Dashboard: meaningful completion is confirming the required operational review for an eligible account-day.
- Monthly Reporting: meaningful completion is successfully generating and sharing the month-end report.
- Quarterly Planning: meaningful completion is publishing an approved quarterly plan.
- One-time CRM Integration: meaningful completion is connecting the CRM and receiving the first successful data sync.
- Incident Export: meaningful completion is generating the required export for a qualifying incident.
Illustration only
| Feature or workflow | Eligible accounts | Eligible opportunities | Accounts with at least one completion | Raw Visits | Meaningful completions | Opportunity-normalized completion |
|---|---|---|---|---|---|---|
| Daily Operations Dashboard | 48 | 6,048 account-days | 39 | 14,200 | 1,840 completed operational reviews | 30.4% |
| Monthly Reporting | 45 | 270 account-months | 40 | 680 | 233 completed reports | 86.3% |
| Quarterly Planning | 36 | 72 account-quarters | 31 | 240 | 58 published plans | 80.6% |
| One-time CRM Integration | 30 | 30 newly eligible accounts | 26 | 155 | 26 successful initial connections | 86.7% |
| Incident Export | 48 with access | 9 qualifying incidents across 9 accounts | 8 | 27 | 8 successful exports | 88.9% |
Illustration only
| Feature or workflow | Expected cadence | User distribution | Resulting interpretation |
|---|---|---|---|
| Daily Operations Dashboard | Daily on eligible working days | 168 operations users across 48 accounts | Very high traffic does not translate into expected operational completion. Underuse, an overly weak completion definition, or a mismatch between the dashboard’s stated job and actual value should be investigated. |
| Monthly Reporting | Once per month-end cycle | 63 finance and administrator users, usually one to three per account | Raw Visits are far below the dashboard, but completion across account-month opportunities is strong. The specialist distribution is plausible for the job. |
| Quarterly Planning | Once per quarterly planning cycle | 54 leaders, planners, and operations managers | The workflow appears healthy across two observed cycles. A 30-day mid-quarter view could incorrectly label it inactive. |
| One-time CRM Integration | Once after prerequisite setup | 29 administrators and implementation users | Low recurring interface activity is expected after completion. Twenty-five of the 26 completed integrations still delivered data at period end; the four non-completing accounts deserve a setup investigation. |
| Incident Export | Only when a qualifying incident occurs | 11 support and security specialists | The feature is rare but completed for eight of nine observed opportunities. The denominator is small, so the rate should be shown with counts and interpreted cautiously. |
What raw volume would get wrong
A ranking by raw Visits would put the Daily Operations Dashboard first and Incident Export last. That ranking describes interface volume, not workflow health.
- The dashboard is opened frequently but completes the declared operational job in only 30.4% of eligible account-day opportunities. High traffic can coexist with genuine underuse.
- Monthly Reporting has fewer than 5% as many Visits as the dashboard, yet completes 86.3% of the eligible month-end opportunities.
- Quarterly Planning can look inactive in a 30-day window that does not include a planning cycle, even though its six-month opportunity completion is strong.
- CRM Integration should not produce recurring setup activity after success. Its ongoing health depends on connection persistence and downstream delivery.
- Incident Export is healthy despite rare use because only nine qualifying incidents created a realistic production opportunity.
The example also shows why one metric is rarely sufficient. The team still needs to inspect who did the work, which accounts missed opportunities, how long completion took, what happened in failed attempts, and whether automated outputs remained healthy.
Use cohorts and lifecycle context
A feature can be irrelevant before an account reaches its prerequisite and irrelevant again after a one-time job is complete. A global average can combine these incompatible states and produce a number with no useful interpretation.
Useful comparisons include:
- newly onboarded accounts versus mature accounts;
- accounts that reached the prerequisite versus accounts that did not;
- accounts experiencing the relevant event versus accounts without the event;
- accounts in the same plan, industry, size, or use case;
- users with the same role and permission;
- current versus previous comparable cycles; and
- release or eligibility cohorts given the same opportunity duration.
Cohort analysis groups entities around a shared starting condition or characteristic and follows their behavior over time. For one-time setup, the useful starting point may be first eligibility rather than account creation. For renewal administration, it may be entry into a renewal window. For an integration, it may be completion of a prerequisite configuration step.
Give every cohort enough time to qualify for the measured outcome. Accounts that became eligible near the end of a period have not had the same opportunity as those eligible from the beginning. Either exclude incomplete follow-up periods from that comparison or report them separately.
Lifecycle also changes what success looks like:
- A newly onboarded account may be expected to discover and configure a feature, not yet repeat it.
- A mature account may be expected to complete the workflow across repeated opportunities.
- An account that finished a one-time migration should not continue returning to the migration interface.
- An account that has not experienced an incident should not be penalized for not using incident investigation.
- An account outside a renewal period may have no reason to use renewal configuration.
Compare behavior only after deciding which lifecycle states represent a fair opportunity.
Separate first use, recurring use, and automated value
Activation, setup, adoption, retention, completion, and automated value describe different stages. Combining them into one frequency threshold can make successful one-time or automated workflows look unhealthy.
| Stage | Question | Possible evidence |
|---|---|---|
| Activation | Did the account or user reach an initial value-bearing moment? | Cohort conversion, time to first meaningful completion, prerequisite completion |
| Initial setup | Was the capability configured successfully? | Eligible accounts completing setup, time to completion, failed attempts, setup abandonment |
| Recurring adoption | Was a repeatable workflow used when its opportunities recurred? | Completed account-periods or trigger events, opportunity-normalized completion |
| Retained use | Did initial adopters return across later eligible opportunities? | Completion in later daily, weekly, monthly, quarterly, or triggered periods |
| Successful completion | Did the workflow produce the declared outcome? | Confirmed state change, successful output, completion time, error or failure rate |
| Ongoing automated value | Did the configured system continue producing value without repeated UI use? | Successful jobs, data freshness, delivered reports, API responses, notifications, sync health |
How to evaluate one-time setup
A one-time setup feature should not be judged by weekly return frequency. Relevant measures may include:
- the share of eligible accounts completing setup;
- time from eligibility to completion;
- failure and abandonment rates;
- the number of attempts required;
- persistence of the resulting integration or configuration; and
- successful downstream data delivery.
A quiet setup page after successful completion can be the intended outcome. Conversely, repeated setup Visits without completion can be a stronger underuse or friction signal than low return frequency.
Low UI activity can coexist with substantial value
Human interface activity is only one layer of some SaaS workflows. Scheduled reports, integrations, API usage, notifications, automated workflows, and background processing may continue producing account value after configuration.
Separate three layers:
| Layer | What it asks | Example evidence |
|---|---|---|
| Configuration adoption | Did eligible accounts enable and correctly configure the capability? | Successful setup, required fields completed, permissions granted, first test passed |
| Automated output health | Does the system continue delivering the expected result? | Job success, sync freshness, delivered outputs, failures, retries, exception volume |
| Human interaction | When and why do people return to review, change, or resolve something? | Configuration changes, exception handling, report review, selected Visits, role distribution |
UI analytics alone may not contain the automated-output denominator or success signal. Combine interface behavior with trustworthy system, integration, delivery, CRM, or operational data where required. Do not infer healthy automation merely from a quiet interface.
Signals that genuine underuse is more plausible
No single signal proves the cause, but the following patterns make an underuse hypothesis more credible:
- Stable or rising eligible opportunities with declining completion. The workflow has not become less relevant, yet fewer opportunities produce the intended outcome.
- High discovery with repeated abandonment. Relevant users reach the feature and begin, but the meaningful completion remains weak.
- Low adoption among otherwise comparable accounts. Similar accounts with the same plan, lifecycle, prerequisites, role coverage, and use case behave differently.
- Strong use in one relevant segment and unexplained absence in another. The gap remains after checking access, role, opportunity, and need.
- Repeated setup Visits without successful completion. Users appear to have intent but do not reach the required state.
- Feature-specific support complaints or requests for help. Qualitative evidence aligns with the behavioral gap.
- Alternative manual workflows. Users still need the job but complete it through spreadsheets, support requests, duplicate entry, or external tools.
- Successful users show a distinct path or prerequisite. Accounts that complete the workflow consistently differ from unsuccessful accounts in a potentially actionable way.
- Declining adoption breadth after prior use. Previously adopted workflows disappear from relevant accounts even though their need and access remain.
Each pattern narrows the investigation; none independently proves weak discovery, poor fit, friction, or missing value. Validate the interpretation with account context, role ownership, system state, qualitative evidence, and selected successful and unsuccessful Visits.
A practical 13-step evaluation process
- Define the job. State the user or account outcome the feature supports.
- Define eligibility. Identify the accounts and roles for which the job is relevant and possible.
- Identify realistic opportunities. Name the calendar cycle, event, prerequisite, or task that creates a reason to use the workflow.
- Define meaningful completion. Choose the confirmed action or output that represents the job being completed.
- State the expected cadence. Classify the workflow as continuous, daily, weekly, monthly, quarterly, annual, one-time, event-driven, or irregular-but-critical.
- Select a suitable observation window. Include enough complete opportunities without combining incompatible lifecycle or product contexts.
- Segment by lifecycle, role, and use case. Compare entities that had comparable access, need, responsibility, and time to act.
- Compare discovery, progress, and completion. Locate the stage at which relevant entities stop.
- Inspect account and user distribution. Determine whether usage is broad, role-appropriate, or dependent on one specialist.
- Review relevant successful and unsuccessful Visits. Look for repeated behavioral differences rather than overinterpreting one recording.
- Check substitution and automated use. Find out whether the job happens through another feature, integration, API, manual process, or background system.
- Classify the current issue. Decide whether the strongest evidence points to discovery, friction, fit, cadence, opportunity, substitution, automation, or measurement.
- Remeasure using the same definition. Preserve the entity, eligibility, opportunity, completion, cadence, and window rules so the comparison remains reproducible.
The process should produce a sentence more precise than “the feature is underused.” For example:
Among mature accounts that reached month-end with Reporting enabled, report completion declined from the previous comparable cycle despite a stable number of opportunities. Discovery remained high, while more users abandoned after starting configuration.
That statement identifies the population, opportunity, outcome, comparison, and stage requiring investigation without claiming a cause the evidence does not prove.
Common mistakes when interpreting feature usage frequency
- Using a seven- or 30-day period for every feature. The period may omit the only realistic monthly, quarterly, annual, or triggered opportunity.
- Comparing daily and quarterly workflows by raw events. Event volume mostly reflects cadence and interaction design, not comparable adoption health.
- Ignoring eligibility. Accounts without access, prerequisites, permissions, or a relevant use case dilute the denominator.
- Ignoring opportunity. Eligible entities may not have encountered the event or cycle that makes the workflow necessary.
- Treating one-time setup as failed retention. Successful completion should reduce future setup activity.
- Assuming low UI use means low value. Scheduled reports, integrations, APIs, notifications, and background jobs can work without repeated human visits.
- Using total page views instead of meaningful completion. Repeated loads, retries, and exploratory entry can inflate apparent usage. See Page Views, Visits, Sessions, and Engaged Time for the metric distinctions.
- Interpreting seasonality as churn. A quiet period may contain fewer opportunities than the comparison period.
- Allowing “low-frequency” to excuse high abandonment. Cadence explains how often the job occurs, not why users fail when they try.
- Comparing onboarding and mature accounts. Their prerequisites, expectations, and time to encounter the workflow differ.
- Ignoring role specialization. Low user penetration may be correct for an administrator-owned task, while one-person concentration may be risky for a collaborative workflow.
- Changing the observation period until the result looks healthy. Define the cadence and comparison rule before interpreting the data.
- Summing daily distinct users or companies. The same entity can appear on several days and must be deduplicated across the complete measurement period.
- Confusing percentage changes from tiny baselines with meaningful movement. A rise from one completion to two is 100%, but it is still one additional completion. Show counts, denominators, and opportunities beside the percentage.
How Hymetry helps distinguish underuse from expected cadence
Hymetry connects product usage across product areas, grouped pages, customer companies, individual users, and Visits. That connected model helps a team move from an aggregate signal to the accounts and session evidence behind it.
- Pages organizes normalized product paths into grouped pages and product areas so teams can compare adoption, Visits, engaged time, interaction, and trend at a meaningful workflow level.
- Companies shows which customer accounts contribute to the pattern and whether adoption is broad, narrow, changing, or concentrated.
- Users shows the roles and people behind account-level activity, including whether usage depends on one specialist or extends across relevant users.
- Visits provides the session-level evidence to review what happened in selected successful or unsuccessful attempts.
A practical investigation can move through:
Product-area trend → Affected companies → Eligible or relevant users → Selected Visits
Selected periods and the immediately preceding period of the same length can help reveal changes in product-area and company activity. The team must still decide whether those periods contain comparable opportunities. A previous 30-day period does not automatically provide a fair comparison for a quarterly, annual, or event-driven workflow.
Observed engaged behavior can add context to a Visit or grouped page, but engaged time is an attention signal rather than proof of value. Teams should continue to distinguish discovery, progress, completion, recurrence, and automated output.
Hymetry does not automatically know the correct cadence, eligibility rule, business opportunity, workflow owner, or causal explanation. Those definitions come from the product’s job model, customer context, operational data, and human review. Hymetry helps connect the resulting question to reviewable company, user, page, and Visit evidence.
This investigation path can support both product teams evaluating feature behavior and customer-success teams preparing for account-level follow-up.
Frequently asked questions
How do I know if a feature is underused?
Define the eligible population, realistic opportunities, meaningful completion, expected cadence, and lifecycle context. Underuse becomes more plausible when comparable eligible entities repeatedly have opportunities but discovery, completion, or expected recurrence remains below a stated expectation. Raw volume alone is insufficient.
What feature adoption time window should I use?
Use a window that contains enough complete opportunities for the workflow’s natural cadence. Seven days may suit a daily job, 30 days may contain a monthly cycle, and 180 or 365 days may be needed for quarterly or annual analysis. One-time and event-driven features often need cohort or trigger-aligned windows instead. These are analytical examples, not universal standards.
Is low feature usage frequency always a problem?
No. Low-frequency product usage can be healthy for monthly, quarterly, annual, one-time, role-specific, event-driven, or automated workflows. It becomes concerning when the low activity remains after accounting for eligibility, opportunity, cadence, completion, substitution, and lifecycle.
How can I measure an infrequent SaaS workflow if I do not capture opportunity events?
Use a transparent proxy such as accounts reaching a prerequisite, permissioned users with an assigned task, month-end active accounts, renewal-stage accounts, or qualifying support records. Label it as a proxy and explain its limits. If no defensible proxy exists, report raw counts and state that the opportunity denominator is unknown.
Should a one-time setup feature have a retention metric?
Not in the same sense as a repeatable workflow. Measure eligible setup completion, time to completion, failure rate, and persistence of the resulting configuration. For an integration, ongoing sync health or downstream delivery is usually more relevant than weekly returns to the setup page.
Are page views or raw Visits enough to prove feature adoption?
No. They can show reach, entry, or session volume, but they do not automatically show meaningful completion. A frequently opened feature can still be underused when users do not finish the intended job, while a rarely opened feature can be healthy when it completes most eligible opportunities.
What if only one role uses the feature?
First decide whether that role legitimately owns the job. Specialist concentration may be healthy for billing, compliance, administration, or integration setup. It may be risky when the workflow needs collaboration or when the account depends on one irreplaceable champion. Use role-specific eligibility and inspect backup coverage.
Can automated output count as feature adoption?
Configuration adoption and ongoing automated value should be measured separately. A successful integration, scheduled report, API workflow, or notification system may deliver value with little UI activity. Confirm setup success and output health through suitable system data rather than assuming a quiet interface is healthy.
Sources
- Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications, Google Research. https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications/
- About events, Google Analytics Help. https://support.google.com/analytics/answer/9322688?hl=en
- Cohort exploration, Google Analytics Help. https://support.google.com/analytics/answer/9670133?hl=en
- Analyze User Engagement, Mixpanel Guide to Product Analytics. https://docs.mixpanel.com/guides/strategic-playbooks/guide-to-product-analytics/analyze-user-engagement
- Retention: Measure engagement over time, Mixpanel Documentation. https://docs.mixpanel.com/docs/reports/retention
- Retain Your Users, Mixpanel Guide to Product Analytics. https://docs.mixpanel.com/guides/strategic-playbooks/guide-to-product-analytics/retain-your-users
- Group Analytics: Group users together as an aggregated unit of measurement, Mixpanel Documentation. https://docs.mixpanel.com/docs/data-structure/group-analytics
- Time Series and Seasonal Adjustment, United States Census Bureau. https://www.census.gov/topics/research/seasonal-adjustment.html
- ‘Our Users Are Everyone’: Designing Mass-Market Products for Large User Audiences, Nielsen Norman Group. https://www.nngroup.com/articles/everyone-as-users/
- Frequency & Recency of Site Visits: 2 Metrics for User Behavior, Nielsen Norman Group. https://www.nngroup.com/articles/frequency-recency/
- Diary Studies: Understanding Long-Term User Behavior and Experiences, Nielsen Norman Group. https://www.nngroup.com/articles/diary-studies/