Conditional UI 로그인 완료
Conditional UI 로그인 완료는 사용자가 식별자를 입력할 때와 필드 수준의 패스키 도움말이 제공될 때의 서버 이전 로그인 경로를 비교합니다. 이는 서버 측 패스키 성공률이 완벽에 가까워 보일 수 있는 반면, 실제 Conditional UI 성능이 필드 연결, 사용자 선택, 최종 로그인 완료 및 속도에 의존하는 이유를 보여줍니다.
실제로 Conditional UI가 실패하는 지점: 세 가지 측정 포인트
Conditional UI(CUI)는 대개 단일 지표인 서버 측 성공률로 보고됩니다. 이 수치는 플로우의 가장 마지막 단계에 위치하여 거의 완벽에 가까워 보입니다. 사용자가 실제로 이탈하는 이전의 두 수치는 아래와 같습니다.
이는 서버 도달 전 단계입니다. 제안이 표시되고, 사용자가 이를 선택한 후 브라우저 검증이 완료되는 시점입니다. 여기에서의 이탈은 사용자가 프롬프트를 닫거나, 계정을 전환하거나, 로컬 잠금을 해제하지 못하거나, 기기에 사용할 수 있는 자격 증명이 없거나, 서명된 요청이 생성되기 전에 포기함을 의미합니다.
결국 로그인은 성공하며, 때로는 추가적인 CUI 시도, 자동 완성 또는 직접 입력하는 폴백 이후에 이루어지기도 합니다. 이는 사용자 대면 관점에서의 완료 수치입니다.
이 수치는 서버 안정성을 확인하는 데 유용하지만, Conditional UI 사용자 경험이 이미 성공적으로 작동한 이후의 결과를 나타냅니다.
Conditional UI가 도입으로 이어지는 지점
가장 중요한 수치는 브라우저의 Conditional UI 지원 여부가 아닙니다. 실제 사용자가 적절한 순간에 올바른 패스키 제안을 얼마나 자주 확인하고 계정 혼동, 비밀번호 관리자 우회 또는 수동 폴백 없이 로그인에 도달하는지가 중요합니다.
| 플랫폼 | 패스키 제안 점유율 | 의미 |
|---|---|---|
| macOS | 높음 | 대부분의 지원 입력에서 제안이 표시됩니다. |
| Windows | 낮음 | 사용 가능한 로컬 패스키를 가진 데스크톱 사용자가 적기 때문에 CUI가 덜 자주 발생합니다. |
다음 신호를 사용하여 자체 배포 상태를 파악하세요.
자격 증명 커버리지 누락, 다른 기기에 있는 패스키, 잘못된 필드 연결, 비밀번호 관리자 오버레이, RP/계정 컨텍스트 불일치 또는 자격 증명 기반이 충분히 구축되지 않은 배포 상태인지 확인하세요.
사용자가 로그인은 하지만 직접적으로 이루어지지는 않습니다. 최적화 목표는 속도와 직결성입니다. 식별자 우회를 줄이고 복구를 지원하며, 컨텍스트가 충분히 강력한 경우 인식된 기기 또는 원탭 로그인을 사용하세요.
- 최종 로그인 완료는 동일한 로그인 프로세스 내의 후속 상호작용과 병합됩니다. 즉, 사용자가 로그인을 최종적으로 완료하기 전에 계정을 전환하거나, 프롬프트를 닫거나, CUI를 재시도하거나, 직접 타이핑하는 폴백을 사용할 수 있습니다.
- 유효한 Conditional UI 어서션은 서버 측에서 거의 항상 수락됩니다. 측정 격차는 어서션이 존재하기 전 단계에 있습니다. 따라서 서버 전용 보고는 실제 로그인 진입 경험보다 더 양호하게 보입니다.
- 지원 입력 내에서 Conditional UI의 점유율은 배포된 기기의 구성 및 제품의 서비스 기간에 따라 달라집니다. Windows 데스크톱 배포의 경우, 많은 사용자가 현재 기기보다 휴대폰에 사용 가능한 패스키를 보관하므로 로컬 제안 기반이 더 작게 나타나는 경우가 많습니다.
- 건강한 자동 완성 동작은 건강한 Conditional Create의 전제 조건입니다. 비밀번호 로그인 성공 후 패스키가 얼마나 자주 자동으로 생성되는지 자동 완성 품질이 예측하는 반대 관점은 Conditional Create Rate를 참조하세요.
참고 자료
Corbado가 엄선한 연구 및 주요 참고 자료입니다.