인스타그램 광고 리포트를 보면 클릭도 괜찮고 장바구니 담기도 꽤 나옵니다. 그런데 결제 완료만 유독 적습니다. 직접 광고를 눌러 주문을 해 보면 이유가 보입니다. 카드사 앱으로 넘어갔다가 돌아오는 순간 주문서가 초기화되거나, 휴대폰 본인인증 창이 하얗게 멈춥니다. 문제는 이 장면이 어떤 리포트에도 "실패"로 찍히지 않는다는 점입니다. 이 글은 그 조용한 손실을 우리 몰 숫자로 계산해 보는 방법을 다룹니다.
인앱 브라우저가 무엇이고 Google 로그인이 왜 막히는지는 인앱 브라우저 링크 문제 정리와 인스타그램 인앱 Google 로그인 차단 글에서 다뤘습니다. 여기서는 "그래서 얼마나 잃고 있나"에 집중합니다.
인앱 브라우저에서 결제가 끊기는 지점
자사몰 결제 흐름에서 인앱 브라우저가 걸림돌이 되는 구간은 대체로 네 곳입니다.
- 간편결제·앱카드 전환: 카카오페이, 네이버페이, 토스페이나 카드사 앱카드는 결제 화면에서 외부 앱을 호출했다가 다시 쇼핑몰로 돌아오는 구조입니다. 인앱 브라우저에서는 이 왕복 과정에서 결제창이 닫히거나, 돌아왔을 때 결제 결과를 받지 못하는 경우가 생깁니다.
- 휴대폰 본인인증: 통신사 인증 앱을 오가는 방식이라 결제와 같은 이유로 끊기기 쉽습니다. 성인 인증이 필요한 상품이나 가입 시 본인인증을 받는 몰이라면 영향이 큽니다.
- 로그인 상태: 평소 Safari나 Chrome에 로그인해 둔 고객도 인앱에서는 처음 방문한 사람처럼 보입니다. 비밀번호를 다시 입력해야 하고, 저장된 배송지와 카드도 쓸 수 없습니다.
- Google 로그인: Google 계정 로그인만 열어 둔 몰이라면 인앱에서는 아예 진행되지 않습니다.
어느 구간이 얼마나 끊기는지는 결제대행사, 결제 수단, 앱 버전에 따라 달라집니다. 그래서 일반론보다 우리 몰 데이터를 직접 보는 편이 정확합니다.
1단계 우리 몰의 인앱 유입 비중 확인하기
먼저 전체 모바일 방문 중 인앱 브라우저로 들어온 비중을 봅니다. 비중이 5%라면 손실이 커도 우선순위가 낮고, 40%라면 이야기가 달라집니다.
| 확인 위치 | 보는 곳 | 인앱으로 보이는 값 | 주의할 점 |
|---|---|---|---|
| GA4 | 탐색 보고서의 브라우저 측정기준 | Safari (in-app), Android Webview | 어느 앱인지까지는 구분되지 않음 |
| 단축 링크 분석 | 리퍼러 항목 | instagram, kakaotalk 같은 앱 이름 | 단축 링크를 거친 클릭만 집계됨 |
| 서버 접속 로그 | User-Agent 문자열 | Instagram, KAKAOTALK, NAVER(inapp) 등 | 개발자 도움이 필요함 |
가장 빠른 방법은 GA4입니다. 탐색 보고서에서 기기 카테고리를 모바일로 거르고 브라우저별 세션을 보면, Safari (in-app)와 Android Webview를 합친 값이 대략적인 인앱 비중입니다. 여기에 세션 소스(instagram, kakao 등)를 함께 놓으면 어느 채널에서 인앱 유입이 많은지 보입니다.
광고나 카카오톡 채널 메시지에 단축 링크를 쓰고 있다면 링크 분석의 리퍼러도 참고할 만합니다. 인앱 브라우저는 리퍼러를 비워 보내는 경우가 많은데, Edgelink는 이런 클릭을 User-Agent로 판별해 kakaotalk, instagram 같은 앱 이름으로 분류합니다.
2단계 인앱과 일반 브라우저의 퍼널을 나란히 놓기
비중을 확인했다면 이제 어디서 새는지 봅니다. GA4 퍼널 탐색 보고서에서 단계를 상품 상세 조회, 장바구니, 주문서 진입(begin_checkout), 결제 정보 입력(add_payment_info), 구매(purchase) 순으로 만들고, 브라우저 측정기준으로 인앱과 일반 브라우저를 나눕니다.
예를 들어 가상의 쇼핑몰 A의 한 달 데이터가 아래와 같다고 해 보겠습니다. 모든 숫자는 설명을 위한 예시입니다.
| 단계 | 일반 모바일 브라우저 | 인앱 브라우저 |
|---|---|---|
| 상품 상세 조회 | 30,000 | 20,000 |
| 장바구니 | 3,600 (12%) | 2,200 (11%) |
| 주문서 진입 | 1,500 | 900 |
| 결제 정보 입력 | 1,200 (주문서의 80%) | 690 (77%) |
| 구매 완료 | 1,050 (주문서의 70%) | 450 (50%) |
이 표에서 읽어야 할 것은 단계별 전환율 차이가 어디서 벌어지느냐입니다. 쇼핑몰 A는 상세 조회에서 주문서까지는 인앱과 일반 브라우저가 거의 같습니다. 그런데 결제 정보를 입력한 뒤 구매 완료로 넘어가는 구간에서 격차가 확 벌어집니다. 상품이나 가격의 문제가 아니라 결제 수단 호출 이후, 즉 앱 전환과 본인인증 구간에서 끊긴다는 신호입니다.
반대로 장바구니 단계부터 인앱이 크게 낮다면 결제보다는 로그인 문제일 가능성이 큽니다. 비회원 장바구니가 없어 로그인을 요구하는 몰에서 자주 보이는 모양입니다.
3단계 손실 추정 공식에 숫자 넣기
이제 손실을 금액으로 바꿉니다. 공식은 단순합니다.
월 손실 주문 수 = 인앱 주문서 진입 수 × (일반 브라우저 결제 완료율 - 인앱 결제 완료율)
월 손실 매출 = 월 손실 주문 수 × 평균 객단가
쇼핑몰 A에 대입하면 이렇습니다.
- 인앱 주문서 진입 수: 900건
- 결제 완료율 차이: 70% - 50% = 20%p
- 월 손실 주문 수: 900 × 0.2 = 180건
- 평균 객단가 45,000원을 곱하면 월 손실 매출은 약 810만 원
여기서 바로 "매달 810만 원을 버리고 있다"고 결론 내리면 안 됩니다. 인앱으로 들어온 고객은 광고를 스치듯 누른 사람이 많아, 같은 환경에서도 원래 구매 의향이 조금 낮을 수 있습니다. 그래서 이 값은 상한으로 보고, 실제로 되찾을 수 있는 몫은 절반 안팎으로 잡는 편이 안전합니다. 쇼핑몰 A라면 월 400만 원 전후가 현실적인 목표치입니다.
광고비와 함께 보면 판단이 더 쉬워집니다. 인스타그램 광고에 월 500만 원을 쓰는데 인앱 결제 손실이 400만 원이라면, 광고 효율을 높이는 소재 실험보다 결제 경로를 고치는 쪽이 먼저입니다. 단계별 전환율 계산은 전환율 계산기로 빠르게 확인할 수 있습니다.
손실을 줄이는 방법
손실 지점이 결제와 본인인증 구간이라면 해결 방향은 하나입니다. 고객이 결제 단계에 도착하기 전에 평소 쓰는 Chrome이나 Safari로 옮겨 주는 것입니다. 브라우저를 옮기면 앱 전환 왕복이 정상적으로 돌아오고, 로그인 상태와 저장된 결제 정보도 그대로 이어집니다.
다만 모든 링크를 브라우저로 넘기는 것은 답이 아닙니다. 브라우저로 옮겨 가는 동안 1~3초짜리 안내 화면이 끼는데, 앱 안에서 보고 끝나는 링크에는 이 화면이 그 자체로 새 이탈 지점이 됩니다.
| 링크 종류 | 브라우저 전환 | 이유 |
|---|---|---|
| 광고에서 상품 상세·기획전으로 | 켬 | 장바구니와 결제까지 이어지는 경로 |
| 카카오톡 채널 메시지의 구매 링크 | 켬 | 메시지를 보고 바로 결제하는 고객이 많음 |
| 회원가입·본인인증 페이지 | 켬 | 인증 앱 전환과 Google 로그인 구간 |
| 이벤트 공지, 매거진 콘텐츠 | 끔 | 앱 안에서 읽고 끝나는 경우가 대부분 |
| 스마트스토어 상품 링크 | 끔 | 결제가 네이버페이 안에서 처리되는 별도 흐름 |
사이트 쪽에서 할 수 있는 일도 함께 챙깁니다. 비회원 주문을 열어 두면 로그인 구간의 손실이 줄고, Google 로그인만 있다면 카카오·네이버 로그인을 함께 제공하는 것이 좋습니다. 결제대행사에 인앱 환경에서 앱 전환 후 복귀가 실패한 사례가 있는지 문의해 보는 것도 방법입니다.
적용 전후를 공정하게 비교하는 법
브라우저 전환을 켰다면 효과를 숫자로 확인해야 합니다. 그냥 지난달과 이번 달을 비교하면 시즌, 소재, 할인율이 섞여 판단이 흐려집니다. 같은 기간에 두 갈래를 나란히 돌리는 방식이 가장 깔끔합니다.
- 같은 목적지로 단축 링크 두 개를 만들고, 하나만 브라우저 전환을 켭니다.
- 목적지 주소에 UTM을 달리 붙여
utm_content=escape_on,utm_content=escape_off처럼 구분합니다. UTM은 UTM 빌더로 만들 수 있습니다. - 광고 세트나 메시지 발송 대상을 반씩 나눠 두 링크를 씁니다.
- 2~4주 뒤 GA4에서 utm_content별 주문서 진입 대비 구매 완료율을 비교합니다.
두 갈래의 결제 완료율 차이에 인앱 주문서 진입 수와 객단가를 곱하면, 3단계에서 추정한 손실 중 실제로 회수한 금액이 나옵니다. 링크를 둘로 나눠 비교하는 방법은 링크로 A/B 테스트하는 법에 더 자세히 정리해 두었습니다.
Edgelink로 결제 링크만 브라우저 전환하기
Edgelink의 브라우저 전환은 링크마다 켜고 끄는 토글입니다. Hobby 플랜 이상에서 쓸 수 있고, 무료 플랜에는 포함되지 않습니다.
- 켜 둔 링크를 인앱에서 누르면 앱 이름과 이동할 주소가 담긴 안내 화면이 1~3초 보인 뒤 Chrome이나 Safari로 열립니다. iPhone의 NAVER, Daum, Facebook, Messenger, TikTok, Snapchat 인앱처럼 자동으로 넘어가지 않는 곳에서는 방문자가 버튼을 한 번 눌러 이동합니다.
- 지원하는 인앱은 Instagram, Threads, Facebook, Messenger, 카카오톡, NAVER, Daum, TikTok, Line, Snapchat 10종입니다.
- 목적지 주소의 UTM은 그대로 남고, 광고 클릭에 붙어 온 fbclid·gclid 같은 클릭 식별자도 목적지까지 전달됩니다. 광고 플랫폼의 전환 보고가 끊기지 않는 이유는 광고 클릭 식별자 글에서 따로 설명합니다.
- 꺼 둔 링크와 일반 브라우저에서 연 클릭은 안내 화면 없이 바로 이동합니다.
계산 전에 우리 몰이 어느 구간에서 영향을 받는지 먼저 훑어보고 싶다면 무료 인앱 손실 진단기에 사이트 주소를 넣어 보세요. 로그인, 결제, 본인인증, 측정 네 영역의 손실 가능성을 보여 줍니다.
이번 주에 해 볼 점검 순서
- GA4에서 모바일 세션 중 Safari (in-app)와 Android Webview 비중을 확인합니다.
- 같은 퍼널을 인앱과 일반 브라우저로 나눠, 격차가 가장 큰 단계를 찾습니다.
- 손실 공식에 우리 몰 숫자를 넣고, 그 절반을 회수 목표로 잡습니다.
- 인스타그램 DM이나 카카오톡 나에게 보내기로 상품 링크를 보내 실제 결제를 끝까지 시도해 봅니다.
- 결제로 이어지는 링크에만 브라우저 전환을 켜고, 켠 링크와 끈 링크를 2~4주 나란히 비교합니다.
손실액이 광고비와 비슷한 규모로 나온다면, 다음 달 예산 회의에서 소재보다 결제 경로 이야기를 먼저 꺼낼 근거가 생긴 셈입니다.
자주 묻는 질문
인앱 브라우저에서 결제가 실패하는 이유는 무엇인가요?
간편결제나 앱카드 결제는 결제 화면에서 카드사·간편결제 앱을 호출했다가 다시 돌아오는 구조인데, 인앱 브라우저에서는 이 앱 전환과 복귀가 매끄럽지 않은 경우가 있습니다. 휴대폰 본인인증도 같은 방식으로 끊기기 쉽고, 평소 브라우저의 로그인 상태가 없어 다시 로그인해야 하는 부담도 더해집니다. 실제 동작은 결제대행사와 앱 버전에 따라 다릅니다.
인앱 결제 손실액은 어떻게 계산하나요?
손실 주문 수는 인앱에서 주문서까지 들어온 수에 (일반 브라우저 결제 완료율 - 인앱 결제 완료율)을 곱해 구합니다. 여기에 평균 객단가를 곱하면 월 손실 매출 추정치가 나옵니다. 채널마다 구매 의향이 달라 이 값은 상한에 가까우므로, 절반 정도를 회수 가능한 범위로 보는 편이 보수적입니다.
브라우저 전환을 모든 링크에 켜면 안 되나요?
권하지 않습니다. 브라우저로 옮겨 갈 때 1~3초 안내 화면이 보이는데, 공지나 콘텐츠처럼 앱 안에서 보고 끝나는 링크에는 이 화면이 불필요한 단계가 됩니다. 결제, 가입, 본인인증으로 이어지는 링크에만 켜는 것이 손실을 줄이면서 새 이탈을 만들지 않는 방법입니다.
브라우저 전환은 무료 플랜에서도 쓸 수 있나요?
Edgelink 브라우저 전환은 Hobby 플랜 이상에서 링크별로 켜고 끌 수 있습니다. 무료 플랜에는 포함되지 않습니다.
인앱에서 연 링크를 Chrome·Safari로 옮겨 열어요.
