您的仪表板显示，发布成功了。注册人数增加，登录人数飙升，团队感到放心。
然后两周过去了。支持票减少，但不是因为产品运行顺畅。人们只是不再回来。少数强大的用户活跃。新账户的大多数是沉默的。您交付了访问权，而不是采纳。
That’s the gap 用户采纳指标 旨在填补的差距。它们帮助您回答一个比“用户是否出现？”更困难的问题。它们回答“用户是否达到了价值，回来了，并且将产品纳入了他们的日常 routine？”这种转变很重要，因为原始注册和登录通常是虚荣指标。它们告诉您有人触摸了门把手。它们并没有告诉您他们是否完全搬进去了。
对于产品团队来说，这通常在实践中表现为一项发布看起来很好，但在实际操作中却很弱。一个协作工具可能会获得大量的账户创建，但只有少部分用户创建了第一个项目，邀请了团队成员，或者后来返回。一个移动应用可能会看到下载量，但很少用户完成了注册流程或完成了第一个使产品有用的事情。如果您已经盯着这种不匹配，您已经问到了正确的问题。
更好的框架是将采纳视为从访问到习惯的旅程。也就是说，观察用户第一次理解产品，第一次获得结果，然后重复行为的时刻。负责处理入门、激活和 应用用户体验改进 的团队通常会发现同样的事情。用户的第一次成功比用户的第一次登录更重要。
目录
介绍：从注册到真正的采用
许多团队仍然以商店统计步行人流量的方式衡量成功。更多的访问者一定是好事。但是，产品并不是因为人们只来一次而获胜的。它们获胜的是因为用户完成了有意义的动作并重复它们。
采用指标的存在就是为了解决这个问题。它代替了对原始获取的浅表关注，提供了产品价值的行为视图。有用的问题不是“有多少创建了账户？”而是“有多少人到达了产品变得足够有用以便返回的阶段？”
实用规则： 如果一个指标与用户价值没有连接，它可能不会帮助您提高采用。
想象一下一个项目管理应用。登录一次就像走进健身房大厅一样。它并不意味着有人锻炼了。创建第一个项目、分配任务并返回第二天更新进度。这些是表明采用开始的行为。
通常最重要的三个问题是什么
- 价值发现： 用户是否完成了第一个有意义的操作?
- 重复行为： 他们是否在第一次成功之后回来了?
- 工作流适配： 使用是否从好奇心转变为习惯?
本指南的其余部分围绕着这些问题构建。一些指标告诉你是否成功的用户引导。其他指标告诉你产品是否形成了习惯。更高级的指标帮助B2B团队回答一个更复杂的问题。是某个人采用了产品，还是整个客户账户都采用了它?
8个基本用户采用度指标的解释
简化的用户采用度
最容易理解的比喻是健身会员。注册不是采用。第一次上课更接近。每周都去上课才证明健身会成为某人的生活的一部分。
软件也一样。根据 ClickLearn的用户采用度指标概述通常，采用率被定义为目标人群中达到意义使用里程碑的百分比，而不是原始注册或登录。同样的框架包括公式，如 采用率 = (新活跃用户 / 总用户) × 100 和 特征采用率 = (使用特征的用户 / 总活跃用户) × 100.
核心用户采用率指标一览
| 指标 | 公式 | 它告诉你什么 |
|---|---|---|
| 激活 | 产品里程碑各异 | 用户是否达到了第一个真正价值的时刻 |
| DAU/MAU | 每日活跃用户 / 月活跃用户 | 用户在一个月内返回的频率 |
| 留存率 | 根据返回窗口而变化 | 用户是否会继续使用产品 |
| 流失率 | 根据流失定义而变化 | 用户停止使用产品的比例 |
| 粘性 | 通常使用DAU/MAU来衡量 | 用户是否会形成使用习惯 |
| 功能采用率 | (活跃用户使用该功能人数 / 总活跃用户人数) × 100 | 某一特定能力在实际应用中是否重要 |
| 价值时间 | 从注册到首次价值时刻的时间 | 用户获取有意义结果的速度 |
| 采用率 | (新活跃用户人数 / 总用户人数) × 100 | 用户从访问到活跃使用的转变率 |
连接采用率与忠诚度的团队可以将这些指标与 应用用户保留模式进行比较采用会将用户带入价值。保留则表明他们是否会留在那里。
每个指标真正告诉你的内容
激活 判断用户是否已经完成了首次操作。对于笔记应用，可能是创建第一笔记，Slack可能是发送消息。具体公式取决于产品，但原则是稳定的。选择第一个证明产品点击的操作。
DAU/MAU 比较每日活跃用户与每月活跃用户。它是一个频率信号。如果许多月活跃用户也活跃于每日，产品很可能已经成为日常习惯的一部分。
留存率 询问用户是否在初始时间段后返回，因为一些产品在首次印象良好后却无法成为有用的产品。
流失率 是留存率的反面。它显示了停止参与的用户。流失率是有用的，但它最好作为警告灯，而不是主要的方向盘。流失率上升的时间，原因通常已经在激活或价值交付中开始了。
跟踪流失率，但在产品中花费更多的精力来解释它的指标。
粘性 通常与DAU/MAU一起讨论。在许多团队中，人们几乎将这两个术语混淆。实际想法是简单的。粘性产品经常被访问到，用户不需要提醒就能访问。
功能采用率 将焦点从整个产品缩小到一个功能。如果您启动了工作流程设计器、文件共享工具或审批流程，这个指标就会显示是否有活跃用户在使用它。使用之前的来源的公式很清晰： (使用特定功能的用户/总活跃用户) × 100.
到价值时间 衡量用户需要多长时间才能达到他们的第一个有意义的结果。这一指标经常会揭示入门阻力。如果用户需要太多的设置步骤才能让产品有用，采用就会在早期停滞不前。
采用率 总结了大局。它问的是有多少用户变得有意义地活跃，而不是仅仅注册。所以它比仅仅注册的指标更强大。
好的工作规则是将指标配对而不是单独阅读：
- 激活+到价值时间 显示入门是否会带来有用的第一个胜利。
- DAU/MAU+留存 显示使用是否浅表还是习惯性的。
- 功能采用+流失 帮助您确定核心功能是否吸引用户还是无法产生影响。
有效地衡量和跟踪采用
从事件监控开始
采用衡量从开始时就开始了，不是打开仪表板时才开始。它是您决定要跟踪的用户行为时就开始了。
如果您的团队使用Amplitude、Mixpanel、Heap、PostHog或Google Analytics，所有这些工具的关键决策都是相同的。定义产品事件围绕价值，而不是单独的界面点击事件。 “项目创建”、“邀请发送”、“模板应用”和“报告导出”是有用的事件。 “页面浏览”通常不足以。
通常，简单的事件设置包括：
- 入口事件： 注册、首次登录、引导开始
- 价值事件： 首次创建项目、首次上传文件、首次完成工作流
- 习惯事件： 重复会话、重复任务完成、重复协作动作
Teams 也使用受控的发布来测试是否某个变化提高了这些里程碑。 Feature flag 系统可以帮助隔离登录页面复制、默认设置或 UI 变化的影响。 如果您的团队正在实验阶段发布，您对
实现 Feature Flags 的指南
是一个实用的补充。
使用团队来查看时间变化
- 团队分析是避免自欺欺人的最清晰的方法之一。
- 而不是将所有用户聚合在一起，您将他们分组为他们开始或接收的体验。
- 这有助于回答这些问题：
那些看到新登录页面的用户是否完成激活更多？
重新设计后创建的账户是否返回得更加一致？ 新计划等级是否与自助用户行为不同？
Map the path with __CAPGO_KEEP_0__
Funnels show where users stop moving. They’re useful because most adoption problems are not mysterious. They happen at a specific step.
For most products, the adoption funnel looks something like this:
- 到达: 有人访问网站或安装应用
- 账户创建: 他们注册
- 首次使用: 他们完成初始核心动作
- 关键动作完成: 他们达到产品特定里程碑
- 重复使用： 他们回来了，还是会做
不是为了让漏斗看起来漂亮。真正的目标是找出哪一步骤失败了。如果有很多用户注册但很少完成首次使用，说明你的引导流程可能存在问题。如果用户到达首次使用但不返回，说明产品可能是可理解的但不够吸引人。
解读指标并设定基准
上下文比孤立的数字更重要
一个单独的指标可能会误导你。好的解读从产品的目标开始。
每个产品都有不同的使用节奏。团队协作产品的工作流程与个人工具的使用节奏是不同的。所以，当团队问一个数字是否‘好’时，通常的回答是‘好’于什么行为？’
不过，一个基准值变得尤为重要。根据 Stonly关于用户采纳指标的讨论, the DAU/MAU比率 被广泛用作粘性度指标， 50% DAU/MAU 比率 意味着平均用户每月打开产品大约15天 而不是30天。因此，团队会将其用作习惯形成的替代品，而不是一次性使用。 一张名为解读用户采纳指标的图表，显示了百分比和目标指标，用于关键业务绩效指标。
粘性很强，因为它可以区分广泛但浅表的使用和更深入的参与。即使产品有很多用户，但如果大多数用户都很少返回，也可能很弱。
但粘性本身并不是一个独立的判决。它变得更有用时与保留和行为质量一起使用。如果 DAU/MAU 上升，而有意义的动作保持平稳，用户可能只是打开了应用程序而没有做太多事情。如果粘性低，但产品本身是自然的偶发性，指标可能仅仅反映了用例。
因此，性能解释应该包括产品背景、发布历史和体验质量。改进
应用程序性能优化 的团队经常发现，加载速度更快，延迟更少，可以支持更好的重复使用，但指标仍然需要与用户完成的任务一起阅读。 最佳基准通常是内部指标
__CAPGO_KEEP_0__
外部benchmark有助于定位。内部benchmark更适合决策。
比较在产品变更前后的同一群体。比较已完成onboarding的用户与跳过onboarding的用户。比较不同计划或不同设置路径的账户。这些比较会告诉你你的工作是否改变了行为。
一个实用的benchmark系统通常包括:
- 基线: 变更前产品的当前行为
- 预期移动: 如果实验成功，哪个指标应该改变
- 决策规则: 如果实验失败，你将采取什么后续行动
当指标移动时，问用户行为改变了什么。当指标不移动时，问产品变更是否触及了真正的价值来源。
超出基础用户级别与账户级别的采用
为什么团队产品会造成盲点
许多B2B团队都容易陷入一个常见的误区。看似健康的采用率可能掩盖了一个脆弱的账户。
B2B采用率测量的讨论 指出主流指导中存在一个常见的缺口。大多数解释都集中在激活、DAU/MAU、价值时间和特性采用率上，但它们并没有清晰地告诉你何时采用率应该以用户为单位、以账户为单位，或者两者兼而有之。
区分这两种视图很重要，因为它们回答了不同的问题。以用户为单位的采用率告诉你个人是否参与。以账户为单位的采用率告诉你客户组织是否将产品嵌入其工作流程中。
同时追踪广度和深度
想象一下一个被大公司购买的销售平台。一个运营负责人每天登录，生成报告，并喜欢这个产品。账户看起来很活跃。但是，如果没有人使用它，推广就仍然很弱。如果那个倡导者离开，账户突然处于风险之中。
一个更好的模型是同时追踪：
- 采用率的广度： 一个账户内部有多少人活跃
- 采用率的深度： 那些人如何意义地使用产品
- 分段： 无论是角色、方案还是用例，采用情况是否有所不同
尤其是在多人使用的产品中，这一点非常重要。一个账户可能会显示功能使用情况，但仍然无法在团队中广泛使用。反之亦然。许多用户可能会登录，但只浅尝辄止。
一种实用的方法是通过分段查看账户，而不是以一个巨大的平均值来查看。团队通常通过 按方案和渠道分段用户，然后在此基础上添加基于角色使用情况的层次来获得更好的可见性。重点是避免将一个热情的支持者误认为是组织层面的采用。
一个强大的B2B推广通常会同时显示使用情况的广泛性和实质性。缺一不可。
构建您的采用仪表板并采取行动
一个有用的仪表板不试图显示所有内容。它讲述了一个关于用户是否达到了价值、重复使用并在账户内部传播使用情况的简短故事。
仪表板中应该包含什么
对于大多数产品团队来说，仪表板应该围绕一个小的行为信号集：
- 激活趋势： 是否新用户能够达到首个重要里程碑？
- 价值时间趋势： 是否成功的路径变得更短或更复杂？
- 保留视图： 是否用户在首次成功后返回？
- 功能采用视图： 是否关键功能被活跃用户使用？
- 账户采用切片： 是否团队广泛采用，还是使用集中？
仪表盘也需要分段。新用户与老用户。自助式与企业式。个人用户与账户。没有这些切分，平均值会扁平化故事。
将指标转化为产品决策
每个指标都应该触发特定的响应。如果激活度弱，需要加强引导并减少设置阻力。如果价值时间慢，需要减少用户看到核心结果之前所需的步骤数量。如果功能采用率低，问题可能出在发现、相关性或工作流适配度上。
在这里，发布速度很重要，因为产品团队通过快速的反馈循环来学习。像Amplitude和Mixpanel这样的工具可以帮助您读取行为。交付工具可以帮助您测试与行为相反的变化。在移动和跨平台团队中， Capgo 是将JavaScript、CSS、配置、副本和资产更新发送到应用商店的方法之一，而不必等待应用商店的审查，这可以缩短观察到采用问题并测试修复之间的周期。
在工作流程的后期，演示视频可以帮助团队围绕什么改变了和为什么改变了达成一致。
一个实际的运营节奏如下：
- 每周查看仪表板。
- 确定一个采用瓶颈。
- 发送一个专注的更改。
- 将下一个队列与之前的队列进行比较。
- 基于行为而不是意见，保留或撤销。
这就是采用度量工作变得可管理的方法。不是一次性追求所有指标，而是通过在测量和产品行动之间建立一个稳定的循环来实现的。
人工智能和自动化的未来采用度量指标
人工智能开始使采用率的含义变得复杂。传统的用户采用率指标假设人类登录、执行操作并返回。这种模型在人工智能代理生成内容、触发工作流程或自动完成任务时就会变得摇摆不定。
作为 Userpilot关于改变采用率衡量的写作 指出，新的指导方针已经提出了“人类vs.人工智能代理”的问题。实际问题很简单。像DAU/MAU、会话持续时间和到达首个关键操作所需的时间这样的指标可能会看起来更强大，即使活动是由自动化而不是人实现的价值。
团队需要更清晰的归因。谁启动了任务？人工智能帮助了什么？什么是完全自动化的？这些区别会变得更加重要，因为自动化成为正常产品使用的一部分。北极星仍然是相同的。测量人们和组织是否获得了真正的、持续的价值。只是不要假设每个操作都来自人类了。
如果您的团队部署Capacitor或Electron应用，并希望采用率分析和产品变化之间的闭环更紧密， Capgo 值得一看。它让团队能够快速交付code和内容更新、针对特定的发布渠道、监控发布行为，以便产品、工程和支持团队可以更快地响应采用率出现问题时。
