Usage data locates features that were never found

What it is

Which features go undiscovered is not a team hunch. It is usage data: people who entered a relevant situation and never opened the entry, people who opened once and never returned, people who took a longer substitute path for the same job. The data locates “the entry was not found, or was found and unusable,” not a popularity score. This entry is the measurement problem of discovery: see who did not find it, then decide whether to change the entry or the capability. It does not prescribe how the entry should look, and it does not argue for pushing adoption with more teaching.

Why it happens

Self-report conflates “I know that exists” with “I can find it in the UI”; logs split them. Global click rate is not the signal—a rare feature can be little-clicked because demand is rare. What carries information is conditional adoption: among sessions that already show a demand signal, the share that open the target entry. Demand signals come from substitute paths (download then email, copy into another tool), pauses, search terms, or repeated failure. Low clicks with no demand signal means nobody wanted it; low clicks with a demand signal means it was not found. The funnel must also split “saw the entry,” “opened it,” and “got a result”: stuck on the first step is scent or place; stuck on the third is capability or permission. Mixing the three into one “adoption rate” hands both discovery and product problems to teaching.

Studying it

In live traffic, define a demand signal and a success event per candidate feature and build a conditional funnel; follow up briefly with people who took substitute paths.

Independent variables: before/after entry placement, before/after labels (teaching held constant). Dependent variables: entry-open rate in sessions with a demand signal, substitute-path share, success after open.

Lab tasks make demand mandatory and overstate discovery. Do not use feature DAU as a discovery metric. In-app searches for the internal name or “how do I export” are strong demand signals and belong in the funnel, not only in support tickets.

Where it stops holding

Right after launch, demand signals have not formed yet and everything looks undiscovered; wait until task patterns stabilize. Privacy and minimization: conditional adoption does not need content-level logs, only situation type and entry events. Failures blocked by permission or plan look like non-discovery; the funnel must mark “gave up at the wall” as acquisition. Internal tools with few people and messy events are better served by watching substitute paths in session replay than by a fake funnel.

Applying it

• For each feature claimed to be under-discovered, write two events: a demand signal (substitute path, related search, relevant object selected) and entry-open; compute open rate only in sessions with the signal.
• Keep post-open incompletion on its own line; do not fold it into “low adoption.”
• Change the entry first and watch the funnel; if it does not move, inspect capability, permission, or value before adding a tour.
• Verify by comparing open rate under the same demand signal after an entry change. Signal present, open rate still, discovery is unsolved; open rate up, completion still, the problem is not discovery.

Related

• Within the group: H2.05.1 Discovery depends on a visible entry, not a lesson · H2.05.3 Repeating the tour cannot fix a missing entry
• Adjacent: H2.09 Onboarding checklists and completion · H2.07 Hint Restraint · G3.07 Zero-result handling
• Search terms: feature adoption · conditional use · undiscovered feature