과다 집계가 맞는지부터 어떻게 확인하나

트래킹 코드가 중복 설치되면 지표가 부풀려지고 사용자 수가 왜곡되며 전환 귀속이 훼손돼, 그 위에서 수행한 분석이 함께 무너집니다. 그러니 손대기 전에 정말 중복인지부터 확정합니다.

방법은 건수 대조입니다. 어드민 주문 건수와 GA4 구매 이벤트 수, 매체 전환수를 같은 기간으로 놓고 비교합니다. 금액으로 먼저 보면 배송비나 할인 처리 차이와 뒤섞여 판단이 흐려집니다. 건수가 어긋난 날짜를 골라 그날의 거래 ID를 뽑고, 같은 값이 두 번 이상 나타나는지 봅니다. 전자상거래 구현 가이드는 transaction_id를 구매와 환불에 필수로 규정하는데, 이 값이 비어 있거나 페이지를 열 때마다 새로 만들어지는 구조라면 중복 판별 자체가 불가능하므로 그 경우엔 거래 ID를 주문번호로 고정하는 작업이 진단보다 먼저입니다.

중복 로드를 만드는 구성은 몇 가지 유형인가

다섯 가지로 정리됩니다.

첫째, 이중 설치입니다. 결제 완료 페이지 템플릿에 매체 스크립트를 직접 넣어둔 상태에서 GTM으로 같은 태그를 또 배포한 경우입니다. 솔루션 쇼핑몰에서 특히 잦습니다. 카페24는 메타 채널 설정을 완료하면 픽셀과 전환 API가 함께 자동 구성되는데, 이 사실을 모르고 GTM에 픽셀 태그를 따로 만들면 같은 이벤트가 두 경로로 나갑니다.

둘째, 태그 실행 옵션입니다. GTM 태그 고급 설정의 실행 옵션은 Unlimited, Once per event, Once per page 세 가지이고, Unlimited는 트리거가 지시할 때마다 매번 실행합니다. 결제 완료 지점의 태그가 이 값으로 남아 있고 트리거가 여러 번 걸리면 그대로 여러 건이 됩니다.

셋째, 화면 전환 감지입니다. 메타 픽셀 기본 코드는 HTML5 History State API 리스너를 기본값으로 활성화하므로, 라우트가 바뀔 때마다 픽셀이 자동으로 페이지뷰 이벤트를 발동시킵니다. 결제 완료 화면이 단일 페이지 애플리케이션 안의 한 라우트라면 이 동작이 중복의 원인이 됩니다.

넷째, 새로고침과 뒤로가기입니다. 완료 페이지가 다시 열릴 때마다 태그가 발동하는 구조라면 사용자가 화면을 새로고침한 횟수만큼 전환이 늘어납니다.

다섯째, 매체 스크립트 병존입니다. 네이버 광고 웹 전환 추적 스크립트는 한 사이트에 한 종류만 설치해야 하고, 신 스크립트와 구 스크립트가 같은 전환 지점에 함께 있으면 전환 이벤트가 중복 발생해 광고 보고서에도 중복 집계될 수 있습니다.

한 페이지에서 몇 번 발동했는지 어떻게 세나

추측 대신 실제로 셉니다. 테스트 주문을 한 건 넣고 완료 페이지에 도달한 상태에서 세 가지를 확인합니다.

미리보기 모드를 켜면 Tag Assistant 창에서 실행된 태그, 처리 중인 데이터, 트리거 조건 충족 여부를 볼 수 있습니다. 컨테이너를 열고 작업공간 탭에서 미리보기를 누른 뒤 테스트할 주소를 입력해 연결하면 새 창에서 사이트가 열립니다. 여기서 완료 페이지 도달 시점에 구매 태그가 몇 번 실행됐는지 그대로 셉니다.

브라우저 쪽은 Pixel Helper로 봅니다. 이 확장 프로그램은 어떤 픽셀 이벤트가 발동했는지, 성공과 실패 여부, 누락된 매개변수, 중복 이벤트, 브라우저 차단 요인을 함께 보여줍니다. 오독하기 쉬운 표시가 하나 있습니다. 추적 옵트아웃 경고가 뜬 상태에서는 화면에 이벤트가 잡혀도 실제로는 서버에 로그되지 않으므로, 이 상태의 브라우저로 개수를 세면 안 됩니다.

서버 쪽 이벤트는 이 도구들에 잡히지 않습니다. Pixel Helper는 브라우저 클라이언트 단만 보여주므로, 전환 API를 함께 쓰는 구성이라면 이벤트 관리자의 테스트 이벤트 도구로 확인합니다. 테스트 이벤트 코드를 페이로드에 실어 보내면 약 30초 이내에 이벤트명, 타임스탬프, 소스가 브라우저인지 서버인지, 중복 제거 여부까지 목록에 나타납니다.

여기서 반드시 함께 하는 동작이 새로고침과 뒤로가기입니다. 완료 페이지에서 새로고침 한 번, 뒤로가기 후 다시 앞으로 한 번을 밟으면서 각각 태그가 다시 실행되는지 셉니다. 이 두 동작을 빼고 검증하면 넷째 유형은 절대 잡히지 않습니다.

원인별로 어디를 바꾸나

유형이 다르면 손대는 자리도 다릅니다.

이중 설치라면 하나를 지웁니다. 남길 쪽은 관리 주체가 명확한 쪽입니다. 솔루션이 자동 구성하는 영역과 GTM 컨테이너가 겹칠 때는 GTM 쪽을 정리하고 솔루션 설정을 정본으로 두는 편이 유지보수가 단순해지는 경우가 많습니다. 어느 쪽을 남기든 태그 인벤토리에 소유자를 적어 둡니다.

실행 옵션 문제라면 결제 완료 태그를 Once per page로 바꿉니다. 화면 전환 감지 때문이라면 픽셀 기본 코드의 disablePushState 플래그를 true로 설정해 pushState 기반 자동 페이지뷰 발동을 끌 수 있습니다. 새로고침 재발동이라면 트리거 조건을 페이지 열림이 아니라 주문 완료라는 사건에 걸어야 하고, 그 사건은 데이터레이어 push로 넘어옵니다. 매체 스크립트 병존이라면 구 스크립트를 걷어내 한 종류만 남깁니다.

브라우저와 서버 양쪽으로 같은 이벤트를 보내는 구성이라면 지우는 것이 답이 아닙니다. 메타는 같은 event_name과 같은 event_id를 짧은 시간 안에 받으면 중복으로 판단해 하나만 계산하므로, 두 경로가 같은 event_id를 싣도록 맞추는 것이 정상 구성입니다.

이미 부풀려진 데이터는 어떻게 처리하나

되돌릴 수 없습니다. 태그를 고쳐도 그 사이 GA4와 각 매체에 들어간 이벤트는 사라지지 않고, GA4에서 주요 이벤트로 표시한 설정조차 설정 시점부터만 조회되고 과거 데이터에는 소급 적용되지 않습니다. 그래서 남는 작업은 기록입니다.

세 가지를 적습니다. 언제부터 언제까지 중복이 발생했는지, 어떤 이벤트와 어떤 매체가 영향을 받았는지, 건수 대조로 확인한 오차율이 얼마였는지입니다. 이 기록을 월간 리포트 각주로 붙여두면 다음 분기에 그 구간을 정상 데이터로 놓고 비교하는 사고를 막을 수 있습니다. 광고 성과를 그 구간과 비교해 판단해야 한다면 매체 리포트 대신 어드민 주문 데이터를 기준으로 놓는 편이 안전합니다.