GTM 디버깅 실전 가이드: 태그 실행부터 GA4 수집까지 확인하기

GTM(Google Tag Manager)은 웹사이트의 측정 태그를 관리하는 도구입니다. 태그는 GA4 같은 서비스에 데이터를 보내도록 설정한 코드이고, 트리거는 태그를 실행할 조건입니다. GA4는 웹사이트와 앱의 이용 현황을 분석하는 Google 도구로, 이 글에서는 태그가 데이터를 보내는 곳입니다. 이벤트는 페이지 조회나 클릭 같은 행동을 알리는 신호이고, 변수는 주소나 클릭 문구처럼 조건 비교에 쓰는 값입니다.

디버깅은 문제가 생기는 조건을 재현하고 원인을 좁히는 작업입니다. "태그가 안 찍힌다"는 말만으로는 태그가 실행되지 않았는지, 요청이 차단됐는지, 보고서에 아직 반영되지 않았는지 알 수 없습니다. 그래서 행동 한 번을 기준으로 아래 네 단계를 따로 확인합니다. 단계마다 알 수 있는 것과 아직 알 수 없는 것이 다릅니다.

클릭 한 번이 GA4에 도착하기까지 확인하는 네 단계

1. 11. dataLayer 이벤트행동 신호가 전달됐는지
   태그 전송 여부는 아직 모름
2. 22. 미리보기의 Fired태그가 실행됐는지
   수집과 집계는 아직 모름
3. 33. Network 요청보낸 대상과 내용, 응답
   보고서 값은 아직 모름
4. 44. 실시간, DebugView이 환경에서 보이는지
   전체 보고서 정상 여부는 모름

먼저 테스트 행동 하나를 정합니다

실제 결제나 고객 문의를 반복하기 전에 담당자와 테스트 환경을 정합니다. 그리고 "테스트 페이지의 안내 버튼을 한 번 누르면 지정 이벤트가 한 번 기록된다"처럼 시작 조건과 기대 결과를 적습니다.

함께 적을 내용은 페이지 주소, 브라우저, 발생 시각, 이벤트 이름, 예상 태그와 GA4 대상입니다. 이때 혼동하기 쉬운 것이 두 ID입니다. GTM-으로 시작하는 컨테이너 ID는 태그 설정 묶음을, G-로 시작하는 GA4 측정 ID는 웹 데이터를 받을 곳을 가리킵니다.

GTM- 컨테이너 ID와 G- 측정 ID가 쓰이는 곳

확인할 일	GTM- 컨테이너 ID태그 설정 묶음	G- 측정 IDGA4 데이터 스트림
사이트에 설치된 컨테이너와 미리보기 작업 공간 대조	제공	제공하지 않음
Network 요청의 tid 값 대조	제공하지 않음	제공
크로스 도메인 측정에서 두 도메인이 같은 값을 쓰는지	제공하지 않음	제공

GA4의 속성은 분석 데이터를 관리하는 단위이고, 데이터 스트림은 그 속성으로 웹사이트나 앱 데이터를 받는 수집 연결입니다.

1. 미리보기에 연결하고 해당 이벤트를 선택합니다

Google Tag Manager에서 미리보기를 켜면 Tag Assistant가 열립니다. Tag Assistant는 태그의 실행 순서와 전달값을 보여 주는 점검 화면입니다.

Tag Assistant 미리보기 연결 순서

1. 11. 컨테이너 열기사이트에 맞는 컨테이너와
   작업 공간 선택
2. 22. 미리보기오른쪽 위
   미리보기(Preview)
3. 33. 주소 입력 후 연결테스트할 주소를 넣고
   연결(Connect)
4. 44. 정한 행동 수행열린 사이트에서 한 번
   그다음 Tag Assistant로
5. 55. 이벤트 선택전체 요약이 아니라
   왼쪽의 그 행동 이벤트

