GA4 구매 이벤트 안잡힘: 끊긴 구간 찾는 4단계 진단 순서

GA4에서 구매 이벤트가 안 잡히는 문제의 원인은 대부분 태그 하나가 아닙니다. 이벤트가 만들어지고, 전송되고, 리포트에 보이기까지 거치는 세 구간 중 어딘가에서 데이터가 끊긴 것입니다.

그래서 진단할 때는 태그를 다시 설치하는 것보다 어느 구간에서 끊겼는지 먼저 나누는 것이 중요합니다. 구간만 정확히 잡으면 확인할 항목이 절반 넘게 줄어들고, 고친 뒤에도 같은 문제가 다시 생기지 않습니다.

아래에서 구간 구분 방법, 구간별 점검 항목, 그리고 "잡히긴 하는데 숫자가 틀린" 경우까지 순서대로 설명합니다.

1. GA4 구매 이벤트 안잡힘, '어디서' 끊겼는지부터 나누기

구매 이벤트가 0건으로 보인다고 해서 데이터가 정말 하나도 없는 건 아닐 수 있습니다.

GA4 표준 보고서에는 보통 24~48시간의 처리 지연이 있습니다. 어제 태그를 고쳤는데 오늘 보고서가 비어 있다면, 고장이 아니라 아직 반영이 안 된 상태일 가능성도 있습니다.

그래서 처음에는 아래 세 구간 중 어디에서 끊겼는지부터 확인합니다.

이 표의 핵심은 확인 순서를 거꾸로 해도 된다는 점입니다.

DebugView에 purchase가 정상적으로 뜨고 transaction_id·value·currency까지 들어와 있다면 ①과 ②는 문제가 없는 겁니다. 그때는 태그를 건드릴 필요 없이 ③ 보고 구간만 보면 됩니다.

반대로 DebugView에 purchase가 안 뜬다면 보고서 설정을 아무리 바꿔도 소용이 없습니다.

-> 핵심: DebugView 한 화면으로 "태그 문제인지, 보고 문제인지"를 먼저 가르세요.

DebugView를 쓸 때 자주 놓치는 조건

DebugView는 디버그 모드가 켜진 기기의 이벤트만 보여줍니다.

GTM 미리보기 모드로 접속했거나, Google Analytics Debugger 확장 프로그램을 켜야 해당 기기의 이벤트가 표시됩니다. 일반 브라우저로 테스트 결제를 해놓고 DebugView가 비었다며 태그 문제로 판단하는 경우가 실무에서 꽤 자주 생깁니다.

또 광고 차단 확장 프로그램이 켜진 브라우저로 테스트하면 GA4 요청 자체가 차단됩니다. 테스트 전용 브라우저 프로필을 따로 두는 편이 안전합니다.

2. 구매 이벤트 발생 단계 점검: 태그·데이터레이어·완료 페이지

DebugView에 purchase가 뜨지 않는다면 대부분 ① 발생 구간 문제입니다. 확인할 지점은 크게 네 가지입니다.

① 결제 완료 페이지에 태그가 실제로 실행되는가

가장 기본이지만 가장 많이 어긋나는 부분입니다.

GTM에서 purchase 태그의 트리거를 "페이지 경로에 /order_complete 포함"처럼 URL 기준으로 걸어둔 경우, 쇼핑몰 솔루션 업데이트나 결제 방식 변경으로 완료 페이지 주소가 바뀌면 그날부터 이벤트가 끊깁니다.

특히 간편결제를 새로 붙였을 때 주의해야 합니다. 일반 카드결제는 기존 완료 페이지로 돌아오는데, 간편결제는 다른 경로의 완료 페이지로 돌아오는 구조가 흔합니다. 이렇게 되면 전체 매출은 그대로인데 GA4 구매만 서서히 줄어드는 형태로 나타납니다.

-> 0건이 아니라 "줄었다"면 결제 수단별로 완료 페이지 URL을 하나씩 확인해야 합니다.

② 데이터레이어에 ecommerce 객체가 제대로 들어가는가

GTM으로 전자상거래를 구현할 때는 데이터레이어에 아래와 같은 구조로 값이 들어가야 합니다.

• event: "purchase"

• ecommerce.transaction_id: 주문번호

• ecommerce.value: 결제 금액(숫자형)

• ecommerce.currency: "KRW"

• ecommerce.items: 상품 배열(item_id 또는 item_name 필수)

