产品指标

它代表什么

它不代表什么

示例

• 安装量

• [每日|每月] 活跃用户

• 第[7|30]天留存率

庞大的应用程序安装量或使用量通常意味着一些事情：

• 它表明了产品经过精心设计的实现，特别是在 Web 和 Android 平台上。在这些平台上兼容各种底层 API 和浏览器版本的复杂迷宫本身就是一个值得赞扬的成就。

• 它标志着产品能够在各种地理位置之间有效运行，每个地区都有其独特的互联网连接、隐私/法律规定和手机制造商。

• 它表明产品更好地适配了 Android 硬件的碎片化，以及存在于 Apple 平台上的多种形态因素（如 MacOS、tvOS、watchOS 等）。

• 它体现了工程师解决不常见设备和浏览器上的微妙 bug 的能力。

• 它强调了工程师在保护生态系统健康方面所起到的关键作用，特别是对于那些真正无处不在的应用程序(十亿安装量)以及可能造成系统范围灾难的应用程序来说。

• 与普遍看法相反，十亿次安装并不能有效地衡量客户端工程师在构建新兴产品方面的能力。

• 用更轻松的语气来说，这就像构建一个每秒提供 50 万个查询的后端 API。虽然令人印象深刻，但并不是工程师能力的唯一标志，也不是产品整体活力和增长轨迹的明确衡量指标。

• 如果缺乏可靠的质量指标的支持（下文有详述），那么安装量指标就有点像一个没有披风的超级英雄。当然，它看起来很华丽，可能会给你带来一些街头信誉，但这还不足以真正拯救世界。单独来看，它主要只是炫耀产品增长，缺乏真正展示影响力的深度。所以，我们不要让它在没有全副武装的情况下投入战斗，好吗？

• Mitra改进了我们的文本编辑器，使其能够在小众 Android 厂商设备上运行，为我们1亿DAU的产品扩大了1%的用户群。

• Akira在 Web 标准上的贡献促进了我们从 2K 用户的私人预览向跨浏览器 1 百万用户公共预览的转变。

• Mireya使用 C 实现了核心的移动功能，使我们能够在推出 Android 后仅两个月就推出 iOS 应用，增加了 1 百万日活跃用户。

• Ila对 Apple 平台 API 的深入了解使我们能够在 WWDC 发布后两周内向 10 万用户推出 Apple Silicon 版本的应用。

• 由于 Laya 解决了影响数千名没有模拟功能的 Android 用户的 bug，我们在印度的客户满意度评分提高了 3% 。

• Amal对本地存储的优化是让高级用户在连续30天内高度参与产品而不会耗尽磁盘空间的关键。

产品指标

它代表什么

它不代表什么

示例

程序崩溃

程序崩溃的减少（或超过 99% 无崩溃）意味着：

• 展示了工程师有远见和严谨的工程能力，他们提供了出色的客户端软件，相比后端，客户端软件更加难以回滚。

• 遵循了 Web、Apple 和 Android 平台不断变化的最佳实践。

• 能够构建在不同计算环境中无缝运行的软件，这对于 Android 来说尤为重要。这突显了团队的技术多样性和对各种计算环境的深入理解，确保了所有平台上的最佳功能和用户体验。

应用程序不发生崩溃也可能是因为它本身就很简单。这些指标需要与产品支持的流程和功能数量一起进行校准。

Maya将支持 4 种不同身份验证登录流程的崩溃率从每天 1 万次降低到了不到 1 千次。

• 启动延迟

• 应用程序大小

• 内存占用

• 构建时间

• 大多数生产级应用程序都具有复杂的启动路径，不仅涉及业务逻辑的初始化，还有一系列复杂的依赖项。快速启动对于留住用户来说至关重要。对P95冷启动的任何实质性改进都需要细致的分析、建立假设和严格的实验。

• 具有合理内存占用的应用程序表明采用了工程最佳实践，例如高效加载实体和重用对象。这在拥有大量低端设备的Android平台上尤为重要。

• 与 Web 工程相比，原生移动开发的一个痛点是相对较长的编译时间。能够显著缩短编译时间的努力将在开发者生产力方面产生多重效应。这可以通过缓存构建工件、优化依赖关系（消除无关依赖项）和使用库动态链接等方法来实现。

• Alice在过去的6个月里将iOS冷启动的P95降低了25%。Alice通过仔细分析启动路径和延迟加载初始屏幕不需要的库实现了这一点。

• Yu重写了视图模型缓存。这提高了内存利用率，并在过去6个月内减少了15%的OOM崩溃。

热修复

适度数量的热修复通常意味着：

• 稳定、高水准的发布，能够经受住用户需求和技术挑战的考验，展示出对交付卓越、可靠软件解决方案的承诺。

• 深思熟虑的实验标志，突显了对功能测试和实现的战略性方法，进一步增强了软件的韧性和以用户为中心的设计。

Kriti设计了一个在客户端允许我们在后端远程配置客户端参数而无需重新发布应用程序的实验框架，并且不违反应用商店的政策。我们平均每个季度的热修复数量已从 6 个降至少于 2 个。

后端错误 (4XX) (以及其他后端指标)

后端错误率的降低可能意味着：

• 客户端实现的更正，减少了错误的 RPC。这表明系统通信和协调得到了改善。

• 提高了客户端的可配置性，允许在启动后进行参数调整，确保更好的性能和对项目需求和问题的响应。

Indra经历了一个辛苦的过程来理解是什么情况导致客户端发送错误参数并在后端触发了 400 错误。这使我们值班时的误报率降低了30%以上。

指标

它代表什么

它不代表什么

外部问题修复

尽管这可能被视为一种虚荣指标，但对于面临用户报告问题的开源客户端应用程序来说，它通常具有重大意义。这个指标强调了处理和解决这些问题的重要性，有助于维护和提升项目在开源社区中的可靠性和声誉。

• 对于习惯宣告大规模 Bug 被消除的团队，这个指标失去了效力。如果大量 Bug 经常被一笔勾销而不加以解决，那么它就不能作为可靠的绩效和改进衡量指标。

• 此外，这个指标基于某种诚信假设。

发布次数

频繁的发布意味着：

• 持续的 Bug 修复和改进，体现了改善产品并确保其可靠性和有效性的承诺。

• 提高了发布能力，克服了历史上的挑战，并展示了改进的更有效率的发布流程。

• 努力与生态系统的其他部分保持同步，包括依赖项和平台更新，确保产品保持最新、安全，并与生态系统的其他元素兼容。

• 大量的发布也可能源于不稳定性，说明需要进行频繁更新来解决持续出现的问题，并确保产品安预期运行。

• 这一观点强调了在产品稳定性与发布频率之间取得平衡的重要性，避免对团队和最终用户造成过重的负担。

NPS/CSAT

尽管客户满意度调查具有通用性，但通常会受到客户端应用程序的影响。应用程序是用户与服务之间的第一个、最具体且频繁的互动。

• 糟糕的体验可能会留下深刻的负面印象，难以抹去。

• 相反，出色的应用体验可以弥补服务特性、性能和价格方面的不足，给客户留下积极而持久的印象，有助于培养忠诚度和满意度。

可访问性/可用性指标

• 努力打造一款无障碍、包容的产品，供听力、视力、行动能力或语言障碍人士使用。

• 可用性通常表现为产品支持成本的降低。