미리보기는 현재 작업 공간의 초안을 시험하는 기능이라, 실제 방문자에게 제공되는 게시 버전과 내용이 다를 수 있습니다. 이벤트를 선택하면 아래 항목을 차례로 봅니다.

Tags Not Fired 목록에는 원래 그 시점에 실행되지 않아야 하는 태그도 들어 있습니다. 구매 태그가 일반 페이지 조회에서 실행되지 않는 것이 그런 예입니다.

전체 요약에는 Fired인데 방금 누른 버튼의 이벤트에서는 Not Fired라면, 그 태그는 다른 시점에 실행된 것입니다. 이번 클릭 이벤트를 선택한 상태에서 트리거 조건과 Variables 값을 비교합니다. 조건을 고친 뒤에는 같은 행동을 한 번 더 하고, 기대한 이벤트에서 한 번만 실행되는지와 다른 행동에서는 실행되지 않는지를 봅니다.

연결이 안 되면

연결이 안 될 때는 아래 순서로 원인을 좁힙니다. 연결 실패만으로 GTM을 다시 설치하지 않습니다.

미리보기 연결이 안 될 때 보는 순서

1. 11. 컨테이너 ID사이트에 설치된 ID와
   작업 공간의 ID가 같은지
2. 22. 입력 주소테스트할 페이지 주소가
   정확한지
3. 33. 팝업과 확장 프로그램팝업 차단, 광고 차단
   확장 프로그램의 영향
4. 44. 디버깅 종료 후 재연결이전 디버깅을 끝내고
   같은 브라우저에서 다시
5. 55. 디버그 매개변수주소에 붙는 값 때문에
   사이트가 멈추면 옵션 조정

시크릿 창에서도 사용자가 허용한 확장 프로그램은 실행되므로, 조직 정책이 허용하는 별도 테스트 브라우저에서 비교하는 편이 확실합니다. 브라우저 쿠키를 전부 지우는 것은 위 순서를 모두 본 뒤에 합니다.

2. 트리거와 실제 값을 나란히 비교합니다

트리거가 실행되지 않을 때는 기대한 조건과 Variables의 실제 값을 나란히 놓습니다. 아래는 자주 나오는 불일치의 예시입니다.

Page URL은 전체 주소, Page Path는 주소의 경로 부분입니다. 이벤트 이름과 변수 키는 실제 구현과 글자 하나까지 대조합니다. 모두 소문자로 바꿔 비교하면 서로 다른 이름이 하나로 합쳐질 수 있습니다.

조건을 넓힐 때는 통과해야 할 주소와 통과하면 안 되는 주소를 함께 정합니다. 정규표현식은 문자열의 일치 규칙을 지정하는 방식이고, ^/products/?$는 /products와 /products/만 통과시킵니다. 같은 목적으로 '포함' 조건을 쓰면 /products-old까지 통과합니다.

조건 방식별로 통과하는 경로

실제 경로	같음/products	포함/products	정규식^/products/?$
/products	제공	제공	제공
/products/	제공하지 않음	제공	제공
/products-old	제공하지 않음	제공	제공하지 않음

3. dataLayer에 필요한 신호가 있는지 봅니다

dataLayer는 사이트가 GTM에 이벤트와 부가 값을 전달할 때 쓰는 데이터 구조입니다. 이름이 purchase인 이벤트를 보내기로 했다면 철자와 함께 금액 같은 필요한 값이 그 시점에 준비됐는지도 봅니다.

먼저 Tag Assistant의 Data Layer와 Variables 화면을 봅니다. 그래도 원인이 보이지 않으면 개발자 도구의 Console에서 아래 코드를 실행합니다. Chrome에서는 Windows의 Ctrl+Shift+J, Mac의 Cmd+Option+J로 Console이 열립니다.

이 코드는 새 이벤트를 보내거나 dataLayer.push를 바꾸지 않고, 현재 배열에서 최근 이벤트 이름 20개만 읽습니다. 결과는 아래 두 가지 가운데 하나로 나옵니다.