여기서 자주 생기는 실수는 세 가지입니다.

첫째, 이벤트 이름의 대소문자입니다. GA4는 이벤트 이름의 대소문자를 구분합니다. "Purchase"나 "purchase_complete"로 보내면 GA4는 이를 권장 이벤트인 purchase로 인식하지 않습니다. 이벤트는 들어오지만 수익 창출 보고서에는 잡히지 않는 이유가 됩니다.

둘째, 데이터레이어 변수 버전입니다. GTM의 데이터레이어 변수가 예전 방식으로 설정돼 있거나 경로를 "ecommerce.purchase.actionField.id"처럼 구 유니버설 애널리틱스 구조로 읽으면, 값이 undefined로 전송됩니다.

셋째, 푸시 순서입니다. 데이터레이어 푸시보다 GTM 태그가 먼저 실행되면 값이 비어서 나갑니다. 트리거를 '페이지뷰'가 아닌 '맞춤 이벤트: purchase'로 걸어야 하는 이유가 여기에 있습니다.

③ 쇼핑몰 솔루션 기본 연동과 GTM이 충돌하지 않는가

카페24, 아임웹, 쇼피파이처럼 솔루션 자체에 GA4 연동 기능이 있는 경우, 기본 연동과 GTM 태그를 동시에 켜두는 계정이 많습니다.

이때 나타나는 증상은 두 가지로 갈립니다.

• 측정 ID가 서로 다르면: 한쪽 속성에만 구매가 잡히고, 다른 속성은 0건

• 측정 ID가 같으면: 구매가 두 번 잡히거나, 한쪽 구현만 파라미터가 비어 매출이 섞임

연동 방식은 반드시 하나로 정해야 합니다. 솔루션 기본 연동이 items 배열까지 정확하게 보내준다면 그쪽을 쓰고, 커스텀 파라미터가 필요하면 기본 연동을 끄고 GTM으로 일원화하는 방식이 깔끔합니다.

④ 측정 ID와 데이터 스트림이 맞는가

의외로 많은 경우가 다른 속성을 보고 있는 것입니다.

대행사나 개발사가 바뀌면서 새 GA4 속성을 만들고, 태그는 예전 속성의 측정 ID(G-로 시작하는 값)를 그대로 쓰고 있는 경우입니다. 페이지뷰는 예전 속성에, 새로 추가한 purchase는 새 속성에 들어가면서 어느 쪽에서도 전체 흐름이 보이지 않게 됩니다.

GTM의 구글 태그와 GA4 이벤트 태그에 들어간 측정 ID를 보고 있는 속성의 데이터 스트림 ID와 한 번 대조해보시기 바랍니다.

구글 태그 설치 순서: 광고 성과 측정 전 확인할 4단계 기준

3. 수집 단계 점검: 동의 모드·외부 결제창·서버 전송

태그는 실행되는데 DebugView나 실시간 보고서에 purchase가 일부만 들어온다면, ② 수집 구간을 의심해야 합니다.

동의 모드(Consent Mode)로 인한 누락

쿠키 동의 배너를 운영하는 사이트는 동의 모드 설정에 따라 이벤트가 전송되지 않거나, 쿠키 없이 비식별 신호로만 전송됩니다.

analytics_storage가 거부 상태로 시작하고 사용자가 배너를 닫지 않은 채 결제하면, 기본 동의 모드에서는 purchase 이벤트가 GA4 보고서에 포함되지 않습니다. 국내 쇼핑몰은 동의 배너를 쓰지 않는 경우가 많지만, 해외 판매 사이트나 글로벌 솔루션 템플릿을 그대로 쓰는 경우 기본값으로 켜져 있는 사례가 있습니다.

테스트할 때는 동의 거부 상태와 동의 수락 상태에서 각각 결제를 진행해보고, 두 상황의 DebugView를 비교하면 원인이 바로 드러납니다.

외부 결제창(PG)을 거치면서 세션이 끊기는 경우

국내 쇼핑몰에서 가장 흔한 구조적 문제입니다.

결제 과정에서 PG사 도메인이나 간편결제 도메인으로 이동했다가 쇼핑몰 완료 페이지로 돌아오면, GA4는 이를 새로운 유입으로 인식할 수 있습니다. 이 경우 구매 이벤트 자체는 잡히지만 다음과 같은 일이 생깁니다.

• 구매의 세션 소스가 PG 도메인 referral로 기록

