GTM 트리거 종류 정리: 실행 시점으로 고르는 4가지 기준

GTM 트리거는 태그를 켜는 단순한 스위치가 아닙니다. 태그가 언제, 어떤 조건에서 실행될지 정하는 규칙이고, 여기서 수집되는 전환 데이터가 정확한지도 트리거가 결정합니다.

GTM 트리거 종류를 고를 때는 추적할 행동이 언제 일어나는지, 그 시점에 필요한 데이터가 페이지에 있는지를 먼저 따져야 합니다. 트리거 이름만 보고 고르면 전환이 두 번 잡히거나 아예 잡히지 않습니다. 같은 버튼 클릭이라도 사이트 구조에 따라 맞는 트리거가 다릅니다.

아래에서 GTM 트리거 종류를 4개 그룹으로 나누고, 그룹마다 고르는 기준과 자주 생기는 실패 사례를 설명합니다.

1. GTM 트리거 종류 한눈에 보기: 4개 그룹 16종

GTM에서 새 트리거를 만들면 목록이 길게 나옵니다.

처음 보면 복잡해 보이지만 성격별로 묶으면 4개 그룹입니다.

이 표에서 기억할 건 하나입니다.

트리거 종류는 "무엇을"이 아니라 "언제"로 나뉩니다.

1-1. 트리거는 '유형 + 조건' 두 겹으로 작동합니다

트리거를 만들면 두 가지를 정합니다.

① 트리거 유형: 어떤 이벤트를 감지할지(클릭, 페이지뷰 등)

② 실행 조건: "모든 이벤트"인지 "일부 이벤트"인지

예를 들어 클릭 트리거를 "모든 클릭"으로 두면 로고, 메뉴, 빈 여백 클릭까지 전부 태그를 실행합니다.

그래서 전환용 태그는 거의 항상 "일부 클릭"을 선택하고 Click ID, Click Classes, Click URL 같은 변수로 범위를 좁힙니다.

1-2. 기본 제공 변수를 켜지 않으면 조건을 걸 수 없습니다

처음 세팅할 때 많이 막히는 지점입니다.

클릭 관련 변수(Click Element, Click Classes, Click ID, Click URL, Click Text)는 기본적으로 꺼져 있습니다.

변수 메뉴에서 "구성"을 눌러 켜야 트리거 조건 목록에 나타납니다. 양식·스크롤·동영상 변수도 같습니다.

-> 핵심: GTM 트리거 종류는 4개 그룹으로 나뉘고, 고를 때는 "언제 실행되는가"를 먼저 봅니다.

2. 페이지뷰 계열 트리거: 실행 시점 차이로 고르는 기준

페이지뷰 그룹에는 트리거가 5개 있습니다.

다섯 개 모두 "페이지가 열릴 때" 실행되지만, 정확히 어느 순간에 실행되는지가 다릅니다.

2-1. 다섯 가지 트리거의 실행 순서

실행 순서는 아래와 같습니다.

① 동의 초기화(Consent Initialization): 가장 먼저 실행됩니다. 동의 모드 기본값 설정 전용입니다.

② 초기화(Initialization): 다른 태그보다 먼저 실행해야 하는 설정 태그용입니다.

③ 페이지뷰(Page View): GTM 컨테이너가 로드되는 즉시 실행됩니다.

④ DOM 사용 가능(DOM Ready): HTML 구조가 다 읽힌 뒤 실행됩니다.

⑤ 창 로드(Window Loaded): 이미지·스크립트까지 모두 로드된 뒤 실행됩니다.

순서가 뒤로 갈수록 페이지 안의 데이터를 읽을 수 있는 확률은 높아지고, 실행 시점은 늦어집니다.

2-2. 어떤 트리거에 무엇을 걸어야 할까

실무 기준은 이렇습니다.

GA4 구성 태그(구글 태그)나 메타 픽셀 기본 코드는 페이지뷰나 초기화에 겁니다. 늦게 걸면 페이지를 빨리 떠나는 사용자의 방문이 빠집니다.

페이지 안의 텍스트나 요소 값을 읽어 오는 태그는 DOM 사용 가능에 겁니다. 페이지뷰 시점에는 해당 요소가 아직 없어서 값이 undefined로 잡히는 경우가 많기 때문입니다.

외부 스크립트가 다 로드된 뒤에야 값이 생기는 경우에만 창 로드를 씁니다. 이미지가 많은 상세 페이지에서는 창 로드까지 몇 초가 걸리기도 해서, 그 전에 이탈한 사용자는 집계되지 않습니다.

