전환(문의·구매)까지 가지 않은 방문자가 페이지에서 어디까지 읽었는지, 어떤 버튼을 눌러봤는지는 이벤트 트래킹 없이는 알 수 없습니다. 스크롤 깊이와 클릭 이벤트를 세팅하면 콘텐츠 개선의 우선순위를 데이터로 정할 수 있습니다. 세팅 방식과 과도한 트래킹의 함정을 정리합니다.
행동 이벤트 트래킹이 필요한 순간
페이지뷰·전환 데이터만으로는 "왜" 전환이 안 되는지 알기 어렵습니다. 예를 들어 상세 페이지 방문은 많은데 문의가 없다면, 방문자가 가격 정보까지 스크롤했는지, CTA 버튼을 보고도 안 눌렀는지를 구분해야 원인을 좁힐 수 있습니다. 이런 중간 단계를 보여주는 것이 스크롤·클릭 이벤트입니다.
스크롤 깊이 트래킹 구현
25%, 50%, 75%, 100% 등 구간별로 도달 여부를 한 번씩만 기록하는 방식이 일반적입니다.
let tracked = {};
window.addEventListener('scroll', function() {
const pct = Math.round(
(window.scrollY + window.innerHeight) / document.body.scrollHeight * 100
);
[25, 50, 75, 90].forEach(function(mark) {
if (pct >= mark && !tracked[mark]) {
tracked[mark] = true;
gtag('event', 'scroll_depth', { percent: mark });
}
});
});스크롤 이벤트는 매 픽셀 이동마다 발생하므로, 쓰로틀링(throttle) 처리 없이 그대로 붙이면 브라우저 성능에 영향을 줄 수 있어 실무에서는 requestAnimationFrame이나 디바운스를 함께 적용합니다.
클릭 이벤트: 어떤 요소를 추적할지 선정하는 기준
모든 클릭을 다 추적하면 데이터가 지나치게 방대해져 분석이 어려워집니다. 우선순위를 정해서 추적합니다.
- CTA 버튼(상담신청, 견적요청, 구매하기)
- 가격표·요금제 탭 전환
- 전화번호·카카오톡 채널 링크
- 동영상 재생 시작·완료
- 탭·아코디언 UI의 펼침(어떤 정보에 관심이 큰지 파악)
클릭 이벤트 구현 예시
document.querySelectorAll('[data-track]').forEach(function(el) {
el.addEventListener('click', function() {
gtag('event', 'click', {
element: el.dataset.track
});
});
});HTML에는 추적하고 싶은 요소에 data-track 속성만 붙이면 되므로, 새로운 버튼이 추가될 때마다 코드를 수정하지 않아도 됩니다.
<a href="/type1.php" data-track="cta_package">패키지 보기</a>
이벤트 설계 우선순위 표
| 이벤트 | 확인하려는 것 | 우선순위 |
|---|---|---|
| CTA 클릭 | 전환 직전 이탈 원인 | 최우선 |
| 스크롤 75% 도달률 | 본문이 끝까지 읽히는지 | 높음 |
| 요금제 탭 클릭 | 어떤 옵션에 관심이 큰지 | 중간 |
| 푸터 링크 클릭 | 탐색 패턴 참고 | 낮음 |
과도한 트래킹이 만드는 부작용
이벤트를 너무 세세하게 심으면 다음 문제가 생깁니다.
- 페이지에 스크립트 실행이 늘어 실제 로딩·반응 속도가 느려짐
- 분석 리포트가 이벤트 종류로 가득 차 핵심 지표를 놓치기 쉬움
- 개인정보·행동 데이터 수집 범위가 넓어져 개인정보 처리방침 갱신이 필요해짐
"이 데이터로 어떤 의사결정을 할 것인가"에 답할 수 있는 이벤트만 남기는 것이 원칙입니다.
수집한 데이터를 실제로 활용하는 흐름
이벤트를 심는 것보다 중요한 것은 주기적으로 리포트를 보고 개선에 반영하는 루틴입니다.
- 스크롤 50% 이전 이탈률이 높다면 상단 콘텐츠 재구성
- CTA 클릭은 있는데 폼 전환이 없다면 폼 자체의 UX 문제로 좁힘
- 특정 탭 클릭이 압도적으로 많다면 해당 정보를 상단으로 재배치
히트맵 도구와의 차이, 함께 써야 할까
히트맵·세션 리플레이 도구는 시각적으로 직관적이지만, 대량 트래픽 사이트에서는 표본 제한이나 비용 문제가 있습니다. 반면 이벤트 트래킹은 정량적 수치로 전체 트래픽을 다 반영할 수 있어 상호 보완적입니다.
- 이벤트 트래킹 — 전체 트래픽 대상, "얼마나 많이" 클릭·스크롤했는지 숫자로 확인
- 히트맵·리플레이 — 소수 세션 대상, "왜" 그런 행동을 했는지 정황 파악
초기에는 이벤트 트래킹으로 문제 구간을 좁히고, 그 구간만 히트맵으로 상세히 들여다보는 순서가 효율적입니다.
실무 정리
행동 이벤트 트래킹은 전환 데이터가 설명하지 못하는 중간 과정을 보여주는 도구입니다. 문의 폼 전환 이벤트와 함께 세팅하면 유입부터 전환까지 전체 흐름을 데이터로 추적할 수 있습니다. 이벤트 설계와 구현이 필요하면 무료 견적요청으로 현재 페이지 구조를 알려주세요.
자주 묻는 질문 (FAQ)
스크롤 트래킹이 페이지 속도에 영향을 주나요? +
쓰로틀링 없이 구현하면 스크롤 시마다 과도하게 실행되어 영향을 줄 수 있습니다. requestAnimationFrame이나 일정 간격 디바운스를 적용하면 체감 영향 없이 사용할 수 있습니다.
클릭 이벤트는 몇 개까지 심는 게 적당한가요? +
정해진 정답은 없지만, 실무적으로는 핵심 전환 경로에 있는 5~10개 요소로 시작해 필요에 따라 늘려가는 것을 권장합니다. 처음부터 모든 요소를 추적하면 분석이 오히려 어려워집니다.
이벤트 데이터로 개인정보를 수집하는 건가요? +
클릭·스크롤 자체는 개인 식별 정보가 아니지만, IP나 사용자 ID와 결합해 분석하는 경우라면 개인정보 처리방침에 수집 항목과 목적을 명시해야 합니다.
모바일과 PC의 스크롤 깊이를 같은 기준으로 봐도 되나요? +
화면 높이가 다르기 때문에 퍼센트 기준으로 보면 비교적 공정하게 비교할 수 있지만, 디바이스별로 나눠서 리포트를 보는 것이 더 정확한 해석에 도움이 됩니다.
이벤트를 심었는데 리포트에 데이터가 안 보입니다. +
이벤트 이름이 분석 툴에서 인식하는 예약어와 충돌하거나, 태그 발송 코드가 실제로 실행되지 않는 조건에 있을 수 있습니다. 브라우저 개발자도구의 네트워크 탭에서 이벤트 요청이 실제로 전송되는지부터 확인하세요.
단일 페이지 애플리케이션(SPA)에서도 스크롤 이벤트가 동일하게 동작하나요? +
페이지 전환이 URL 변경 없이 이뤄지는 구조라면, 화면이 바뀔 때마다 추적 상태(tracked 변수)를 초기화해줘야 이전 화면의 기록이 남아 새 화면에서 이벤트가 누락되는 문제를 막을 수 있습니다.