다크 트래픽: AI 유입은 왜 추적이 어려운가

ChatGPT Search·Perplexity·Google AIO가 검색 유입 채널로 비중을 넓히면서 GA4 "direct / (none)" 버킷이 설명되지 않는 속도로 증가하는 현상이 측정 실무자 사이에서 공통 문제로 부상했다. 이 트래픽의 실체는 AI 응답 안의 링크를 클릭한 사용자 세션이지만, HTTP Referrer 헤더가 전달되지 않거나 경로에서 소실되어 출처를 식별할 수 없다. 이를 다크 트래픽(dark traffic)이라 부른다. 문제는 어트리뷰션 오류에 그치지 않는다. AI 채널의 전환율·이탈률·세션 품질을 측정하지 못하면 AEO·GEO 최적화 효과를 정량적으로 평가할 근거가 없다.

Referrer 유실의 세 가지 기술적 경로

• Referrer-Policy 헤더 제약: 대부분의 AI 챗봇 웹 인터페이스는 Referrer-Policy: strict-origin-when-cross-origin을 채택한다. 이 정책은 cross-origin 요청에서 origin(스킴+호스트+포트)만 전달하고 경로·쿼리스트링을 제거한다. 왜: origin 정보는 착지 서버 로그에 남아야 하지만, CDN·WAF·캐시 레이어를 거치면서 이 값마저 소거되는 경우가 실측상 빈번하다. 어떻게: Nginx 액세스 로그의 $http_referer 필드를 확인하면 빈 문자열이거나 https://chat.openai.com origin만 남은 두 가지 패턴이 혼재한다.
• 네이티브 앱 WebView: ChatGPT·Perplexity 앱은 외부 링크를 SFSafariViewController(iOS) 또는 Chrome Custom Tabs(Android)로 열거나, 앱 내장 WebView로 렌더링한다. 왜: 두 경우 모두 앱 컨텍스트에서 새 세션이 초기화되므로 브라우저 내비게이션 히스토리가 없고 Referer 헤더 자체가 생성되지 않는다. 어떻게: 착지 서버에서는 iOS 경유 시 UA에 CFNetwork, Android 경유 시 okhttp 문자열이 포함되므로 서버 로그 기반 분류가 가능하다.
• 중간 리다이렉트 레이어: Perplexity는 일부 환경에서 pplx.page 또는 자체 리다이렉트 엔드포인트를 링크에 삽입한다. 왜: 클릭 집계 목적의 프록시 레이어가 최종 Referer를 원본 도메인 대신 리다이렉트 서버 도메인으로 노출하거나, 302 체인 말단에서 소실시킨다. 어떻게: curl -sI -L "https://pplx.page/..."로 리다이렉트 체인을 추적하면 최종 Location 요청에 Referer 헤더가 포함되지 않음을 확인할 수 있다.

AI 플랫폼별 Referrer 전달 특성 비교

Google AIO는 예외다. 검색 결과 페이지 내 링크 클릭 시 Referer가 https://www.google.com/으로 전달되어 GA4에서 organic 채널로 집계된다. AIO 세션과 기존 오가닉 클릭을 구분하려면 Google Search Console 데이터를 별도 대조하거나, 착지 URL에 UTM 파라미터를 심어야 한다.

클라이언트사이드 탐지 구현

document.referrer를 페이지 로드 시점에 캡처해 GA4 커스텀 이벤트로 기록하는 방식이다. Referrer가 완전히 유실된 세션은 탐지하지 못하지만, origin 수준 정보라도 전달된 세션을 분류한다. 서버 로그 분석과 병행해야 탐지 커버리지를 최대화할 수 있다.

// ai_referrer_tracker.js
// GA4 gtag.js 초기화 이후 실행 (defer / DOMContentLoaded 보장)

const AI_REFERRER_MAP = {
  chatgpt:    /chat\.openai\.com|chatgpt\.com/i,
  perplexity: /perplexity\.ai/i,
  claude:     /claude\.ai/i,
  gemini:     /gemini\.google\.com/i,
  copilot:    /copilot\.microsoft\.com|bing\.com/i,
  you:        /you\.com/i,
};

(function detectAITraffic() {
  const referrer = document.referrer || '';
  let detectedSource = null;

  for (const [source, pattern] of Object.entries(AI_REFERRER_MAP)) {
    if (pattern.test(referrer)) {
      detectedSource = source;
      break;
    }
  }

  if (!detectedSource) return;

  // GA4 커스텀 이벤트 — Explore 보고서에서 ai_source로 필터링 가능
  gtag('event', 'ai_traffic_detected', {
    ai_source:    detectedSource,
    referrer_raw: referrer.substring(0, 200), // GA4 문자열 파라미터 256자 제한 고려
    landing_page: window.location.pathname,
  });

  // 세션 전반에 걸쳐 전환 이벤트에 ai_source 병기
  sessionStorage.setItem('ai_traffic_source', detectedSource);
})();

// 전환 이벤트 발화 예시
function sendConversionEvent(eventName, params = {}) {
  const aiSource = sessionStorage.getItem('ai_traffic_source');
  gtag('event', eventName, {
    ...params,
    ...(aiSource ? { ai_source: aiSource } : {}),
  });
}

서버사이드 보완: Nginx 액세스 로그에 $http_referer와 $http_user_agent를 기록하고 Loki·BigQuery·Elasticsearch로 수집한다. CFNetwork 또는 okhttp UA 패턴을 필터링하면 앱 WebView 유입 세션을 별도 집계할 수 있다. 이 두 레이어를 병행해야 direct 버킷의 실질 구성 비율을 추정할 수 있다.

흔한 오해: "direct 증가 = AI 트래픽" 단순 치환의 위험

GA4 direct 버킷 증가를 전부 AI 트래픽으로 귀속시키는 분석은 잘못된 결론으로 이어진다. direct 세션에는 북마크 접속, 이메일·Slack·KakaoTalk 앱 링크, Referrer-Policy를 강화한 타 사이트에서의 이동, 브라우저 주소창 직접 입력이 혼재한다. AI 트래픽만을 분리하지 않으면 전환율·이탈률 산정 기준이 왜곡된다.

올바른 처리법: GA4 탐색 보고서에서 direct 세션을 랜딩 페이지와 교차 분석한다. AI 챗봇이 자주 인용하는 특정 깊은 URL(가이드·FAQ·블로그 포스트)로의 direct 유입이 AI 검색 성장 시점과 동기화해 증가한다면, 해당 세션의 상당 비중이 AI 출처일 가능성이 높다. 확인 방법은 두 가지다. 첫째, Google Search Console "외부 링크" 탭에서 해당 URL의 신규 참조 도메인 증가를 확인한다. 둘째, Perplexity·ChatGPT에서 관련 키워드를 직접 질의해 해당 URL이 인용되는지 수동 검증한다. 두 신호가 일치하면 AI 기여 비중으로 잠정 분류할 수 있다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.

• Google 검색 센터 — SEO 기본 가이드
• Google — 구조화 데이터 마크업 & 리치 결과
• Schema.org — 구조화 데이터 시작하기