产品功能分析：保留、改进与下线的证据矩阵

调整路线图之前，先用透明的证据矩阵比较三项功能，不把流行程度当成价值，也不把相关性当成效果证明。

产品功能分析，是把功能触达、成功使用、重复使用、用户价值与维护成本放在一起，判断该保留、改进还是考虑下线。先明确有资格使用的人群和完成结果，再结合行为数据与用户研究。单凭点击排行，分不清功能是关键、难以发现，还是维护成本偏高。

把要做的决定写出来

「哪些功能用得最多」适合做盘点；「接下来简化批量导出、投入定时报告，还是替换旧报表」才是产品决策。后者还需要资格、依赖关系、质量、成本，以及改动会影响谁。

本文分析的是已经存在的功能，不是竞品功能清单、机器学习特征重要性，也不是用问卷研究偏好的方法。功能采用指南负责解释采用漏斗；这里补上投入或撤出之前需要的证据。

Amplitude 的功能分析文章讨论功能目录、可使用人群和使用指标。本文增加可复算的示例矩阵与决策记录，把行为事实、价值判断和待验证假设分开。

先做功能目录，再查事件

按用户能理解的任务命名功能，比如「导出完成的报告」，而不是前端组件名称。一个功能可能对应多个事件，同一个导航事件也可能进入多个功能。没有目录，容易重复计数，或把不同任务混为一谈。

找流程负责人核对埋点。下载开始不等于文件已经生成，点了定时按钮也可能只触发权限错误。无法观察完成结果时，应明确标记限制，而不是把尝试当成价值。

行为变化时给目录留版本，记录发布时间和事件定义，避免把埋点调整造成的突增当作产品成功。统计导出发生过，通常不需要采集报告正文或自由输入文本。

触达、使用深度和回访分开看

每个计算内部保持统计单位一致。个人任务按人，共享组织任务在身份数据支持的情况下按账户或空间；同时看两者时，分别写口径。

触达率是窗口内成功使用者除以有资格人群，回答有多少可使用者实际使用，不能代表满意度。

使用频率可以看成功次数、活跃天数，以及这些值在成功使用者中的分布。少量自动账户可能产生大量活动，因此均值之外还要看集中情况。

重复使用关注初次使用者在合适窗口内是否再次完成任务。按月导出的功能，不应仅因图表方便就要求次日再次使用。

质量与任务成本补充失败尝试、操作障碍和支持负担。按尝试计算的错误率，不要与按人去重的采用率互换。低频但重要的任务，尤其需要访谈或任务观察。

需要周期性追踪时，可参考产品采用的衡量方法。本篇是决策复核，不要求把每项证据都做成长期看板。

复算一张示例功能矩阵

以下均为协作产品的示例数据，不是客户结果或行业基准。重复使用队列都已完成相同的十四天观察；各功能资格人群不同，是因为权限和需求范围不同。

评论触达为 500 ÷ 1,000 = 50%；导出为 120 ÷ 200 = 60%；定时报告为 100 ÷ 1,000 = 10%。重复率依次为 350 ÷ 500 = 70%、90 ÷ 120 = 75%、20 ÷ 100 = 20%。

按原始人数排序，导出的一百二十人明显少于评论的五百人；但在可使用的人群里，导出触达反而更高。这不能证明应该给导出更多资源，只能说明「人少就不重要」的判断缺了分母。

最后一列有条件。缺少中间证据时，它只是研究安排，不能直接变成预算建议，更不能把示例率写成行业合格线。

app.tapcub.com

触达率要带上资格分母

功能	有资格	使用者	触达率
评论	1,000	500	50%
批量导出	200	120	60%
定时报告	1,000	100	10%

均为虚构数字，不以流行程度直接决定下线。

示例数据

留存相关性不等于功能效果

再看一组独立的示例：一百名功能使用者中八十名下月回来，四百名未使用者中二百名回来。观察到的回访率分别为 80% 和 50%，相差 30 个百分点，但不能说功能带来了三十个百分点的提升。

使用者可能账户更老、套餐不同、本来就有更强需求，也可能必须先留下足够久才能用到功能。如果用「本月任意时间使用过」分组，同时比较本月留存，还会混入时间与存活机会差异。

尽量让功能接触发生在结果窗口之前，比较资格和账户年龄相近的队列，并说明仍未排除的差别。需要因果结论时，另设适合的实验或有依据的因果设计。TapCub 提供行为分析，本文不声称它会运行特性开关实验或偏好问卷。更多见相关与因果。

单独对待低频关键功能

密码找回、无障碍设置、账务导出可能使用不频繁，但需要时非常重要。决定是否下线之前，先确认它是否承担访问、恢复、业务义务或客户工作流程，不能仅用流行程度判断。

也要寻找看不见的依赖。一小部分管理员导出文件，可能供许多同事使用；事件只记录管理员动作，不一定看得到后续使用。先找账户负责人核对实际流程。

高频同样不必然代表喜爱。反复打开设置页，可能是在找不到选项。把成功结果、质量与直接观察结合，避免把操作负担当成参与度。

用决策记录保留不确定性

加权总分容易把人的判断藏进权重。可以先用一张简短记录，让证据和未知项都看得见。

考虑下线时，再补依赖负责人、受影响账户、迁移方案和沟通责任。矩阵能提示候选，不能替代删除授权或抹去客户承诺。复核日期应与新证据挂钩，不是每周重复同一轮无依据投票。

在 TapCub 中取得行为证据

事件次数和趋势从 全端分析 › 行为分析 › 事件分析 查看；完成阶段用漏斗，特定动作后的回访用留存。保存分析，让团队以后复查同一口径，具体模型见分析选择文档。

账户层级分析要先准备资格和账户标识。维护成本、合同依赖、访谈记录通常来自其他系统，应在决策记录里注明出处，不要把综合价值分包装成事件分析自动输出。

持续监控用范围明确的采用看板，解释操作障碍则补任务研究。每份材料都应对应一个尚未回答的问题，而不是为了让报告看起来完整而加入。

FAQ

功能分析与功能采用有什么区别？

功能采用看发现、初次使用与重复使用；功能分析进一步结合价值、质量、成本和依赖，服务投入或退出决定。采用是输入之一，不是全部结论。

使用率低就应该删除吗？

不能。先检查资格、观测能力、合理频率和流程依赖。恢复或导出能力即使受众小，也可能很重要。考虑退出前应有证据和可行替代。

使用者留存更高，就能证明功能成功吗？

只能说明相关。账户年龄、套餐、原有意图和接触时间都可能影响结果。保留这个线索，同时明确它尚不能证明因果。

必须做加权总分吗？

不必。透明矩阵配决策记录往往更好复查。确实要加权时，应写明权重原因、结果对权重的敏感性，以及缺失数据的处理规则。

资料来源与下一步

2026 年 11 月 7 日核对：Amplitude 功能分析、Hex 功能分析流程、TapCub 分析模型。示例矩阵、计算和决策记录均由本文构造。先选三项功能与一个要做的决定，把缺少的证据补齐，再排投入顺序。