通过

制定策略并决定要度量的内容

  • 项目

应用在组织或Microsoft Teams 应用商店中分发后，跟踪用户与应用交互的方式非常重要。 随着应用用户的增长，应用安装数可能不是相关指标。

请务必规划开发 Teams 应用时要监视的数据、指标和事件类型。 产品的 North Star 指标将指导你建立与业务相关的指标、核心用户操作和关键事件集。

若要在生态系统中实现长期可持续发展，应用必须有良好的新用户增长。 第二个属性是参与和保留。 用户必须返回到应用，并继续在应用中查找并使用它。 最后，第三个质量是收入。 应用必须为用户提供足够的价值，以便愿意付费。 应用必须具备这三种品质，才能在平台上长期取得成功。 如果应用中缺少这三种品质中的任何一个，则它在平台上的成功概率很低。

为长期可持续发展而参与和保留

检测策略应确保测量产品是否满足这三个质量。

监视应用的事件

就本文而言，让我们使用 HEART 框架来指示应考虑监视解决方案的一组有代表性的指标和事件。 请注意，以下列表并不详尽，建议添加与业务和产品相关的其他检测。

监视应用的事件

采用

目标：获取可以开始探索应用的新用户，从而保持漏斗图的正常顶部。 发现和采用新应用的方式有以下其中一种：

  • 用户自行搜索并安装应用。
  • 当用户在聊天、会议或频道中由其他用户、 (选项卡或自适应卡片) 共享时，用户偶然发现了该应用。
  • 管理员为用户安装应用，应用发送欢迎消息。

旨在提高采用率的检测应旨在提高应用及其功能的可发现性。 当现有用户开始在协作范围内使用应用时，在新用户中发现应用的可能性会增加。 例如，添加频道或会议选项卡、将机器人添加到频道或在群组聊天中共享消息传递扩展卡。

提示

  • 测量协作范围内的应用的使用情况，以及发现协作或会议范围内的应用功能所花费的时间。 如果使用量低或花费的时间长，则通过应用或营销工作更好地社交所述功能。
  • 虽然衡量总体采用度是很好的开始，但从平台功能和功能级别衡量采用情况。
