GA4 리퍼럴 스팸: 잘못된 필터 없이 트래픽 정리하기

월요일에 GA4가 1,800세션의 낯선 리퍼럴 소스를 보여 줍니다. 참여 시간은 0에 가깝고, 트래픽 거의 전부가 타깃 시장 밖의 한 도시에서 오며, 주문은 하나도 없습니다. 첫 반응은 흔히 그 도메인을 "원치 않는 추천"에 추가하는 것입니다. 거기서 멈추면 오염된 데이터를 없애는 것이 아니라 이름표만 바꾸는 것일 수 있습니다.

리퍼럴 스팸, 셀프 리퍼럴, 봇, 결제 업체의 리퍼럴은 획득 리포트에서 비슷해 보일 수 있습니다. 올바른 처리는 어떤 것인지 식별하는 데서 시작합니다.

GA4가 리퍼럴을 기록하는 방식

리퍼럴 세션은 GA4가 방문자가 다른 도메인의 링크를 통해 도착했다고 판단한 세션입니다. 이전 도메인이 source가 되고 medium은 보통 referral입니다.

실제 사이트가 방문자를 보낸 경우에는 정상적입니다. 다음과 같을 때 문제가 됩니다.

• 도메인이 결제 업체이거나 내 여정의 일부일 때;
• 내 도메인이나 서브도메인이 서로를 참조할 때;
• 봇이나 자동화된 브라우저가 추적을 작동시킬 때;
• 스팸 이벤트가 측정 엔드포인트로 직접 전송될 때;
• UTM 파라미터가 없어 캠페인 트래픽이 잘못 귀속될 때.

낯선 리퍼럴 행 하나가 봇 트래픽의 증거는 아닙니다.

혼동하기 쉬운 네 가지 상황

1. 정당한 원치 않는 리퍼럴

고객이 결제 대행사로 떠났다가 감사 페이지로 돌아옵니다. GA4는 결제 대행사를 새 소스로 취급하고 전환 기여를 그쪽에 줄 수 있습니다.

트래픽은 실제입니다. 여정을 거치면서도 원래의 획득 소스가 유지되도록 원치 않는 추천이나 크로스 도메인 측정을 설정하세요.

2. 셀프 리퍼럴

내 도메인이나 서브도메인이 소스로 나타납니다. 흔한 원인은 다음과 같습니다.

• 흐름의 일부에 Google 태그가 없음;
• 도메인 사이에서 쿠키가 사라짐;
• 크로스 도메인 측정이 불완전함;
• 리디렉션이 linker 파라미터를 제거함;
• 페이지마다 동의 동작이 다름.

도메인을 숨긴다고 측정 단절이 복구되지 않습니다. 쿠키와 태그 경로를 추적하세요.

3. 실제 사이트를 방문하는 크롤러 또는 봇

봇은 페이지를 불러와 브라우저처럼 추적을 실행합니다. 세션, 조회, 심지어 이벤트까지 나타날 수 있습니다. IP 유형, user agent, 행동, 속도, 클릭 품질을 조사하세요.

4. 고스트 스팸

웹사이트를 열지 않고 GA4로 이벤트가 전송됩니다. 낯선 호스트 이름, 의미 없는 페이지 경로, 스패머를 홍보하는 캠페인이 담길 수 있습니다. 요청이 웹 서버에 닿지 않으므로 접근 로그에는 아무것도 나타나지 않을 수 있습니다.

"원치 않는 추천"이 하는 일과 하지 않는 일

GA4는 일치하는 이벤트에 ignore_referrer=true를 표시해 그 리퍼러가 새로운 트래픽 소스가 되지 않게 합니다.

결제 대행사, 관리형 상호작용 도메인, 일부 크로스 도메인 흐름에 유용합니다. 하지만 다음에 유의하세요.

• 이벤트는 여전히 수집됩니다;
• 사용자와 세션이 사라지지 않습니다;
• 과거 리포트는 다시 쓰이지 않습니다;
• 스팸 도메인이 웹사이트에 접근하는 것이 차단되지 않습니다;
• 귀속이 direct가 되거나 이전 소스에 남을 수 있습니다.

스팸 도메인을 목록에 추가하는 것은 봇 필터가 아닙니다.

조사 워크플로

1단계: 세션 너머를 보기

다음을 추가하세요.

• 호스트 이름;
• 랜딩 페이지;
• 국가와 도시;
• 기기 카테고리;
• 브라우저;
• 참여율;
• 평균 참여 시간;
• 전환 또는 핵심 이벤트;
• 첫 사용자 소스와 세션 소스.