Chrome 개발자 도구, Console

> window.dataLayer.filter(...).slice(-20).map(item => item.event)

["gtm.js", "click_button"]

기대한 이벤트 이름이 배열에 있는지 봅니다

'dataLayer array not found'

["gtm.js", "click_button"]이 나오면 현재 배열에 그 이름의 기록이 있다는 뜻입니다. dataLayer array not found는 이 창에서 window.dataLayer 배열을 찾지 못했다는 뜻이고, 사이트가 다른 이름의 dataLayer를 쓸 때도 이렇게 나옵니다. 페이지 조회 같은 기본 동작은 맞춤 이벤트를 따로 만들지 않고 GTM의 기본 이벤트로 확인합니다.

원하는 이름이 결과에 없을 때는 먼저 세 가지 경우를 배제합니다. 최근 20개 밖에 있거나, 페이지 이동으로 이전 기록이 사라졌거나, 사이트가 다른 dataLayer 이름을 쓰는 경우입니다. 또 이 코드는 gtag() 명령 형식의 기록은 보여 주지 않습니다. 이 네 가지를 모두 확인한 뒤에 구현 누락으로 판단합니다.

운영 사이트 Console에서 시험용 purchase를 직접 보내면 실제 구매 수집과 섞입니다. 개발 담당자에게 이벤트 이름, 발생 조건, 필요한 항목, 중복 처리 기준을 전달하고 테스트 환경에서 확인합니다. 데이터 전체나 고객 정보는 복사해 보내지 않습니다.

4. Fired라면 실제 요청의 대상과 내용을 봅니다

Chrome 개발자 도구를 열고 Network(네트워크) 탭을 고릅니다. 페이지 이동이 포함된 행동이면 Preserve log(기록 유지)를 켜서 요청 목록이 지워지지 않게 합니다. 기록이 켜진 상태에서 테스트 행동을 한 번 더 합니다.

Network 탭 검색창에 collect를 넣으면 GA4 브라우저 요청을 대부분 좁혀 볼 수 있습니다. 요청을 선택한 뒤 Headers(요청 주소와 헤더 정보)와 Payload(전달 데이터)에서 대상 주소와 전달 항목을 봅니다. 구현에 따라 매개변수가 주소에 붙기도 하고 요청 본문에 담기기도 합니다.

Chrome 개발자 도구, Network, Payload

tid=G-TEST1234
en=click_button
dl=https://example.com/products
상태 코드 204

tid가 의도한 측정 ID인지, en이 기대한 이벤트 이름인지 봅니다

200이나 204 응답은 브라우저가 요청을 보내고 응답을 받았다는 뜻까지입니다. 대상 속성이 다르거나 값이 잘못된 요청도 같은 응답을 받을 수 있습니다. 서버 측 태깅이나 자체 수집 주소를 쓰는 사이트는 요청 호스트가 google-analytics.com이 아니므로, 호스트 이름보다 요청 내용으로 판단합니다.

요청이 보이지 않으면 검색 필터를 지우고 기록을 시작한 시점, 테스트한 창, 동의 상태, 차단 여부, 구현 방식을 차례로 봅니다. 요청 하나에 여러 이벤트가 묶여 갈 수 있어서 요청 개수와 이벤트 개수가 다를 수 있습니다.

차단 메시지가 있다면

CSP(Content Security Policy)는 브라우저가 어떤 출처의 스크립트나 요청을 허용할지 정하는 보안 정책입니다. Console에 CSP 위반 메시지가 있으면 차단된 주소와 정책 항목을 담당자에게 전달합니다. 모든 출처를 뜻하는 *를 허용하거나 보안 정책 전체를 끄는 방식으로 해결하지 않습니다.