• 광고에서 들어온 고객의 구매가 광고 성과에서 빠짐

• 결과적으로 "광고 구매 전환이 안 잡힌다"는 증상으로 보임

해결 방법은 GA4 관리 > 데이터 스트림 > 태그 설정 구성 > 원치 않는 추천 목록에 결제 관련 도메인을 등록하는 것입니다. 사용 중인 PG사, 간편결제, 본인인증 도메인을 모두 넣어야 합니다. 하나만 빠져도 그 결제 수단으로 들어온 구매는 여전히 referral로 잡힙니다.

수정 후 트래픽 획득 보고서에서 PG 도메인 referral 비중이 줄어드는지 확인하면 적용 여부를 판단할 수 있습니다. 단, 이 설정은 이후 데이터부터 적용되고 지난 데이터는 바뀌지 않습니다.

서버 전송(Measurement Protocol) 구현 시 누락

브라우저 태그 누락을 보완하려고 서버에서 Measurement Protocol로 purchase를 보내는 구조도 늘고 있습니다. 이 방식에서 자주 놓치는 부분은 client_id와 session_id입니다.

client_id 없이 보내면 이벤트가 사용자와 연결되지 않고, session_id가 없으면 세션 소스가 비어 "(not set)"으로 쌓입니다. 서버에 이벤트는 쌓이는데 채널별 매출이 비어 보이는 경우 대부분 이 문제입니다.

또 Measurement Protocol은 잘못된 요청이어도 정상 응답을 돌려주는 경우가 있어서, 검증용 엔드포인트(debug/mp/collect)로 요청 형식을 먼저 확인해야 합니다.

4. 구매 이벤트가 잡히긴 하는데 숫자가 틀릴 때: 매출 0원·중복·건수 차이

"안 잡힌다"는 문의 중 상당수는 사실 잡히는데 틀리게 잡히는 경우입니다. 증상별로 원인이 꽤 명확하게 나뉩니다.

매출 0원: currency와 value 형식

GA4는 value를 보낼 때 currency가 함께 있어야 수익을 계산합니다. currency가 빠지면 이벤트는 들어오지만 수익은 0으로 처리됩니다.

value에 "39,000원"처럼 쉼표나 단위가 붙은 문자열이 들어가도 같은 문제가 생깁니다. 쇼핑몰 화면에 보이는 가격 텍스트를 그대로 긁어오는 방식으로 구현했을 때 자주 발생합니다. 숫자형 39000으로 넘겨야 합니다.

구매 중복: transaction_id가 방어선입니다

GA4는 같은 transaction_id를 가진 purchase를 중복으로 판단해 제거하려고 합니다. 그래서 transaction_id를 비워두거나 매번 랜덤 값으로 만들면 이 장치가 작동하지 않습니다.

실무에서 흔한 사례는 이렇습니다. 결제 완료 페이지를 고객이 새로고침하거나, 앱에서 뒤로 가기를 했다가 다시 들어오면 purchase가 다시 실행됩니다. 이때 transaction_id에 실제 주문번호가 들어가 있으면 중복이 걸러지지만, 비어 있으면 그대로 두 건이 됩니다.

한 생활용품 쇼핑몰의 경우 GA4 구매 건수가 실제 주문보다 눈에 띄게 많아서 확인해보니, 모바일에서 완료 페이지가 다시 로드될 때마다 이벤트가 재전송되고 있었습니다. transaction_id를 주문번호로 고정하고, 쿠키나 세션 저장소에 "이미 전송한 주문번호"를 기록해 재실행을 막자 GA4 구매 수가 실제 주문 수와 오차 범위 안으로 맞춰졌습니다.

-> 핵심: transaction_id는 선택 항목처럼 보이지만, 사실상 구매 데이터 정확도를 지키는 유일한 방어선입니다.

실제 주문 수와 몇 퍼센트까지 차이 나면 정상일까

GA4 구매 수와 쇼핑몰 관리자 주문 수가 완전히 일치하는 경우는 거의 없습니다. 광고 차단, 동의 거부, 완료 페이지에 도달하기 전에 이탈한 결제 등 브라우저 기반 측정의 구조적 한계 때문입니다.

판단 기준은 이렇게 잡는 편이 실용적입니다.

• 차이가 일정하게 유지되면: 측정 구조상 손실이므로 추세 판단에는 문제없음

