Uber が Restore Credentials API を使用して手動ログインを年間 400 万回削減している方法

Uber は世界最大のライドシェア企業であり、何百万人もの人々を目的地に送り届けるとともに、フード デリバリー、医療輸送、貨物物流もサポートしています。アクセスの簡素化は、このサービスの成功に不可欠です。ユーザーが新しいデバイスに切り替える際、Uber アプリに再度ログインしたり、SMS ベースのワンタイム パスワード認証を行ったりすることなく、シームレスに移行できることが求められます。この頻繁なデバイスの入れ替えは、課題であると同時に、ユーザー維持率を高める機会でもあります。

ユーザーの継続性を維持するため、Uber のエンジニアは認証情報の復元機能に注目しました。これは、米国の 40% の人々が毎年スマートフォンを買い替える時代に不可欠なツールです。ユーザーの需要を評価し、コードのプロトタイプを作成した後、Uber 乗客アプリに認証情報の復元サポートを導入しました。認証情報の復元が再ログインの負担軽減に役立つことを検証するため、Uber チームは 5 週間にわたって A/B テストを実施し、成功を収めました。この統合により、手動ログインが削減されました。Uber の膨大なユーザーベース全体にわたって予測すると、年間 400 万回の手動ログインが削減されると推定されます。

Restore Credentials でログインの摩擦を解消

過去には、通常のデータ バックアップや BlockStore などのソリューションを使用して、新しいデバイスでアカウントを復元する試みが行われていましたが、どちらのソリューションも、ソースデバイスから移行先デバイスに認証トークンを直接共有する必要がありました。トークン情報は機密性が高いため、これらのソリューションは、移行先デバイスのログイン フィールドに事前入力し、ログインフロー中の摩擦を軽減するために、ある程度のみ使用されます。パスキーも安全で迅速なログイン方式を提供するために使用されますが、ユーザーが開始する必要があるため、シームレスなデバイス移行への影響は限定的です。

「Uber アプリを毎日使うわけではないユーザーも、必要なときにはすぐに使えることを期待しています」と、Uber の Android エンジニアである Thomás Oliveira Horta 氏は言います。「新しい Android スマートフォンでアプリを開いて配車をリクエストしようとしたときに、ログアウトされていることがわかると、不快で、がっかりする体験になる可能性があります。」

Restore Credentials を使用することで、エンジニアはこのギャップを埋めることができました。この API は、以前のデバイスで一意のトークンを生成します。このトークンは、ユーザーが標準のオンボーディング プロセス中にアプリデータを復元すると、新しいデバイスにシームレスかつサイレントに移動されます。このプロセスでは、Android OS のネイティブのバックアップと復元のメカニズムを利用して、アプリのデータとともに復元キーを安全に転送します。この合理化されたアプローチにより、シンプルで安全なアカウント移行が保証され、ユーザーによる追加の入力や開発オーバーヘッドなしで Uber のセキュリティ要件を満たすことができます。

注: 復元キーとパスキーは、同じ基盤となるサーバー実装を使用します。ただし、データベースに保存する場合は、それらを区別する必要があります。この区別は重要です。ユーザーが作成したパスキーはユーザーが直接管理できますが、復元キーはシステム管理であり、ユーザー インターフェースには表示されません。

「Uber の乗客向けアプリに Restore Credentials を導入したことで、一貫した利用が見られるようになりました」と Thomás 氏は言います。「現在のロールアウト段階では、1 日あたり平均 10,000 人のユニーク ユーザーが Restore Credentials を使用してログインしており、新しいデバイスで初めてアプリを開くときにシームレスなエクスペリエンスを享受しています。全ユーザーに展開すれば、この数字は倍増すると見込んでいます。」

実装に関する注意事項

「サンプルコードとドキュメントに沿って Android 側で微調整を行うだけで、統合は非常に簡単でした」と Thomás 氏は言います。「私たちのアプリはすでにパスキーに認証情報マネージャーを使用しており、バックエンドに必要な調整はわずかでした。そのため、認証情報マネージャーの依存関係を最新バージョンに更新するだけで、新しい Restore Credentials API にアクセスできるようになりました。同じパスキー作成フローで復元キーを作成し、新しいデバイスでアプリが起動されると、アプリはサイレント パスキー取得を試みて、このキーを事前に確認します。復元キーが見つかった場合は、すぐに使用されてユーザーが自動的にログインし、手動ログインはスキップされます。」

開発プロセス全体を通して、Uber のエンジニアは、適切なエントリ ポイントの選択からバックエンドでの認証情報のライフサイクルの管理まで、実装中にいくつかの課題に直面しました。

Restore Credentials のエントリ ポイントの選択

エンジニアは、 復元に使用する Restore Credentials エントリ ポイントを選択する際に、完全にシームレスなユーザー エクスペリエンスと実装の簡素化のトレードオフを慎重に検討しました。最終的に、理想的なバランスを実現するソリューションを優先しました。

