블로그 › 데이터
데이터

GA4 구매 이벤트(purchase)가 0으로 안 잡힐 때 확인하는 순서 5가지

대시부스터 팀2025-09-15 · 읽는 데 약 12분

주문 문자는 계속 울리는데 GA4 purchase는 야속하게 0. 결제도 됐고 정산에도 돈이 들어왔는데 이벤트만 안 잡히면 미치죠. 원인은 거의 정해져 있어요. 제일 흔한 다섯 가지를 순서대로만 짚으면 그 안에서 대부분 걸립니다.

📋 목차 · 급하면 골라 읽으세요
  1. 먼저 확인할 것: 이벤트가 아예 안 나가는가, 나가는데 안 보이는가
  2. 원인 1~2: 완료 페이지 태그 누락과 PG 리다이렉트
  3. 원인 3~5: 파라미터·동의·측정 ID
  4. 15분 만에 끝내는 점검 순서

새벽에 주문 알림 문자는 계속 울리는데, GA4 실시간 화면에는 구매가 하나도 안 잡혀요. 결제는 분명히 됐고 정산 내역에도 돈이 들어왔는데 이벤트 탭 purchase는 야속하게 0. 저도 이거 때문에 며칠을 날렸어요. 로그를 아무리 봐도 스크립트는 멀쩡한데 왜 안 잡히지... 결론부터 말하면 원인은 거의 정해져 있어요. 흔한 다섯 가지만 순서대로 짚으면 대부분 그 안에서 걸립니다.

이 글은 "결제 완료 페이지까지는 뜨는데 purchase만 안 들어오는" 상황에 초점을 맞춰요. 회원가입이나 장바구니 이벤트는 잘 잡히는데 유독 구매만 비는 케이스요. 자사몰이든 카페24든 스마트스토어(외부 스크립트 심는 경우)든 원리는 같아요.

먼저 확인할 것: 이벤트가 아예 안 나가는가, 나가는데 안 보이는가

디버깅 전에 이걸 갈라야 해요. 둘은 완전히 다른 문제거든요. GA4 좌측 관리 → DebugView를 켜 놓고 본인 폰이나 시크릿 창으로 실제 결제를 한 번 태워보세요(소액 상품 하나 만들어서 테스트하면 편해요). DebugView에 purchase가 뜨면 "나가긴 하는데 리포트에 안 보이는" 문제고, 아예 안 뜨면 "이벤트 자체가 안 나가는" 문제예요.

DebugView는 디버그 모드가 켜진 세션만 보여줘요. 크롬 확장 프로그램 'GA Debugger'를 켜거나, 스크립트에 debug_mode: true를 임시로 넣으면 바로 잡혀요. 테스트 끝나면 꼭 빼시고요.

둘로 갈렸으면 아래 순서대로 내려가면 돼요. 위에서부터 흔한 순서로 배치했어요.

순서의심 원인증상 특징확인 방법
1결제 완료 페이지에 태그 미로딩다른 이벤트는 정상, 구매만 0완료 URL 소스에서 gtag 존재 확인
2외부 결제창(PG) 리다이렉트로 세션 끊김구매는 뜨는데 소스가 전부 directreferral 제외 목록 확인
3이벤트 파라미터 형식 오류purchase는 있는데 매출 0원DebugView에서 value·items 확인
4Consent Mode·동의배너로 태그 차단일부 유저만 안 잡힘동의 전/후 발동 여부 비교
5측정 ID·데이터스트림 불일치DebugView엔 뜨는데 리포트 0G- 아이디 대조

원인 1~2: 완료 페이지 태그 누락과 PG 리다이렉트

1. 결제 완료 페이지에만 태그가 안 붙은 경우. 이게 압도적으로 흔해요. GTM이나 gtag를 전 페이지 공통 영역에 넣었다고 생각하는데, 완료 페이지(주문 감사 페이지)는 별도 템플릿을 쓰는 쇼핑몰이 많아요. 특히 자사몰 솔루션은 "주문 완료" 화면이 시스템 페이지라 공통 헤더가 안 먹는 경우가 있어요. 완료 URL로 이동한 뒤 페이지 소스 보기(Ctrl+U)에서 gtagG-XXXXXXX를 검색해 보세요. 안 나오면 그냥 그 페이지엔 태그가 없는 거예요. 원인 찾기 끝.

