How to Track Feature Adoption in a SaaS
One event per feature first-use, read per cohort. The minimal instrumentation that tells you what to build more of — and what to cut.
Every SaaS eventually faces the roadmap court case: engineering swears feature X matters, sales swears customers ask for Y, and the founder suspects half the product is furniture. Feature adoption data settles it — and the instrumentation is deliberately minimal: one event per feature, fired on first meaningful use, not on every click.
The instrumentation pattern
// Once per user per feature — gate client-side or accept
// the duplicate and dedupe in analysis
window.webanalytics?.track('feature_used', {
feature: 'export_csv', // stable slug, lowercase
first_time: true, // if you can cheaply know
plan: user.plan, // the property that prices it
});- One event name (feature_used) with a feature property beats forty event names — reports group naturally and the naming convention cannot drift.
- 'Meaningful use' means the value moment: report generated, not report-menu opened. Menu opens measure curiosity; completions measure adoption.
- The plan property turns adoption data into pricing data — see below.
The three adoption reports
- Adoption rate per feature: share of active users who used each feature this month. The shape is always a cliff — three features carry the product, five get moderate use, the rest are furniture. Now you know which furniture.
- Adoption vs retention correlation: compare features used by your retained users against your churned ones (churn signals guide). The feature that retained users disproportionately adopt is your activation candidate — push it earlier in onboarding and watch cohorts improve.
- Adoption by plan: a feature heavily used on the free tier and absent on paid plans is mispriced packaging. This report has moved more pricing pages than any consultant.
What not to instrument
Resist tracking every button — that path leads back to the taxonomy graveyard. Clycyo already captures clicks and navigation automatically; the explicit feature_used layer is reserved for the dozen value moments your roadmap debates actually hinge on. If a feature is not worth arguing about in a planning meeting, it is not worth an event.
Closing the loop
Ship a feature → watch its adoption curve for four weeks → compare adopters' retention against the baseline. That loop, run honestly, kills more bad roadmap items than any prioritization framework — because 'nobody used it' is the one argument that survives every meeting.