(https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fo3yk1ol9fdu9d2yj4e0f.png)

대부분의 팀이 너무 늦게 알아차리는 격차

GA4는 로그인 트래킹을 통해 로그인 퍼널(funnel) 전환율 하락이 발생했음을 알려주는 데는 능숙합니다. 하지만 그 원인이 무엇인지는 훨씬 못 알려줍니다.

이는 당연하게 들릴 수 있지만, 인증 과정이 단순한 사용자 이름 및 비밀번호 양식 이상으로 복잡해지면 실제 문제가 됩니다. 현대의 로그인 흐름에는 Passkey, WebAuthn 프롬프트, 소셜 로그인 리디렉션, OTP 재시도, 네이티브 자격 증명 선택기(credential pickers), 인앱 브라우저, 폴백 경로 등이 포함됩니다. 이 중 하나라도 오류가 발생하면, 일반적인 분석 도구는 근본 원인 대신 전환 누락만을 보여줄 뿐입니다.

여기서 핵심 경계가 있습니다: 제품 분석은 퍼널 이동을 측정하는 반면, 인증 관측 가능성(authentication observability)은 인증 실패를 설명합니다.

GA4가 실제로 잘하는 것들

공정하게 말하자면, GA4는 로그인 관련 보고서에 유용합니다.

다음과 같은 질문들에 대해 잘 작동합니다:

• 로그인 페이지에 도달한 사용자는 몇 명인가?
• 어떤 로그인 방법이 가장 많이 클릭되는가?
• 버튼 순서를 재배열한 후 결제 완료율이 변했는가?
• 로그인 마찰(sign-in friction)이 재방문 또는 회원가입 완료에 영향을 주었는가?

만약 질문이 퍼널 모양, 비즈니스 결과 상관관계, 또는 실험 측정에 관한 것이라면, GA4로 충분히 할 수 있습니다.

예를 들어, login_started, passkey_clicked, login_success와 같은 이벤트를 모델링한 다음 코호트(cohort)별로 변이형을 비교할 수 있습니다. 이는 제품 및 성장 팀이 변경 사항이 전반적인 전환율을 개선했는지 여부를 파악하는 데 도움을 줍니다.

하지만 이것은 퍼널 수준에서 무슨 일이 일어났는지만 답할 뿐입니다. 그 아래에 있는 실패한 인증 과정을 설명해주지는 못합니다.

로그인 디버깅 중 GA4가 무너지는 이유

주요 문제는 간단합니다: GA4는 이벤트(events)를 저장할 뿐, 인증 여정(authentication journeys)을 저장하지 않습니다.

실제 로그인 시도는 다음을 포함할 수 있습니다:

실제 로그인 시도는 다음을 포함할 수 있습니다:

• 기능 검사(capability check)
• 네이티브 패스키 프롬프트(native passkey prompt)
• 자격 증명 제공업체 선택(credential-provider selection)
• 생체 인식 단계(biometric step)
• 소셜 제공업체로의 리디렉션(redirect to a social provider)
• OTP 폴백(OTP fallback)
• 최종 세션 생성(final session creation)

만약 이 단계 중 하나라도 실패하면, GA4는 일반적으로 의식(ceremony)의 맥락을 이해할 네이티브 방법이 없습니다. 팀이 메서드(method), 단계(step), 환경(environment), 오류(error), 그리고 폴백 경로(fallback path)에 대한 별도의 계측(instrumentation)을 구축하지 않는 한, 실패는 종종 이탈(abandonment)로 나타납니다.

이는 특히 클라이언트 측 실패에서 고통스럽습니다. 사용자는 WebAuthn 시간 초과를 겪거나, 생체 인식 프롬프트를 취소하거나, Safari에서 리디렉션 쿠키를 잃거나, Android의 자격 증명 관리자 문제에 직면할 수 있습니다. 퍼널 대시보드(funnel dashboard)에서는 이 모든 것이 거의 동일하게 보일 수 있습니다. 즉, 사용자가 시작했지만 완료하지 않은 것처럼 보이는 것입니다.

근본 원인 분석을 위해 필요한 누락된 맥락

로그인 실패를 디버깅하려면 이벤트 카운트 이상의 것이 필요합니다. 흐름이 벗어난 정확한 환경과 단계를 알아야 합니다.

일반적인 인증 조사에서는 다음과 같은 차원(dimension)이 필요할 수 있습니다:

차원	중요한 이유
로그인 방식	패스키, 비밀번호, OTP, 소셜 로그인은 모두 다르게 실패함
...
이 경우 타이밍도 중요합니다. 사고는 종종 좁고 높은 카디널리티(high-cardinality)의 슬라이스에 존재하는데, 예를 들어 특정 브라우저 버전 내의 인앱 브라우저 하나 또는 Android 자격 증명 선택기 회귀(credential picker regression) 같은 경우입니다. GA4는 그러한 종류의 빠른 진단적 슬라이싱에 최적화되어 있지 않습니다.

이 글에서 잘 지적하고 있습니다: GA4는 하락을 확인하는 데 도움을 줄 수는 있지만, 근본 원인이 WebAuthn 시간 초과였는지, Safari가 리디렉션 쿠키를 차단했는지, Android 자격 증명 선택기 회귀 때문인지, 소셜 제공업체 장애 때문인지, 또는 사용자가 생체 인식 프롬프트를 취소했는지는 일반적으로 알려주지 못합니다.

인증 관측 가능성이 별도의 계층인 이유

인증 관측 가능성(Authentication observability)은 GA4를 대체하는 것이 아니라 보완합니다.

GA4는 광범위한 보고(funnel trends, experiment outcomes, and downstream business impact)에 사용하고, 인증 관측 가능성(authentication observability)은 GA4가 잘 답변하지 못하는 인증 관련 질문(어떤 방법이 실패했는지, 어떤 코호트가 영향을 받았는지, 어느 단계에서 문제가 발생했는지, 사용자가 복구되었는지 여부 등)을 위해 사용하세요.

이는 엔지니어링 영역을 넘어 중요합니다. 프로덕트 매니저, 성장 팀, IAM(Identity and Access Management) 소유자, 지원팀, 인시던트 대응 담당자 모두 동일한 근본적인 인증 여정(auth journey)이 필요하지만, 필요한 상세 수준은 다릅니다.

Corbado는 대규모 B2C 기업을 위한 패스키 관측 가능성 및 도입 플랫폼입니다.

실질적인 핵심 내용은 간단합니다. 만약 대시보드가 로그인 전환율 하락을 보여준다면, GA4는 종종 조사의 시작점일 뿐, 답은 아닙니다.

전체 분석 보기를 읽어보세요.