이벤트 이름 설계의 세분성(granularity)

세분성의 스펙트럼 — 너무 잘게 / 적정 / 너무 뭉치기

같은 ‘회원가입 버튼 클릭’이라는 행동을 세 가지 방식으로 설계하면 다음과 같이 갈립니다.

중앙의 ‘적정’이 우리가 추구하는 자리입니다. 다만 ‘적정’이 어디인지는 사이트의 성격·분석 목적·운영 환경에 따라 미세하게 달라집니다 — 그래서 ‘세분성’ 이야기는 한 줄 규칙이 아니라 판단 기준이 됩니다.

우리의 원칙 — “이벤트는 적게, 매개변수는 풍부하게”

이 원칙이 좋은 이유는 ‘합치는 분석’과 ‘쪼개는 분석’ 둘 다 가능하기 때문입니다.

• 합치기 — click_btn의 총 클릭 수를 한 줄로 본다. (이름이 하나라 자연스럽게 합산됨)
• 쪼개기 — btn_name을 측정기준으로 두면 ‘회원가입 버튼·결제 버튼·취소 버튼…’이 어떻게 다른지를 즉시 본다.
• 새 버튼이 추가돼도 — 새 이벤트를 만들지 않고 btn_name에 새 값만 들어오면 분석에 자동 반영. 운영이 가볍습니다.

반대로 ‘이벤트로 쪼개야 마땅한 경우’도 있습니다 — 같은 ‘클릭’이라도 ① UX 요소 유형이 다르면(click_btn vs click_tab vs click_gnb), ② KPI에 직결되는 행동이라면(sign_up, purchase는 주요이벤트로 별도), 이때는 이벤트를 분리합니다. ‘무엇이 일어났는가’가 종(種)으로 다르면 이름도 다르게.

적용 예시 — 무엇을 이벤트로, 무엇을 매개변수로

요지 — UX 요소가 같으면 같은 이벤트, 다르면 다른 이벤트. 회원가입·구매처럼 ‘결과’가 KPI인 행동만 의미론적 이름으로 따로 분리합니다(→ 주요이벤트와 서브이벤트).

새 이벤트로 쪼갤지 — 판단 체크리스트

‘이 행동을 별도 이벤트로 만들어야 할까, 매개변수로 처리할까?’를 결정할 때 다음 다섯 가지를 차례로 봅니다. 대부분은 매개변수로 처리가 정답이고, 그 모든 질문에 ‘분리’ 쪽 답이 나올 때만 새 이벤트를 만듭니다.

1. UX 요소 유형이 다른가? ‘버튼’과 ‘탭’과 ‘메뉴’는 사용 맥락이 달라 분석가가 따로 봅니다 → 다르면 분리(click_btn ≠ click_tab ≠ click_gnb).
2. KPI에 직접 영향을 주는 ‘결과’ 행동인가? 회원가입·구매·로그인·문의 제출 같은 비즈니스 마일스톤은 별도 이벤트(주요이벤트, 의미론적 이름)로.
3. 두 행동을 ‘합쳐서 본 적이 있나/볼 가능성이 있나’? 합쳐 보고 싶으면 같은 이벤트로(매개변수로 구분). 절대 합치지 않을 별개 행동이라면 분리.
4. 매개변수만으로 구분하기 어려운가? 같은 매개변수 키에 너무 많은 종류의 값이 들어가 분석가가 헷갈리면 분리하는 게 낫습니다. 반대로 btn_name 같은 단일 키로 100가지 버튼을 구분해도 무리 없으면 매개변수 그대로.
5. 새 이벤트로 만들면 GA4 한도가 부담되지 않나? 이벤트 이름은 한 속성당 약 500개, 그중 의미 있게 분석할 수 있는 건 훨씬 적습니다. 비슷한 행동을 50개로 늘리는 결정은 ‘이게 정말 필요한가’를 한 번 더 묻고.

다섯 질문 중 분리할 명백한 근거가 두 개 이상이 아니라면 — 같은 이벤트로 두고 매개변수로 차이를 두는 쪽이 거의 항상 안전합니다.

GA4 한도 관점

세분성 판단은 GA4의 운영 한도와도 직결됩니다. 한도를 안 후 결정 기준을 다시 보면 ‘왜 이벤트는 적게, 매개변수는 풍부하게’가 자연스럽게 따라옵니다.

정확한 한도는 표준/360 속성에 따라 다르고 시기별 정책으로 조정되므로 GA4 공식 문서로 한 번 확인하는 게 좋습니다 — 본 표는 일반적인 설계 의사결정을 도울 어림수입니다.

자주 묻는 질문