评估 Insights
• 用户在 R1、R7、R14、R28 天内安装应用。
• 如果应用具有登录) ，则 (登录。		 • 应用级采用按租户、区域和细分细分。
• 基于Microsoft Entra 配置文件对用户进行细分。
• 按租户和组织名称分段。
• 首次使用 (单击选项卡、机器人、自适应卡片和会议) 所花费的平均时间。 • 在功能或平台功能级别进行报告，以衡量功能级别的采用情况。
• 第一个发现的扩展性点。
• 首次发现的范围。		 • 使用数据测量最终用户最常用于发现应用的扩展点和范围。
• 导致应用安装的链接展开的百分比。 • 对安装应用、发现后感兴趣的用户。
• 在协作范围内添加应用所花费的平均时间 - 频道、群组聊天和会议。 • 应用内的使用情况渗透。
• 在协作范围内添加应用的用户百分比。 • 有助于确定病毒性的潜力，即新用户的有机发现和使用。
• 在频道或群组聊天中添加应用后配置应用的用户百分比。 • 如果在安装当天未配置应用，则用户有 5% 的几率在下周对其进行配置。

参与和任务成功

目标：增加在应用中完成核心操作的参与型优质用户的数量。

核心操作定义为该用户操作，该操作是业务的核心，并且直接对北星做出了贡献。 例如，如果你是 IT 票证解决方案提供商，则核心用户操作可能是“创建票证”，其中包含搜索问题的步骤，升级是用户旅程漏斗中的关键业务事件，可推动用户执行核心操作。

Engagement 旨在测量用户与应用之间交互的强度和深度。 参与强度衡量用户使用应用 (量，例如，在应用中完成的核心操作数) 。 交互深度衡量用户与之交互的各种平台功能、范围和应用功能的数量。

提示

  • 不仅在整体应用级别，而且在单个应用功能和功能级别衡量参与度和使用情况非常重要。 确定为企业定义参与用户的核心操作和关键业务事件。 仅登录或查看应用可能不是质量参与。
  • 核心操作特定于你的业务，你应该有一个核心操作与你的产品的 North Star 相关。 核心操作不超过 2-3 个。
  • 关键业务事件是用户在执行核心操作的过程中可能采取的辅助操作。 关键业务事件可帮助准备漏斗图，了解有多少用户正在经历理想的用户旅程，并确定下车次数高的点。
评估 Comments
• # 应用用户 (R7、R14、R28) 。 – DAU 和 MAU。
• # 应用用户趋势线。		 • 应用和功能级别参与
• 基于Microsoft Entra 配置文件对用户进行细分。
• 按客户端报告 - 桌面、Web 和移动设备。
• 按租户和组织名称分段。
• 按产品功能细分 (功能级别) 活跃用户。
• 在 Teams 应用中使用关键功能的用户与在 Web 或本机应用中使用相同的功能的用户百分比。 • 指示在 Teams 应用中使用该功能的可发现性、易用性和价值。
• 应用功能级别的报表。
• #，跨不同范围 (R28) 使用应用的用户百分比。 • 参与渗透。
• 按范围报告。
• 能够按功能向下钻取。
• #，在不同平台功能中使用应用的用户百分比 (R28) 。
• #，% 与选项卡交互。
• #，% 与消息传递扩展交互。
• #， % 与机器人交互。
• #，% 与会议中的侧面板交互。
• #，%与 Stageview 交互。		 • 应用功能的参与和价值属性。
• 如果任何平台功能的使用率较低，请考虑深入了解易用性和增值细节。
任务成功
• 完成核心操作的用户百分比。 • 轻松执行核心任务。
• 报告一周级别。
• Teams 应用中的用户旅程 - 包含用户下车的漏斗图视图。 • 用户旅程中的摩擦点。
• 在租户级别向下钻取。
• 核心操作的失利分数：
核心操作的丢失分数
其中，
L = Lostness
N = 执行核心操作时执行的不同和唯一步骤的数目。
S = 执行核心操作（包括重复步骤）时执行的步骤总数。
R = 完成核心操作所需的最小步骤数。		 • 区域钻取的易用性提供有关区域设置需求的见解。
• 在区域和租户级别向下钻取。
• 如果丢失程度高于 0.4，则应用应改善用户体验，使用户更容易完成核心操作。
• 执行核心操作所用的平均时间。 • 易于使用。
• 同时报告在 Teams 应用外执行核心操作的时间。
• 一个月内执行核心操作的平均次数。
• 一个月内执行关键业务事件的平均次数。		 • 参与的级别和强度。
• 查看月份趋势。
• 按租户向下钻取。

保留

目标：通过增加用户参与应用的好处来提高产品粘性。

用户保留期衡量用户返回使用产品的频率。 它实质上是衡量参与频率。 如果用户获得更多权益，则反复使用你的产品。 他们使用产品越多，切换应用的成本就越高。 例如，当用户开始添加他们作为应用的一部分跟踪的任务或操作项时，它可能有助于更好地跨项目协调，并逐渐增加放弃任务管理系统的成本。

提示

  • 与单个功能用户相比，使用多个 Teams 平台功能的用户比单个功能用户更好地保留 20 到 35pp。
  • 在第一周将新用户转换为参与的平台用户可提高保留率。
  • 与通过通知被动使用信息的用户相比，在应用中执行创建事件的用户的保留期更高。 创建事件取决于你的业务。 例如，创建票证、创建新帖子、项目板等。
  • 一个月内多次使用 (>5 次) 的应用具有比月更好的保留期。 使用频率更高的定期用例可提高保留期。
评估 见解
• 新用户保留队列分析 (周、月) 。 • 按客户端划分的保留期细分 - Teams 桌面、Web 和移动应用、非 Teams Web 应用。
• 向下钻取到租户级别。
• 用户流失 14 天、28 天、56 天、72 天。 • 用户流失。
• 向下钻取到租户级别。
• 平台功能和功能向下钻取。
• 按客户端细分的流失：Teams 桌面、Web 和移动应用、非 Teams Web 应用。
• #，在多个范围内使用应用的百分比。 • 参与深度。 目标是鼓励跨不同范围使用应用。
• #，使用应用 1 个以上功能的用户百分比。 • 参与深度。
• 目标是鼓励用户使用应用支持的不同平台功能。
• [核心操作 1,2..] 之间的平均时间 per user。 • 参与强度。
• 租户级别的报表。
• 目标是减少此时间，以促进定期使用。
• 执行创建事件的用户百分比。
• 执行消耗事件的用户百分比。 跟踪：
  - 读取机器人消息的回执。
  - 通知单击。		 • 参与强度。 与纯使用相比，执行创建事件的用户更多时，应用保留期会更高。
• 具有高重复使用量的应用功能或范围。 • 应用的高度维持性功能或功能。

幸福

目标：为最终用户提供足够的差异化价值，提高其支付意愿。

幸福感旨在衡量用户对你产品的态度，并可以转化为他们愿意付费，并转介其他用户使用你的产品。 幸福大多是自我报道的。 有一些领先指标，例如收集反馈、满意度评分。 滞后指标包括新订阅和用户更倾向于使用 Teams 应用而不是其他方式。

提示

  • 幸福感应在正确的时间根据上下文进行衡量，并针对用户进行上下文化。 在固定日期发送通用调查可能无法提供准确的幸福感度量，因为用户可能不记得他们的体验。
  • 集成产品驱动的反馈捕获和分级机制，让用户在完成核心操作后在流中轻松提交反馈和评分。
  • 提供足够的产品支持、支持人员，让用户阐明其查询、报告 bug 并提供反馈。
评估 见解
• 应用 Net 提升程序分数 (来自应用源的 NPS) 。 • 净发起人分数。
• Microsoft Entra ID 和租户信息。
• 满意或满意用户的百分比。 • 在租户级别向下钻取。
• 报告随时间推移的趋势。
• 使用 Teams 应用与 Web 或移动应用的用户百分比。 • 按月报告。
• 完成核心操作后，用户对体验的反馈。 • 引入在完成核心操作后收集反馈的产品主导方式， (例如应用内消息来) 提交反馈。

后续步骤

使用分析服务规划代码检测