트래킹 방안 수립
유저 식별 시스템 결정
데이터를 연동하기 전에 먼저 프로젝트에서 사용할 유저 식별 시스템을 결정해야 합니다. 더 많은 시나리오 사례는 유저 식별 규칙에서 확인할 수 있습니다. #account_id는 AE 시스템에서 유저를 식별하는 최소 단위로, 일반적으로 유저의 계정 ID를 #account_id로 설정합니다. 하나의 계정 아래에 서로 독립적인 캐릭터가 여러 개 있다면 캐릭터 ID를 #account_id로 설정해야 합니다. 예를 들어 하나의 게임 계정으로 여러 서버에서 캐릭터를 만들 수 있고 각 캐릭터마다 레벨, 직업, 장비 등이 따로 있다면, 이때는 캐릭터 ID가 최소 단위가 됩니다. #distinct_id는 유저가 게스트 상태일 때의 행동(앱 열기, 공지 보기 등)을 기록하는 ID입니다. 계정에 로그인하기 전이나 캐릭터 정보를 얻기 전에는 행동 데이터가 #distinct_id에 귀속됩니다. #user_id(AE 유저 ID)는 AE 시스템이 #account_id와 #distinct_id를 바탕으로 생성하는 고유 식별자로, #user_id를 통해 유저의 로그인 전후 행동을 연결할 수 있습니다. 한 건의 데이터에 #account_id와 #distinct_id가 함께 있고 각각에 대응하는 #user_id가 다르면, 해당 데이터는 #account_id에 대응하는 #user_id에 귀속됩니다.
이벤트 및 이벤트 속성 결정
이벤트는 유저의 의미 있는 하나 또는 일련의 행동을 나타내며, 주요 분석 대상이기도 합니다. 프로젝트의 핵심 지표에서 출발하여 회원가입, 로그인, 결제, 핵심 플레이 등 주요 기능을 정리하고, 이 기능들을 이벤트로 변환할 수 있습니다. 이벤트를 정한 후에는 각 이벤트의 고유 속성도 정해야 이후 분석에 더 많은 상세 정보를 제공할 수 있습니다. 예를 들어 유저가 결제 이벤트를 한 번 트리거할 때 이벤트 속성으로 결제 금액, 구매한 패키지 ID 등을 기록할 수 있습니다. 고유 속성 외에도 일부 중요한 속성을 공통 이벤트 속성으로 설정할 수 있으며, 이 속성은 행동이 발생한 시점의 유저 상태를 반영합니다. 예를 들어 VIP 등급을 공통 이벤트 속성으로 설정하면 모든 이벤트를 전송할 때 이 속성이 함께 전송되므로, VIP 등급이 유저 행동에 미치는 영향을 더 정확하게 분석할 수 있습니다.
유저 속성 결정
공통 이벤트 속성과 달리 유저 속성은 유저의 현재 상태를 기록합니다. 다음 세 종류의 값을 유저 속성으로 설정할 수 있습니다:
- 고정값: 변하지 않는 속성(예: 가입 시간, 유입 채널, 사용자 이름 등)
- 최신값: 유저가 마지막으로 특정 행동을 했을 때의 정보(예: 마지막 로그인 시간, 마지막 결제 시간 등)
- 누적값: 최신값과 비슷하며, 유저의 과거 누적 데이터를 나타냅니다(예: 누적 결제 금액, 누적 로그인 횟수 등).
예를 들어 어떤 유저가 결제 이벤트를 두 번 트리거했고, 그중 1회 결제 금액은 고유 속성이고 누적 결제 금액은 공통 이벤트 속성으로서 결제 이벤트가 발생한 시점에 해당 유저가 그동안 결제한 금액의 합계를 기록한다고 가정합니다:
| 이벤트 시간 | 누적 결제 금액 | 1회 결제 금액 |
|---|---|---|
| 1월 1일 | 0 | 50 |
| 1월 2일 | 50 | 100 |
이벤트 상세 정보를 보면 이벤트 속성의 속성 값은 시간이 지나도 바뀌지 않습니다. 반면 누적 결제 금액이 유저 속성이라면, 유저가 처음 결제한 후 속성 값이 0에서 50으로 업데이트되고 두 번째 결제 후에는 150으로 업데이트됩니다. 이벤트, 이벤트 속성, 유저 속성에 대한 자세한 내용은 데이터 관리에서 확인할 수 있습니다. 추적할 모든 이벤트와 속성을 문서 형태로 정리할 것을 강력히 권장합니다. 트래킹을 구현할 때 개발 담당자와 소통하는 데 도움이 됩니다. 트래킹 방안을 수립한 다음 단계는 데이터 전송 및 검증입니다.