「これは、アプリの起動時、またはデバイスの復元とセットアップ中にバックグラウンドで BackupAgent を使用して行われます」と Thomás 氏は述べています。「バックグラウンド ログインのエントリ ポイントは、ユーザーにとってよりシームレスですが、バックグラウンド オペレーションに課題があり、BackupAgent API を使用する必要がありました。これにより、Uber のような大規模なコードベースでは複雑さが増すことになります。」そこで、アプリの初回起動時にこの機能を実装することにしました。これは、手動ログインよりも大幅に高速です。

サーバーサイドの課題への対処 

バックエンドの WebAuthn API との統合中に、サーバーサイドでいくつかの課題が発生しました。これらの API の設計では、ユーザー認証が常に必要であり、すべての認証情報がユーザーのアカウント設定に一覧表示されることが想定されていました。しかし、ユーザーが管理しない復元認証情報キーでは、どちらの想定も機能しませんでした。

Uber チームは、WebAuthn サービスに軽微な変更を加え、パスキーと復元認証情報を区別して適切に処理する新しい認証情報タイプを作成することで、この問題を解決しました。

Restore Credentials のライフサイクルを管理する

Uber のエンジニアは、バックエンド エンジニアの Ryan O’Laughlin 氏の専門的なサポートを受けながら、バックエンドでの認証情報キーの管理においていくつかの課題に直面しました。

• 孤立した鍵の防止: 登録済みの公開鍵を削除して「孤立」を防ぐための戦略を定義することが大きな課題でした。たとえば、アプリをアンインストールするとローカル認証情報は削除されますが、このアクションはバックエンドに通知されないため、サーバーに未使用の鍵が残ります。
• 鍵の有効期間のバランス: 鍵には、エッジケースに対応できる十分な長さの「有効期間」が必要でした。たとえば、ユーザーがバックアップと復元を行い、古いデバイスから手動でログアウトすると、その古いデバイスから鍵が削除されます。ただし、新しいデバイスが引き続き使用できるように、鍵はサーバー上で有効なままである必要があります。
• 複数のデバイスのサポート: ユーザーが複数のデバイスを所有している可能性があるため（どのデバイスからでもバックアップと復元を開始できる）、バックエンドはユーザーごとに複数の復元認証情報をサポートする必要がありました（デバイスごとに 1 つ）。

Uber のエンジニアは、新しい認証情報の登録と認証情報の使用に基づいて、サーバーサイドの鍵を削除するルールを確立することで、これらの課題に対処しました。

この機能は、2 か月という短い開発およびテスト プロセスを経て、設計からリリースに至りました。その後、5 週間の A/B テスト（ユーザーによる機能の検証期間）がスムーズに実施され、確実な結果が得られました。 

Restore Credentials でユーザーの離脱を防ぐ

新しいデバイスでの手動ログインを不要にすることで、Uber は、新しいデバイスでのログインフローを放棄した可能性のあるユーザーを維持しました。この顧客の利便性の向上は、さまざまな改善に反映されています。一見するとわずかな改善に見えるかもしれませんが、Uber のユーザーベースの規模を考えると、その影響は甚大です。

• 手動ログイン（SMS OTP、パスワード、ソーシャル ログイン）が 3.4% 減少。
• SMS OTP を必要とするログインの費用が 1.2% 削減。
• Uber のアクセス率（アプリのホーム画面に正常に到達したデバイスの割合）が 0.575% 増加。
• 移動が完了したデバイスが 0.614% 増加。

現在、Restore Credentials は Uber の乗客向けアプリの標準機能になりつつあり、試験群の 95% 以上のユーザーが登録しています。

新しいデバイスのセットアップ時に、ユーザーはバックアップからアプリデータと認証情報を復元できます。復元対象として Uber を選択し、バックグラウンド プロセスが完了すると、新しいデバイスでアプリを初めて起動したときに、ユーザーは自動的にログインされます。

目に見えないが大きな影響を与える Restore Credentials

今後数か月以内に、Uber は Restore Credentials の統合を拡大する予定です。この試験運用の結果から、この変更により年間 400 万回の手動ログインが不要になると推定されています。アプリへのアクセスを簡素化し、主な課題を解消することで、1 回の乗車ごとに、より満足度の高い、ロイヤルティの高い顧客ベースを積極的に構築しています。

「Google の RestoreCredentials を統合することで、ユーザーが新しいデバイスに期待するシームレスな『すぐに使える』エクスペリエンスを提供できるようになりました」と、Uber のリード プロダクト マネージャー（コア ID）である Matt Mueller 氏は述べています。「このことは、収益の目に見える増加に直接つながり、ログインの摩擦を減らすことがユーザー エンゲージメントとユーザー維持の鍵であることを証明しています。」

アプリのログイン エクスペリエンスを向上させる準備はできましたか？

Restore Credentials を使用してデバイスを切り替える際に、シームレスなログイン エクスペリエンスを実現する方法について、ブログ投稿で詳細をご確認ください。Android Studio Otter の最新の Canary 版では、バックアップと復元のメカニズムをモックする新機能を使用して、統合を検証できます。

認証情報マネージャーを初めて使用する場合は、統合に役立つ公式ドキュメント、Codelab、サンプルをご覧ください。