Google Tag Gateway를 쓰면 뭐가 좋아지나?

성과 판단의 데이터를 지키는 도구의 필요성

전환 수가 줄었다. 대시보드를 연 마케터가 가장 먼저 떠올리는 가설은 보통 하나다. "성과가 나빠졌다."

그런데 지난 몇 년간 GA4, Google Ads, 쿠키 제한, ad blocker, 브라우저 privacy 변화가 동시에 진행되면서, 점점 더 자주 일어나는 일은 다른 쪽이다. 성과가 나빠진 게 아니라 측정이 어려워진 것이다. 실제 매출과 리드는 그대로인데, 그 사실을 우리에게 보고하는 신호가 중간에서 사라져버리는 것이다.

이 혼란을 깔끔하게 해결해주는 마법의 버튼은 없지만, 그 '사라진 신호'의 일부를 다시 붙잡으려는 측정 인프라(measurement infrastructure)의 변화가 조용히 진행되고 있다. Google Tag Gateway는 그 변화의 한 축이 될수 있는 유의미한 해결수단을 제공한다. (물론, 모든 데이터 유실 문제를 해소해주는 것은 아니다!)

Google Tag Gateway란 무엇인가

일반적으로 널리 쓰이는 기본적인 데이터 측정 방식은, 방문자가 브라우저를 통해 우리 사이트에 들어오면, 그 브라우저는 GA4와 같은 성과 측정 인프라쪽으로 직접 신호를 보내는 구조이다. googletagmanager.com에서 태그 스크립트를 받아오고, google-analytics.com으로 방문 기록을 보낸다. 우리 웹사이트는 그 데이터 송수신에 거의 관여하지 않는다.

비유를 하자면, 손님이 가게에 들어오자마자 밖에 있는 본사로 직접 전화를 거는 구조에 가깝다.

문제는 그 직통 전화가 점점 잘 안 걸린다는 점이다. 브라우저와 확장 프로그램은 third-party 추적 요청을 제한하고, 보안·네트워크·privacy 정책은 일부 요청을 차단한다. 여러 개의 외부 광고·분석 endpoint로 직접 요청이 나가니 페이지 성능과 거버넌스(governance)도 복잡해진다.

Google Tag Gateway는 이 구조를 살짝 바꾸어서, Google tag나 GTM container를 외부 Google 도메인에서 직접 부르는 대신, 자사 웹사이트 도메인 안에 마련한 measurement path(/gtm-gateway/나 /measurement-path/처럼 내 도메인 뒤에 붙인 전용 주소 경로)를 통해 로드하고, 측정 hit 역시 자사 도메인을 거쳐 Google로 전달한다. 가게 안에 접수 창구를 하나 두고, 손님의 요청을 그 창구가 받아 본사로 전달하는 first-party routing 방식이다.

이 구조가 적용되면 브라우저가 보내는 요청은 외부 Google 도메인이 아니라 자사 도메인 안의 경로로 향한다. 예를 들어 D.intelligence 사이트에서는 측정 요청이 dintelligence.co.kr 도메인 내부의 measurement path로 향한 뒤 Google로 forward되는 구조가 형성된다.

손님 입장에서는 외부로 직접 전화를 거는 게 아니라, 늘 드나들던 가게의 창구에 말을 거는 셈이된다고나 할까?

무엇이 좋아지는가

Google 공식 문서가 제시하는 이점은 data privacy 강화, measurement signal recovery 개선, conversion measurement accuracy 개선, 그리고 이를 통한 광고 입찰(bidding)·캠페인 최적화(campaign optimisation)·ROAS 판단 개선 가능성이다.

마케터의 언어로 설명하자면 다음 네 가지가 좋아진다고 요약할수 있다.

첫째, 데이터 손실 가능성을 줄인다. 가장 흔한 오해부터 정리하자. Tag Gateway의 가치는 "트래픽이 갑자기 늘어난다"가 아니다. 더 정확한 표현은 "기존 환경에서 사라질 수 있었던 일부 measurement signal을 더 안정적인 first-party 경로로 회수할 가능성을 높인다"이다. GA4의 session, event, key event, Google Ads conversion이 이전보다 덜 누락될 수 있다는 뜻이다.

둘째, AI 입찰의 입력값이 단단해진다. 퍼포먼스 마케팅에서 전환 데이터는 단순한 결과 보고서가 아니라, 입찰 알고리즘(bidding algorithm)이 학습하는 재료가 된다. 전환 성과 신호(conversion signal)의 품질이 곧 캠페인 최적화(ampaign optimisation)의 품질로 이어진다. 더 안정적인 전환 측정은 더 신뢰할 수 있는 conversion signal로, 그 신호는 더 나은 입찰 학습 데이터로, 결국 ROAS 해석의 신뢰도로 연결된다. Tag Gateway는 광고 소재나 타겟팅을 바꾸는 도구가 아니다. 그 판단의 바탕이 되는 데이터를 덜 잃어버리게 만드는 도구인 셈이다.

셋째, 캠페인 기여 분석(Campaign Attribution)이 조금 더 또렷해질 수 있다. 마케팅 성과 관리에서 가장 골치 아픈 장면들이 있다. 광고 클릭은 분명 있었는데 GA4에서 source/medium이 흐려지고, 전환은 났는데 캠페인 기여 분석(Campaign Attribution)이 불명확하며, direct / none 비중이 비정상적으로 높고, Google Ads와 GA4의 전환 수가 따로 논다. Tag Gateway가 이 모든 걸 해결하지는 않지만, 성과 측정 데이터 신호를 first-party 경로로 더 안정적으로 전달함으로써 attribution 품질 개선에 기여할 여지가 있다.

