Uber 如何借助 Restore Credentials API 每年减少 400 万次手动登录

Uber 是全球最大的拼车公司，为数百万人提供出行服务，同时还支持送餐、医疗运输和货运物流。访问的简便性对于其成功至关重要；当用户切换到新设备时，他们希望能够无缝过渡，而无需重新登录 Uber 应用或通过基于短信的一次性验证码进行身份验证。这种频繁的设备更替既带来了挑战，也带来了提高用户留存率的机遇。

为了保持用户连续性，Uber 的工程师采用了恢复凭据功能。在美国，每年有 40% 的人会更换智能手机，因此这项功能至关重要。在评估用户需求并进行代码原型设计后，他们在 Uber 乘客应用中引入了 Restore Credentials 支持。为了验证恢复凭据是否有助于消除重新登录时的阻碍，Uber 团队开展了一项为期五周的 A/B 实验，并取得了成功。集成后，手动登录次数有所减少。根据 Uber 庞大的用户群进行推算，预计每年可减少 400 万次手动登录。

使用 Restore Credentials 消除登录障碍

过去，我们曾尝试使用常规数据备份和 BlockStore 等解决方案在新设备上恢复账号，但这两个解决方案都需要直接从源设备向目标设备共享身份验证令牌。由于令牌信息高度敏感，这些解决方案仅在一定程度上用于在目标设备上预填充登录字段，并减少登录流程中的一些阻碍。通行密钥也用于提供安全、快速的登录方法，但其由用户发起的性质限制了其对无缝设备转换的影响。

“有些用户不会每天都使用 Uber 应用，但他们希望在需要时，应用能正常运行，”Uber 的 Android 工程师 Thomás Oliveira Horta 说道。“当您在新 Android 手机上打开应用叫车时，却发现自己已退出登录，这可能会让您感到不快和扫兴。”

借助恢复凭据功能，工程师们成功弥合了这一差距。该 API 会在旧设备上生成一个唯一令牌，当用户在标准初始配置流程中恢复其应用数据时，该令牌会无缝且静默地移至新设备。此过程利用 Android OS 的原生备份和恢复机制，确保恢复密钥与应用数据一起安全传输。这种简化的方法可确保账号转移过程简单安全，既能满足 Uber 的安全要求，又无需用户进行任何额外输入，也不会产生任何开发开销。

注意：恢复密钥和通行密钥使用相同的底层服务器实现。不过，当您将这些数据保存到数据库中时，必须对它们进行区分。这种区分至关重要，因为用户创建的通行密钥可由用户直接管理，而恢复密钥由系统管理，并且不会显示在界面中。

Thomás 表示：“在 Uber 乘客应用中采用恢复凭据后，我们开始看到用户持续使用该功能。”“在当前发布阶段，平均每天有 10,000 位唯一身份用户使用‘恢复凭证’功能登录，他们在新设备上首次打开应用时，体验非常顺畅。我们预计，一旦向整个用户群全面推广，这一数字将翻倍。”

实现方面的注意事项

Thomás 表示：“集成非常简单，只需按照示例代码和文档在 Android 端进行细微调整即可。”“我们的应用已经使用 Credential Manager 来管理通行密钥，后端只需进行一些细微调整。因此，我们只需将 Credential Manager 依赖项更新到最新版本，即可使用新的 Restore Credentials API。我们通过相同的通行密钥创建流程创建了一个恢复密钥，当我们的应用在新设备上启动时，应用会尝试静默检索通行密钥，从而主动检查此密钥。如果找到恢复密钥，系统会立即使用该密钥自动登录用户，而无需手动登录。”

在整个开发过程中，Uber 的工程师在实现过程中遇到了一些挑战，从选择正确的入口点到在后端管理凭证生命周期。

选择“恢复凭证”入口点

在选择使用哪个 Restore Credentials 入口点进行恢复时，工程师们仔细权衡了完美无缝的用户体验与实现简单性之间的利弊。最终，他们优先选择了一种能够实现理想平衡的解决方案。