실제 소스는 전환율이 낮더라도 합리적인 랜딩 페이지, 다양한 기기, 읽는 행동을 보입니다. 스팸은 보통 나쁜 지표 하나가 아니라 일련의 이상 징후를 만들어 냅니다.

2단계: 호스트 이름 점검

호스트 이름은 내가 실제로 측정하는 도메인이어야 합니다. 낯선 호스트 이름이나 (not set)이 붙은 이벤트는 측정 ID가 다른 곳에서 사용되고 있을 가능성을 높입니다.

유효한 도메인이 여러 개라면 기억에 의존하지 말고 리포트나 BigQuery에서 허용 목록 로직을 유지하세요.

3단계: 서버 로그 비교

같은 시간 범위, 랜딩 경로, 지역을 사용하세요. GA4가 수천 세션을 보고하는데 서버에 대응하는 트래픽이 없다면 고스트 스팸이나 직접 이벤트 전송일 가능성이 더 높습니다.

로그에 반복되는 user agent의 데이터센터 IP에서 오는 요청이 빽빽하다면 봇이 사이트를 방문했을 가능성이 큽니다.

4단계: 누락된 캠페인 태그 확인

UTM이 없는 이메일, 제휴, 광고는 낯선 리퍼럴로 나타날 수 있습니다. 제외하기 전에 마케팅 팀에 그 도메인이 파트너, 결제 플랫폼, 리디렉션 서비스에 속하는지 물어보세요.

5단계: 시작 날짜 찾기

결제, 동의, 도메인, 태그를 바꾼 뒤 리퍼럴이 급증했다면 구현 문제일 때가 많습니다. 스팸은 릴리스 없이도 시작될 수 있지만 시점은 단서일 뿐입니다.

행이 아니라 원인을 처리하세요

결제 업체와 여정 도메인

1. 내가 운영하는 도메인에 크로스 도메인 측정을 설정합니다.
2. 적절하다면 결제 업체를 원치 않는 추천에 추가합니다.
3. DebugView로 전체 여정을 테스트합니다.
4. 원래 소스가 여전히 전환 기여를 받는지 확인합니다.

무작정 도메인을 추가하지 마세요. 가치 있는 리퍼럴이 direct 트래픽으로 바뀔 수 있습니다.

셀프 리퍼럴

Google 태그 적용 범위, 쿠키 도메인, 동의 상태, linker 파라미터를 확인하세요. 홈페이지만이 아니라 전체 흐름에서 Tag Assistant를 사용하세요.

셀프 리퍼럴은 측정 경로가 끊겼다는 증거입니다. 원치 않는 추천 규칙은 증상을 가릴 수는 있어도 다시 연결해 주지는 않습니다.

사이트를 방문하는 봇

기본 GA4 리포트에는 IP 주소가 노출되지 않습니다. 외부 증거를 사용하세요.

• 접근 로그 또는 CDN 로그;
• 가정용/데이터센터/VPN/Tor 분류;
• IP나 핑거프린트별 속도;
• 반복되는 user agent;
• 클릭 행동과 이벤트 타이밍.

IP 조회와 트래픽 점수는 조사 단서이며 방문자가 사람인지 봇인지 입증하지 않습니다. 애플리케이션 결과와 비교하고 불확실한 분류는 그대로 기록하세요.

고스트 스팸

이미 수집된 데이터를 제거하는 범용 버튼은 없습니다. 현실적인 통제 방법은 다음과 같습니다.

• 유효한 호스트 이름만 받는 리포트;
• 오염된 것으로 알려진 기간을 제외하는 세그먼트;
• Measurement Protocol 이벤트를 위한 서버 측 엔드포인트 보호;
• 가능한 한 공개 측정 식별자를 더 엄격하게 관리;
• 반복되는 캠페인, 호스트 이름, 지역 패턴 모니터링.

웹 측정 ID는 설계상 공개되어 있으므로 리포트 계층의 허용 목록이 비밀로 유지하려는 시도보다 대개 더 믿을 만합니다.

과거를 다시 쓰지 않고 분석 정리하기

GA4 설정 변경은 소급 적용되지 않습니다. 변경 날짜를 기록하고 두 기간을 분석하세요.

• 조치 전: 확인된 소스나 호스트 이름을 제외하는 세그먼트를 사용합니다.
• 조치 후: 새 설정이 작동하는지 확인합니다.

BigQuery나 웨어하우스에서는 행을 삭제하는 대신 traffic_quality_status 필드를 추가하세요.