동의 상태도 구분합니다. 일부 태그는 동의 여부에 따라 실행이 막히고, Google 태그는 설정에 따라 동의 상태에 맞춰 동작을 바꿉니다. 태그가 보이게 하려고 사용자 선택을 허용으로 바꾸지 말고, 예상한 동작과 실제 동의 설정을 대조합니다.

5. 수집 결과와 게시 버전을 확인합니다

요청이 맞게 나갔다면 GA4에서 수집 결과를 보고, 실제 방문에도 반영되는지 게시 버전까지 확인합니다.

요청 확인 뒤 남은 네 단계

1. 11. 실시간, DebugView관리 → 데이터 표시
   → DebugView에서 이벤트
2. 22. 일반 보고서처리 시간이 지난 뒤
   개발 트래픽 제외 설정도
3. 33. 게시 버전 비교시험한 초안과
   현재 게시 버전의 차이
4. 44. 게시수정 내용과 테스트 결과를
   남기고 배포 절차대로

DebugView는 디버그 모드로 보낸 이벤트를 따로 보여 주는 화면입니다. 볼 때는 대상 속성과 테스트 기기, 시각을 맞춥니다. DebugView 표시도 동의 설정의 영향을 받습니다.

일반 보고서는 처리 시간이 걸리므로, 실시간 화면에 한 번 보였다고 모든 보고서 수치가 완성된 것은 아닙니다. 개발 트래픽 제외 같은 설정이 있으면 테스트 자료가 일반 보고서에 나타나지 않는 것이 의도된 결과일 수 있습니다.

미리보기에서만 되고 실제 방문에서는 안 된다면 시험한 초안과 현재 게시 버전을 비교합니다. 작업 공간에 변경사항 표시가 있어도 그 변경이 다른 태그의 작업일 수 있으므로, 시험한 태그의 설정을 게시 버전과 직접 비교합니다. 게시할 때는 수정 내용과 테스트 결과를 남기고 조직의 배포 절차로 해당 버전만 게시합니다. 원인을 모르는 상태에서 쌓인 변경을 한꺼번에 제출하지 않습니다.

자주 만나는 네 가지 상황

데이터 준비보다 태그가 먼저 실행됩니다

이벤트 시점의 Variables에 undefined가 보이면 변수 이름과 자료형, 데이터 준비 순서를 점검합니다. undefined는 그 시점에 값이 정해지지 않았다는 표시입니다. 필요한 값을 이벤트 신호와 함께 dataLayer에 전달하도록 설계하면 시점이 어긋나는 문제를 줄일 수 있습니다.

클릭 트리거를 DOM Ready로 바꾸는 것은 클릭 누락의 해결법이 아닙니다. DOM Ready는 페이지 구조가 준비되는 시점이고, 사용자가 클릭하는 행동과는 다른 시점입니다. 태그 시퀀싱으로 실행 순서를 강제하기 전에 Google 태그와 동의 설정, 실제 데이터 준비 시점을 먼저 점검합니다.

SPA에서 페이지뷰가 없거나 두 번 생깁니다

SPA는 문서를 매번 새로 받지 않고 화면만 바꾸는 웹앱 방식입니다. 그래서 초기 문서 로드와 이후 화면 이동을 나눠 점검합니다.

page_view는 페이지 조회 이벤트입니다. GA4의 향상된 측정은 설정에 따라 일부 행동을 자동으로 수집하는 기능이고, 브라우저 기록 변경을 감지해 page_view를 보낼 수 있습니다. GTM의 History Change는 주소와 연결된 브라우저 방문 기록의 변경을 감지하는 트리거입니다. 향상된 측정이 켜진 상태에서 History Change나 맞춤 이벤트로 수동 페이지뷰를 더하면 같은 화면 이동이 두 번 기록될 수 있습니다. 지금 어떤 방식이 페이지뷰를 보내는지 먼저 확인하고 한 가지 방식으로 맞춥니다. send_page_view: false는 향상된 측정의 기록 변경 수집까지 끄지 않으므로 향상된 측정 쪽 설정은 따로 봅니다.

