관측일지 03. 데이터를 보기 전에 질문부터 설계하기

이벤트 설계가 필요한 이유

GA4는 검색만 잘한다고 모든 걸 알아서 잘 깔끔하게 분석해주는 도구가 아닙니다. `page_view`, `scroll` 같은 이벤트는 GA4가 자동으로 수집해주지만 '회원가입 과정 중 어디서 이탈하는지', '게시글 작성을 몇 명이나 끝까지 마치는지' 같은 질문에 답하기 위해서는 그 서비스에서만 존재하는 행동을 GA4가 이해할 수 있는 형태로 미리 정의해서 코드에 심어둬야 합니다. 

 

 

 

선 질문 후 이벤트

그렇기에 이벤트 설계는 이벤트 이름부터 정하는 게 아니라 풀고 싶은 질문과 사용자 행동 흐름을 먼저 정의한 뒤 그 가설을 검증할 이벤트를 결정하는 순서로 진행해야 합니다. 

질문 없이 이벤트부터 설계하면 방향성 없이 '일단 다 찍어보자' 식으로 태깅하게 되고 결과적으로 정작 필요한 데이터는 빠진 채 아무도 안 보는 이벤트만 잔뜩 쌓이는 경우가 많습니다. 반대로 질문이 먼저 있으면 이 질문에 답하려면 어떤 순간을 이벤트로 남겨야 하는지가 자연스럽게 정해지고, 어떤 파라미터를 같이 보내야 하는지도 함께 결정됩니다. 즉, 질문 → 가설 → 이벤트 순서를 지켜야 합니다. 

 

예를 들어 보자면, '회원가입 과정에서 어디서 이탈하는가?'라는 질문에 대해 '입력 항목이 많아 폼 작성 중 이탈할 것이다.'라는 가설을 세우면 이 가설을 확인할 이벤트가 자연스럽게 정해집니다. `signup_page_view`에서 시작해 `signup_start`를 거쳐 `signup_complete` 혹은 `signup_error`로 끝나는 흐름입니다. 좀 더 쪼개서 보도록 하겠습니다.

 

• `signup_page_view`: 가입 페이지에 도달
• `signup_click`: '가입하기' 버튼 클릭
• `signup_start`: 실제 입력 폼 작성 시작
• `signup_complete`: 가입 완료
• `signup_error`: 시도했지만 실패함

 

그렇다면 왜 이렇게 복잡하게 쪼개야할까

생각보다 복잡합니다. 하나로 뭉쳐도 될 것 같은데 굳이 5개로 쪼개는 이유가 있을 겁니다. 이유는 '어느 타이밍에서 이탈하는지'를 알아내기 위해서입니다. 이벤트를 하나로 뭉치면 가입했다/안했다라는 결과값만 남지만 여러 개로 쪼갤 경우 각 단계 사이의 전환율을 확인할 수 있습니다. 

• `page_view`는 많은데 `click`이 적다 → 버튼 자체가 눈에 안 띄거나 매력이 없다.
• `click`은 많은데 `start`가 적다 → 폼 진입 자체에서 이탈한다.
• `start`는 있는데 `complete`가 적다 → 입력 과정 자체가 길거나 번거롭다.

 

complete와 error를 나누는 이유

그렇다면 성공이든 실패든 `signup_start`와 세트로 `signup_end` 하나로 합치면 되지 않을까요? 이유는 앞서 단계를 쪼갠 이유와 같습니다. `signup_end` 하나로 뭉치면 가입 시도가 끝났다는 것만 알 수 있을 뿐 성공했는지 실패했는지, 실패했다면 왜 실패했는지 알 수 없습니다. `complete`와 `error`를 나누고 `error_code` 같은 파라미터를 따로 붙여야만 어떤 이유로 실패가 몰리는지를 분석할 수 있습니다. 이렇게 하면 성공률과 실패율을 각각 계산하고 실패 원인별 대응이 가능해집니다.

 

 

 

이벤트 네이밍 규칙

이벤트가 많아질수록 이름이 제각각 만들어지는 문제가 자주 발생합니다. 그렇기에 개인마다, 팀마다 다르겠지만 대략적으로는 다음 규칙을 따릅니다. 

• 이벤트 이름은 영문 소문자와 `snake_case`를 사용한다.
• 같은 행동은 항상 같은 동사를 사용한다. ex. 클릭은 항상 `_click`
• 이벤트 이름만 보아도 어떤 행동인지 이해할 수 있어야 한다.
• 화면 이름이나 버튼 이름 자체를 이벤트 이름으로 사용하지 않는다. (파라미터의 역할을 침범함)
• 이벤트(무슨 행동인가)와 파라미터(어떤 조건에서인가) 역할을 구분한다. 

 

많은 이벤트가 발생할 수 있기에 이벤트 설계 표라는 것을 만듭니다.

사용자 행동	이벤트 이름	발생 조건	파라미터	분석 목적
가입 페이지 도달	signup_page_view	가입 페이지 로드 시	-	가입 페이지 유입 수 확인
회원가입 버튼 클릭	signup_click	가입 버튼 클릭 시	button_location	가입 시도 사용자 수 확인
가입 완료	signup_complete	서버 응답 성공 시	signup_method	회원가입 전환율 확인
가입 실패	signup_error	서버 응답 실패 시	error_code	주요 실패 원인 확인

 

 

 

 

 

사례. 블로그 글 완독률

다음 글에서 더 많은 사례가 있겠지만 대략적으로 하나의 질문을 가져왔습니다. 

• 질문: 사용자가 observatory 시리즈 글을 끝까지 읽을까?
• 가설: 글이 너무 길거나 초반 구성이 지루해서 끝까지 스크롤하지 않을 것이다.
• 필요한 이벤트 / 데이터
  • `page_view`
  • `scroll` (90% 스크롤 도달 여부)
  • 평균 참여 시간
  • 다음 글 링크 클릭 수
• 예상: 조회 수는 높은데 90% 스크롤 도달 비율은 낮게 나타남
• 해석
  • 조회수는 높은데 스크롤 완료율이 낮다면, 글이 너무 길거나 초반에 이탈이 많을 수 있음
  • 완독률은 높은데 다음 글 클릭률이 낮다면, 시리즈 간 연결이 약할 수 있음
• 개선 액션
  • 글 상단에 목차 추가
  • 글 중간에 요약 박스 추가
  • 다음 편 링크를 시각적으로 강조
  • 시리즈 전용 내비게이션(이전글/다음글 바) 추가