ユーザー識別ルール
ユーザーは異なるデバイスで製品を使用することもあれば、未ログインの状態で使用することもあるため、ユーザーを正確に識別するのは非常に複雑です。AEは、比較的正確で理解しやすい方式を採用しています。このドキュメントでは、ユーザー識別のルールを詳しく説明し、すばやく理解できるよう事例も紹介します。
1. 1人のユーザーは、次の3つのIDで識別されます：
- AEユーザーID（#user_id）：AEシステムにおけるユーザーの一意のID
- アカウントID（#account_id）：ユーザーのログインID
- ゲストID（#distinct_id）：ユーザーが未ログイン状態のときのID
2. ユーザーの識別で最も重要なのは「AEユーザーID」です。AEシステムが受信するデータは1件ごとに、そのデータの「アカウントID」と「ゲストID」に基づいて、対応する「AEユーザーID」に関連付けられます。1件のデータに「アカウントID」と「ゲストID」の両方が含まれる場合は、「アカウントID」に基づく「AEユーザーID」への関連付けが優先されます。「アカウントID」が存在しない場合は、「ゲストID」に基づいて「AEユーザーID」に関連付けられます
3. AEのバックエンドが受信したデータに、新しい「アカウントID」が含まれる場合：
- データに「ゲストID」が存在し、その「ゲストID」がすでに「AEユーザーID」に関連付けられているものの「アカウントID」には紐付けられていない場合は、その「アカウントID」と「ゲストID」が紐付けられ、1つの「AEユーザーID」を共有します
- 「ゲストID」が存在しない場合、またはすでに他のアカウントIDに紐付けられている場合は紐付けが行われず、「アカウントID」は新しい「AEユーザーID」に関連付けられます
4. AEのバックエンドが新しい「ゲストID」を含むデータを受信した場合：
- 現在のデータに「アカウントID」が存在する場合は、その「アカウントID」と紐付けられ、2つのIDは同じ「AEユーザーID」に関連付けられます
- 現在のデータに「アカウントID」が存在しない場合は紐付けが行われず、その「ゲストID」は新しい「AEユーザーID」に関連付けられます
5. 「AEユーザーID」と「アカウントID」は1対1で対応します。「アカウントID」と「ゲストID」は1対多で紐付けられますが、1つの「ゲストID」に紐付けられる「アカウントID」は1つだけです。
1. ユーザー識別IDの種類
AEプラットフォームでは、主に3つのユーザー識別IDを使用します。「ゲストID（#distinct_id）」、「アカウントID（#account_id）」、「AEユーザーID（#user_id）」です。この節では、これら3つのIDの意味を簡単に説明します：
1.1 ゲストID（#distinct_id）
ゲストIDは、ユーザーが未ログイン状態のときの識別子で、ログイン前やゲーム外のデータ（登録前のデータ、広告データなど）を識別するために使用します。
クライアントSDKで接続する場合は、SDKがそのユーザーに一意のゲストIDを自動的に設定します。ユーザーのゲストIDをカスタマイズする必要がある場合は、SDKの初期化直後にidentifyを呼び出して設定してください。
イベントをアップロードした後に、再度identifyを呼び出してゲストIDを変更しないでください。ユーザーを照合できない、ユーザーが重複するなどの深刻なデータ問題が発生するおそれがあります。
1.2 アカウントID（#account_id）
アカウントIDは、ユーザーがログイン状態のときの識別子で、ログイン後のデータを識別するために使用します。ゲームの多くは「アカウント、キャラクター」の2つのディメンションでユーザーを識別します。一般的には、より小さい粒度、つまり「キャラクター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」を生成するロジックは、次の2つのステップに分けられます：
- 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」に関連付けることです。これにより、1人のユーザーのログイン前とログイン後のデータが紐付けられます。
-
「アカウントID」と「ゲストID」をどちらも初めて受信した場合、2つのIDは紐付けられ、新しい「AEユーザーID」に関連付けられます
-
「アカウントID」がID関連付けテーブルに存在し、「ゲストID」が新しいIDの場合は、「ゲストID」が「アカウントID」に紐付けられます。1つの「アカウントID」には複数の「ゲストID」を紐付けられます。
-
「ゲストID」がID関連付けテーブルに存在し、「アカウントID」が新しいIDの場合は、次の2つのケースがあります：
- 「ゲストID」がすでに他の「アカウントID」に紐付けられている場合、「ゲストID」は「アカウントID」に紐付けられず、「アカウントID」は新しい「AEユーザーID」に関連付けられます
- 「ゲストID」が他の「アカウントID」に紐付けられていない場合、「ゲストID」は「アカウントID」に紐付けられます
データ内の「アカウントID」と「ゲストID」がいずれもID関連付けテーブルに存在する場合、ID関連付けテーブルは変更されません。
3. データと「AEユーザーID」の関連付け
次は、データを「AEユーザーID」に関連付ける段階です。これも次の2つのルールに分かれます：
- データに「アカウント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 |
上記のシナリオでは、バックエンドが3つの新しい「ゲストID」を受信したため、「ユーザーID」が3回新規作成されました。4番目のステップでは、「ゲスト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"に関連付けられます。3番目のステップでは、「アカウントID」"乙"と「ゲストID」"B"が同時に渡されますが、「ゲストID」"B"はまだ「アカウントID」に紐付けられていないため、両者が紐付けられます。そのため、4番目のステップで渡された「ゲスト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」"4"に関連付けられます
（10）最後に、データには「ゲストID」"C"のみが含まれるため、関連付けられた「ユーザーID」"3"が返されます
最終的なID関連付けテーブルの構造は次のとおりです：
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | null |
| 3 | 丙 | B, C |
| 4 | 丁 | D |