(fGTM + sGTM 기반 Payload 수집 아키텍처)
GA4(Google Analytics 4)는
웹과 앱의 사용자 행동을 수집하는 대표적인 분석 도구입니다.
하지만 실제 운영 환경에서는
한 가지 아쉬운 지점을 자주 마주하게 됩니다.
“GA4로 어떤 데이터가 실제로 전송되고 있는지 직접 확인하기 어렵다”
우리가 확인할 수 있는 대부분의 정보는
GA4 UI 또는 BigQuery에 적재된 결과 데이터입니다.
이벤트가 생성되어 전송되는 그 순간의 데이터(Payload) 는
일반적인 환경에서는 쉽게 확인하기 어렵습니다.
이번 글에서는
GA4 이벤트가 전송되기 직전의 Payload를 실시간으로 확보하는 방법을
fGTM(Client-side GTM)과 sGTM(Server-side GTM)을 활용한 구조를 통해
간단한 예제로 소개합니다.
GA4 이벤트는 어디에서 어떻게 수집될까요?
일반적인 GA4 이벤트 수집 흐름은 다음과 같습니다.
- 사용자가 페이지에 접속하거나 행동 수행
- 브라우저에서 GA4 이벤트 생성
- 이벤트가 Google Analytics 서버로 전송
- GA4 UI 또는 BigQuery Export를 통해 결과 확인
이 과정에서 우리가 확인하는 것은 결국 집계된 데이터입니다.
하지만 이벤트가 전송되는 순간,
즉 GA4로 전달되는 Payload 자체는
직접 확인하기 어려운 영역에 속합니다.
왜 GA4 Payload를 직접 확인해야 할까요?
GA4 이벤트는 단순한 트리거가 아니라
여러 정보가 포함된 데이터 묶음입니다.
- 이벤트 이름
- 페이지 정보
- 세션 정보
- 이벤트 파라미터
- 사용자 속성 등
만약 Payload를 직접 확인할 수 있다면,
- 이벤트가 의도한 시점에 생성되는지
- 값이 정상적으로 매핑되어 전송되는지
- 태깅 변경 이후 데이터 구조가 달라지지 않았는지
보다 빠르게 검증할 수 있습니다.
UA customTask 방식과의 차이
UA 시절에는 Payload는 GTM 상에서 customTask를 통해 데이터를 hooking 하여
SendHitPayload 데이터를 확인하는 방식을 사용하였습니다.
하지만 GA4 환경에서는 동일한 방식이 제공되지 않기 때문에
sGTM을 활용한 서버 기반 접근이
현실적인 대안으로 자리잡고 있습니다.
sGTM을 처음 접하는 분들을 위한 간단한 설명!
Server-side GTM(sGTM)은 브라우저가 아닌 서버 환경에서 태그를 실행하는 방식으로
기존 구조는 아래와 같은 흐름이 였다면,
Browser
→ Client-side GTM (fGTM)
→ GA4
sGTM 을 적용하면 여기에 한 가지 단계가 추가됩니다.
Browser
→ Client-side GTM (fGTM)
→ Server-side GTM (sGTM)
→ GA4
sGTM 역할은 무엇인가요?
최근 브라우저 환경 변화로 인해
- 광고 차단 증가
- 쿠키 제한 강화
- 네트워크 제약 확대
와 같은 이슈가 지속적으로 발생하고 있습니다.
sGTM은 이러한 환경에서
- 데이터 전송 안정성 확보
- 서버 중심 데이터 흐름 구성
을 가능하게 하는 역할을 합니다.
즉, 단순한 태그 도구를 넘어 데이터 파이프라인의 중간 레이어로 활용할 수 있습니다.
fGTM + sGTM 기반 Payload 수집 아키텍처
이 구조의 핵심은
이벤트 전송 과정 중간에
데이터를 제어할 수 있는 지점이 생긴다는 것입니다.
sGTM에서 GA4로 전달되기 직전의 Payload를 외부 시스템으로 한 번 더 전송합니다.
이렇게 하면 GA4 이벤트의 실제 Payload를 실시간으로 확인하거나 저장할 수 있습니다.
간단한 구현 흐름
전체 흐름은 크게 복잡하지 않습니다.
- fGTM에서 GA4 이벤트(page_view 등) 발생
- 이벤트가 sGTM 컨테이너로 전달
- sGTM 태그 템플릿에서 Payload 추출
- 외부 Webhook URL로 POST 전송
- 이후 GA4로 정상 전달
이 방식은 기존 GA4 태깅 구조를 크게 변경하지 않고도
실시간 Payload 로그를 확보할 수 있는 방식입니다.
Step 1. sGTM 태그 템플릿을 활용한 기능 구현
앞서 설명드린 내용을 테스트하기 위해서는
sGTM 內 커스텀 태그 템플릿을 활용하여 아래 기능을 구현해야 합니다.
- 요청 Payload 파싱
- 외부 URL POST 전송
- 전송 결과 로그 처리
※ 아래 이미지 ① 는 sGTM 內 커스텀 태그 템플릿을 활용한 기능 구현 내용 일부로,
구현된 태그 템플릿을 ② 태그 영역에서 설정하여 사용하겠습니다.
①
②
Step 2. 실제 페이지 로드 시 전송된 Payload 확인
sGTM 內 커스텀 태그 템플릿 구현 이후 반영하고 테스트를 진행하겠습니다.
페이지가 로드되면 아래와 같은 Payload가 외부 Webhook으로 실시간 전달되는 것을 볼 수 있으며
이벤트 이름, 페이지 정보, 세션 값 등 GA4 이벤트의 실제 데이터 구조를 확인할 수 있습니다.
(1) sGTM 미리보기 내용 확인
(2) webhook.site 내용 확인
Payload 수집 이후 활용 가능 영역
Payload 데이터는 단순한 디버깅을 넘어 데이터 운영 관점에서도 활용할 수 있습니다.
이벤트 품질 모니터링
- 잘못된 파라미터 실시간 감지
- 태깅 오류 빠른 확인
릴리즈 전 사전 검증
- page_view / purchase 이벤트 테스트
- 값 누락 여부 확인
데이터 로그 백업
- GA4 이전 단계 원본 데이터 보관
- 분석 이슈 발생 시 추적 가능
데이터 구조 변경 감지
- 이벤트 버저닝 관리
- Breaking Change 탐지
마치며
GA4는 강력한 분석 도구이지만
이벤트가 실제로 어떻게 전송되는지는 쉽게 드러나지 않습니다.
fGTM과 sGTM을 함께 활용하면
GA4로 전달되는 Payload를 실시간으로 확인할 수 있고,
데이터 품질과 운영 가시성을 한 단계 높일 수 있습니다.
이번 글에서 소개한 구조가
GA4 데이터 흐름을 이해하는 데 작은 도움이 되기를 바랍니다.
최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.