넷째, 개인정보 보호(privacy)를 존중하면서 측정한다. 이 지점이 가장 오해받기 쉽다. Google의 쿠키 처리(cookie handling) 문서에 따르면, Tag Gateway는 자사 쿠키(first-party cookie)가 포함된 요청을 받을 수 있지만 Google은 Google 자사 쿠키만 사용하며, 게이트웨이를 거쳐 전달된 비(非) Google 자사 쿠키는 삭제(drop)한다. 즉, 이것은 "개인정보 보호 제한을 우회하는 기술"이 아니다. 개인정보 보호 요구사항(privacy requirement)을 무시하지 않으면서, 허용된 신호만 더 안정적으로 전달하려는 개인정보 보호 친화적(priavcy-aware) 자사 기반 측정 인프라다.

오해하면 안 되는 것들

좋은 도구일수록 과장의 위험도 크기 때문에 몇가지는 분명히 선을 그어야 한다.

먼저 Tag Gateway가 모든 추적 손실을 되돌려 주는 건 아니다. 광고 차단 프로그램(ad blocker), 브라우저 제한, 동의 거부, 쿠키 삭제, 기기 간 이동(cross-device) 같은 이유로 생기는 손실은 Tag Gateway를 사용한다고 하더라도 여전히 온전히 복구하지는 못한다.

또한 사용자 동의 없이 데이터를 수집하게 해주는 기술은 아니어서 Consent Mode를 대신하지 않는다. Tag Gateway를 켜면 태그가 동작하는 방식(tag firing)에 영향이 있을 수 있다. 그래서 Google도, 동의 상태에 따라 측정 방식이 달라지는 구조라면 Consent Mode와 동의 설정(consent setting)을 함께 점검하라고 안내한다. Consent Mode는 동의 배너 자체가 아니라, 사용자의 선택을 측정 방식에 반영하는 ‘연결층’이다. Tag Gateway는 그 위에서 작동할 뿐, 이를 건너뛰지 않는다.

마지막으로, 이것은 말 그대로 Google용 Tag Gateway다. Meta Pixel, 카카오, 네이버, TikTok, CRM 이벤트 파이프라인까지 한 번에 해결해주지 않는다. 여러 매체를 함께 관리하려면 server-side GTM, Conversion API, 오프라인 전환 업로드, CRM 매칭, 이벤트 기준(택소노미) 표준화, 동의 기반 데이터 레이어 설계 같은 작업이 별도로 필요하다.

마지막으로, "성과 증가"와 "측정 회수"를 혼동하면 안 된다. 적용 후 GA4 전환 수가 늘었다고 해서 매출이 늘었다고 단정할 수 없다. 실제 전환 증가일 수도 있고, 이전에는 측정되지 않던 전환이 회수된 결과일 수도 있다. 보고서는 둘을 반드시 구분해야 한다.

Server-side GTM과는 어떻게 다른가?

Tag Gateway와 server-side tagging은 비슷한 문제의식에서 출발한다. 브라우저가 외부 측정 서버로 바로 요청을 보내는 구조를 줄이고, 내 도메인 안에서 측정 흐름을 관리해 데이터 품질과 개인정보 보호를 함께 챙기고 싶다는 것이다. 하지만 둘은 같은 도구가 아니다.

server-side tagging은 내가 운영하는 중간 서버(중계 지점)를 두고 데이터를 검증·정리·가공할 수 있는 더 강력한 방식이다. 대신 구축과 운영이 복잡하다. 반면 Tag Gateway는 더 가볍고 Google 태그 신호가 덜 누락되게 first-party 경로로 전달하는 데 초점이 있다.

둘은 경쟁이라기보다 단계가 다른 선택지에 가깝다. Tag Gateway는 “server-side로 가기 전, 가볍게 시작하는 옵션”으로 보면 이해가 쉽다.

그래서, 효과는 어떻게 측정하나

여기서 가장 흔한 함정이 나온다. Tag Gateway의 효과를 GA4의 raw 숫자만으로 판단하는 것이다. GA4 자체가 개선의 대상인데, 그 숫자가 늘었다고 효과를 입증하려 하면 ‘자기 자신을 기준으로 자기를 증명’하는 순환에 빠진다.

그래서 GA4를 더 안정적인 외부 기준(external denominator)과 비교해야 한다. 예를 들어 Cloudflare의 page views·unique visitors, 서버 로그의 page request, 구글 서치 콘솔(GSC)의 클릭(clicks), CRM 리드 수치, 실제 폼 수집-제출 수가 있다.

이들을 분모로 두고 비율의 변화를 볼수 있는데, 굳이 수식을 만들자면 아래와 같이 구성할수 있다.

normalized_rate = GA4 metric / external denominator
uplift_% = ((post_rate - baseline_rate) / baseline_rate) * 100

마케터로서 실무적인 관점에서 관찰해야할 지표는 다음과 같다.

GA4 sessions / Cloudflare unique visitors
GA4 page_views / Cloudflare page_views
GA4 key events / Cloudflare page_views
Google Ads conversions / Google Ads clicks
direct / none session share
paid traffic attributed conversions
session_start : page_view ratio

하지만 위 수식의 개선(uplift) 수치는 계산 방법을 보여주는 예시일 뿐이다. 실제 효과는 사이트마다 다르기 때문에, 트래픽 규모, 동의율, 브라우저 구성, 광고 유입 비중, 기존 태그 품질에 따라 결과가 달라질수 있다.