이벤트 추적을 시작하면 대개 눈에 보이는 것부터 세게 됩니다. 버튼 클릭, 스크롤 깊이, 파일 다운로드. 그런데 몇 달 뒤 리포트를 열면 btn_click_3 · cta_top_new2 같은 이름들이 줄지어 있고, 그것이 무엇이었는지 아무도 기억하지 못합니다.
원인은 기록의 양이 아니라 이름입니다. 화면의 생김새를 이름으로 쓰면, 화면이 바뀌는 순간 그 데이터는 뜻을 잃습니다. 사이트는 계속 바뀌므로 이것은 언젠가 일어날 일이 아니라 반드시 일어나는 일입니다.
이름이 데이터의 수명을 정합니다
오른쪽 이름들의 공통점은 사업의 말로 되어 있다는 것입니다. 개편으로 버튼 위치가 바뀌고 색이 바뀌고 문구가 바뀌어도 “문의를 제출했다” 는 사실은 그대로이므로, 개편 전후를 한 줄로 이어서 볼 수 있습니다. 이것이 이름 규칙의 실제 이득입니다.
무엇을 이벤트로 만들 것인가
모든 상호작용을 기록할 필요는 없습니다. 첫 회차의 질문을 그대로 씁니다 — 이 이벤트가 늘거나 줄면 무엇을 다르게 할 것인가. 답이 있는 것만 남깁니다.
기록을 줄이는 것에는 부수 효과도 있습니다. 이벤트가 적으면 브라우저에서 실행되는 코드도 적고, 나중에 정리해야 할 개인정보도 적습니다.
이름 규칙은 처음에 정합니다
규칙은 단순할수록 지켜집니다. 소문자 · 밑줄 · “대상_동사(과거형)” 정도면 충분합니다. enquiry_submitted, pricing_viewed 처럼요. 여기에 두 가지만 덧붙입니다.
첫째, 같은 행동은 어디서 일어나든 같은 이름을 씁니다. 랜딩의 문의 폼과 하단 문의 폼을 다른 이름으로 만들면 “총 문의 수” 를 볼 때마다 두 줄을 더해야 하고, 언젠가 한쪽을 빠뜨립니다. 위치는 이름이 아니라 속성으로 붙입니다.
둘째, 이름 목록을 표 하나에 적어 공유합니다. 이름 · 뜻 · 언제 발생하는가 세 칸이면 됩니다. 이 표가 없으면 6개월 뒤에 비슷한 이름이 하나 더 생기고, 그때부터 두 이름이 같은 것을 나눠 갖습니다.
넣은 뒤에 반드시 확인할 것
이벤트를 설정했다면 실제로 그 행동을 해 보고 기록되는지 확인합니다. 특히 문의 폼은 제출 후 페이지가 이동하는 경우가 많아, 이벤트가 전송되기 전에 화면이 넘어가 기록이 통째로 누락되는 일이 있습니다. 이런 종류의 누락은 리포트에서 “전환이 0” 이 아니라 “전환이 좀 적다” 로 보여서 더 위험합니다.
측정과 개선을 잇는 관점은 SEO 아카이브에 더 있고, 우리가 사이트를 고칠 때 무엇을 어떤 순서로 재는지는 작업 과정에 절차 그대로 공개돼 있습니다.
다음 회차
이벤트가 의미를 갖게 됐으면, 그것들을 순서대로 이을 차례입니다. 다음 회차는 퍼널 — 단계를 나눠야 어디서 사람을 잃는지가 보입니다.