2. 외부 결제창을 거치며 세션이 끊기는 경우. 토스페이먼츠, KG이니시스, 네이버페이 같은 PG창으로 넘어갔다가 우리 완료 페이지로 돌아오죠. 이때 브라우저가 그 PG 도메인을 '유입 출처(referral)'로 인식해서 세션을 새로 끊어버려요. 그러면 구매 이벤트는 잡히는데 매출 소스가 전부 direct나 PG 이름으로 뭉개져요. 진짜 광고로 들어온 매출이 어디서 왔는지 안 보이는 거죠. 이건 관리 → 데이터 스트림 → 태그 설정 구성 → 원치 않는 추천 나열에 결제사 도메인을 넣어 해결해요.

referral 제외에 이런 도메인들을 넣어두세요. pg.tosspayments.com, inicis.com, pay.naver.com, kcp.co.kr, settle.co.kr 등. 안 넣으면 광고 성과 측정이 통째로 어긋나서, ROAS를 실제보다 낮게 착각하게 돼요. 이게 생각보다 크더라고요...

이 두 개만 잡아도 절반 이상은 해결돼요. 특히 "purchase는 0인데 결제는 됨" 조합이면 90%는 1번이에요.

이 글의 숫자, 내 가게 걸로 바로 보고 싶다면대시부스터가 매출·순수익·ROAS·정산을 실시간으로 계산해요 · 카드 없이 7일 무료
무료로 시작하기 →

원인 3~5: 파라미터·동의·측정 ID

3. 이벤트는 나가는데 파라미터가 깨진 경우. DebugView에 purchase가 뜨는데 value가 0이거나 items가 비어 있으면 이 케이스예요. GA4 권장 이벤트 구조를 안 지키면 이벤트는 카운트되지만 매출이 0원으로 들어와요. 가장 흔한 실수 세 가지만 볼게요. 하나, currency를 안 넣음(value가 있어도 통화가 없으면 매출 무시돼요). 둘, 가격을 "39,000"처럼 콤마 붙은 문자열로 보냄(숫자 39000이어야 해요). 셋, items 배열 없이 총액만 보냄. 아래처럼 맞춰야 해요.

파라미터잘못된 값올바른 값
value"39,000원"39000
currency(누락)"KRW"
transaction_id(누락, 중복집계 원인)"주문번호 고유값"
items[][{item_name, price, quantity}]

transaction_id를 빼먹으면 완료 페이지 새로고침·뒤로가기 재진입 때마다 구매가 중복 집계돼요. 반대로 매출이 뻥튀기되는 거죠. 이 값은 꼭 주문번호로 채워주세요.

4. 동의 관리(Consent Mode)나 쿠키 배너가 태그를 막는 경우. PIPA·개인정보 동의 배너를 붙였다면, 유저가 동의하기 전에는 GA 태그가 아예 발동 안 하도록 막혀 있을 수 있어요. 그런데 결제 완료 페이지는 대부분 유저가 배너를 안 건드리고 지나가는 지점이라, 동의 이벤트 없이 완료 페이지에 도달하면 purchase가 통째로 유실돼요. "일부 유저만 안 잡힘"이면 이걸 의심하세요. GTM 태그의 실행 조건에 동의 상태가 걸려 있는지 확인하고, 없으면 발동 조건을 손봐야 해요.

5. 측정 ID·데이터스트림이 다른 경우. DebugView엔 분명 뜨는데 보고서만 0이면 십중팔구 이거예요. 개발용 속성과 운영용 속성 두 개를 만들어 놓고 스크립트엔 옛날 G- 아이디가 박혀 있는 식이죠. 지금 데이터가 들어오는 스트림의 G- 아이디와, 실제 사이트 소스에 박힌 아이디를 한 글자씩 대조해 보세요. 웹+앱 통합 속성이거나 UA(구버전) 아이디가 섞여 있으면 여기서 어긋나요.

참고로 GA4 리포트는 실시간 말고는 24~48시간 지연이 정상이에요. 어제 결제가 오늘 리포트에 없다고 바로 버그로 몰지 마세요. 실시간 화면이나 DebugView에서 먼저 확인하는 게 순서예요.

