Conditional UI 登录完成度

Conditional UI 登录完成度比较了用户键入标识符时与提供字段级通行密钥帮助时的服务器前登录路径。它显示了为什么服务器端通行密钥成功率看起来近乎完美，而真实的 Conditional UI 性能取决于字段配置、用户选择、最终登录完成度和速度。

Q1 2026 · 三个测量点的 Conditional UI

Conditional UI 实际中断的位置：三个测量点

Conditional UI (CUI) 通常被报告为一个数字：服务端成功率。该数字处于流程的最末端，看起来近乎完美。而用户实际流失的两个更早阶段的数字如下。

1 首次建议交互 55–90% 用户选择并完成第一个可见的通行密钥建议

这是到达服务端之前的时刻：建议可见，用户选择它，浏览器验证完成。此处的流失意味着用户关闭了提示、切换账号、无法在本地解锁、设备上没有可用的凭据，或者在生成签名请求前放弃。

→

2 最终的 CUI 路径登录 90–95% 包含重试和回退后的最终登录成功率

登录最终成功，有时是在再次尝试 CUI、自动填充或手动输入回退之后。这是面向用户的完成率数据。

→

3 多数团队报告的指标 97–99% 提交签名请求后服务端验证成功

此数字对评估服务端可靠性很有用，但它的起点是在 Conditional UI 用户体验已经成功之后。

决定性的数字不是浏览器是否支持 Conditional UI。而是真实用户在合适时机看到正确的通行密钥建议，然后在没有账号混淆、密码管理器绕路或手动回退的情况下完成登录的频率。

平台	通行密钥建议占比	含义
macOS	高	在大多数辅助输入中均可看到建议。
Windows	低	拥有可用本地通行密钥的桌面用户较少，因此 CUI 触发频率较低。

使用这些信号来解读你自己的部署情况。

建议展示率低 资格缺口

检查是否缺乏凭据覆盖、通行密钥在其他设备上、字段绑定错误、密码管理器覆盖、RP/账号上下文不匹配，或者由于刚推出尚未建立足够的凭据基础。

间接完成 路由缺口

用户依然能登录，但不是直接登录。优化目标是速度和直接性：减少标识符绕路，支持恢复，并在上下文足够强的情况下使用受信任设备或一键登录入口。

最终登录完成率汇总了同一登录流程中的后续交互：在最终登录完成之前，用户可以切换账号、关闭提示、重试 CUI 或回退到手动输入。
有效的 Conditional UI 断言几乎总是被服务端接受；测量缺口出现在断言生成之前。因此，仅基于服务端的报告看起来比真实的登录输入体验更好。
辅助输入中的 Conditional UI 占比取决于部署的设备组合以及产品上线的时间。Windows 桌面端部署通常显示较小的本地建议基数，因为许多用户的可用通行密钥保存在手机上，而非当前设备。
健康的自动填充行为是健康的 Conditional Create 的先决条件。请参阅 Conditional Create Rate 了解反向视图，其中自动填充质量预示了在密码登录成功后通行密钥被自动创建的频率。

Corbado 精选研究与主要参考资料。