Product

How to Measure Feature Adoption (and Find Out Why a Feature Is Ignored)

Shipping a feature is not the same as users adopting it. Learn the four stages of feature adoption, the metrics for each, and how to use session recordings to discover whether an unused feature is unwanted, undiscovered, or unusable.

Purushottam Kumar Suman
Purushottam Kumar SumanSeptember 17, 20267 min read
Founder & CEO, DeepSync
Product team reviewing feature adoption metrics

Short answer: measure adoption in four stages: did users see the feature, did they try it, did they complete what it is for, and did they come back to it. A feature with low adoption fails at one of those stages for a specific reason. Low discovery is a placement problem, low completion is a usability problem, and low repeat use means it did not solve a real need.

Table of Contents

  1. The Four Stages
  2. Instrumenting a Feature
  3. Diagnosing Low Adoption
  4. Choosing the Right Denominator
  5. When to Remove a Feature
  6. Key Takeaways

The Four Stages

StageQuestionMetric
ExposedDid they see where the feature lives?Share of users who viewed the page or entry point
TriedDid they start using it?Share of exposed users who opened or began
CompletedDid they finish the task?Share of triers who reached the outcome
RepeatedDid they use it again?Share who used it in a later week

Repeat use is the stage that matters. Trying a new feature once is curiosity (novelty effect).

Instrumenting a Feature

Track a start and a completion, not just a click:

deepsync("track", "report_builder_opened");
deepsync("track", "report_created", { type: "funnel" });

Then build a funnel per feature:

  1. Page containing the entry point viewed
  2. Feature opened
  3. Outcome completed

For repeat use, count users with the completion event in two different weeks. Identify users so usage can be tied to people and plans:

deepsync("identify", user.id, { plan: "pro", role: "admin" });

Diagnosing Low Adoption

The funnel shows which stage fails. Recordings show why.

Low exposure: they never saw it

  • The entry point is in a menu few people open.
  • It sits below the fold on a page people do not scroll.
  • Its label does not suggest what it does.

Check: a click heatmap of the navigation, and how many sessions reach the page. Fix: move it, rename it, or link to it from where the need arises.

Exposed, not tried

  • Users see the button and pass over it.
  • The name is jargon.
  • It looks like it belongs to a higher plan.
  • They do not have the need.

Check: watch users on that page. Do they hover and move on? Fix: clearer naming, a short description of the benefit, an example.

Tried, not completed

  • The first screen asks for configuration they do not understand.
  • An error occurs. Check JavaScript errors.
  • It needs data or a setup step they have not done.
  • It is slow.

Check: recordings of users who opened it and did not finish. Note where they stopped. Fix: defaults, templates, fewer required inputs, fixing the fault.

Completed, not repeated

  • It worked and the result was not useful.
  • The need is occasional.
  • They found a quicker way elsewhere.

Check: talk to users who completed it once. This stage needs conversation more than recordings. Fix: this is a product question. Sometimes the answer is that the feature was not needed.

Choosing the Right Denominator

"Five percent of users use the export feature" can be good or bad.

  • Of all users? Includes people who could never need it.
  • Of users on plans that include it?
  • Of users with the relevant role? An admin feature should be measured against admins.
  • Of users who have data to export?

Choose the group for whom the feature is relevant. A feature used by eighty percent of the people it was built for is a success even if that is five percent of all accounts.

Also separate breadth from depth. A feature used occasionally by everyone and a feature used daily by a few are both valuable, in different ways (power and casual users).

When to Remove a Feature

Unused features have a cost: they clutter the interface, slow onboarding, and need maintenance.

Consider removing or hiding a feature when:

  • Exposure is good and use is still very low.
  • Those who try it rarely return.
  • It was built for a need that has since changed.
  • It complicates the path for most users.

Before removing, check who the few users are. If they are your largest customers, hide it from others instead of deleting it.

Measure adoption at week four, not week one

First-week usage after a launch mostly measures curiosity. Whether people are still using it a month later measures value.

Key Takeaways

  • Adoption has four stages: exposed, tried, completed, repeated.
  • Each stage fails for a different, diagnosable reason.
  • Measure against the users the feature is for.
  • Repeat use is the real test.

Conclusion

An unused feature is a question: unwanted, unseen, or unusable? The answer is in the funnel and the recordings, and it decides whether you promote, fix, or remove it.

Start free with DeepSync.

Frequently Asked Questions

Was this article helpful?

Ready to understand
users like never before?

Join thousands of teams who use DeepSync to uncover insights,improve experiences, and build better products—faster.

Quick & easy onboarding
See results in real time
Enterprise-grade security