동의 모드를 쓰는 사이트라면 기본값 태그는 반드시 동의 초기화에 걸어야 합니다. 페이지뷰에 걸면 다른 태그가 동의 상태를 확인하기 전에 먼저 실행될 수 있습니다.

GTM 동의 모드 설정: 기본값·업데이트·검증 3단계 기준

2-3. 실패 사례: SPA 사이트에서 페이지뷰가 한 번만 잡힐 때

React, Vue 같은 SPA(싱글 페이지 애플리케이션) 구조의 사이트에서 자주 생기는 문제입니다.

사용자가 상품 목록 → 상세 → 장바구니로 이동해도 브라우저 입장에서는 페이지를 새로 불러온 게 아닙니다. 그래서 페이지뷰 트리거는 처음 진입할 때 한 번만 실행됩니다.

이런 사이트에서 장바구니 페이지 URL을 조건으로 페이지뷰 트리거를 걸면 전환이 0건으로 나옵니다.

이때는 기타 그룹의 기록 변경(History Change) 트리거를 함께 씁니다. URL이 주소창에서만 바뀌는 순간을 감지하기 때문에 SPA의 화면 이동을 잡을 수 있습니다.

단, GA4의 향상된 측정에서 "브라우저 기록 이벤트 기반 페이지 변경"이 켜져 있으면 GA4가 이미 page_view를 보내고 있을 수 있습니다. 여기에 기록 변경 트리거로 page_view를 또 보내면 페이지뷰가 두 배로 잡히니, 둘 중 하나만 남겨야 합니다.

-> 핵심: 기본 태그는 빠르게, 값을 읽는 태그는 늦게. SPA라면 기록 변경 트리거를 확인합니다.

3. 클릭·사용자 참여 트리거: 오집계 막는 선택 기준

광고 전환 추적에서 가장 많이 쓰는 그룹입니다.

그리고 데이터가 가장 많이 틀어지는 그룹이기도 합니다.

3-1. '모든 요소' vs '링크만' 클릭 트리거

클릭 트리거는 두 종류입니다.

링크만(Just Links): a 태그, 즉 href가 있는 링크 클릭만 감지합니다. 전화번호(tel:), 카카오톡 채널 링크, 외부 사이트 이동처럼 실제로 페이지를 이동시키는 클릭에 적합합니다.

모든 요소(All Elements): div, span, button, 이미지 등 클릭되는 모든 요소를 감지합니다. 링크가 아닌 "구매하기" 버튼이나 팝업 열기 버튼에 씁니다.

판단 기준은 간단합니다.

클릭하면 다른 페이지로 넘어가는가? → 링크만

클릭해도 같은 페이지에서 무언가 열리는가? → 모든 요소

3-2. 버튼 안쪽 아이콘을 누르면 안 잡히는 문제

'모든 요소' 트리거를 쓸 때 자주 겪는 문제입니다.

버튼 안에 아이콘이나 span 텍스트가 들어 있으면, 사용자가 아이콘을 눌렀을 때 Click Element는 버튼이 아니라 아이콘이 됩니다. 버튼의 Click Classes로 조건을 걸어 두면 이 클릭은 빠집니다.

실무에서는 조건을 "Click Element CSS 선택자와 일치"로 바꾸고 아래처럼 씁니다.

.btn-purchase, .btn-purchase *

버튼 자신과 그 안의 모든 하위 요소 클릭을 함께 잡는 방식입니다. 이 설정 하나만 바꿔도 버튼 클릭 수가 눈에 띄게 늘어나는 경우가 많습니다. 그동안 아이콘 클릭이 통째로 빠져 있었다는 뜻입니다.

GTM 버튼 클릭 전환 설정: 오집계 막는 트리거 4단계 기준

3-3. 클릭 트리거로 '전환'을 잡으면 안 되는 경우

전환 추적에서 가장 흔한 실수입니다.

결제하기 버튼 클릭을 구매 전환으로 잡는 경우인데, 버튼을 눌렀다고 결제가 끝난 게 아닙니다. 카드 오류, 결제창 이탈, 중복 클릭이 모두 전환으로 잡힙니다.

실제로 이렇게 세팅한 계정을 보면 광고 관리자 전환 수가 쇼핑몰 실제 주문 수보다 훨씬 많게 찍혀 있는 경우가 흔합니다. 이 상태로 자동 입찰을 돌리면 알고리즘이 "결제 버튼은 누르지만 사지 않는 사람"까지 학습합니다.

