Measuring feature usage: adoption, active users, retention, churn

Feature usage is measured with a small set of metrics: adoption, active users, unique users, usage count, frequency, retention, and churn. Each answers a different question about a feature, and two pairs of them are easy to confuse in ways that lead to wrong decisions. This article defines each metric and shows what it does and does not tell you. It assumes the terms from the vocabulary of feature usage analytics — event, user, account, segment.

Adoption

Adoption measures whether users started using a feature. It is usually a percentage: the share of a population that has used the feature at least once in a period.

The population is the part people forget to pin down. “40% adoption” means nothing until you say 40% of what. Of all users? Of active users? Of a single segment, such as enterprise accounts? The same feature can show 5% adoption across everyone and 60% adoption among the segment it was built for. Always state the denominator.

Adoption also depends on the time window. Adoption “ever” only rises. Adoption “in the last 30 days” can fall, which is often the more useful number, because it shows whether people still pick the feature up.

Active users, DAU, WAU, MAU

Active users is the count of distinct users who did something in a time window. The three standard windows have names:

• DAU — daily active users
• WAU — weekly active users
• MAU — monthly active users

These can apply to the whole product or to a single feature. “Feature X has 1,200 WAU” means 1,200 distinct users touched that feature in the week. The ratio of DAU to MAU is a rough measure of how often people come back: a DAU/MAU of 0.5 means the average monthly user shows up on half the days.

Unique users vs. usage count

This is the first of those two pairs. Two metrics count the same activity in different ways:

• Unique users — how many distinct people used the feature.
• Usage count — how many times the feature was used, ignoring who.

They can tell opposite stories about the same number. Consider 100 uses of a feature in a week:

• 100 users using it once each — broad, shallow reach. Many people touched it; none rely on it.
• 1 user using it 100 times — narrow, deep reliance. One person built it into their workflow; nobody else cares.

Same usage count of 100. Completely different features. If you only look at usage count, you cannot tell them apart, and you will misjudge who a feature serves. This is why counting distinct users needs a stable user identifier — without one, everything a tool can report is the usage count.

Frequency

Frequency is how often a single user returns to a feature. It turns the two cases above into a distribution: most features have a few high-frequency users and a long tail of one-time users. Frequency is what separates a power user from someone who tried a feature once. When a feature’s usage count is high but its unique-user count is low, frequency explains why — a small group uses it a lot.

Retention

Retention measures whether the users who used a feature come back to it in a later period. It is the clearest signal of whether something is worth keeping.

Retention is measured against a starting group, usually a cohort — the users who first used the feature in a given week. You then track what share of that cohort returns in week 1, week 2, week 4, and so on. A feature where 60% of new users are still using it a month later is healthy. One where the curve drops to 5% by week 2 was tried and abandoned, no matter how good its first-week adoption looked.

Churn

Churn is the opposite of retention: the users who stop coming back. It applies at two levels.

• Customer churn — accounts that leave the product entirely.
• Feature churn — users who used a feature and then stopped, while staying in the product.

Feature churn is the more useful lens for feature decisions. A feature with high adoption and high churn is a feature people try and reject. That is a stronger signal to fix or remove it than low adoption alone, because the users came, saw, and chose to leave.

Adoption vs. engagement

This is the second pair, and telling them apart decides what you do next.

• Adoption asks: did users start using the feature.
• Engagement asks: how much do they use it after adopting.

Suppose your product has 1,000 active users in the last 30 days, and two features:

	Feature A	Feature B
Users who used it	900 of 1,000	100 of 1,000
Uses per user (frequency)	1	250
Adoption	90%	10%
Engagement	low	very high

Feature A is something nearly everyone touches but rarely — an import step, or an “accept terms” dialog. Feature B is a power-user tool — an API, a command palette, a search bar — that a small group lives in. Same product, opposite shapes. Judged on adoption alone, Feature B looks like a failure; engagement shows it is indispensable to the people who reach it. (Uses per user is frequency, the visible half of engagement; retention is the other half.)

A feature can have high adoption and low engagement — everyone tried it once, few came back. The fix for low adoption (discovery, onboarding, making the feature visible) is different from the fix for low engagement (making the feature more useful once found). Reading one number as the other sends you down the wrong path: promoting a feature nobody wants, or reworking a feature people simply never see.

The distinction maps onto the metrics above. Adoption is the first-use percentage. Engagement is frequency and retention combined — how often and how long people keep using it once they start.

How these fit together

No single metric decides anything. Each answers one part of the question, and the conclusion comes from reading them in order:

1. Adoption — did anyone start? Low adoption means a discovery or onboarding problem, or a feature nobody wants.
2. Unique users vs. usage count — is that usage broad, or concentrated in a few accounts?
3. Frequency and retention (engagement) — of the people who started, how often and how long do they keep using it?
4. Churn — of those who stopped, did they leave after genuinely trying the feature (a reject), or never really started?

Two of these — adoption and engagement — carry most of the decision. Put adoption (how many started) on one axis and engagement (how much they keep using it) on the other, and every feature lands in one of four quadrants, each with a different conclusion:

	High engagement	Low engagement
High adoption	Core capability — used widely and often. Protect and invest (search, dashboard).	Occasional necessity — everyone needs it now and then. Keep it, but don’t over-invest (export, settings).
Low adoption	Power-user feature — a small group relies on it heavily. Valuable to a subset; consider surfacing it wider (API, command palette).	Low value — few use it, and those who do don’t return. Candidate for redesign, better discovery, or removal.

The top-left is what you protect; the bottom-right is where feature bloat collects, and the clearest target for removal. The two low-adoption quadrants look identical if you only measure adoption — engagement is what separates a hidden gem (bottom-left) from dead weight (bottom-right).

Any one metric in isolation misleads. Adoption without engagement flatters a feature nobody keeps; usage count without unique users hides a feature propped up by one account. The decision comes from the combination.

Further reading

• The vocabulary of feature usage analytics — the terms these metrics are built from.
• Segment, cohort, dimension: terms people mix up — including active users vs. usage count and adoption vs. engagement.
• How to Choose Segments for Feature Usage Analytics — sending the user identifier that unique-user and retention metrics depend on.