SPA 화면 이동 뒤 page_view 검증 순서

1. 11. 화면 A에서 B로 이동메뉴나 링크로
   한 번만 이동
2. 22. page_view 횟수이동 한 번에
   한 번만 기록되는지
3. 33. page_location주소가 A가 아니라
   B를 가리키는지
4. 44. 페이지 제목제목도 B의 것으로
   바뀌어 있는지

제목이 주소보다 늦게 바뀌는 앱에서는 주소가 바뀌는 순간에 보낸 page_view에 화면 A의 제목이 담길 수 있습니다. 이때는 제목이 바뀐 뒤 신호를 보내도록 구현을 조정합니다.

구매 이벤트가 중복됩니다

같은 주문을 사이트 코드와 GTM이 각각 보내는지, 같은 역할의 태그가 두 개 있는지, 새로고침이나 전송 재시도가 있었는지 봅니다. 태그의 '한 이벤트당 한 번' 설정은 같은 주문이 서로 다른 이벤트로 다시 전송되는 것까지 막지 못합니다.

'한 페이지당 한 번'으로 제한하면 한 페이지에서 일어난 별개의 정상 구매를 놓칩니다. 완료 페이지를 곧바로 다른 곳으로 보내는 방식도 중복을 막거나 전송 완료를 보장하지 못합니다. 중복 여부는 주문 식별자와 실제 완료 시점, 재시도 규칙으로 검증합니다.

다른 도메인으로 이동할 때 이용 기록이 나뉩니다

세션은 일정한 기준으로 묶은 방문 중 활동입니다. 먼저 example.com에서 checkout.example.net처럼 다른 도메인으로 이동하는 상황인지 구분합니다. pay.example.com처럼 하위 도메인으로만 이동하는 경우는 다른 도메인 이동과 따로 봅니다.

크로스 도메인 측정에서는 두 도메인이 같은 웹 데이터 스트림의 동일한 G- 측정 ID를 쓰는지, 도메인 설정에 두 도메인이 모두 들어 있는지, 링크로 이동할 때 _gl이 전달되는지를 봅니다. _gl은 도메인 사이에서 식별 정보를 넘기는 링크 매개변수이고, 리다이렉트 중에 사라지기도 합니다. 같은 GTM 컨테이너를 쓰는지는 크로스 도메인 측정의 조건이 아닙니다.

담당자에게 보낼 점검 메모

점검을 마치면 확인한 단계와 아직 모르는 단계를 나눠 적습니다. 아래는 그 형식의 예시입니다.

이렇게 확인한 단계와 아직 모르는 단계를 나누면 담당자가 같은 상황을 재현하고 다음 단계부터 이어서 볼 수 있습니다. 점검이 끝나면 Tag Assistant에서 디버깅 종료를 눌러 미리보기를 닫습니다.

Sources

• Google Tag Manager 미리보기와 디버그
• dataLayer의 동작과 이름 규칙
• Chrome DevTools Network 사용법
• GTM 동의 설정 안내
• GA4 DebugView 안내
• GA4 페이지뷰 수집
• GTM으로 SPA 측정하기
• GA4 크로스 도메인 측정

3줄 요약

1. GTM 디버깅은 테스트 행동 한 번을 기준으로 dataLayer 신호와 미리보기의 Fired, Network 요청, GA4 DebugView를 차례로 확인하는 작업입니다.

2. Fired는 태그 실행을, 200이나 204는 요청 응답을 알려 줄 뿐이므로 요청의 tid가 의도한 G- 측정 ID인지와 en이 기대한 이벤트 이름인지 함께 봅니다.

3. SPA에서 향상된 측정의 기록 변경 수집과 History Change 트리거의 수동 페이지뷰를 함께 쓰면 page_view가 중복될 수 있으므로 한 가지 방식으로 맞춥니다.