개발·스테이징 트래픽이 운영 데이터에 섞일 때

증상

보고서의 호스트 이름을 펼쳐 보면 운영 도메인 아래에 localhost나 미리보기 배포 주소(*.vercel.app, *.netlify.app), staging. dev.로 시작하는 주소가 함께 들어 있습니다. 배포가 있었던 날만 세션 그래프가 솟고, 그 다음 날 다시 내려갑니다.

더 나쁜 증상은 매출 쪽에서 나옵니다. QA가 결제 플로우를 열 번 돌린 날, 주문 관리 시스템에는 없는 purchase가 GA4에만 열 건 잡혀 있습니다. 실제 매출과 GA4 매출이 왜 다른지를 설명하려고 앉았다가, 원인이 우리 팀이었다는 걸 알게 되는 순간입니다.

원인

개발·스테이징 환경이 운영과 같은 측정 ID를 쓰고 있기 때문입니다. GA4는 이벤트가 어느 환경에서 왔는지 스스로 알지 못하고, 태그가 실린 곳이면 어디든 똑같이 수집합니다. 실제로 자주 나오는 경로는 이렇습니다.

AnalyticScan은 호스트 이름별 세션 비중을 봅니다. 비운영으로 판정하는 패턴은 localhost, 127.로 시작하는 주소, .vercel.app·.netlify.app으로 끝나는 호스트, 그리고 staging.·dev.·test.로 시작하는 호스트입니다. 이 호스트들이 전체 세션의 0.5%를 넘으면 주의, 2%를 넘으면 감점으로 봅니다.

0.5%라는 기준이 낮아 보인다면, 이 트래픽의 문제가 양이 아니라 성격이기 때문입니다. 일반 방문자는 대부분 한두 페이지를 보고 나가지만, 개발자와 QA는 전환 경로만 골라서 반복해 밟습니다. 세션 기준으로 1%밖에 안 되는 트래픽이 purchase나 generate_lead 같은 키 이벤트에서는 훨씬 큰 몫을 차지할 수 있습니다. 전체 방문자 수는 1% 틀리는데 전환율과 매출은 그보다 훨씬 크게 틀어지는 구조입니다.

GA4에서 확인

1) 호스트 이름으로 나눠 본다. 탐색에서 호스트 이름을 측정기준으로 놓고 세션 수를 세워 보세요. 운영 도메인 말고 무엇이 있는지, 각각 몇 퍼센트인지가 한 화면에 나옵니다.

2) 키 이벤트를 호스트 이름별로 다시 센다. 같은 표에 purchase나 폼 제출 이벤트를 얹어 보세요. 세션 비중보다 이벤트 비중이 훨씬 크다면, 비운영 트래픽이 정확히 아픈 자리를 밟고 있다는 뜻입니다.

3) 날짜를 배포 일정과 대조한다. 비운영 호스트의 세션을 날짜별로 펼치면 대개 특정 날짜에 몰려 있습니다. 그 날짜가 배포일·QA 일정과 겹치는지 확인하면 누구의 트래픽인지가 바로 좁혀집니다.

수정

환경마다 다른 측정 ID를 쓰는 것이 유일한 확실한 해법입니다. 측정 ID를 환경 변수로 주입하고, 운영이 아닌 환경에서는 빈 값을 넣어 태그를 아예 로드하지 않게 하거나 개발 전용 속성으로 보내세요. 하드코딩된 ID 하나를 환경 변수로 바꾸는 작업이 대부분의 경우 30분입니다. GTM을 쓴다면 컨테이너의 환경 기능이나 환경별 변수로 같은 일을 할 수 있습니다.

당장 배포가 어렵다면 임시로 필터를 씁니다. 관리자 > 데이터 스트림 > 태그 설정 구성 > 내부 트래픽 정의에서 개발 환경의 IP를 등록하고, 관리자 > 데이터 수집 및 수정 > 데이터 필터에서 그 필터를 활성으로 바꾸세요. 다만 IP 기반이라 재택·모바일 회선은 잡히지 않고, 필터가 테스트 상태로 남아 있으면 아무것도 빠지지 않습니다 — 이 함정은 앞 글에서 따로 다뤘습니다.

로컬 디버깅은 개발자 트래픽 필터로도 걸러집니다. GA4의 데이터 필터에는 내부 트래픽 말고 개발자 트래픽 유형이 있고, 디버그 모드로 들어온 이벤트를 제외합니다. 디버그 모드를 켜고 작업하는 로컬 환경에는 잘 맞지만, 디버그 모드 없이 그냥 도는 스테이징 서버에는 해당하지 않습니다.

테스트 결제는 데이터를 남깁니다. 이미 들어온 가짜 주문은 필터로 지워지지 않습니다. 소급 적용이 없으므로 과거 기간을 분석할 때는 탐색에서 비운영 호스트 이름을 제외한 세그먼트로 읽어야 합니다.

한 줄 요약

개발 트래픽은 적은 양으로 가장 비싼 숫자를 틀리게 만듭니다. 호스트 이름을 한 번만 펼쳐 보면 5분 안에 알 수 있고, 제대로 된 해법은 필터가 아니라 환경마다 다른 측정 ID입니다.