결제·신청 완료는 클릭이 아니라 완료 페이지 진입이나 맞춤 이벤트로 잡아야 합니다. 클릭 트리거는 "전화 걸기 시도", "상담 버튼 클릭"처럼 클릭 자체가 목표 행동일 때만 전환으로 씁니다.

3-4. 사용자 참여 트리거 4종의 쓰임새

양식 제출(Form Submission): form 태그의 submit 이벤트를 감지합니다. 그런데 요즘 신청 폼은 상당수가 ajax로 전송되어 페이지 이동 없이 처리되고, submit 이벤트가 발생하지 않는 경우가 많습니다. 이때는 양식 제출 트리거가 아예 실행되지 않습니다. "유효성 검사 확인" 옵션을 켜면 필수 항목이 비어 있는 실패 제출은 걸러집니다.

요소 공개 상태(Element Visibility): 특정 요소가 화면에 보일 때 실행됩니다. ajax 폼에서 "신청이 완료되었습니다" 메시지가 뜨는 순간을 전환으로 잡을 때 유용합니다. 해당 요소가 나중에 생겨나는 구조라면 "DOM 변경사항 관찰" 옵션을 켜야 합니다.

스크롤 깊이(Scroll Depth): 25%, 50%, 75%, 90%처럼 지정한 지점에 도달하면 실행됩니다. GA4 향상된 측정의 스크롤 이벤트는 90% 한 지점만 잡기 때문에 구간별로 보려면 GTM에서 따로 설정합니다.

YouTube 동영상: 페이지에 삽입된 유튜브 영상의 시작·진행률·완료를 감지합니다. 다른 동영상 플레이어에는 작동하지 않습니다.

GTM 양식 제출 추적: 폼 유형별 트리거 고르는 기준

-> 핵심: 클릭은 '시도', 완료는 '결과'입니다. 전환은 결과 시점의 트리거로 잡습니다.

4. 맞춤 이벤트·트리거 그룹: 사이트 구조가 복잡할 때 고르는 기준

기타 그룹은 처음에는 잘 쓰지 않습니다.

하지만 전환 데이터의 정확도를 끝까지 올리려면 결국 이 그룹을 쓰게 됩니다.

4-1. 맞춤 이벤트 트리거: 가장 정확한 전환 추적 방식

맞춤 이벤트(Custom Event)는 사이트 코드가 데이터 영역(dataLayer)에 보낸 이벤트 이름을 감지합니다.

예를 들어 결제가 실제로 승인된 뒤 개발 코드가 아래처럼 보내면,

dataLayer.push({ event: 'purchase_complete', value: 59000, transaction_id: 'A1234' })

GTM에서 이벤트 이름 purchase_complete로 맞춤 이벤트 트리거를 만들면 됩니다.

장점은 세 가지입니다.

① 화면 구조(CSS 클래스, 버튼 위치)가 바뀌어도 트리거가 깨지지 않습니다.

② 결제 금액, 주문번호 같은 값을 정확하게 함께 받을 수 있습니다.

③ 결제 실패·중복 클릭이 섞이지 않습니다. 서버가 승인한 시점에만 이벤트가 발생하기 때문입니다.

단점은 개발 작업이 필요하다는 것입니다. 그래서 실무에서는 매출과 직결되는 구매·회원가입·리드 제출만 맞춤 이벤트로 받고, 나머지 보조 행동은 클릭·노출 트리거로 처리하는 방식이 효율적입니다.

이벤트 이름은 대소문자까지 정확히 일치해야 합니다. Purchase_Complete와 purchase_complete는 다른 이벤트로 인식됩니다.

GTM 데이터영역 변수: 설정 기준과 값이 안 잡힐 때 확인할 4가지

4-2. 트리거 그룹: 조건이 '둘 다 일어났을 때'

트리거 그룹(Trigger Group)은 여러 트리거가 모두 한 번 이상 실행된 뒤 태그를 실행합니다.

예를 들어 "스크롤 75% 도달"과 "체류 30초 경과(타이머)"를 묶으면, 두 조건을 모두 충족한 방문자만 '관심 방문자' 이벤트로 보낼 수 있습니다.

랜딩 페이지의 클릭 수는 많은데 전환은 없을 때, 실제로 콘텐츠를 읽은 방문자가 얼마나 되는지 따로 볼 때 유용합니다. 이 이벤트를 리타겟팅 잠재고객 소스로 쓰면 단순 방문자 전체보다 모수는 작지만 반응은 좋은 경우가 많습니다.

