환불을 언제 전송하고 어느 달 매출에서 뺄지부터 정해요. 두 기준에 맞춰 주문 내역과 GA4 기록을 대조하는 순서로 살펴봅니다.
환불 정보를 GA4에 전달할 때는 구매 기록과 환불 내역을 함께 확인해요.
취소·반품은 언제 환불 이벤트로 보내나요?
구매 기록과 환불 확정 여부를 확인한 뒤 금액 대조, 전송, 수신 확인으로 이어갑니다.
구매 기록이 있는지와 환불 확정 여부를 함께 보고 전송 기준을 정해요.
| 상태 | 구매 기록 | 환불 확정 | 전송 기준안 |
|---|---|---|---|
| 결제 전 취소 | 없음 | 해당 없음 | 제외 |
| 결제 후 취소 | 있음 | 처리별 상이 | 확정 시 대상 |
| 반품 접수 | 있음 | 확정 전 | 보류 |
| 환불 완료 | 있음 | 확정 | 대상 |
환불 확정부터 수신 확인까지 다음 순서로 점검해요.
- 관리자·고객센터에서 환불을 확정해요.
- 연동 시스템에서 구매금액과 환불액을 대조해요.
- GA4로 전송한 뒤 전송 기록과 수신 기록을 맞춰 봐요.
GA4 환불 누락·중복은 어떤 기록을 비교하나요?
같은 거래 ID의 환불 항목과 합계를 대조해 누락·중복이 생긴 구간을 찾습니다.
거래 ID를 이용한 구매 이벤트 중복 제거와 웹 스트림 적용 범위를 설명하는 공식 문서 — 출처: Google 애널리틱스 고객센터
주문별로 원장과 전송 기록을 GA4 수신·집계 결과와 맞춰 봐요.
환불 이벤트에는 원래 구매의 거래 ID(transaction_id)를 넣습니다. 웹 태그와 서버의 Measurement Protocol 모두 거래 ID는 필수이며, 환불 금액(value)을 보내면 통화(currency)도 반드시 포함해야 합니다. value는 이번 환불 대상 상품의 단가(price)와 환불 수량(quantity)을 곱한 금액의 합계로 설정하고, 배송비(shipping)와 세금(tax)은 제외합니다. shipping과 tax는 별도의 선택 항목입니다.
상품별 환불을 확인하려면 상품 목록(items)에 환불 대상의 상품 ID(item_id), 환불 수량(quantity), 단가(price)를 함께 넣습니다. items는 두 방식 모두 명세상 선택 항목이지만, 포함한 각 상품에는 item_id 또는 상품명(item_name) 중 하나가 필요합니다. quantity를 생략하면 1로 처리되므로 부분 환불에서는 실제 환불 수량을 확인해야 하며, 상품 환불 금액은 price와 quantity로 계산됩니다.
Measurement Protocol로 웹 스트림에 직접 전송한다면 환불 항목 외에 요청 URL의 measurement_id와 api_secret, 본문의 client_id와 events 배열도 점검합니다. events 안에는 이벤트 이름(name)을 refund로 지정합니다.
전액·부분 환불과 재전송을 나눠 테스트해요. 아래 수치와 결과는 가정한 예시입니다.
| 입력 상황 | 기대 결과 | 실제 결과(예시) | 판정 |
|---|---|---|---|
| 전액 10만 원 | 10만 원 반영 | 10만 원 | 합격 |
| 부분 1만+2만 원 | 합계 3만 원 | 1만 원 | 누락 |
| 동일 환불 재전송 | 추가 차감 없음 | 이중 차감 | 실패 |
| 전송 실패 후 재시도 | 한 번 반영 | 미반영 | 실패 |
| 구매 ID 불일치 | 오류 탐지·수정 | 미해결 | 실패 |
여러 차례 부분 환불한 주문은 원래 주문의 거래 ID(transaction_id)에 연결된 각 refund 이벤트의 상품·수량·금액을 확인합니다. 금액(value)은 해당 환불 상품의 가격×수량 합계로 대조하며, 배송비와 세금은 제외합니다. 동일 환불의 재전송이 자동으로 중복 제거된다고 가정해서는 안 됩니다. 공식 문서에서 명시한 거래 ID 중복 제거 대상은 웹 스트림의 구매 이벤트이므로, 환불 재전송은 별도로 중복 여부를 확인합니다. 보고서에 반영되기까지 24~48시간이 걸릴 수 있으므로, 이 처리 시간을 고려해 주문 시스템의 환불 내역과 다시 대조하고 합계가 일치하며 중복·누락이 없는지 판단합니다. 다만 48시간이 지나면 반드시 처리가 끝난다는 보장은 없습니다.
마케팅 대시보드에서 환불 매출은 어떻게 계산하나요?
환불액은 한 번만 차감하고, 별도 대시보드의 집계 월은 보고 목적에 맞춰 정합니다.
매출 지표에 환불액이 이미 반영됐는지부터 살펴봐요. 환불을 차감한 금액에서는 다시 빼지 않도록 계산 기준을 정합니다.
| 지표 | 정의·계산 기준 |
|---|---|
| 구매금액 | 환불 차감 전 금액 |
| 환불액 | 확정된 반환 금액 |
| 환불 반영 매출 | 구매금액−환불액 |
구매금액이 10만 원이고 환불액이 3만 원이면 환불 반영 매출은 7만 원이에요. 이미 차감한 7만 원에서 환불액을 또 빼지 않아요. 배송비·세금의 포함 여부와 통화도 맞춥니다.
차감 시점은 보고 목적에 맞춰 정해요. 10월 구매·11월 환불의 집계 예시입니다.
| 보고 목적 | 차감 기준 |
|---|---|
| 월별 발생 내역 | 11월 차감 |
| 구매월별 성과 | 10월 주문 재집계 |
| 구매 전환 건수 | 환불 반영 매출 |
|---|---|
| 1건 | 7만 원 |
GA4에서는 ‘총 구매 수익’과 ‘구매 수익’을 구분해야 합니다. 총 구매 수익은 구매·인앱 구매·구독 수익의 합계이고, 구매 수익은 여기서 환불을 차감한 금액이므로 환불액을 다시 빼면 중복 차감됩니다. ‘총수익’에는 광고 수익도 포함되며, ‘상품 수익’은 세금·배송비를 제외한 상품 매출에서 상품 환불액을 뺀 값입니다. ‘환불 금액’은 refund와 app_store_refund 이벤트의 환불 수익을 합산합니다.
구매·환불 이벤트의 금액인 value에는 상품별 가격×수량의 합계를 넣고, 세금과 배송비는 별도로 전달하도록 되어 있습니다. 따라서 대시보드와 주문관리 매출을 비교할 때도 세금·배송비의 포함 여부를 맞춰야 합니다.
날짜별 집계는 속성 시간대에 따른 이벤트 날짜가 기준입니다. 이 정의를 적용하면 환불은 환불 이벤트에 기록된 날짜에 반영되는 것으로 해석합니다. 서버에서 측정 프로토콜로 전송할 때 시각을 지정하지 않으면 요청 수신 시각이 적용되고, 과거 이벤트 시각 지정은 최대 72시간까지 가능합니다.
또한 ‘전자상거래 구매 건수’는 purchase 이벤트 횟수이므로 refund 이벤트를 보내도 그만큼 줄어들지 않습니다. 환불 횟수는 별도 지표로 확인해야 합니다.
정리
오늘은 환불이 끝난 주문 한 건을 골라 기록을 따라가 봐요. 원장과 전송 내역을 놓고 대시보드에 반영된 금액과 기간까지 적습니다.
트래킹·대시보드 상담을 원하시면 불일치 구간·쇼핑몰·대시보드 정보와 확정된 일정·예산을 문의 폼으로 보내 주세요.
