Conditional UI ログイン完了
Conditional UI ログイン完了は、ユーザーが識別子を入力する場合と、フィールドレベルでのパスキー入力支援が利用可能な場合のプレサーバーログインパスを比較します。サーバー側でのパスキー成功率がほぼ完璧に見える一方で、実際のConditional UIのパフォーマンスは、フィールドの連携、ユーザーの選択、最終的なログイン完了、そして速度に依存する理由を示しています。
Conditional UIが実際に失敗する場所: 3つの測定ポイント
Conditional UI (CUI) は通常、サーバー側の成功率という単一の数値として報告されます。この数値はフローの最後に位置し、ほぼ完璧に見えます。しかし、ユーザーが実際に離脱する前の2つの数値を以下に示します。
これはサーバー通信前の瞬間です。提案が表示され、ユーザーがそれを選択し、ブラウザの検証が完了します。ここでの離脱は、ユーザーがプロンプトを閉じる、アカウントを切り替える、ローカルでロック解除できない、デバイス上に利用可能なクレデンシャルがない、または署名付きリクエストが作成される前に放棄したことを意味します。
別のCUIの試行、自動入力、または手動入力へのフォールバックを経て、最終的にログインが成功します。これはユーザー向けの実質的な完了率です。
この数値はサーバーの信頼性を測るのに役立ちますが、Conditional UIのユーザーエクスペリエンスが既に機能した後の結果です。
Conditional UIが導入率に直結するポイント
決定的な数値は、ブラウザがConditional UIをサポートしているかどうかではありません。実際のユーザーが適切なタイミングで適切なパスキーの提案をどれだけ頻繁に目にし、アカウントの混乱やパスワードマネージャーの迂回、手動でのフォールバックなしにログインに到達できるかです。
| プラットフォーム | パスキー提案割合 | これが意味すること |
|---|---|---|
| macOS | 高 | ほとんどの支援入力において提案が表示されます。 |
| Windows | 低 | 利用可能なローカル パスキー を持つデスクトップユーザーが少ないため、CUI の起動頻度は低くなります。 |
これらのシグナルを使用して、独自の展開状況を読み解いてください。
クレデンシャルのカバレッジ不足、別デバイスにあるパスキー、不適切なフィールド設定、パスワードマネージャーのオーバーレイ、RPとアカウントコンテキストの不一致、またはクレデンシャル基盤が十分に構築されていない展開に注意してください。
ユーザーはサインインできていますが、直接的ではありません。最適化の目標はスピードと直接性です。識別子の迂回を減らし、リカバリーをサポートし、コンテキストが十分に強力な場合は認識済みデバイスやワンタップ入力を利用してください。
- 最終的なログインの完了は、同一ログインプロセス内の後続のインタラクションに統合されます。ユーザーはアカウントを切り替えたり、プロンプトを閉じたり、CUIを再試行したり、最終的なログイン完了前に手動入力へフォールバックしたりする可能性があります。
- 有効なConditional UIアサーションは、サーバー側でほぼ常に受け入れられます。測定のギャップはアサーションが存在する前に発生します。そのため、サーバー側のみのレポートは、実際のログイン入力の体験よりも良好に見えます。
- アシスト入力におけるConditional UIの割合は、展開されているデバイスの構成とプロダクトの運用期間に依存します。多くのユーザーが現在のデバイスではなくスマートフォンに利用可能なパスキーを保持しているため、Windowsデスクトップの展開ではローカルの提案基盤が小さくなることがよくあります。
- 健全な自動入力の動作は、健全なConditional Createの前提条件です。逆の視点についてはConditional Create Rateを参照してください。ここでは、自動入力の品質が、パスワードログイン成功後にパスキーがどれだけ頻繁に自動作成されるかを予測します。
参考資料
厳選されたCorbadoの調査および主要な参考文献。