지금 읽는 곳클릭 트리거는 어떤 범위로 만들 수 있나목차
STEP 2 중급·실무 › 2-4. 데이터 분석·퍼포먼스 테크 › 과목 83 › 레슨 04
클릭 트리거 엔지니어링: 특정 구매 버튼의 ID(Click ID) 또는 클래스(Click Classes) 값을 추출해 클릭 이벤트 구현하기
클릭 트리거의 조건을 버튼의 ID나 클래스가 아니라 텍스트로만 잡으면, 문구가 바뀌는 순간 트리거가 조용히 멈춥니다.
핵심요약
- 클릭 트리거는 사용자가 버튼이나 링크를 클릭할 때 발동하는 GTM 트리거 유형이다
- '모든 요소' 클릭 트리거와 '일부 링크만' 클릭 트리거로 범위를 다르게 설정할 수 있다
- Click ID, Click Classes, Click Text 같은 내장 변수로 클릭한 요소를 식별한다
- ID는 페이지 안에서 유일해야 하므로 클래스보다 안정적인 식별 기준이 된다
- 트리거 조건은 미리보기 모드에서 실제 클릭 시 변수 값을 확인하며 맞춰야 한다
클릭 트리거는 어떤 범위로 만들 수 있나
GTM의 클릭 트리거는 크게 '모든 요소'와 '일부 링크만(또는 일부 클릭만)' 두 범위로 나뉩니다. '모든 요소'는 페이지 안의 어떤 요소를 클릭하든 트리거가 발동하는 가장 넓은 설정이고, '일부'는 특정 조건(ID, 클래스, 텍스트 등)을 만족하는 클릭에만 반응하도록 좁힌 설정입니다. 구매 버튼처럼 특정 행동만 추적하고 싶은 경우에는 반드시 '일부' 옵션을 선택하고 조건을 구체적으로 지정해야, 페이지 안의 다른 클릭까지 함께 잡히는 노이즈를 피할 수 있습니다.
Click ID와 Click Classes는 어떻게 다른가
Click ID는 클릭한 요소의 HTML id 속성값을, Click Classes는 class 속성값을 담는 내장 변수입니다. id는 한 페이지 안에서 원칙적으로 유일해야 하는 값이므로, id가 지정되어 있다면 이를 기준으로 트리거 조건을 잡는 것이 가장 안정적입니다. 반면 class는 같은 페이지 안에 동일한 클래스를 가진 요소가 여러 개 있을 수 있어, 클래스만으로 조건을 잡으면 의도하지 않은 다른 요소의 클릭까지 함께 잡힐 위험이 있습니다. 개발팀에 요청할 수 있다면, 추적이 필요한 핵심 버튼에는 고유한 id를 미리 부여해달라고 협의하는 것이 가장 깔끔한 방법입니다.
Click Text로 조건을 잡을 때의 위험
id나 class가 없는 경우 차선책으로 Click Text(클릭한 요소의 텍스트)를 조건으로 쓸 수 있습니다. 다만 이 방법은 버튼 문구가 "구매하기"에서 "지금 구매"로 바뀌는 것처럼 UI 개편 한 번으로 조건이 깨질 수 있다는 치명적인 약점이 있습니다. 텍스트 조건은 id·class를 전혀 쓸 수 없는 예외적인 상황에서만 최후 수단으로 사용하고, 가능하다면 항상 id나 class 기반 조건을 우선 검토해야 합니다.
조건을 조합해서 정확도를 높이는 법
하나의 조건만으로 원하는 요소를 정확히 특정하기 어려운 경우, 여러 조건을 '그리고(AND)'로 묶어 정확도를 높일 수 있습니다. 예를 들어 "Click Classes가 btn-purchase를 포함하고, 동시에 Page URL이 /product/로 시작한다"처럼 조건을 조합하면, 같은 클래스명이 다른 페이지에서 다른 용도로 쓰이고 있더라도 원하는 페이지의 원하는 버튼만 정확히 잡아낼 수 있습니다.
미리보기 모드에서 어떻게 검증하나
클릭 트리거를 만든 뒤에는 반드시 미리보기 모드에서 실제로 해당 버튼을 클릭해보고, Tag Assistant 화면에서 Click ID·Click Classes·Click Text 값이 예상한 값과 일치하는지 확인해야 합니다. 이 값들을 실제로 눈으로 확인하지 않고 추측만으로 조건을 설정하면, 개발자 도구로 직접 HTML을 열어보지 않는 이상 놓치기 쉬운 오탈자나 예상과 다른 속성값 때문에 트리거가 조용히 작동하지 않는 상황이 생길 수 있습니다.
SPA(단일 페이지 애플리케이션)에서 주의할 점
리액트·뷰 같은 프레임워크로 만들어진 SPA 사이트는 페이지 이동 시 실제로는 새로고침 없이 화면만 바뀌는 경우가 많아, 표준 클릭 트리거가 예상과 다르게 작동하거나 아예 감지하지 못하는 경우가 생길 수 있습니다. 이런 사이트에서는 히스토리 변경 트리거를 함께 사용하거나, 개발팀과 협의해 데이터레이어 이벤트를 직접 push하는 방식으로 우회하는 것이 더 안정적입니다.
모바일과 데스크톱에서 요소 구조가 다를 때는 어떻게 하나
반응형 사이트라도 모바일 화면과 데스크톱 화면에서 실제로는 서로 다른 HTML 요소가 렌더링되는 경우가 있습니다. 예를 들어 데스크톱에서는 상단 고정 구매 버튼, 모바일에서는 하단 고정 구매 버튼이 별도의 요소로 존재한다면, 두 요소의 id나 class가 다를 수 있으므로 트리거 조건에 '또는(OR)' 조건을 추가해 두 요소를 모두 포함하도록 설계해야 합니다. 이 작업을 건너뛰면 모바일 사용자의 구매 클릭만 누락되는 식으로 특정 기기의 데이터만 조용히 비게 됩니다.
트리거를 여러 개 만들지, 조건을 조합할지 판단하는 기준
비슷한 성격의 클릭(장바구니 담기 버튼이 페이지마다 여러 개 있는 경우 등)을 추적할 때, 페이지마다 별도의 트리거를 만드는 방법과 하나의 트리거에 여러 조건을 '또는'으로 묶는 방법 중 선택해야 하는 상황이 자주 생깁니다. 페이지별로 서로 다른 매개변수(예: 카테고리명)를 함께 보내야 한다면 트리거를 나누는 편이 관리하기 쉽고, 단순히 같은 이벤트를 여러 위치에서 잡기만 하면 된다면 조건을 조합한 트리거 하나로 통합하는 편이 컨테이너를 단순하게 유지하는 데 유리하며, 트리거 개수 자체가 늘어날수록 전체 구조를 파악하기 어려워진다는 점도 함께 고려해야 합니다.