使用数据可定位未被发现的功能
别名: 功能采用漏斗 · 未发现检测 · feature adoption analytics
概念解释
哪些功能没被发现，不能靠团队的直觉，要靠使用数据：到过相关情境却从未打开该入口的人、打开过一次再也不来的人、以及同一任务上走了更长替代路径的人。数据定位的是「入口没被找到或找到了却不可用」，不是用活跃度给功能打分。这条是发现的测量问题：先看见谁没找到，再决定改入口还是改能力本身。它不规定入口该长什么样，也不主张靠反复教学把采用率催上去。
机制
自我报告会把「我知道有这个」和「我能在界面上找出来」混在一起；日志把两者拆开。关键不是全局点击率——冷门功能点击少可能只是需求少。有信息量的是条件采用：在已经出现需求信号的会话里，目标入口被打开的比例。需求信号来自替代路径（下载后去邮箱、复制到别的工具）、停顿、搜索词、或重复失败。没有需求信号的低点击，是没人要；有需求信号的低点击，才是没被发现。漏斗还要分开「看见入口」「打开入口」「做成结果」：卡在第一步是气味或位置，卡在第三步是能力或权限。把这三截混成一个「采用率」，会把发现问题和产品问题一起扔给教学去修。
怎么研究
在真实流量里为每个候选功能定义需求信号与成功事件，做条件漏斗；辅以对「走了替代路径」的人的短期回访。
自变量：入口位置改动前后、标签改动前后（教学保持不变）。 因变量：有需求信号的会话中的入口打开率、替代路径占比、打开后的成功完成。
实验室任务会把需求做成必做项，发现被高估。不要用「功能 DAU」当发现指标。搜索日志里的内部功能名或「怎么导出」是强需求信号，应并进漏斗而不是单独当客服工单。
边界
新功能刚上线，需求信号本身还没形成，数据会暂时全是「未发现」，要等任务模式稳定再读。隐私与最小采集：不需要内容级日志也能做条件采用，只记情境类型和入口事件。被权限或套餐挡住的失败会看起来像未发现，漏斗必须把「墙前放弃」标成获取问题。内部工具人手少、事件埋点乱，与其假漏斗，不如定期看一遍会话录像里的替代路径。
怎么落地
- 为每个声称「发现不足」的功能写两条事件：需求信号（替代路径、相关搜索、相关对象被选中）和入口打开；只在有信号的会话里算打开率。
- 把打开后未完成单独列出来，不要和未打开混成一个低采用结论。
- 先改入口再看漏斗是否动；漏斗不动，再查能力、权限或价值，而不是先加导览。
- 验证：改入口后对比同一需求信号下的打开率。信号在、打开率不动，发现仍未解决；打开率升但完成不动，问题不在发现。