如何将产品使用数据转化为功能采用率报告 (2026)

使用情况导出数据是一长串事件列表：用户 ID、事件名称、时间戳，可能还有一两个属性。而功能采用率报告只是一个百分比。这两者之间的距离是三个决定，而不是一个公式。

哪些用户应该归入分母。什么样的情况才算使用过该功能。以及你在多长的时间窗口内进行衡量。

改变其中任何一项，数据就会产生几十个百分点的偏差。而报告看起来依然是正确的，这正是问题所在。

本指南将介绍需要首先确定的内容、三种手动计算途径，以及每种途径在何处会失效。

开始前的准备工作

你需要事件级别的行数据，而不是预先聚合的摘要。每行代表一个事件，包含用户标识符和时间戳。

你需要真正代表该功能的事件名称。这很少像听起来那么干净简单，因为大多数功能都会触发多个事件。功能采用率数据的准确性完全取决于这种映射关系的质量。

你还需要知道谁有资格使用它。如果该功能仅通过 flag 向部分账户开放，那么其他所有人都不应该计入分母。

快速进行一次合理性检查可以省去后面一个小时的麻烦。统计导出数据中的去重用户数，并将其与你已知的活跃用户数进行对比。如果两者差异很大，说明导出数据被应用了你未注意到的过滤条件。

改变数据的三个决定

分母。 是所有注册用户、月活跃用户，还是仅对该功能有使用资格的用户？对于相同的事件，这三者会产生三个截然不同的百分比。每个功能采用率数据都是一个分数，因此在进行任何计算之前，请先明确分子和分母分别代表什么。

对于新发布的功能，“有资格的用户”通常是最诚实的选择。而“所有注册用户”则是看起来最糟糕、但最容易被辩护为“保守估计”的数据。

“使用”的定义。 是触发了一次事件、两次事件，还是在两个不同的会话中触发？在功能引导过程中的单次点击并不算采用，大多数团队都是在吃过苦头后才明白这一点的。

选择一个阈值并将其写在报告上。在两天内分别使用过一次（共两次）是一个常见且合理的规则。

时间窗口。 采用率不是一个时间点。它是指在某一时间段内执行了该操作的有资格用户的比例，因此该时间段是定义的一部分。

在照搬某个工具的方法论之前，有一个记录在档的细节值得了解。Amplitude's retention documentation 解释了其计算原理。它“通过比较初始事件的日期与你指定的返回事件的日期来计算留存数据”。

日期范围仅适用于第一个事件。Amplitude 明确指出，“用户无需在该期间内触发返回事件即可出现在分析中。”

这种行为很合理，但往往会让人感到意外。如果电子表格将两个事件都过滤在同一个窗口内，其结果将与该工具不一致，而这两种方法其实都没有错。

如何手动计算

方案 1：统计去重用户数，然后相除

首先进行去重，因为原始事件数并不等于采用用户数。使用 UNIQUE 提取唯一用户列表。

然后，使用 COUNTIFS 结合事件名称和日期范围，统计这些用户中有多少人触发了该功能事件。最后除以你的有资格用户数。

将这两个统计值保留在可见的单元格中，而不是将它们嵌套在一个公式里。因为总会有人问分母是多少，而你肯定希望能够直接指给他们看。

这种方法的局限性在于，它只给你一个孤立的数字，没有任何具体的画像。你只知道有 18% 的人采用了，却对这些人是谁一无所知。

方案 2：构建用户级别的 flag 表

每个有资格的用户占一行，每个问题占一列。例如：他们是否触发了事件、触发了多少次，以及在多少个不同的日期触发。

现在你可以进行多维度剖析了。按订阅方案、按注册群组、按账户规模，或者按他们是否完成了新手引导来查看采用率。

这就是功能采用率从“仅供汇报”转变为“可指导行动”的关键所在。一个 18% 的综合数据会掩盖以下事实：新用户的采用率高达 40%，而去年老用户的采用率仅为 4%。

这一差距就是你的发现。我们的群组分析指南介绍了为什么即使用户行为没有发生变化，只要注册量发生波动，综合数据就会随之改变。

这种方法的限制在于数据量和关联操作。一个百万行的导出数据加上一个账户表，已经超出了公式能轻松处理的范畴。

方案 3：在数据旁保留一个定义标签页

记录下事件名称、阈值、时间窗口、分母以及谁是有资格的用户。

这正是让下个月的报告具有可比性的关键。然而，当有人急需在十分钟内拿到数据时，这个标签页往往会被直接忽略。

局限性在于，记录定义并不等于应用定义。在每个周期中，依然会有人重新构建那五个相同的过滤器。

共同的瓶颈。 这三种方案都假设事件名称是干净规范的。当代码重构后，同一个操作以三个不同的名称触发时，在开始任何计算之前，真正的核心工作其实是去协调和统一这些名称。

手动计算在何处会拖慢效率

第一份报告需要花一个上午的时间。而第四份报告花的时间会更长，因为到那时，定义已经悄然发生了偏差。

