Event Tracking Guideline

<a id="1-목적과-범위"></a>

1. 목적과 범위

<a id="목적"></a>

목적

• 사용자 행동 데이터를 수집하여 의사 결정 지원

<a id="범위"></a>

범위

• 서비스(웹/앱) 상에서 뷰, 노출(Impression), 클릭을 포함한 모든 상호작용

<a id="2-설계-기본-원칙"></a>

2. 설계 기본 원칙

0. 필요하다고 판단해 적재를 시작하면 과거 데이터는 없다.
1. 데이터 분석은 과거에서 답을 찾는 행위이므로, 처음부터 잘 설계를 해서 데이터를 적재해야 한다.
2. 목적에 부합하는 데이터만 수집한다.
3. 목적이 없는 데이터는 garbage data와 다를 바 없다.
4. 모든 것을 직접적으로 수집할 필요는 없다.
5. 직접적으로 측정할 수 없다면, 간접적으로라도 측정해 데이터를 남기도록 한다.
6. 일관성과 확장성을 고려해야 한다.
7. Event Name, Type, Format 등은 일관되어야 하며 Event의 추가/변경/삭제를 고려하여 설계해야 한다.

<a id="3-governance"></a>

3. Governance

• Event Tracking 운영을 위한 정책
• 전체 Tracking에 대한 중앙 관리가 권장된다.
  • Event를 생성/수정할 때는 담당자(팀)가 요청하고, 영향 등을 고려하여 사전/사후 모니터링을 진행한다.
• 보통의 경우 Deprecated가 잘 진행되지 않아 항상 계획하고 실행해야 한다.
  • 3개월 이상 사용하지 않은 Event는 Deprecated 고려
  • 1년 이상 사용하지 않은 Event는 즉시 Deprecated
    • “주기적으로 사용하는 건데요?”
    • → 새로 Tracking 작업을 하는 것이 바람직
• 삭제
  • Deprecated는 더이상 수집하지 않을 뿐, 데이터 삭제를 의미하지 않는다.
  • 삭제하는 경우
    • 중복 수집 등의 잘못 수집한 데이터
    • 저장 가용 기간을 넘어서 삭제하는 경우
  • 삭제하면 영원히 사라지는 것으로 신중히 진행해야 한다.

<a id="4-event와-property"></a>

4. Event와 Property

<a id="정의"></a>

정의

• Event
  • 모든 사용자의 행위 중 목적과 관련이 있어서 정의 내리고 확인하고자 하는 사용자의 행위와 그 결과
• (Event) Property
  • Event와 함께 수집되는 부가 정보
  • Event 자체의 정보(속성*) 뿐 아니라 다른 Event와의 관계를 설명하는 데이터 포함

<a id="수집-기준"></a>

수집 기준

<a id="event로-수집해야-하는-경우"></a>

Event로 수집해야 하는 경우

• 사용자의 행동 자체가 분석 대상일 때
• 행동의 시점이 중요한 경우
• 행동이 발생하지 않으면 이후 분석이 불가능한 경우
• 행동이 반복될 수 있고 그것이 의미가 있는 경우

<a id="property로-수집해야-하는-경우"></a>

Property로 수집해야 하는 경우

• 행동의 맥락을 설명하는 부가 데이터일 때
• 해당 Event와 함께 수집되는 데이터일 때
• 후행 Event에서 Property로 수집되어도 되는 데이터일 때
  • 후행 Event에서 수집되면 후행 Event 도달 전에 이탈하면 적재되지 않는다.
  • 즉, 과정으로 의미가 없는 데이터일 때 후행 Event에 Property로 수집한다.

<a id="예시"></a>

예시

• 회원가입
  • 회원가입 전체 절차 중 어디서 이탈이 발생했는지 알기 위해 각 Step을 전부 Event로 수집한다.
  • 아래 예시의 경우 약관동의 → 실명인증 → 회원정보입력 → 가입완료, 총 4가지 Step

• 약관 동의
  • 약관 동의는 결과만 필요하기 때문에 “회원가입 진행” Click에 동의 여부를 Property로 수집
  • 중간에 “동의합니다”, “동의하지 않습니다”는 Event로 수집하지 않는다.

<a id="5-value와-id"></a>

5. Value와 ID

<a id="id로-수집하는-경우"></a>

ID로 수집하는 경우