• valid;
• internal;
• known_bot;
• suspected_bot;
• ghost_spam;
• attribution_issue.

원본 데이터가 있으면 감사 추적을 잃지 않고 나중에 분류를 수정할 수 있습니다.

유용한 리퍼럴 스팸 알림 보드

하나의 임계값으로 트래픽을 자동 삭제하지 마세요. 알림은 조사를 시작하게 할 뿐이며 결정에는 여러 신호가 필요합니다.

자주 하는 실수

이탈률이 높은 리퍼럴을 모두 제외

실제 뉴스 기사나 디렉터리가 한 페이지만 읽는 독자를 보낼 수 있습니다. 전환율이 낮다고 해서 사기가 입증되는 것은 아닙니다.

넓은 정규식 규칙 작성

"pay"와 일치하는 규칙은 PayPal, 결제 서브도메인, 관련 없는 유효한 소스에도 영향을 줄 수 있습니다. 정확한 도메인을 표준화하고 릴리스 전에 조건을 테스트하세요.

GA4만 고치고 서버는 무시

실제 봇은 리포트에서 숨긴 뒤에도 대역폭을 소모하고 광고를 클릭할 수 있습니다. 애널리틱스 위생과 트래픽 보호는 별개의 계층입니다.

필터링된 GA4와 원본 로그 비교

로그에는 자산, 크롤러, API, 실패한 요청이 포함되고, GA4에는 동의에 따라 달라지는 클라이언트 이벤트가 포함됩니다. 합계를 비교하기 전에 두 소스를 표준화하세요.

공개 태그 검사는 외부에 보이는 계측 코드를 식별합니다. 비공개 GA4 보고서를 가져오거나 실제 방문자 비율을 계산하지 않습니다. 권한이 있는 보고서를 애플리케이션 및 서버 증거와 비교하세요.

한 번에 끝내는 정리 체크리스트

1. source/medium, 호스트 이름, 랜딩 페이지를 확인합니다.
2. 참여도, 지역, 기기, 전환을 비교합니다.
3. 서버 또는 CDN 로그와 대조합니다.
4. 마케팅 팀에 결제, 제휴, 리디렉션에 대해 묻습니다.
5. 기여도 문제, 셀프 리퍼럴, 실제 봇, 고스트 스팸으로 분류합니다.
6. 알맞은 통제 방법을 적용하고 날짜를 기록합니다.
7. 최소한 한 번의 비즈니스 주기를 모니터링합니다.

다음 사고로부터 반복 리포트 보호하기

즉각적인 정리를 마친 뒤에는 로직을 한 분석가의 노트에서 꺼내세요. 유효한 호스트 이름, 소유 도메인, 결제 업체, 알려진 내부 소스, 확인된 스팸 패턴의 작은 참조 표를 유지하세요. 모든 항목에 담당자와 검토 날짜를 지정하세요.

대시보드에는 원본 보기와 정리된 보기를 모두 노출하세요. 원본 데이터는 증거를 보존하고, 정리된 보기는 주간 의사결정을 뒷받침합니다. 이해관계자가 정리된 획득 차트를 필터링되지 않은 경영진 합계와 비교하며 추적이 깨졌다고 생각하지 않도록 필터를 눈에 띄게 표시하세요.

새로운 source/호스트 이름 쌍과 세션 대비 참여 비율의 급격한 변화에 대한 이상 알림을 만드세요. 알림에는 랜딩 페이지와 지역이 포함되어 분석가가 리포트를 다섯 개나 열지 않고도 조사할 충분한 맥락을 얻을 수 있어야 합니다.

조치 날짜를 주석이나 데이터 품질 로그에 문서화하세요. 원치 않는 추천 규칙, 동의 릴리스, 호스트 이름 필터가 6월 10일에 바뀌었다면 전년 대비 차트가 달라졌을 때 이후의 분석가에게 그 맥락이 필요합니다.

무엇보다 제거를 연습하세요. 오탐 필터는 실제 제휴나 캠페인을 숨길 수 있습니다. 모든 규칙은 되돌릴 수 있어야 하며, 예산 결정에 사용하는 리포트에 반영되기 전에 복사한 탐색에서 테스트해야 합니다.

결론

추천 스팸은 기여 분석 설정, 애플리케이션 증거와 관련 로그로 조사하세요. 보안 헤더만으로 이벤트나 추천 소스의 진위를 판단할 수 없습니다.

참고 자료: Google Analytics 고객센터 – 원치 않는 추천 식별.