当产品发生变化时，事件名称也会随之改变。代码库中的一次重命名会导致你的图表出现断崖式下跌，看起来就像是用户放弃了该功能。这就是为什么功能采用率图表最终反映的往往是代码的改动，而不是客户的真实决策。

逐步推广的变化会破坏分母。当该功能覆盖到 100% 的账户时，采用率看起来反而下降了，因为有资格的用户群体扩大了三倍。

此外，还有一个存在时间最长的计算错误：每当少数重度用户频繁使用该功能时，对事件总数进行求和（而不是统计去重用户数）就会虚增采用率。

还有一个只有在临近截止日期时才会显现的成本。当有人问“这个数据好吗？”时，单一的百分比无法给出答案，而构建对比分析又成了一个新的项目。

如何使用 Powerdrill Bloom 构建报告

步骤 1：上传你的使用情况导出数据

上传事件导出数据，或者将事件和账户文件一起上传。Powerdrill Bloom 会在文件导入时对列进行分析，因此在计算任何百分比之前，不一致的事件名称和缺失的用户 ID 就会被暴露出来。

步骤 2：用自然语言描述定义

直接陈述规则，而不是去构建它们。指出事件名称、阈值、时间窗口以及哪些用户具有资格。

然后提出能够避开陷阱的问题。例如，询问是否有任何事件名称看起来几乎重复；询问触发该事件的去重用户数与事件触发总数的对比；以及功能采用率在不同注册月份之间有何差异。

步骤 3：导出图表、报告或幻灯片

导出采用率趋势图、按细分群体划分的表格，或者将数据和定义结合在一起的幻灯片。

为什么这比每个周期都重新构建要好

	手动计算途径	Powerdrill Bloom
从事件中去重用户	每个文件都需要辅助列	直接询问去重用户数
按群组或订阅方案拆分	关联并重新构建表格	直接索取拆解数据
发布后重命名的事件	事后在图表中发现	在上传时即被指出
更改有资格的用户群体	重新计算分母	直接陈述新规则

第三行是决定准确性成败的关键。在折线图中，重命名的事件和真实的采用率下跌看起来完全一样，但其中只有一种情况需要产品团队做出响应。

常见错误

统计事件数而非用户数。 200 人产生的 10,000 次事件并不等于高采用率。请务必先进行去重。

在设有 flag 的功能上将所有注册用户作为分母。 如果只有三分之一的账户能看到该功能，那么其余三分之二的人并不是“未采用者”，他们根本没有使用资格。

将单次点击视为采用。 在新手引导过程中的单次事件只能算作“曝光”。如果你希望这个数据有实际意义，请要求在不同日期进行重复使用。

对比跨月份的综合率。 新用户和老用户的采用率不同，因此用户结构的变化本身就会影响数据。在得出结论之前，请先按群组进行拆分。

忽视事件重命名。 代码重构会导致数据出现断崖式下跌，看起来就像是流失。在调查用户行为之前，请先检查事件字典。

在不了解其工作原理的情况下照搬工具的时间窗口。 记录在档的留存窗口通常仅对第一个事件进行过滤，因此对两个事件都进行过滤的电子表格计算出的结果会与之不一致。

在不附带定义的情况下汇报百分比。 如果没有分母和阈值，这个数字就毫无意义。请将这两者都标注在图表上，就像一个优秀的 KPI 仪表盘 标注其指标那样。

结论

确定有资格的用户群体、设定使用阈值、固定时间窗口，并在相除之前对用户进行去重。这四个步骤能将一个冰冷的功能采用率百分比转化为产品团队可以据此采取行动的有用信息。

维护这一指标的高昂成本在于，其定义必须能够应对产品的变化。重命名的事件和扩大范围的逐步推广都会在无人修改报告的情况下改变数据。

如果你的报告周期正面临这些困扰，不妨在你的使用情况导出数据上 尝试使用 Powerdrill Bloom。另请参阅我们关于 构建群组留存图表 的指南、用于产品分析的最佳 AI 工具 汇总，以及 CSV AI 助手 页面。

常见问题解答

什么是功能采用？

它是指在定义的时间窗口内使用过某功能的有资格用户的比例，以去重用户数而非事件数来衡量。只有在明确了分母和使用阈值的情况下，该定义才成立。

如何从事件导出数据中计算它？

统计在你的时间窗口内触发了该功能事件的去重用户数，然后除以有资格的用户数。请务必先进行去重，因为一个用户可能会产生数百个事件。

分母应该是所有用户还是活跃用户？

建议使用有资格的用户群体，即实际上能够接触到该功能的用户。使用“所有注册用户”会产生一个保守的数据，并低估了在 rollout flag 控制下的功能采用率。

衡量时间窗口应该多长？

应该足够长以覆盖一个正常的使用周期，例如对于日常使用的产品建议设为每周，对于周期性使用的产品建议设为每月。请在不同的报告中保持该窗口固定，因为改变它就会改变最终的数据。

为什么我的数据与分析工具的数据不一致？

通常是因为时间窗口或去重规则的不同。记录在档的留存计算通常仅将日期过滤器应用于第一个事件，而基于这两个事件构建的电子表格是无法重现这一计算逻辑的。