• Client에서 모든 데이터를 적재하지 않고, 구분자(ID)만 적재
• 데이터 변경 시, 기존 데이터를 수정하지 않고, 연결 방식으로 최신 데이터 반영

<a id="value로-수집하는-경우"></a>

Value로 수집하는 경우

• 값 자체가 분석 핵심인 경우(예 : 검색어, 자유 입력값)
• 정해진 몇가지 중에서 변화 가능성이 매우 낮은 경우(예 : payment_method = 카드/무통장입금/간편결제)
• Event 발생 시점의 스냅샷이 필요한 경우(예 : 당시 가격, 재고 수량)

<a id="예시"></a>

예시

<a id="6-page-view와-impression"></a>

6. Page View와 Impression

<a id="정의"></a>

정의

• Page View
  • 사용자가 Web이나 App의 특정 페이지(또는 화면)를 완전히 Load하거나 진입한 순간을 한 번으로 적재
• Impression
  • 특정 UI 요소가 Viewport(사용자에게 보여지는 영역)에 노출된 순간을 한 번으로 적재

<a id="viewport"></a>

Viewport

• 현재 화면에 보여지고 있는 영역
• Layout Viewport, Visual Viewport
  • Layout Viewport는 브라우저나 App이 그려낸 Viewport
  • Visual Viewport는 현재 표시되는 Viewport
  • 화면을 확대하면 Layout Viewport는 변하지 않지만 Visual Viewport는 변한다.

<a id="구분-기준"></a>

구분 기준

<a id="예시"></a>

예시

<a id="똑닥"></a>

똑닥

• Scroll을 내려서 Viewport에 보이지 않던 것이 보이면서 Impression을 남긴다.

<a id="굿닥"></a>

굿닥

• 진입시 Home화면 위에 Pop Up(Modal)이 등장
  • Home 화면은 Page View, Pop Up(Modal)은 Impression

• “이 지역 재검색” Click 후에 표시되는 병원 정보
  • 화면에 표시되는 모든 병원의 정보를 하나의 Impression에 담아서 적재

• “가까운 약국 찾기”에서 특정 약국을 Click 후에 표시되는 병원 정보
  • 해당 Bottom Sheet가 등장하면서 Impression을 남긴다.

<a id="강남언니"></a>

강남언니

• Carousel UI의 경우 화면 상에 보여지며 Impression을 남긴다.

<a id="7-event-versioning"></a>

7. Event Versioning

• Backlog List : Backlog List - “Event Version 관리”
  • 관련 기능이 개발된다면 그에 맞추어 Guideline 제공
• Event 구조나 의미가 변경될 경우 새로운 Event를 생성
  • 기존 Event는 Deprecated 처리하여, 중복 수집 방지를 위한 관리가 필요
• Event 구조나 의미가 변경되는 것이 아닌 단순한 누락, 오자 수정 등은 Event를 수정
  • 변경 사항은 명확하게 이력을 관리

<a id="8-event-상위-개념"></a>

8. Event 상위 개념

• Backlog List : Backlog List - “Event 상위 개념 도입”
• Event를 여러 Category로 분류하여 여러 Event를 하나의 그룹으로 지정한다.
  • Category 기준은 상황에 따라 다르다.
  • 예 : Page view, Click, Impression, …
• Event는 동시에 여러 Category에 속할 수 없다.
  • 개념적으로 가능하지만, 기능 구현에 문제가 있을 것으로 예상됨.
  • 기능적으로 문제가 없다면 여러 Category에 속하는 것이 어떤 이득인가?
    • Deprecated를 구별할 수도 있고
    • Team이나 Domain 단위로 Event를 구분할 수도
      • 담당자 찾기 용이하다.

<a id="9-공통-property"></a>

9. 공통 Property

• 일부 Property는 모든 Event에서 수집한다.
• Event의 종류에 상관 없이 기본적으로 필요한 정보
  • Example
    • Session ID, IP, User Agent, User ID, …

<a id="10-event-관계-property"></a>

10. Event 관계 Property

• Event 간의 연결, 흐름, 맥락을 추적하기 위해 사용
• 선행 Event 수집이 어려운 경우 후행 Event에서 선행 Event에 대한 정보를 수집
  • 예 : 외부에서 유입된 Marketing Campaign
• 각 Event에서 수집해야 하는 경우
  • 실시간 데이터가 필요한 경우
  • 스냅샷
• Dwell time(GA에서 user_engagement)
  • 우선은 생각하지 않는 것으로