웹뷰 결제에서 전환이 사라지는 근본 원인은 무엇인가

가장 흔한 오해가 "웹뷰도 결국 브라우저니까 웹 태그가 그대로 돌 것"이라는 가정입니다. Google Analytics for Firebase 공식 문서가 안내하는 구조는 다릅니다. 웹뷰 안에서 실행되는 자바스크립트 코드는 네이티브 Firebase Analytics에 직접 접근할 수 없고, 자바스크립트 핸들러가 플랫폼을 판별해 네이티브 브릿지로 데이터를 넘기면 네이티브 구현이 Firebase Analytics를 호출하는 3단 구조를 거칩니다.

즉 앱 안에 웹 결제 페이지를 띄웠을 때, 그 페이지의 전환 이벤트는 기본적으로 앱 세션과 이어지지 않습니다. 브릿지를 구현하지 않았다면 이벤트는 앱 쪽에 존재하지 않고, 웹 쪽으로 보내더라도 앱 사용자로 집계되지 않습니다. "가끔 누락"이 아니라 "구조적으로 안 잡히는" 문제이므로, 원인을 태그 설정이나 네트워크에서 찾으면 시간을 잃습니다.

안드로이드 쪽 브릿지는 어떻게 구성되나

안드로이드에서는 네이티브 코드가 addJavascriptInterface로 자바스크립트 인터페이스를 등록합니다. 공식 예시에서 등록 이름은 AnalyticsWebInterface이며, 해당 클래스는 @JavascriptInterface로 표시된 두 메서드를 노출합니다. 하나는 logEvent(String name, String jsonParams)이고 다른 하나는 setUserProperty(String name, String value)입니다.

웹 페이지 쪽에서는 window.AnalyticsWebInterface.logEvent(name, JSON.stringify(params)) 형태로 호출합니다. 여기서 실무 사고가 나는 지점은 세 곳입니다. 등록 이름 오타, 매개변수를 객체 그대로 넘겨서 문자열 직렬화가 빠진 경우, 그리고 결제 완료 페이지가 웹뷰가 아닌 외부 브라우저나 PG사 도메인으로 벗어나 브릿지 객체가 존재하지 않는 경우입니다. 특히 세 번째는 코드가 멀쩡한데도 값이 안 잡히는 대표적 원인입니다.

iOS 쪽 브릿지는 어떻게 다른가

iOS는 WKWebView에 WKScriptMessageHandler를 firebase라는 이름으로 등록하는 방식입니다. 웹 페이지는 window.webkit.messageHandlers.firebase.postMessage()로 command 값이 logEvent 또는 setUserProperty인 객체를 전달하고, 네이티브 핸들러가 이를 받아 Firebase Analytics를 호출합니다.

호출 형태 자체가 안드로이드와 완전히 다르다는 점이 중요합니다. 웹 페이지 스크립트는 두 인터페이스의 존재를 각각 확인해 분기해야 하며, 한쪽만 구현하면 다른 OS에서 전량 누락됩니다. 실제로 "안드로이드는 잡히는데 iOS만 0건"으로 나타나는 사례 대부분이 이 분기 누락입니다. 진단할 때 OS별로 전환 건수를 나눠 보는 것만으로 원인 범위가 절반으로 줄어듭니다.

어떤 순서로 진단해야 원인을 좁힐 수 있나

순서를 지키는 것이 중요합니다. 첫째, 결제 완료 시점의 화면이 여전히 앱 웹뷰 안인지, 외부 브라우저로 이탈했는지 확인합니다. 둘째, OS별로 전환 건수를 분리해 한쪽만 0인지 양쪽 다 0인지 봅니다. 셋째, 웹뷰 안에서 브릿지 객체가 실제로 존재하는지(안드로이드는 window.AnalyticsWebInterface, iOS는 window.webkit.messageHandlers.firebase) 개발팀과 함께 확인합니다. 넷째, 이벤트 이름과 매개변수 규격이 GA4 제약 안에 있는지 점검합니다.

네 번째 단계에서 자주 걸립니다. GA4는 이벤트 이름 40자, 이벤트당 매개변수 최대 25개, 매개변수 이름 40자, 매개변수 값은 일반적으로 100자로 제한합니다. 결제 페이지에서 상품 정보를 통째로 넘기다 값이 잘리면 이벤트는 들어오는데 전자상거래 보고서에 제대로 뜨지 않습니다. 구매 이벤트는 items 배열에 item_id, item_name, price, quantity를 필수로 포함해야 하고, 필수 매개변수가 빠지면 커스텀 이벤트로 처리돼 전자상거래 보고서에 표시되지 않습니다.

수정한 뒤에는 무엇을 검증해야 하나

누락을 고쳤다면 이번에는 반대 방향의 사고를 확인해야 합니다. Firebase 웹뷰 문서는 iOS에서 SDK가 가능한 경우 인앱 구매를 계속 자동 기록하며, 수동으로 기록한 인앱 구매 이벤트를 중복 제거하지 않는다고 명시합니다. 누락을 메우려고 수동 로깅을 덧붙였다가 자동 기록과 겹치면 구매가 두 번 집계됩니다.

그래서 검증은 주문번호 단위 유일성으로 합니다. 수정 배포 후 최소 며칠간, 결제 시스템의 주문번호 목록과 분석 도구의 구매 이벤트를 주문번호 기준으로 대조해 일대일로 맞는지 확인합니다. 여기서 한 주문번호가 두 건으로 잡히면 중복이고, 결제 시스템에만 있고 분석 도구에 없으면 여전히 누락입니다. 이 대조표를 만들지 않고 대시보드 총합만 보면 누락과 중복이 서로를 가려 숫자가 맞아 보이는 상황이 생깁니다.