4-3. 타이머·JavaScript 오류 트리거

타이머(Timer): 지정한 간격(밀리초)마다 실행됩니다. 실행 횟수 제한을 걸지 않으면 사용자가 페이지에 머무는 동안 계속 이벤트가 쌓이니 반드시 제한을 겁니다. 체류 시간 측정 목적이면 제한은 1회가 기본입니다.

JavaScript 오류: 페이지에서 잡히지 않은 스크립트 오류가 생기면 실행됩니다. 결제 페이지 오류로 전환이 갑자기 떨어졌을 때 원인을 찾는 진단용으로 쓰입니다. 광고 전환 태그에 걸 일은 없습니다.

4-4. 상황별 트리거 선택 기준 정리

자주 받는 추적 요청을 기준으로 정리하면 아래와 같습니다.

표에서 1순위가 맞춤 이벤트인 항목이 많은 이유는 화면이 바뀌어도 깨지지 않기 때문입니다. 클릭 기반 트리거는 사이트 리뉴얼이나 버튼 디자인 변경 한 번에 조용히 0건이 되기 쉽습니다. 실제로 디자인 개편 후 몇 주 동안 전환이 0으로 찍혀도 아무도 모르고 있다가, 광고 학습이 무너진 뒤에야 발견하는 경우가 적지 않습니다.

-> 핵심: 매출과 직결된 전환은 맞춤 이벤트로, 보조 행동은 클릭·노출 트리거로 나눕니다.

자주 묻는 질문

GTM 트리거 종류 중 전환 추적에 가장 정확한 것은?

맞춤 이벤트 트리거입니다. 사이트 코드가 결제나 신청이 실제로 완료된 시점에 데이터 영역으로 이벤트를 보내기 때문에 실패 건이나 중복 클릭이 섞이지 않습니다. 개발 작업이 어렵다면 완료 페이지 URL 조건의 페이지뷰 트리거가 차선책입니다.

GTM 클릭 트리거가 작동하지 않는 이유는?

클릭 관련 기본 제공 변수가 꺼져 있거나, 조건을 버튼에 걸었는데 실제 클릭은 버튼 안쪽 아이콘에서 일어난 경우가 대부분입니다. 미리보기 모드에서 클릭 이벤트의 Click Element 값을 확인하고, 필요하면 CSS 선택자 조건으로 하위 요소까지 포함시킵니다.

GTM 페이지뷰와 DOM 사용 가능 트리거의 차이는?

페이지뷰는 GTM 컨테이너가 로드되는 즉시, DOM 사용 가능은 HTML 구조를 다 읽은 뒤 실행됩니다. 기본 추적 태그는 페이지뷰에, 페이지 안의 요소 값을 읽어야 하는 태그는 DOM 사용 가능에 거는 것이 일반적입니다.

GTM 양식 제출 트리거가 실행되지 않을 때는?

폼이 ajax 방식으로 전송되어 submit 이벤트가 발생하지 않는 경우가 대부분입니다. 이때는 완료 메시지를 감지하는 요소 공개 상태 트리거나, 개발 코드에서 보내는 맞춤 이벤트 트리거로 바꿔야 합니다.

GTM 트리거 실행 횟수를 제한하려면?

태그 설정의 고급 설정에서 "태그 실행 옵션"을 "페이지당 한 번"으로 바꿉니다. 타이머 트리거는 트리거 자체에 실행 횟수 제한 항목이 있으니 함께 설정합니다.

마무리

GTM 트리거 종류는 많아 보이지만 기준은 하나입니다.

추적하려는 행동이 언제 일어나는지, 그 시점에 필요한 데이터가 있는지.

기본 태그는 페이지뷰 계열로 빠르게 실행하고, 클릭은 시도 행동에만 쓰고, 매출과 직결된 전환은 맞춤 이벤트로 받는다.

이 세 가지만 지켜도 전환이 두 배로 잡히거나 0건이 되는 문제는 대부분 막을 수 있습니다.

트리거를 만든 뒤에는 반드시 미리보기 모드에서 실제로 실행되는지 확인하고 게시하세요. 실행 여부를 확인하지 않은 트리거는 아직 측정하고 있다고 볼 수 없습니다.

GTM 미리보기 안됨: 연결 실패부터 태그 미작동까지 진단 순서