Feature usage
How adoption per feature is calculated, how underused features are detected, and how adoption sits beside reliability in Feature health.
Feature usage reports how many distinct users touch each feature of your product over a period, ranks features by adoption, and surfaces the ones almost nobody uses.
Those last ones are usually generating maintenance and bug reports out of all proportion to their value.
Adoption per feature
A feature is created automatically on its first event. Each one gets an adoption percentage, a distinct user count and a trend over the window.
| Feature | Users | Adoption |
|---|---|---|
| Recipe Generator | 18,492 | 38.3% |
| Shopping List | 12,822 | 26.6% |
| Meal Planner | 8,331 | 17.3% |
| Nutrition Report | 3,104 | 6.4% |
| Change Color | 2 | 0.004% |
Adoption is distinct users of the feature over distinct active users of the product in the same window. The denominator matters: measured against total accounts instead of active users, every number drifts downward as your dormant account list grows, and adoption starts looking like churn.
Underused feature detection
ErrorDock flags features whose usage falls below a threshold over a window — the "Change Color: 2 users in 90 days" case above.
Every one of those still has code paths, tests, documentation and a share of your bug surface. Knowing which they are is the first step to deleting them, and deletion is the only change that makes a codebase permanently cheaper.
Two cautions before you delete on the strength of a number:
- Check the window. A feature used once a quarter by finance is not unused; it is seasonal.
- Check who. Two users out of fifty thousand is noise. Two users who are your two largest accounts is not.
The tool ranks. The decision stays with you.
Read against reliability
Feature health puts each feature's adoption, uses and users next to its error rate and P95 latency, each with its change against the previous window. An error rate of 4.8 percent in a feature 72 percent of your customers depend on reads very differently from a 40 percent error rate in a feature nobody opens — and sorting by event volume alone gets that backwards every time.
The error rate needs withFeature, which records the outcome of the feature's work as well as the
use. Usage and errors come through the same SDK, for the same users, in the same sessions, which is
what makes the two columns comparable.
Related
Last updated October 20, 2026