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

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

请务必规划开发 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 或移动应用的用户百分比。 • 按月报告。
• 完成核心操作后,用户对体验的反馈。 • 引入在完成核心操作后收集反馈的产品主导方式, (例如应用内消息来) 提交反馈。

后续步骤