유저 식별 규칙
유저는 여러 디바이스에서 제품을 사용할 수도 있고, 로그인하지 않은 상태에서 사용할 수도 있어 유저를 정확하게 식별하기가 상당히 복잡합니다. AE는 비교적 정확하고 이해하기 쉬운 방식을 채택했습니다. 이 문서에서는 유저 식별 규칙을 자세히 설명하고, 빠르게 이해할 수 있도록 사례를 제공합니다.
1. 한 유저는 다음 세 가지 ID로 식별됩니다:
- AE 유저 ID(#user_id): AE 시스템의 유저 고유 ID
- 계정 ID(#account_id): 유저의 로그인 ID
- 게스트 ID(#distinct_id): 로그인하지 않은 상태의 유저 ID
2. 유저 식별에서 가장 중요한 것은 AE 유저 ID입니다. AE 시스템은 수신한 모든 데이터에 대해 해당 데이터의 계정 ID와 게스트 ID에 따라 대응하는 AE 유저 ID를 연결합니다. 데이터에 계정 ID와 게스트 ID가 모두 포함되어 있으면 계정 ID를 기준으로 AE 유저 ID를 우선 연결합니다. 계정 ID가 없으면 게스트 ID를 기준으로 AE 유저 ID를 연결합니다
3. AE 백엔드가 수신한 데이터에 새로운 계정 ID가 포함된 경우:
- 데이터에 게스트 ID가 있고 이 게스트 ID가 이미 AE 유저 ID와 연결되어 있지만 계정 ID와 바인딩되어 있지 않으면, 해당 계정 ID와 게스트 ID를 바인딩하여 하나의 AE 유저 ID를 공유합니다
- 게스트 ID가 없거나 이미 다른 계정 ID와 바인딩되어 있으면 바인딩하지 않으며, 계정 ID는 새로운 AE 유저 ID와 연결됩니다
4. AE 백엔드가 새로운 게스트 ID가 포함된 데이터를 수신한 경우:
- 현재 데이터에 계정 ID가 있으면 해당 계정 ID와 바인딩하며, 두 ID는 같은 AE 유저 ID와 연결됩니다
- 현재 데이터에 계정 ID가 없으면 바인딩하지 않으며, 해당 게스트 ID는 새로운 AE 유저 ID와 연결됩니다
5. AE 유저 ID와 계정 ID는 일대일로 대응합니다. 계정 ID 하나에 여러 게스트 ID를 바인딩할 수 있지만, 게스트 ID 하나는 계정 ID 하나에만 바인딩할 수 있습니다.
1. 유저 식별 ID의 종류
AE 플랫폼은 주로 게스트 ID(#distinct_id), 계정 ID(#account_id), AE 유저 ID(#user_id)의 세 가지 유저 식별 ID를 사용합니다. 이 절에서는 세 ID의 의미를 간단히 소개합니다:
1.1 게스트 ID(#distinct_id)
게스트 ID는 로그인하지 않은 상태의 유저 식별자로, 로그인 전이나 게임 외부에서 발생한 유저 데이터(예: 가입 전 데이터, 광고 데이터 등)를 식별하는 데 사용합니다.
클라이언트 SDK로 연동하는 경우 SDK가 유저에게 고유한 게스트 ID를 자동으로 할당합니다. 유저의 게스트 ID를 직접 지정해야 하는 경우 SDK를 초기화한 직후 identify를 호출하여 설정하십시오.
이벤트를 업로드한 후 identify를 다시 호출하여 게스트 ID를 변경하지 마십시오. 이 작업은 유저를 매칭할 수 없거나 유저가 중복되는 등 심각한 데이터 문제를 일으킬 수 있습니다.
1.2 계정 ID(#account_id)
계정 ID는 로그인 상태의 유저 식별자로, 로그인 후의 유저 데이터를 식별하는 데 사용합니다. 게임은 대부분 계정과 캐릭터의 두 차원으로 유저를 식별합니다. 일반적으로 더 작은 단위, 즉 캐릭터 ID를 계정 ID로 사용할 것을 권장하며, 캐릭터 차원이 없는 경우에는 계정 로그인 ID를 계정 ID로 사용합니다.
클라이언트 SDK로 연동하는 경우 유저가 가입하거나 로그인할 때, 또는 캐릭터를 생성하거나 서버에 진입할 때 login을 호출하여 계정 ID를 설정할 수 있습니다. SDK는 계정 ID를 저장하며, 이후의 모든 데이터에 계정 ID가 포함됩니다. login을 다시 호출하여 계정 ID를 설정하면 새로 전달한 값을 계정 ID로 사용합니다. logout을 호출하여 계정 ID를 지울 수도 있으며, 지운 후의 데이터에는 계정 ID가 포함되지 않습니다.
1.3 AE 유저 ID(#user_id)
AE 유저 ID는 AE 시스템 내부에서 유저를 식별하는 데 사용하는 고유 식별 ID입니다. 올바른 데이터가 적재될 때마다 시스템은 계정 ID와 게스트 ID에 따라 해당 데이터의 AE 유저 ID를 생성하여, 그 데이터가 어느 유저에게 속하는지 명확히 합니다.
AE 유저 ID는 분석에서 매우 중요한 역할을 합니다. 이벤트 데이터, 유저 속성, 유저 코호트·태그 등의 데이터 테이블은 AE 유저 ID로 연결됩니다. 분석 모델에서 계산하는 중복 제거 유저 수는 실질적으로 AE 유저 ID의 고유값 수입니다.
유저 식별 규칙은 곧 각 데이터의 AE 유저 ID를 생성하는 규칙이라고 볼 수 있습니다. AE 유저 ID를 생성하는 로직은 두 단계로 나뉩니다:
- ID 연결 테이블 업데이트: 데이터에 새로운 계정 ID 또는 게스트 ID가 있으면 AE 시스템이 내부의 ID 연결 테이블을 업데이트합니다
- 데이터와 AE 유저 ID 연결: 데이터의 계정 ID 또는 게스트 ID로 ID 연결 테이블에서 대응하는 유저 ID를 찾아 각 데이터에 AE 유저 ID를 연결합니다
2. ID 연결 테이블 업데이트
AE 시스템 내부에는 이벤트 테이블, 유저 테이블과 별개인 ID 연결 테이블이 있으며, 이 테이블에는 AE 유저 ID와 계정 ID, 게스트 ID의 연결 관계가 기록됩니다. 시스템이 수신한 데이터에 새로운 계정 ID 또는 게스트 ID가 포함되어 있으면 이 ID 연결 테이블이 업데이트됩니다.
- 데이터에 계정 ID만 있거나 게스트 ID만 있고 해당 ID를 처음 수신한 경우입니다. 이때 시스템은 새로운 AE 유저 ID를 생성하여 전달된 ID와 연결합니다.
데이터에 계정 ID와 게스트 ID가 모두 포함되어 있으면 ID 바인딩 메커니즘도 적용됩니다. ID 바인딩이란 계정 ID와 게스트 ID를 바인딩하여 같은 AE 유저 ID에 함께 연결하는 것으로, 한 유저의 로그인 전후 데이터를 바인딩하는 것과 같습니다.
-
계정 ID와 게스트 ID를 모두 처음 수신한 경우, 두 ID를 바인딩하고 새로운 AE 유저 ID와 연결합니다
-
계정 ID가 ID 연결 테이블에 있고 게스트 ID가 새 ID이면 게스트 ID를 계정 ID와 바인딩합니다. 계정 ID 하나에 여러 게스트 ID를 바인딩할 수 있습니다.
-
게스트 ID가 ID 연결 테이블에 있고 계정 ID가 새 ID이면 다음 두 가지 경우가 있습니다:
- 게스트 ID가 이미 다른 계정 ID와 바인딩되어 있으면 게스트 ID를 계정 ID와 바인딩하지 않으며, 계정 ID는 새로운 AE 유저 ID와 연결됩니다
- 게스트 ID가 다른 계정 ID와 바인딩되어 있지 않으면 게스트 ID를 계정 ID와 바인딩합니다
데이터의 계정 ID와 게스트 ID가 모두 ID 연결 테이블에 이미 있으면 ID 연결 테이블은 조정되지 않습니다.
3. 데이터와 AE 유저 ID 연결
다음은 데이터를 AE 유저 ID와 연결하는 단계이며, 역시 두 가지 규칙으로 나뉩니다:
- 데이터에 계정 ID 또는 게스트 ID만 있으면 해당 ID와 연결된 AE 유저 ID를 바로 가져옵니다
- 데이터에 계정 ID와 게스트 ID가 모두 포함되어 있으면 계정 ID와 연결된 AE 유저 ID를 가져옵니다
간단히 말해, 유저 ID를 연결할 때는 계정 ID의 우선순위가 더 높습니다. 계정 ID가 있으면 계정 ID에 연결된 ID를 사용하고, 계정 ID가 없으면 게스트 ID에 연결된 ID를 사용합니다.
4. 사례 분석
AE의 유저 식별 방식을 더 잘 이해할 수 있도록 이 절에서는 사례를 통해 식별 규칙의 작동 방식을 구체적으로 보여 줍니다. 사례에서는 백엔드가 데이터를 수신한 후 유저 ID를 설정하는 과정을 보여 주며, 각 단계의 #user_id 값과 연결 원리에 주목하면 됩니다.
4.1 게스트 ID만 있는 경우
게스트 ID만 있는 경우에는 #distinct_id로만 유저 ID를 생성합니다
| #account_id | #distinct_id | #user_id |
|---|---|---|
| null | A | 1 |
| null | B | 2 |
| null | C | 3 |
| null | A | 1 |
위 시나리오에서 백엔드는 새로운 게스트 ID 3개를 수신했으므로 유저 ID를 세 번 새로 생성했습니다. 네 번째 단계에서는 게스트 ID "A"에 대응하는 유저 ID "1"이 이미 있으므로 유저 ID를 새로 생성하지 않고 이전에 생성된 유저로 간주하며, 유저 ID는 "1"입니다.
4.2 게스트 ID가 유저 ID와 바인딩되었지만 계정 ID와는 바인딩되지 않은 경우
게스트 ID에 대응하는 유저 ID는 있지만 계정 ID와 바인딩되어 있지 않은 경우, 계정 ID를 전달하면 계정 ID와 게스트 ID가 바인딩됩니다
| #account_id | #distinct_id | #user_id |
|---|---|---|
| null | A | 1 |
| 갑 | A | 1 |
위 시나리오에서 백엔드는 새로운 게스트 ID를 수신하여 유저 ID를 새로 생성했습니다. 이후 새로운 계정 ID를 수신했는데, 이때 게스트 ID가 계정 ID와 바인딩되어 있지 않으므로 새 계정 ID와 게스트 ID가 바인딩되었습니다.
4.3 게스트 ID가 유저 ID와 바인딩되고 계정 ID와도 바인딩된 경우
게스트 ID가 이미 유저 ID와 연결되어 있고 계정 ID와도 바인딩되어 있으면 새 계정 ID는 이 게스트 ID와 바인딩할 수 없으며, 해당 계정 ID는 이후 다른 게스트 ID와 바인딩을 시도할 수 있습니다:
| #account_id | #distinct_id | #user_id |
|---|---|---|
| 갑 | A | 1 |
| 을 | A | 2 |
| 을 | B | 2 |
| null | B | 2 |
| null | A | 1 |
| 병 | B | 3 |
위 시나리오에서 게스트 ID "A"는 이미 계정 ID "갑"과 바인딩되어 있으므로 새 계정 ID "을"은 게스트 ID "A"와 바인딩할 수 없고, 대신 새로운 유저 ID "2"와 연결됩니다. 세 번째 단계에서 계정 ID "을"과 게스트 ID "B"가 함께 전달될 때 게스트 ID "B"는 계정 ID와 바인딩된 적이 없으므로 두 ID가 바인딩됩니다. 따라서 네 번째 단계에서 전달된 게스트 ID "B"는 유저 ID "2"와 연결됩니다. 마지막으로 새 계정 ID "병"과 게스트 ID "B"가 함께 전달되는데, 이 경우에도 바인딩이 발생하지 않으며 계정 ID "병"은 새로운 유저 ID "3"과 연결됩니다. ID 연결 테이블의 최종 상태는 다음과 같습니다:
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 갑 | A |
| 2 | 을 | B |
| 3 | 병 | null |
5. 복잡한 시나리오 분석
마지막으로 복잡한 시나리오에서의 유저 식별을 보여 줍니다. 이해를 돕기 위해 주요 단계의 User 테이블 구조를 함께 제시하므로, 해당 단계의 설명과 대조하며 이해하면 됩니다:
| 단계 | #account_id | #distinct_id | #user_id |
|---|---|---|---|
| 1 | null | A | 1 |
| 2 | 갑 | A | 1 |
| 3 | 을 | A | 2 |
| 4 | null | B | 3 |
| 5 | 을 | B | 2 |
| 6 | 병 | B | 3 |
| 7 | 병 | C | 3 |
| 8 | 을 | C | 2 |
| 9 | 정 | D | 4 |
| 10 | null | C | 3 |
위의 복잡한 시나리오를 단계별로 분석합니다:
(1) 새 게스트 ID "A"가 전달되어 새로 생성된 유저 ID "1"과 바인딩됩니다
(2) 계정 ID "갑"이 추가됩니다. 게스트 ID "A"는 계정 ID와 바인딩되어 있지 않으므로 "갑"과 "A"가 바인딩되어 유저 ID "1"과 연결됩니다.
(3) 계정 ID "을"이 추가됩니다. 게스트 ID "A"는 이미 계정 ID "갑"과 바인딩되어 있으므로 "을"은 새로 생성된 유저 ID "2"와 연결됩니다. 이때 계정 ID "을"은 게스트 ID와 바인딩되어 있지 않으며, ID 연결 테이블은 다음과 같습니다:
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 갑 | A |
| 2 | 을 | null |
(4) 이때 게스트 ID "B"가 추가되어 새로 생성된 유저 ID "3"과 연결됩니다
(5) 계정 ID "을"과 게스트 ID "B"가 모두 ID 연결 테이블에 있으므로 바인딩이 발생하지 않으며, 이때 ID 연결 테이블은 다음과 같습니다:
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 갑 | A |
| 2 | 을 | null |
| 3 | null | B |
(6) 계정 ID "병"이 추가됩니다. 게스트 ID "B"는 계정 ID와 바인딩되어 있지 않으므로 "병"과 "B"가 바인딩되어 유저 ID "3"과 연결되며, 이때 ID 연결 테이블은 다음과 같습니다:
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 갑 | A |
| 2 | 을 | null |
| 3 | 병 | B |
(7) 게스트 ID "C"가 추가되어 계정 ID "병"과 바인딩되며, 이때 ID 연결 테이블은 다음과 같습니다:
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 갑 | A |
| 2 | 을 | null |
| 3 | 병 | B, C |
(8) 계정 ID "을"과 게스트 ID "C"가 모두 ID 연결 테이블에 있으므로 ID 연결 테이블은 변경되지 않습니다
(9) 계정 ID "정"과 게스트 ID "D"가 추가되어 두 ID가 바인딩되고 새로운 유저 ID "4"와 연결됩니다
(10) 마지막으로 데이터에 게스트 ID "C"만 있으므로 연결된 유저 ID "3"을 반환합니다
최종 ID 연결 테이블 구조는 다음과 같습니다:
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 갑 | A |
| 2 | 을 | null |
| 3 | 병 | B, C |
| 4 | 정 | D |