如何衡量身份验证：指标、漏斗和转化跟踪

I’m happy to help translate the article, but I need the full text you’d like translated. Could you please paste the content (or the portions you want translated) here? Once I have the text, I’ll provide a Simplified Chinese translation while preserving the original formatting, markdown, and any code blocks or URLs.

介绍

身份验证是产品的前门。如果登录缓慢、令人困惑或不稳定，用户不会“稍后再试”。他们会离开或联系支持。问题在于可见性：产品分析往往只停留在“登录页面已查看”，而身份系统则报告后端结果，却缺乏用户的上下文。Authentication analytics 通过将身份验证视为一次旅程——成功、失败、流失、登录耗时以及每种结果背后的原因——来弥合这一鸿沟。

登录数据分散在不同团队和工具之间。安全团队监控威胁，产品团队跟踪转化漏斗，身份团队负责基础设施运营。每一种视角单独来看都不完整。严格的策略可能看起来是成功，却在悄悄阻止合法用户。产品团队看到放弃，但无法判断用户是输错密码、未收到多因素认证（MFA）代码，还是遇到客户端错误。身份团队看到错误码，但这些很少直接转化为收入、支持负荷或风险权衡，除非有额外的上下文信息。

身份验证问题很少表现为单一的关键绩效指标（KPI）。它们会在转化率（登录失败和额外步骤）、支持成本（密码重置、锁定）以及导致误报并让真实客户感到沮丧的风险控制之间泄漏价值。

核心指标

A practical metrics set usually covers:

数据来源

1. Identity Provider logs – 权威的后端记录，包含成功、失败、挑战以及提供者特定的错误代码。
2. Frontend analytics – 在联系提供者之前的意图信号（例如，登录页面浏览、“sign in”点击）。这捕获了从未到达服务器的客户端失败。
3. Observability & security tooling – 性能监控（延迟、异常）以及威胁信号和异常模式。

规范化事件与漏斗模型

为了使来源可比，团队将事件规范化为共享模型。一个实用的漏斗通常如下所示：

auth_viewed → auth_method_selected → auth_attempt → auth_challenge_served → auth_challenge_completed → auth_success | auth_failure

关键是将 viewed 与 attempted 分开。用户可能在提交任何内容之前就退出，这些行为后端日志永远捕捉不到。通过标准化事件，你可以按设备、操作系统、浏览器、凭证管理器和认证方式进行细分。

仪表板与利益相关者视图

高价值使用场景

• 方法比较 – 在单一漏斗中比较认证方法。
• 会话调试 – 当支持升级“我无法登录”时，调查单个用户会话。
• 主动监控 – 在操作系统或浏览器变更导致流失之前检测其破坏。

挑战

困难的部分不是构建图表，而是将前端和后端数据拼接起来，定义一致的事件分类法，并在不同平台上对错误进行分类，因为相同的根本原因可能以多种变体出现。不断的操作系统和浏览器更新使得身份验证分析成为一项持续的工作，而不是一次性仪表板项目。