How to Build a Feature Adoption Dashboard

Every roadmap contains features that shipped and were quietly ignored, and features that shipped and quietly drove an outsized share of the retention curve. Without adoption tracking, you cannot tell the difference, which means you keep investing in the wrong things. A feature adoption dashboard turns “I think players like the new crafting system” into “27% of 7-day actives have used it, and of those, 58% used it again within a week — and their 28-day retention is 12 points higher than non-users.” That is a very different product conversation.

Instrument With One Event

The foundation is a single event schema you emit whenever any feature is used. One schema, so your dashboards can loop over features without custom joins per feature.

# feature_used event schema
{
  "event": "feature_used",
  "feature_id": "crafting_v2",
  "stage": "complete",     # enter | complete | abandon
  "outcome": "success",    # success | failure | quit
  "user_id": "...",
  "session_id": "...",
  "build": "1.4.2",
  "ts": "2026-04-10T10:23:11Z"
}

Every feature emits at least two events: stage=enter when the player opens the feature, and stage=complete when they finish the intended flow (crafted an item, finished a quest, placed a building). Multi-step features emit intermediate stages. This gives you a funnel per feature without a custom schema per feature.

Keep feature IDs stable. “crafting_v2” never becomes “crafting_v3” via rename; you ship a new ID alongside if you relaunch the system. This lets you compare v2 and v3 side by side for the transition window.

The Four Core Metrics

For each feature, compute four numbers:

First-use rate. Of all players who have been active in the last 7 days, what percent have emitted feature_id=X stage=enter at least once since it shipped? This is the top-of-funnel number. Low first-use means poor discoverability; a redesign of the entry point is more valuable than iterating on the feature itself.

Repeat-use rate. Of players who first-used the feature, what percent used it again within 7 days? This is the stickiness number. Low repeat-use means players tried it and chose not to come back; the feature has a depth or fun problem.

Funnel completion. For multi-step features, what percent of enter events reach complete? Low completion means players start the flow but drop out — UX friction, required content they do not have, or confusing progression.

Retention correlation. Compare 28-day retention between players who first-used the feature at least once and otherwise-matched players who did not. Positive lift means the feature is pulling its weight; near-zero lift means it is cosmetic from a retention standpoint.

Computing the Numbers

The queries are straightforward SQL over an events table partitioned by date.

-- First-use rate for a feature over 7-day actives
WITH actives AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE ts > NOW() - INTERVAL '7 days'
),
used AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event = 'feature_used'
    AND feature_id = 'crafting_v2'
    AND stage = 'enter'
)
SELECT COUNT(used.user_id) * 1.0 / COUNT(actives.user_id) AS first_use_rate
FROM actives
LEFT JOIN used USING (user_id);

Run these daily and materialize results into a feature_metrics_daily table. The dashboard reads from the table, not from raw events, so it loads in under a second.

The Dashboard Layout

The dashboard is a matrix. Rows are features; columns are the four metrics plus the last-7-day delta for each. Color each cell by percentile against all other features in your game: green for the top third, gray for the middle, red for the bottom.

A feature with green on first-use but red on repeat-use is a shallow feature — players try it and leave. A feature with red on first-use but green on retention correlation is a hidden gem — the few players who find it love it, and your job is to surface it to more. A feature red on everything is a candidate for deprecation or rework.

Add a sparkline per cell showing the last 30 days. A decaying sparkline on first-use usually means the entry point got buried by a UI refresh; a rising sparkline on repeat-use usually means a recent tuning pass is working.

Cohort by Build

When you ship a feature change, you want to compare adoption between the build before and the build after. Add a build filter to the dashboard so you can pull up “crafting_v2 adoption on 1.4.2 vs 1.4.3.” If adoption moves sharply in either direction, you know the change landed.

For experiments (A/B tests on a feature), the feature_id stays the same but you add an experiment_arm field to the event. The dashboard groups arms within a feature and computes all four metrics per arm. This lets you compare an experiment without building a separate dashboard per test.

Beware the Survivor Bias

Retention correlation is not causation. Players who play more tend to use more features; a feature that correlates with high retention might just be correlating with engaged players who would have retained anyway. Control for this by matching users on their pre-feature engagement (hours played before the feature was available) and then comparing retention within matched pairs.

For features that shipped recently, the only honest comparison is a ramped rollout: 50% of eligible users get the feature, 50% do not, and you compare retention between the two groups. This is expensive to run for every feature but essential for anchor features that drive roadmap decisions.

Review Monthly, Not Daily

Feature adoption moves on a weekly cadence, not a daily one. Reviewing the dashboard daily invites noise-driven decisions. Schedule a monthly product review where the team walks through every feature with its metric matrix and decides: invest, leave alone, iterate, or deprecate.

“We deprecated a daily-quest system that had 40% first-use but 3% repeat-use. The replacement was smaller, simpler, and hit 28% first-use with 22% repeat-use. We would never have made that decision without the dashboard.”

Related Issues

For building the underlying dashboard plumbing, read how to build a game health dashboard. For measuring whether your features are reaching the intended audience, see bug reporting metrics every game studio should track.

If you cannot name the top feature by retention lift, you cannot tell your team where to focus next.