서버 사이드로 한 겹 더 받쳐두면 이 다섯 개 중 상당수가 원천 차단돼요. 브라우저 태그가 광고 차단·리다이렉트·동의 배너에 막혀도, 서버에서 결제 확정 시점에 이벤트를 직접 쏘면 유실이 확 줄거든요. 대시부스터의 픽셀 부스터(서버 전송)도 같은 원리로, 브라우저에서 놓친 구매를 서버에서 메꿔서 실제 전환을 더 온전히 잡아줘요.

그리고 GA4 숫자를 아무리 잘 맞춰도, 그건 '매출'이지 '순수익'이 아니에요. 광고비·PG수수료·원가·부가세 다 빼고 나면 통장에 얼마 남는지는 또 다른 얘기죠. 저는 GA4로 유입·전환을 보고, 실제 남는 돈은 원가와 수수료·세금까지 뺀 실시간 순익 대시보드로 따로 봐요. 두 숫자를 헷갈리면 "매출은 느는데 왜 돈이 안 모이지" 하는 함정에 빠지거든요.

15분 만에 끝내는 점검 순서

정리하면 이렇게 내려가면 돼요. 하나, DebugView 켜고 실제 소액 결제 한 번 태우기. 둘, purchase가 뜨는지 안 뜨는지로 두 갈래 나누기. 안 뜨면 완료 페이지 소스에서 태그 검색(원인 1) → 동의 조건 확인(원인 4). 뜨는데 이상하면 value·items·currency 형식 확인(원인 3) → 소스는 direct뿐인지 referral 제외 확인(원인 2) → 그래도 리포트에 없으면 측정 ID 대조(원인 5). 이 다섯 관문을 순서대로 지나면 원인이 안 걸리는 경우가 거의 없어요.

급하면 원인 1과 2만 먼저 보세요. 실무에서 신고 들어오는 "purchase 0" 문의는 이 두 개가 대부분이에요. 나머지 셋은 매출 숫자가 이상하거나 일부만 빠질 때 파고들면 돼요.

Q. 결제도 되고 DebugView에도 purchase가 뜨는데 왜 보고서만 0인가요?

거의 측정 ID 불일치예요(원인 5). 데이터가 실제로 들어오는 데이터스트림의 G- 아이디와, 사이트 소스에 박힌 아이디가 같은지 한 글자씩 대조하세요. 개발·운영 속성을 따로 만들어 두고 옛날 아이디를 그대로 둔 경우가 많아요. 그리고 실시간 말고 일반 보고서는 24~48시간 지연이 정상이라는 점도 같이 확인하고요.

Q. 구매는 잡히는데 매출이 실제보다 부풀려져요.

transaction_id(주문번호)를 안 보내서 완료 페이지 새로고침·뒤로가기 때마다 중복 집계되는 경우가 1순위예요. 주문번호 고유값을 꼭 넣으세요. 반대로 PG 도메인이 referral로 안 걸러져서 세션이 쪼개지면 전환 소스가 뭉개지기도 해요.

Q. 광고 차단 프로그램 쓰는 유저는 어차피 못 잡는 거 아닌가요?

브라우저 태그만 쓰면 그래요. 요즘 결제 유저의 상당수가 광고 차단·앱 인앱브라우저를 써서 브라우저 이벤트가 통째로 유실돼요. 이걸 메꾸려면 서버에서 결제 확정 시점에 이벤트를 직접 쏘는 서버 사이드 전송(CAPI 계열)을 같이 붙이는 게 답이에요.

핵심 정리

GA4는 유입까지, 실제 남는 돈은 대시부스터로

purchase 이벤트를 다 맞춰도 그건 매출일 뿐이에요. 광고비·PG수수료·원가·부가세까지 뺀 진짜 순수익을 실시간으로 보고, 브라우저에서 놓친 구매는 픽셀 부스터가 서버에서 메꿔줘요.

7일 무료로 시작하기 →
# GA4# 구매이벤트# 전환추적# 이커머스분석# purchase
대시부스터 팀

월 매출 수억 원대 쇼핑몰을 직접 운영하며, 사장님들이 감이 아니라 숫자로 장사하도록 돕는 도구를 만들어요. 이 블로그에는 실제로 써 본 것만 적습니다.

← 이전 글
북극성지표(North Star Metric), 쇼핑몰은 뭘로 잡아야 할까 · 매출 말고 '재구매 고객 수'로 바꾼 이야기