GA4 전자상거래 설정: 구매 데이터 누락 막는 4단계 기준
GA4 전자상거래 설정은 구매 이벤트 하나를 심는 작업이 아닙니다. 상품 조회부터 결제 완료까지 단계마다 같은 형식의 상품 정보(items)를 넘겨서, 어느 구간에서 고객이 빠지는지 읽을 수 있게 만드는 작업입니다.
실무에서 가장 중요한 건 이벤트 개수보다 데이터 규격을 통일하는 것입니다. 상품 ID 형식, 금액 기준, 주문번호 처리가 이벤트마다 다르면 보고서 숫자가 맞지 않습니다. 그러면 광고 매체로 넘어가는 전환값까지 함께 틀어집니다.
아래에서 이벤트 범위를 정하는 기준부터 파라미터 규격, 설치 방식 선택, 설치 뒤 검증까지 4단계로 설명합니다.
1. GA4 전자상거래 이벤트, 어디까지 심어야 할까
GA4가 권장하는 전자상거래 이벤트는 10개가 넘습니다.
하지만 처음부터 전부 심을 필요는 없습니다. 그렇다고 purchase 하나만 심는 것도 부족합니다.
기준은 간단합니다.
"이 이벤트가 없으면 내가 내릴 수 없는 판단이 있는가"를 먼저 따져보면 됩니다.
1) 필수 4개: 퍼널을 읽기 위한 최소 단위
이벤트 | 발생 시점 | 이 이벤트로 판단하는 것 |
|---|---|---|
view_item | 상품 상세 페이지 진입 | 광고 유입이 상품까지 도달하는지 |
add_to_cart | 장바구니 담기 클릭 | 상세페이지가 구매 의향을 만드는지 |
begin_checkout | 주문서 작성 진입 | 장바구니에서 이탈하는 비중 |
purchase | 결제 완료 | 실제 매출과 상품별 기여 |
이 4개만 있어도 "상세페이지 문제인지, 결제 구간 문제인지"를 나눠서 볼 수 있습니다.
광고 성과가 떨어졌을 때 소재를 바꿀지 랜딩을 고칠지 정하려면, 최소한 이 정도 구간은 나뉘어 있어야 합니다.
2) 선택 이벤트: 문제가 보일 때 추가
view_item_list / select_item: 카테고리·검색 결과 페이지에서 어떤 상품이 클릭되는지 보고 싶을 때
add_shipping_info / add_payment_info: 주문서 안에서 배송 정보 입력 단계와 결제수단 선택 단계를 나눠서 봐야 할 때
view_promotion / select_promotion: 메인 배너·기획전 성과를 따로 측정할 때
refund: 환불이 많은 업종이라 순매출 기준으로 봐야 할 때
-> 처음에는 필수 4개를 정확하게 잡고, 선택 이벤트는 "어디서 새는지 모르겠다"는 질문이 생겼을 때 그 구간만 추가하는 편이 유지보수에 유리합니다.
3) 흔한 실수: 이벤트는 많은데 쓸 수 있는 데이터가 없는 경우
이벤트를 14개 전부 심었는데 막상 보고서를 열면 상품명이 비어 있거나, 장바구니 이벤트에만 금액이 없는 경우가 꽤 많습니다.
이렇게 되면 이벤트 수는 많아도 퍼널 분석은 할 수 없습니다.
이벤트 개수보다 이벤트 간 데이터 일관성이 먼저라는 점을 기억해두시면 좋습니다.
2. GA4 전자상거래 파라미터 규격: items 배열과 금액 기준 정하기
설치를 시작하기 전에 문서 한 장으로 정해두어야 할 것이 있습니다.
바로 파라미터 규격입니다. 개발자나 솔루션 담당자에게 "GA4 심어주세요"라고만 요청하면, 이 부분이 사람마다 다르게 구현됩니다.
1) 이벤트 단위 파라미터
파라미터 | 필수 여부 | 설정 기준 |
|---|---|---|
currency | value를 보낼 때 필수 | 국내 몰이면 "KRW" 고정 |
value | 권장 | 숫자형. "39,000"이나 "39000원" 같은 문자열 금지 |
transaction_id | purchase에서 필수 | 주문관리 시스템의 주문번호와 동일하게 |
items | 전자상거래 이벤트 전반 | 아래 상품 단위 규격 참고 |
shipping / tax / coupon | 선택 | value와 분리해서 별도 전송 |
여기서 가장 많이 어긋나는 게 value에 무엇을 포함하느냐입니다.
상품 금액만 넣을지
배송비를 포함할지
쿠폰·적립금 차감 후 금액으로 할지
정답이 하나로 정해진 건 아닙니다. 다만 한 번 정한 기준은 모든 이벤트와 모든 매체에 똑같이 써야 합니다.
실무에서는 "쿠폰 차감 후 상품 결제금액, 배송비 제외"로 맞추고, 배송비는 shipping 파라미터로 따로 보내는 경우가 많습니다. 그래야 광고 ROAS를 계산할 때 배송비가 매출처럼 잡히지 않습니다.
2) 상품 단위 파라미터 (items 배열)
items 안의 각 상품에는 item_id 또는 item_name 중 하나가 반드시 있어야 합니다.
실무에서는 둘 다 넣는 것을 권장합니다.
item_id: 상품 고유코드. 광고 매체 카탈로그의 상품 ID와 같은 값을 쓰면 나중에 매체 데이터와 맞춰보기 쉽습니다.
item_name: 상품명. 옵션명까지 붙이지 말고 기본 상품명만 넣습니다.
item_variant: 색상·사이즈 같은 옵션 정보
item_category ~ item_category5: 카테고리 계층
price / quantity: 단가와 수량. price × quantity의 합이 value와 크게 어긋나지 않는지 확인해야 합니다.
3) 실무에서 자주 생기는 규격 불일치 사례
한 패션 자사몰의 경우 상세페이지에서는 item_id에 상품코드를 넣었습니다. 그런데 결제 완료 페이지에서는 옵션까지 붙은 품목코드(SKU)를 넣고 있었습니다.
결과는 이렇게 나타났습니다.
view_item 기준 상위 상품과 purchase 기준 상위 상품이 서로 연결되지 않음
"상품 조회 대비 구매율" 지표가 전 상품 0%에 가깝게 표시됨
상품별 퍼널 분석이 사실상 불가능해짐
이벤트는 다 정상적으로 수집되고 있었기 때문에 한동안 아무도 문제를 몰랐습니다.
item_id 기준을 기본 상품코드로 통일하고 옵션 정보는 item_variant로 옮긴 뒤에야 상품별 전환율이 제대로 보이기 시작했습니다.
-> 같은 상품은 모든 이벤트에서 같은 item_id로 들어와야 합니다. 규격 문서에 이 한 줄만 있어도 이런 문제는 대부분 막을 수 있습니다.
카페24 메타 카탈로그 연동: 상품 ID 맞추는 4가지 기준
3. GA4 전자상거래 설정 방식: 솔루션 연동 vs GTM 데이터레이어
규격을 정했다면 이제 실제로 데이터를 보내는 방법을 골라야 합니다.
크게 세 가지가 있고, 쇼핑몰 구조와 내부 개발 리소스에 따라 선택이 달라집니다.
1) 방식별 비교
방식 | 적합한 상황 | 장점 | 주의점 |
|---|---|---|---|
쇼핑몰 솔루션 자체 연동 | 임대형 솔루션, 개발 인력 없음 | 측정 ID만 넣으면 빠르게 시작 | 파라미터 구성을 직접 바꾸기 어려움 |
GTM + 데이터레이어 | 자체 개발 몰, 커스터마이징 필요 | 규격을 원하는 대로 통제 | 개발자의 dataLayer.push 구현 필요 |
gtag.js 직접 삽입 | 소규모 사이트, 태그 수가 적음 | 구조가 단순 | 태그가 늘면 관리가 어려워짐 |
2) 솔루션 연동을 쓸 때 확인할 것
임대형 쇼핑몰 솔루션 상당수가 GA4 전자상거래 연동 기능을 제공합니다.
편하지만 그대로 믿고 넘어가면 안 됩니다. 꼭 확인해야 할 것은 세 가지입니다.
솔루션이 보내는 이벤트 목록이 무엇인지 (purchase만 보내는 경우도 있음)
value에 배송비·할인이 어떻게 반영되는지
GTM에도 GA4 태그를 따로 심어서 같은 이벤트가 두 번 전송되고 있지 않은지
특히 세 번째가 가장 흔한 사고입니다.
솔루션 연동을 켜둔 상태에서 GTM으로 purchase를 한 번 더 보내면, GA4 매출이 실제보다 크게 부풀려집니다.
3) GTM 데이터레이어 방식의 기본 흐름
자체 개발 몰이라면 GTM 방식이 가장 통제하기 좋습니다. 순서는 이렇습니다.
1단계: 개발자가 각 시점에 dataLayer.push로 ecommerce 객체를 전송
2단계: push 직전에 ecommerce: null을 먼저 보내 이전 이벤트의 상품 정보 초기화
3단계: GTM에서 맞춤 이벤트 트리거(예: purchase) 생성
4단계: GA4 이벤트 태그에서 "전자상거래 데이터 전송" 옵션을 켜고 데이터 소스를 데이터레이어로 지정
2단계는 자주 빠지는 부분입니다.
초기화를 하지 않으면 앞서 본 상품의 items가 다음 이벤트에 섞여 들어갑니다. 장바구니에 담지도 않은 상품이 add_to_cart에 찍히는 식입니다.
4) 주문 완료 페이지에서 반드시 막아야 할 것
purchase 이벤트는 보통 주문 완료 페이지에서 발생합니다.
문제는 고객이 이 페이지를 새로고침하거나, 뒤로가기 후 다시 들어오거나, 주문내역 링크로 재방문할 때입니다.
GA4는 같은 transaction_id로 들어온 구매를 중복 제거 대상으로 처리합니다. 그래서 transaction_id를 제대로 넣는 것이 첫 번째 방어선입니다.
다만 transaction_id가 비어 있거나, 매번 랜덤 값으로 생성되면 이 장치는 작동하지 않습니다.
실무에서는 두 가지를 함께 적용하는 편이 안전합니다.
transaction_id에 반드시 실제 주문번호를 넣는다
같은 주문번호로 이미 이벤트를 보냈다면 쿠키나 세션 저장소에 기록해 재전송을 막는다
구글 태그 설치 순서: 광고 성과 측정 전 확인할 4단계 기준
4. GA4 전자상거래 설정 후 검증: 숫자를 믿기 전 확인할 순서
설치했다고 끝이 아닙니다.
전자상거래 데이터는 틀려도 에러가 나지 않기 때문에, 직접 검증하지 않으면 몇 달 동안 잘못된 숫자로 의사결정을 하게 됩니다.
1단계: DebugView로 이벤트별 파라미터 확인
GTM 미리보기 모드나 디버그 모드를 켜고 실제로 상품 조회 → 장바구니 → 주문서 → 결제까지 진행해봅니다.
GA4 관리 메뉴의 DebugView에서 이벤트를 하나씩 눌러 아래 항목을 확인합니다.
4개 필수 이벤트가 순서대로 찍히는지
각 이벤트의 items 안에 item_id, item_name, price, quantity가 들어 있는지
value가 숫자형이고 currency가 KRW인지
purchase의 transaction_id가 실제 주문번호와 같은지
테스트 결제는 무통장입금이나 소액 상품으로 진행하고, 해당 주문번호를 메모해두면 이후 검증에 그대로 쓸 수 있습니다.
2단계: 결제수단별로 따로 테스트
이 단계를 건너뛰는 경우가 많은데, 실제 누락은 여기서 가장 많이 발견됩니다.
카드 결제
간편결제(외부 결제창으로 이동했다가 돌아오는 방식)
무통장입금
모바일 앱 내 웹뷰 결제
간편결제는 외부 페이지를 거쳐 돌아오기 때문에, 주문 완료 페이지 진입 경로가 카드 결제와 다를 수 있습니다.
한 생활용품 자사몰의 경우 카드 결제는 정상 수집되는데, 특정 간편결제로 산 주문만 purchase가 통째로 빠지고 있었습니다. 결제 후 돌아오는 페이지가 GTM이 설치되지 않은 별도 URL이었던 것이 원인이었습니다.
간편결제 비중이 높은 몰일수록 이런 누락은 광고 성과를 실제보다 낮게 보이게 만듭니다.
3단계: 주문관리 시스템과 7일 단위 대조
설치 후 최소 7일이 지나면 GA4 수익 창출 보고서의 구매 건수·매출과 쇼핑몰 관리자 페이지의 주문 건수·매출을 나란히 놓고 비교합니다.
두 숫자가 완전히 일치하는 경우는 거의 없습니다. 광고 차단 프로그램, 쿠키 동의 거부, 결제 직후 브라우저 종료 같은 이유로 GA4 쪽이 조금 적게 잡히는 게 일반적입니다.
그래서 봐야 할 건 차이의 크기보다 차이의 패턴입니다.
패턴 | 의심할 원인 |
|---|---|
GA4가 매일 비슷한 비율로 적다 | 구조적 누락(차단·동의). 정상 범위 |
특정 날짜·결제수단에서만 크게 빈다 | 해당 결제 경로의 태그 누락 |
GA4가 주문 시스템보다 많다 | 중복 전송(솔루션 + GTM 이중 설치, 새로고침) |
건수는 맞는데 매출이 다르다 | value 기준 불일치(배송비·할인 포함 여부) |
GA4 숫자가 주문 시스템보다 많다면 이건 무조건 설정 문제입니다. 실제 주문보다 많은 구매가 잡힐 수는 없기 때문입니다.
4단계: 광고 매체로 넘어가는 값까지 확인
GA4 purchase를 구글 광고 전환으로 가져오고 있다면, GA4 데이터의 오류가 그대로 입찰 학습에 들어갑니다.
중복으로 부풀려진 매출을 기준으로 자동 입찰이 돌아가면, 매체는 실제보다 성과가 좋다고 판단하고 예산을 더 씁니다.
그래서 GA4 검증이 끝난 다음에 매체 연동을 하는 것이 순서입니다.
이미 연동되어 있다면 검증 기간 동안 GA4 기준 전환과 매체 자체 태그 기준 전환을 함께 보면서 차이를 확인하는 편이 안전합니다.
구글 광고 GA4 연동: 실무 순서와 확인 기준 정리
메타 ga4 데이터 차이, 왜 생기고 어디를 믿어야 할까
자주 묻는 질문
Q1. GA4 전자상거래 데이터가 보고서에 안 보이는 이유는?
수익 창출 보고서는 실시간이 아니라 처리 시간이 걸리기 때문에 보통 하루에서 이틀 뒤에 반영됩니다. 이틀이 지나도 비어 있다면 DebugView에서 purchase 이벤트에 items 배열과 currency가 들어 있는지 먼저 확인하세요. 이벤트는 수집됐는데 items가 비어 있으면 상품 단위 보고서에는 표시되지 않습니다.
Q2. GA4 purchase가 중복으로 잡히는 이유는?
가장 흔한 원인은 쇼핑몰 솔루션 연동과 GTM 태그가 동시에 purchase를 보내는 이중 설치입니다. 그다음은 주문 완료 페이지 새로고침입니다. transaction_id에 실제 주문번호를 넣고, 같은 주문번호는 한 번만 전송되도록 막으면 대부분 해결됩니다.
Q3. GA4 value에 배송비를 포함해야 하나요?
정해진 정답은 없습니다. 다만 광고 ROAS 계산에 쓰려면 상품 결제금액만 value에 넣고 배송비는 shipping 파라미터로 분리하는 경우가 많습니다. 어떤 기준이든 모든 이벤트와 매체에 똑같이 적용하는 것이 더 중요합니다.
Q4. GA4와 쇼핑몰 주문 수가 다른 건 정상인가요?
광고 차단, 쿠키 동의 거부, 결제 직후 이탈 때문에 GA4 쪽이 조금 적게 잡히는 건 구조적으로 생기는 차이입니다. 다만 GA4가 더 많거나, 특정 결제수단에서만 크게 빈다면 설정 오류이므로 따로 점검해야 합니다.
Q5. 임대형 쇼핑몰도 GTM으로 GA4 전자상거래를 설정할 수 있나요?
가능한 경우가 많지만, 주문 완료 페이지에서 주문 정보를 데이터레이어로 꺼내 쓸 수 있는지는 솔루션마다 다릅니다. 솔루션 자체 연동 기능이 있다면 먼저 그것을 쓰고, 부족한 이벤트만 GTM으로 보완하는 편이 이중 전송 위험이 적습니다.
마무리
GA4 전자상거래 설정은 결국 "같은 상품, 같은 금액 기준, 같은 주문번호"를 퍼널 전체에서 지키는 작업입니다.
이벤트 범위는 필수 4개부터 정합니다.
파라미터 규격은 문서로 먼저 고정합니다.
설치 방식은 쇼핑몰 구조에 맞게 고르고, 이중 전송이 없는지 확인합니다.
마지막으로 결제수단별 테스트와 주문 시스템 대조로 숫자를 검증합니다.
이 순서를 지키면 GA4 숫자를 광고 판단에 그대로 써도 될 만큼 신뢰도를 확보할 수 있습니다.
반대로 검증 없이 넘어가면, 잘못된 매출 데이터가 광고 매체의 자동 입찰 학습에까지 들어갑니다.
설치를 끝냈다면 오늘 바로 테스트 주문 한 건을 넣고 DebugView에서 items 배열부터 열어보세요!