• 차이가 특정 날짜부터 갑자기 커졌다면: 그 시점의 사이트 변경(결제 수단 추가, 솔루션 업데이트, 태그 수정)을 먼저 확인

• 특정 결제 수단·기기에서만 차이가 크다면: 해당 경로의 완료 페이지 태그 누락 가능성

비율 자체보다 차이가 언제부터, 어디에서 생겼는지를 보는 것이 원인을 찾는 지름길입니다.

구글 광고·메타 전환과 숫자가 다른 건 별개의 문제

GA4 구매가 정상인데도 구글 광고나 메타 광고 관리자의 구매 수와 맞지 않는 경우가 있습니다. 이건 GA4 측정 오류가 아니라 매체별 어트리뷰션 기준 차이입니다.

GA4는 기본적으로 데이터 기반 어트리뷰션으로 하나의 구매를 여러 채널에 나눠 기여를 부여하고, 각 매체는 자기 광고에 접촉한 구매를 자기 기준으로 집계합니다. 이 차이를 측정 오류로 보고 태그를 수정하면 오히려 멀쩡한 데이터를 망가뜨릴 수 있습니다.

메타 ga4 데이터 차이, 왜 생기고 어디를 믿어야 할까

자주 묻는 질문

GA4 purchase 이벤트가 DebugView에는 뜨는데 보고서에 안 나오는 이유는?
표준 보고서는 처리 지연으로 반영까지 24~48시간이 걸릴 수 있습니다. 시간이 충분히 지났는데도 안 보인다면 이벤트 이름이 정확히 소문자 purchase인지, currency와 value가 함께 들어가는지 확인해야 합니다. 이름이 다르면 이벤트 보고서에는 보여도 수익 창출 보고서에는 집계되지 않습니다.

GA4 구매 수익이 0원으로 나오는 이유는?
대부분 currency 파라미터가 빠졌거나 value가 숫자가 아닌 문자열로 전송된 경우입니다. DebugView에서 purchase 이벤트를 눌러 value와 currency 값이 실제로 어떻게 들어오는지 확인하면 바로 확인할 수 있습니다.

GA4 구매가 실제 주문보다 많이 잡히는 이유는?
결제 완료 페이지 새로고침이나 재진입으로 이벤트가 다시 실행되는데 transaction_id가 비어 있거나 매번 달라지는 경우가 가장 흔합니다. 솔루션 기본 연동과 GTM 태그가 동시에 켜져 있어도 중복이 생깁니다.

GA4에서 구매 매출 출처가 PG사로 잡히는 건 어떻게 해결하나요?
데이터 스트림의 태그 설정에서 '원치 않는 추천 목록'에 사용 중인 PG사·간편결제·본인인증 도메인을 모두 등록하면 됩니다. 설정 이후 데이터부터 적용되며 과거 데이터는 수정되지 않습니다.

GA4 구매 이벤트를 구글 광고 전환으로 쓰려면 무엇을 확인해야 하나요?
GA4에서 purchase가 주요 이벤트로 지정돼 있는지, GA4 속성과 구글 광고 계정이 연결돼 있는지 확인한 뒤 구글 광고에서 해당 전환을 가져오면 됩니다. 이미 구글 광고 자체 태그로 구매를 측정하고 있다면, 두 전환을 모두 기본 전환으로 두지 않도록 주의해야 합니다.

구글 광고 GA4 연동: 실무 순서와 확인 기준 정리

마무리

GA4 구매 이벤트가 안 잡힐 때 태그부터 다시 설치하면, 원인을 모른 채 증상만 바뀌는 경우가 많습니다.

정리하면 순서는 이렇습니다.

💡

• DebugView로 발생·수집 구간인지, 보고 구간인지 먼저 가르기

• 발생 구간이면 완료 페이지 트리거·데이터레이어·이중 연동·측정 ID 확인

• 수집 구간이면 동의 모드·외부 결제창·서버 전송 파라미터 확인

• 잡히는데 틀리면 currency·value 형식·transaction_id 확인

구매 데이터는 광고 입찰, 예산 배분, 성과 보고가 모두 기대는 기준선입니다.

이 기준선이 흔들리면 그 위에서 내리는 판단도 함께 흔들립니다. 결제 수단을 추가하거나 솔루션을 업데이트한 날에는 테스트 결제 한 건으로 DebugView를 확인하는 습관을 들이는 것만으로도, 대부분의 구매 누락을 사고가 아닌 점검 단계에서 막을 수 있습니다.