Thomás 表示：“这可以在应用启动期间进行，也可以在设备恢复和设置期间使用 BackupAgent 在后台进行。”“后台登录入口点对用户来说更加顺畅，但它给后台操作带来了挑战，并且需要使用 BackupAgent API，这会增加 Uber 这样庞大的代码库的复杂性。”他们决定在首次启动应用期间实现该功能，这比手动登录要快得多。

应对服务器端挑战

在与后端 WebAuthn API 集成期间，出现了一些服务器端问题，因为这些 API 的设计假设始终需要进行用户验证，并且所有凭证都会列在用户的账号设置中；但这两个假设都不适用于非用户管理的恢复凭证密钥。

Uber 团队通过对 WebAuthn 服务进行细微调整解决了这一问题，他们创建了新的凭证类型，以便将通行密钥与恢复凭证区分开来，并进行适当的处理。

管理恢复凭证生命周期

Uber 的工程师在管理后端凭证密钥时面临多项挑战，后端工程师 Ryan O’Laughlin 提供了专业支持：

• 防止孤立密钥：一个重大挑战是制定删除已注册公钥的策略，以防止它们成为“孤立密钥”。例如，卸载应用会删除本地凭据，但由于此操作不会向后端发出信号，因此会在服务器上留下未使用的密钥。
• 平衡密钥生命周期：密钥需要有足够长的“生存时间”来处理极端情况。例如，如果用户执行备份和恢复操作，然后手动退出旧设备，则密钥会从该旧设备中删除。不过，该密钥在服务器上必须保持有效，以便新设备仍可使用。
• 支持多台设备：由于用户可能有多台设备（并且可以从其中任何一台设备发起备份和恢复），因此后端需要为每个用户支持多个恢复凭据（每台设备一个）。

Uber 的工程师通过制定规则来应对这些挑战，这些规则会根据新凭证注册和凭证使用情况来删除服务器端密钥。

该功能在短短两个月内就完成了设计、开发、测试和交付。随后，为期五周的 A/B 实验（用于验证用户对该功能的反应）顺利进行，并取得了不容置疑的结果。 

使用恢复凭据防止用户流失

通过消除新设备上的手动登录，Uber 留住了那些原本可能会在新设备上放弃登录流程的用户。客户便利性的提升体现在一系列改进上，虽然这些改进乍一看可能微不足道，但考虑到 Uber 庞大的用户群，其影响是巨大的：

• 手动登录（短信动态密码、密码、社交账号登录）减少了 3.4%。
• 需要短信动态密码的登录费用降低了 1.2%。
• Uber 的访问率（成功进入应用主屏幕的设备所占百分比）提高了 0.575%。
• 完成行程的设备数量增加了 0.614%。

如今，Restore Credentials 正逐步成为 Uber 乘客端应用的标准功能，实验组中已有超过 95% 的用户注册了该功能。

在新设备设置期间，用户可以从备份中恢复应用数据和凭据。在选择恢复 Uber 且后台处理完成后，该应用会在新设备首次启动时自动让用户登录。

“恢复凭证”功能带来的隐形而巨大的影响

在未来几个月内，Uber 计划扩大 Restore Credentials 的集成范围。根据试用结果，他们预计这项变更每年将减少 400 万次手动登录。通过简化应用访问流程并消除关键痛点，他们正在积极打造一个更满意、更忠诚的客户群，让每一次乘车都成为愉悦的体验。

“集成 Google 的 RestoreCredentials 后，我们能够在新设备上提供用户期望的无缝‘即开即用’体验，”Uber 首席产品经理（核心身份）Matt Mueller 说道。“这直接带来了可观的收入增长，证明了减少登录阻碍是提高用户互动度和留存率的关键。”

准备好提升应用的登录体验了吗？

了解如何通过恢复凭证功能在切换设备时提供顺畅的登录体验，并阅读博文了解详情。在最新 Canary 版 Android Studio Otter 中，您可以验证集成，因为新功能有助于模拟备份和恢复机制。

如果您刚开始接触 Credential Manager，可以参阅我们的官方文档、Codelab 和示例，获取集成方面的帮助