Referer 헤더는 이미 믿기 힘들어졌고, 그래서 UTM을 붙인다는 얘기

• 어떤 사이트 운영자는 URL 뒤에 붙는 이상한 쿼리 문자열을 그냥 받아들이지 않음

  • Chris Morgan이라는 사람은 자기 사이트에 ?like=this&and=this 같은 쿼리 문자열이 붙으면 요청을 거부하도록 설정함
  • 사이트 주인이 자기 서버를 어떻게 운영하든 그건 당연히 자유임
  • 다만 글쓴이는 “출처가 궁금하면 Referer 헤더를 보면 된다”는 전제가 이제는 잘 안 맞는다고 봄

• Referer 헤더는 웹 유입 분석에서 예전만큼 믿을 만한 신호가 아님

  • 많은 방문은 Referer 없이 들어옴
  • 그러면 분석 도구에서는 그 트래픽이 Direct 또는 Unknown 같은 커다란 덩어리로 뭉개짐
  • 실제로는 뉴스레터, 앱, 프라이버시 설정, 브라우저 정책 때문에 출처가 사라졌을 수 있는데도 “직접 방문”처럼 보일 수 있음

• 그래서 글쓴이는 자신이 공유하는 외부 링크에 utm_source=Robin_Sloan_sent_me를 붙임

  • 특히 이메일 뉴스레터에서 클릭이 많이 발생한다는 걸 알고 있기 때문에, 링크를 받은 사이트가 출처를 알아볼 수 있게 하려는 의도임
  • Shopify 같은 상점 운영 환경에서는 갑자기 주문이나 구독이 늘었을 때 “이 트래픽이 어디서 왔지?”가 꽤 중요한 정보가 됨

• 실제로 이 정보가 도움이 된 사례도 있음

  • Abrams Planetarium에 갑자기 새 구독자가 몰렸을 때, 그 유입이 진짜 사람들인지 의심스러운 상황이 있었다고 함
  • 글쓴이와 짧은 이메일을 주고받으면서 “뉴스레터 독자들이 맞고, Sky Calendar를 원해서 온 사람들”이라는 점이 확인됨
  • 소규모 사이트나 상점 입장에서는 이런 맥락 하나가 운영상 꽤 유용할 수 있음

• 물론 모든 사이트가 쿼리 문자열을 잘 처리하는 건 아님

  • YouTube조차 예상 밖의 쿼리 문자열에서 문제가 생기는 사이트 목록에 들어간다고 언급됨
  • 그래서 글쓴이는 예외 목록을 따로 관리하고, 이번에 Chris Morgan의 사이트도 그 목록에 추가함

---

기술 맥락

• Referer 헤더는 원래 “이 요청이 어디서 왔는지” 알려주는 단서예요. 그런데 프라이버시 보호가 강화되고, 이메일 클라이언트나 앱 안 브라우저를 거치는 흐름이 많아지면서 이 값이 비어 있는 경우가 흔해졌어요.

• 그래서 UTM이 여전히 쓰이는 이유는 출처 정보를 요청 헤더에만 맡기기 어렵기 때문이에요. 링크 자체에 utm_source를 붙이면, 중간에 Referer가 사라져도 도착한 사이트의 분석 도구가 최소한 유입 맥락을 읽을 수 있어요.

• 다만 쿼리 문자열을 붙이는 방식은 호환성 비용이 있어요. 서버나 라우터가 예상하지 못한 파라미터를 거부하도록 되어 있으면 정상 링크도 깨질 수 있고, 캐시 키나 리다이렉트 처리에도 영향을 줄 수 있거든요.

• 이 글의 재미있는 지점은 추적 기술을 무조건 나쁘게만 보지 않는다는 데 있어요. 대규모 광고 추적이 아니라, 작은 사이트 운영자가 갑자기 늘어난 트래픽의 정체를 이해하게 해주는 최소한의 신호로 UTM을 쓰자는 입장이에요.