Measure feature adoption without counting internal users

Feature adoption requires an eligible population and a meaningful usage event. Dividing every feature event by all registered accounts mixes events with users and may include people who never had access. Staff testing and automated activity can further inflate the numerator.

Define adoption as a user-level measure first. Then add frequency, repeated use and outcomes as separate measures.

Define eligibility for a fictional sharing feature

In the synthetic product analytics lab, report sharing is treated as a pro-plan feature. For this exercise, plans are fixed during the observation window. Eligible users are external nonbot pro users with at least one meaningful report event from January 1 through January 16 at 00:00 UTC, exclusive.

An adopter has at least one valid report_shared event in that same window. This measures adoption among eligible active users. It does not measure adoption among all licensed users or among people who saw the sharing interface.

Construct the denominator before counting adoption

WITH eligible AS (
 SELECT DISTINCT u.user_id FROM users u JOIN events e USING(user_id)
 WHERE u.user_kind='external' AND u.is_bot=0 AND u.plan='pro'
   AND e.valid=1
   AND e.event_name IN
       ('report_created','report_published','report_viewed','report_shared')
   AND e.event_time>='2026-01-01T00:00:00Z'
   AND e.event_time<'2026-01-16T00:00:00Z'
)
SELECT u.user_id,EXISTS(
 SELECT 1 FROM events e WHERE e.user_id=u.user_id
 AND e.valid=1 AND e.event_name='report_shared'
 AND e.event_time>='2026-01-01T00:00:00Z'
 AND e.event_time<'2026-01-16T00:00:00Z'
) AS adopted
FROM eligible u ORDER BY u.user_id;

The eligible users are U1, U2, U3, U5 and U9. U1 and U3 share a report, giving adoption of 2/5, or 40%.

U7 is a staff account that also shares a report. Including it would change both the population and the apparent adoption rate. U8 is a bot. U4 and U6 have basic plans, so they do not belong in this exercise's eligible denominator.

from build_and_verify import database, active_ids, CUTOFF

db = database()
active = set(active_ids(db, '2026-01-01T00:00:00Z', CUTOFF))
pro = {r[0] for r in db.execute("SELECT user_id FROM users WHERE plan='pro' AND user_kind='external' AND is_bot=0")}
eligible = active & pro
shared = {r[0] for r in db.execute("""SELECT user_id FROM events
 WHERE valid=1 AND event_name='report_shared'
 AND event_time>='2026-01-01T00:00:00Z' AND event_time<?""", (CUTOFF,))}
db.close()
assert eligible == {'U1','U2','U3','U5','U9'}
assert eligible & shared == {'U1','U3'}
assert len(eligible & shared)/len(eligible) == .4
print({'eligible_active_users': 5, 'adopters': 2, 'adoption_rate': .4})

Separate access from exposure

Having the pro plan establishes access under this fixture's rule. It does not prove that someone saw the feature. If a new interface is rolled out gradually, distinguish licensed users, assigned users, exposed users and successful users.

Each denominator answers a different question. Assigned-user analysis can support an experiment's intent-to-treat comparison. Exposed-user conversion can diagnose interface behavior, but exposure may depend on user activity and therefore be selective.

Mixpanel's Insights documentation describes event analysis and measurement options. When recreating a report in a product tool, verify its user-counting, filters and interval settings against the metric contract.

Check whether adoption means sustained value

One share is first use, not evidence of a lasting habit. Add repeated usage over a defined period, successful recipient access or another meaningful outcome if those events are available and appropriate. Do not invent recipient success from a sender's click.

Account for tenure as well. U9 joined near the cutoff and has had fewer opportunities to adopt. A fixed post-eligibility adoption window would require maturity rules similar to the activation analysis. The current period measure deliberately answers a different question.

Historical plan changes require an entitlement history. Filtering old events by today's plan can classify a past basic user as having been eligible for a feature they could not access then.

Exercise: add a plan upgrade halfway through the month and compare period-end eligibility with eligibility at event time. State which population each calculation represents.

NeuraPath's Data Analytics with Generative AI course develops the SQL and interpretation skills behind product reporting. A useful adoption metric explains who had a real opportunity to use the feature and what successful use means.

Continue learning

This article is part of the Customer and product analytics sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Analyze repeat purchases when customer identity changes.
• Continue with Experiment guardrails for revenue and user experience.