GA4 보고서에는 지난달 구매 건수가 4,180건으로 나와 있지만, 주문 테이블에는 4,690건으로 기록되어 있습니다. 어느 쪽이 맞는지 묻는다면, 누락된 510건의 주문이 어디로 갔는지 알기 전까지는 어느 쪽도 정확하지 않다고 답할 수밖에 없습니다. 이는 단순히 정리의 문제가 아닙니다. 모든 실험 결과와 우선순위 점수는 알 수 없는 오차 범위 내에서 계산된 수치를 기반으로 하고 있습니다.
Google은 측정되지 않은 상당 부분을 정상으로 처리합니다. 동의 모드에 대한 행동 모델링은 속성이 기록될 때까지 활성화되지 않습니다. 하루에 최소 1,000건의 이벤트가 있습니다. analytics_storage='denied' 최소 7일 동안그 아래 부분은 누락된 데이터가 그대로 남아 있습니다.
이 문서는 전자상거래 팀에서 분석 또는 CRO를 담당하는 모든 분들을 위한 것입니다. 최종적으로는 조정표, 차이점을 구체적인 원인별로 분해하고 각 원인에 대한 테스트 방법을 제시하며, 검증 가능한 허용 오차 값을 산출할 수 있게 됩니다.
구매 대조는 실제로 무엇을 측정하는가?
조정 작업은 단순히 "숫자를 맞추는 것"이 아닙니다. 숫자는 절대 일치하지 않으며, 억지로 맞추려고 하는 팀은 오히려 차이를 그대로 두는 것보다 더 나쁜 결과를 초래할 가능성이 큽니다. 조정 작업은 다음 세 가지 질문에 대한 답을 제시합니다. 차이가 얼마나 큰지, 어떤 메커니즘이 차이를 발생시키는지, 그리고 어떤 비용으로 얼마나 복구할 수 있는지입니다. 모든 실험에 앞서 조정 작업을 진행합니다. 왜냐하면 알 수 없는 비율의 주문이 조용히 손실되는 전환 이벤트를 기반으로 측정하는 테스트는 진정한 실험이 아니기 때문입니다.
1단계: 주문 ID를 기준으로 조인할 수 있는 두 개의 테이블을 가져옵니다.
동일한 달력 범위에 대해 두 시스템 모두에서 주문당 하나의 행이 필요하며, 양쪽 시스템 모두에 존재하는 키를 사용해야 합니다.
- 백엔드 : 주문 ID, 해당 속성의 보고 시간대에 따른 생성 타임스탬프, GA4에서 구성한 세금 및 배송비 기준에 따른 주문 금액, 결제 방법, 기기, 국가, 상태가 표시됩니다.
- GA4: BigQuery 내보내기 자체이지 UI가 아닙니다. 쿼리
purchase이벤트와 함께ecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue기기 카테고리 및 트래픽 소스.
BigQuery를 의도적으로 사용하세요. 동의 모드에서 모델링된 데이터는 GA4 표준 보고서 및 일부 탐색 결과에 나타나지만, Google은 이를 명시적으로 밝히지 않습니다. 지원 BigQuery 내보내기, 잠재고객, 사용자 탐색기, 코호트 또는 유지율 탐색, 예측 측정항목 등에서 UI를 주문 테이블과 비교해 보세요. 그러면 추정치와 실제 데이터를 비교하는 셈이 됩니다.
그다음 주문 ID를 기준으로 전체 외부 조인을 수행합니다. 이제 세 개의 버킷이 생깁니다. 두 버킷 모두, 백엔드 전용, GA4 전용입니다. 세 번째 버킷은 크기는 작지만 진단에 가장 유용합니다.
2단계: 차이를 한 가지 방법이 아닌 세 가지 방법으로 표현하세요.
월별 백분율 하나만으로는 모든 것을 알 수 없습니다. 세 가지 모두 계산해 보세요.
- 주문 건수 차이: (백엔드 주문에서 GA4 일치 구매를 뺀 값) / 백엔드 주문. 이렇게 하면 추적 손실을 분리할 수 있습니다.
- 수익 격차: 가치에 대해서도 동일한 계산 방식을 적용합니다. 수량 차이가 3%이고 매출 차이가 11%라면, 추적에 문제가 있는 것이 아니라 가치 정의에 문제가 있는 것입니다(세금, 배송비, 할인, 환율, 상품권 등).
- 일일 격차 변동률: 일일 주문 건수 차이를 그래프로 나타내세요. 그래프가 평평하면 동의 문제나 차단 요인과 같은 구조적 원인이 있음을 의미합니다. 그래프가 급증하면 배포, 캠페인 급증 또는 결제 서비스 제공업체 오류를 의미합니다.
3단계: 격차를 구체적인 원인으로 분해합니다.
이 표를 따라가 보세요. 각 원인에는 1시간 이내에 확인 또는 배제할 수 있는 검사가 있습니다.
| 원인 | 그것을 테스트하는 방법 | 데이터의 서명 |
|---|---|---|
| 동의가 거부되어 태그가 실행되지 않습니다. | CMP의 동의 상태 로그를 동일 기간의 GA4 세션과 비교하십시오. | 일일 평균 비율 안정적; EU 및 터키 트래픽에 집중됨 |
| 광고 및 추적 차단 | 확인 URL에 대한 서버 로그 요청 수를 세고, 해당 URL에서의 GA4 구매 이벤트 수와 비교합니다. | 데스크톱, 파이어폭스 및 개인 정보 보호 브라우저에 영향을 미치며, 시간이 지나도 안정적입니다. |
| 확인 페이지가 전혀 로드되지 않습니다. | 서버 로그에서 확인 URL 요청이 전혀 없었던 백엔드 전용 주문 수를 계산합니다. | 은행 계좌이체 및 3DS 결제 방식에 집중 |
| 중복 구매 이벤트 | GA4 구매 이벤트 수를 계산합니다. transaction_id | GA4가 특정 날에는 백엔드에 과부하를 일으켜 페이지 새로고침 및 뒤로 가기 버튼 사용이 잦아집니다. |
| 도메인 간 링크가 깨졌습니다 | 검사해 보세요 _gl 결제 제공업체로부터의 반송 과정에서 손상되지 않고 살아남습니다. | 결제 도메인을 추천 경로로 하여 새로운 세션에서 토지 구매가 이루어졌습니다. |
| 쿠키 수명 재설정 | 브라우저별 신규 사용자 비율 세분화 | Safari와 iOS에서 신규 사용자 수와 직접 트래픽이 급증했습니다. |
| 모델링된 이미지와 원본 이미지 비교 | 동일한 날짜 범위에 대해 GA4 UI 총계와 BigQuery 총계를 비교합니다. | 주문 테이블을 열기도 전에 두 개의 구글 수치가 일치하지 않습니다. |
| 가치 정의 | 세금, 배송비 및 할인을 포함한 경우와 포함하지 않은 경우의 백엔드 매출을 다시 계산합니다. | 수치는 일치하지만, 수익은 일치하지 않습니다. |
| 시간대 경계 | 주 단위로 다시 집계합니다. | 주간 단위로 살펴보면 격차가 0에 가까워집니다. |
두 사람은 특별한 보살핌이 필요합니다. transaction_id 중복 제거는 웹 스트림에서만 작동하며 앱 스트림에서는 작동하지 않습니다. 또한 Google은 빈 문자열을 전송하면 Analytics에서 중복 제거가 수행될 수 있다고 경고합니다. 매주 구매 이벤트 진행 중 transaction_id=''그 버그 하나 때문에 하루 종일 시간을 허비할 수도 있습니다. 또한, 원치 않는 추천 목록은 데이터 스트림당 도메인이 50개로 제한되어 있어 여러 결제 대행사, 전자지갑, 은행 페이지를 사용하는 경우 문제가 될 수 있습니다.
[내부 데이터 필요: 독자들이 어떤 원인이 주로 나타나는지 확인할 수 있도록 Switas 화해 활동 전반에 걸쳐 관찰된 이 9가지 원인의 분포 데이터.]
4단계: 정당한 근거를 제시할 수 있는 허용 오차를 설정하십시오.
구글은 허용 가능한 오차 범위를 명시하지 않았으며, 널리 인용되는 "5%면 괜찮다"는 구글 문서 어디에도 나와 있지 않습니다. 따라서 오차 범위는 단순히 수치에만 의존하지 말고, 분해 방식에 따라 직접 설정하십시오.
| 월별 주문 건수 차이 | 읽기 | 동작 |
|---|---|---|
| 최대 2 %까지 | 시간대 경계 및 일반 중복 제거 | 원인을 기록하고 분기별로 재점검하십시오. |
| 2의 % 5 %로 | 모든 점수가 명시된 원인에 기인한 경우에만 허용됩니다. | 먼저 관련 내용을 기록한 후 실험을 진행하세요. |
| 5의 % 10 %로 | 적어도 하나의 구조적 원인은 해결되지 않았습니다. | 절대 변환 수치를 신뢰하기 전에 문제를 해결하세요. |
| 10 % 이상 | 실험용으로 적합하지 않음 | 문제가 해결될 때까지 GA4 구매를 주요 실험 측정 기준으로 사용하지 마세요. |
이는 업계 표준이 아닌 당사의 운영 기준입니다. 중요한 점은 설명할 수 없는 3%가 설명 가능한 8%보다 더 나쁘다는 것입니다.
5단계: 시간당 가장 많은 주문을 복구하는 순서로 수정합니다.
- 값 정의 및 시간대. 엔지니어링이 아닌 구성 작업이며, 보통 오후 시간 정도 소요됩니다.
- 중복 및 빈 거래 ID. 데이터 레이어 수정 사항 하나.
- 도메인 간 연결 및 원치 않는 연결. 두 가지 모두 설정한 다음, 스테이징 환경이 아닌 실제 결제 반환 경로를 다시 테스트하십시오.
- 서버 측 구매 이벤트. 측정 프로토콜을 사용하여 주문 시스템에서 구매 내역을 전송하세요.
client_id웹 태그가 생성되었습니다. Google은 최초 클라이언트 측 이벤트 타임스탬프로부터 48시간 이내에 이러한 이벤트가 발생해야 하며, 그렇지 않으면 어트리뷰션이 예상대로 처리되지 않을 수 있습니다. 이는 차단으로 인해 손실된 주문이나 렌더링되지 않은 확인 페이지로 인해 손실된 주문을 복구하는 데 사용됩니다. - 동의 기반 아키텍처. 가장 느리고 정치적인 문제입니다. 나머지는 규모가 알려져 있고 문서화된 격차로 간주하십시오.
터키나 유럽 연합(EU)에서 판매할 경우 어떤 점이 달라지나요?
두 가지 지역적 요인이 수치에 영향을 미칩니다.
터키에서도 동의는 선택 사항이지만, 구글의 안전망은 없습니다. 터키 데이터 보호 당국은 2022년 12월 23일자 결정 2022/1358에서 법적 근거 없이 광고 및 마케팅 쿠키를 사용한 웹사이트 운영자에게 30만 TL의 벌금을 부과하고, 필수적이지 않은 쿠키에 대해서는 사용자의 적극적인 동의를 요구했습니다. 이에 많은 터키 웹사이트들은 동의 신호를 보내는 대신 구글 태그를 아예 차단하는 배너를 게재하는 방식으로 대응했습니다. 이러한 차별화는 상당한 비용을 수반합니다. 모델링에는 많은 노력이 필요합니다. analytics_storage='denied' 이벤트가 존재해야 합니다. 아무것도 발생시키지 않는 배너는 Google이 모델링할 데이터를 제공하지 않으므로 데이터가 추정되는 것이 아니라 사라집니다.
터키 3DS 배송은 우편으로 구매자에게 반송됩니다. iyzico를 사용하면 판매자는 디코딩된 3DS 페이지를 표시하고, OTP 확인 후 iyzico는 판매자의 페이지로 리디렉션합니다. callbackUrl 과 status, paymentId mdStatusPOST 방식으로 반환되는 것은 리디렉션으로 인해 데이터가 손실될 수 있으므로 Google이 '도메인 간 측정 오류'라고 부르는 바로 그 방식입니다. _gl 목적지 로딩 전에 발생합니다. 카드 결제에서 차이가 나고 현금 결제에서는 거의 0에 가깝다면 바로 이 때문입니다.
널리 퍼진 두 가지 주장을 우리는 확인할 수 없었습니다.
"Safari는 자사 쿠키의 저장 기간을 7일로 제한합니다." 정확하지 않습니다. WebKit 문서에 따르면 ITP는 7일 후 JavaScript 쿠키 및 기타 스크립트 쓰기 가능 저장소를 삭제합니다. 사용자 상호 작용 없음또한, 링크를 통해 광고 도메인에 접속한 경우 JavaScript 쿠키의 유효 기간을 24시간으로 제한합니다. 시모 아하바의 테스트 결과, 쿠키 유효 기간은 달력일이 아닌 브라우저 사용 일수를 기준으로 계산되므로 재방문 고객은 일주일 이상 식별자를 유지할 수 있는 것으로 나타났습니다.
"5% 오차는 허용 가능합니다." 이 수치에 대한 구글 검색 결과는 찾을 수 없었습니다. 해당 수치는 판매업체 블로그와 포럼 답변에서 떠도는 이야기일 뿐입니다. 참고 자료 정도로만 활용하시고, 기준점으로 삼지 마십시오.
이 방법이 한계를 드러내는 지점
이는 앱 스트림을 포함하지 않습니다. transaction_id 중복 제거 기능은 적용되지 않으며, "주문"이 하나의 이벤트가 아닌 구독 및 부분 배송 모델에도 적용되지 않습니다. 동의를 거부한 사용자의 신원을 복구할 수 없고, 단지 주문량을 추정할 수 있을 뿐입니다. 채널 기여도 분석은 별개의 더 어려운 문제이므로 해결하지 못합니다. 또한 주문 테이블이 깨끗하다고 가정합니다. 취소되거나 사기로 차단된 주문이 양측에서 일관성 없이 집계될 경우, 쿼리 자체에만 존재하는 차이를 추적하게 될 것입니다.
자주하는 질문
이 프로그램을 얼마나 자주 실행해야 할까요? 한 번 전체 분해를 실행한 후, 매일 차이 차트를 생성합니다. 결제, CMP, 결제 제공업체 또는 태그 관리자가 변경될 때마다 전체 분해를 다시 실행하십시오.
BigQuery 대신 GA4 인터페이스를 사용해 보는 건 어떨까요? 인터페이스에는 내보내기 파일에는 포함되지 않는 모델링된 사용자 및 세션이 포함될 수 있으므로 두 Google 수치가 서로 일치하지 않습니다. 추정치와 비교하여 조정하면 차이를 분해하는 것이 불가능합니다.
서버 측 태깅이 이러한 격차를 완전히 해소할 수 있을까요? 아니요. 차단으로 인해 손실된 주문이나 표시되지 않은 확인 페이지로 인해 손실된 주문을 복구합니다. 동의를 거부한 사용자는 복구하지 않습니다.
GA4 점수가 저희 백엔드 점수보다 높습니다. 이게 가능한가요? 네. 일반적으로 페이지 새로고침으로 인해 구매 이벤트가 중복되거나, 빈 항목이 재사용되거나 하는 경우입니다. transaction_id또는 생산 시설로 발사되는 준비 명령.
동의 모드는 터키의 동의 격차를 해소할 수 있을까요? 부분적으로만 가능합니다. 거부된 신호는 Google의 볼륨 임계값에 따라 모델링을 가능하게 합니다. 이는 터키 법규에 따른 합법적인 배너 광고를 대체하는 것은 아닙니다.
적절한 공백 기간이란 무엇일까요? 모든 백분율에 이름이 붙은 세상. 입증된 8%가 설명되지 않은 3%보다 낫다.
이 문제를 해결한 후 과거 보고서를 다시 작성해야 할까요? 아니요. 수정 날짜를 주석으로 표시하고 각 기간을 별도의 시리즈로 처리하세요. 추적된 변환을 다시 작성하면 감사 추적 기록이 손상됩니다.
격차가 10% 이상일 때 A/B 테스트를 진행해도 될까요? 테스트 도구 내에서 측정된 상대적 지표를 기준으로 실행하되, 격차가 세분화될 때까지 GA4로 인한 절대적인 매출 영향은 보고하지 마십시오.
이번 달에는 직접 운영하는 매장에서 이 정산 작업을 실행하거나, 저희 분석팀이 함께 실행해 드리겠습니다. 그러면 분해도, 허용 오차 및 수정 순서를 알려드리겠습니다.
지우면 좋을거같음 . SM
- [GA4] 동의 모드에 대한 행동 모델링, Google Analytics 도움말
- [GA4] 거래 ID를 사용하여 중복 키 이벤트 최소화, Google Analytics 도움말
- [GA4] 원치 않는 추천, Google Analytics 도움말
- [GA4] 도메인 간 측정, Google Analytics 도움말
- 측정 프로토콜 이벤트를 Google Analytics 및 Google for Developers로 전송
- 동의 모드 매개변수, Google 태그 플랫폼 문서
- WebKit에서의 추적 방지
- WebKit 브라우저에서 JavaScript 쿠키의 만료 시간 제한이 제거되었습니다 (Simo Ahava)
- KVKK 쿠룰 카라리 2022/1358, 2022년 12월 23일
- 3DS 구현, iyzico 개발자 문서
