# ユーザー識別ルール
このドキュメントでは、TE (ThinkingEngine) で採用されているユーザ識別ルールを説明し、2人のユーザーを識別する方法とログイン状態とログイン状態でない同じユーザーとして区別するルールについて説明します。
ポイント
1. A user will have three IDs for identification
Namely:
Visitor ID #distinct_id The user ID in unlogged state
Account ID #account_id The user ID in logged state
TE User ID #user_id Unique ID of the user by TE
2. The most critical ID to identify a user is the user ID
User IDs in each piece of data are generated from account IDs and visitor IDs
Generation will take precedence over account ID and will be based on visitor ID if account ID does not exist
3. When the TE background receives data containing the new account ID, it will be bound to the visitor ID of the current data.
If a visitor ID exists and is not bound by another account ID, the binding is successful and the data identified by both IDs will use the same user ID
If the visitor ID does not exist or has been bound by another account ID, the binding fails and is no longer bound, the unbound ID is NULL
4. User ID, account ID and visitor ID all correspond to each other, there is no case of more than one bundle
ユーザーは異なるデバイスでアプリを使用することがあり、ログインしていない状態でアプリを使用することもあるため、正確なユーザー識別が非常に複雑になります。このドキュメントでは、ユーザー識別ルールの詳細を説明し、理解を促進させるため例を示します。
# 1.ユーザー識別ルール
TEでは、主に「Guest ID(#distinct_id
)」、「Account ID(#account_id
)」と「TE user ID(#user_id
)」の3つIDを用いてユーザー識別が行われます。本セクションでは、それぞれのID のルールについて説明します。
# 1.1 Guest ID
Guest ID は、未ログイン状態でのユーザーIDであり、ユーザーがSDKを通してデータ送信する場合、アプリをインストールする際にGuest IDが自動的に付与されます。手動でGuest IDを作成する必要がある場合、イベントをアップロードする前にidentify
で設定します。Guest IDはSDKに保存されるため、何度も作成する必要はありません。イベントアップロード後のidentify
でのGuest ID変更はユーザーのミスマッチや重複を引き起こす可能性があるので、ご注意ください。
login
でAccout IDが作成されるまで、そのユーザーのデータに紐づくIDは#distinct_id
のみあり、#account_id
がありません。そのため、そのデータは#distinct_id
を用いてUser IDに紐づけます。
# 1.2 Account ID
Account IDは、ユーザーがログインまたは登録に成功した際に、login
を呼び出してAccount IDを設定できます。この時点でデータには、#account_id
と#distinct_id
がSDKに保存されます。Account IDを設定するためにlogin
を複数回呼び出すと、最後に受信した値がAccount IDとして取得されます。Account IDを削除するためにlogout
を呼び出すことができ、削除された後のデータでは#distinct_id
のみが保存されます。受信データが#account_id
を持つ場合、バックグラウンドは#account_id
に従って優先的にUser IDと紐づけます。
# 1.3 TE User ID
TE User IDは、ユーザーを識別する一意のIDです。TEがデータを受信すると、Account IDとGuest IDに基づいて紐づけられたUser IDを検索し、それぞれのデータの主キーとして挿入するか、User Tableで主キーに対応するプロファイルを検索してユーザープロパティを設定します。
まず、Account IDが存在する場合には優先的にAccount IDに紐づけられているUser IDを検索します。次にAccount IDが存在しない場合には、Guest IDに紐づいているUser IDを検索します。
そのどちらにおいてもUser IDが見つけられない場合には、新しいUser IDが作成され、Account IDかGuest IDと紐づけられます。
いずれの場合にも、3つのIDはそれぞれに関連づけられます。Guest IDとAccout IDの紐付けについては次のセクションで説明します。
# Guest IDとAccount IDの紐付け
TEは新しいGuest IDからデータを受信すると、Guest IDをもとにUser IDを生成し、Guest IDと紐づけます。一方、新しいログインしたユーザーに関するデータを受信した際に、Guest IDが既にUser IDに紐づいている可能性があります。それを確認した上でGuest IDとAccount IDを紐づけるどうかを判断する必要があります。その際に以下3つのシナリオが発生する可能性があります。
- Guest IDとUser IDに紐づけられていない場合には、ログインを該当ユーザーが最初に送信したイベントと見なすことができます。ゲスト状態でイベントが一切発生していない場合、新しいUser IDが作成され、Account IDとGuest IDに紐づけられます。
- Guest IDとUser IDに紐づけられ、Account IDとも紐づけられていない場合、つまり、ゲスト状態のユーザーがログインしたユーザーに変更された場合、Account IDはGuest IDと対応するUser IDに紐づけられ、新しいユーザーは作成されません。
- Guest IDとUserIDは紐づけられ、Account IDとも紐づけられている場合、つまり、ログインしているユーザーが使用していたデバイスに新しいユーザーがアカウントを登録した場合、Account IDはGuest IDを紐付けず、新しいUser IDを作成してAccount IDと紐づけられます。
なお、アカウントIDとユーザーIDの拘束判定は、新たなアカウントIDを含むデータをバックグラウンドで受信した場合に1回のみ発生するため、つまり、アカウントIDの拘束判断は一度しか行われないため、3番目のケースでは、アカウントIDは永続的にビジターIDを拘束できなくなります。
# ケーススタディ
TEのユーザー識別ルールをよりよく理解するために、このセクションでは、ルールがどのように機能するかのケーススタディを示します。それぞれ、データを受信した後にUser IDを設定するシナリオを示しています。各ステップにおける#user_id
とその他IDとの紐づけの原則を理解ください。
# #distinct_idのみのケース
#distinct_id
のみのケースには、#distinct_id
のみが生成されます。
Step | #account_id | #distinct_id | #user_id |
---|---|---|---|
1 | null | A | 1 |
2 | null | B | 2 |
3 | null | C | 3 |
4 | null | A | 1 |
上記のケースでは、Step1からStep3で、それぞれ3つの新しい#distinct_id
を受信、3つの新しい#user_id
が作成されます。その後のStep4で、#user_id =
1には、#distinct_id =
Aに紐づけられます。これは、Step1で作成された#user_id =
1であるとみなされていることを意味します。
# #distinct_idと#user_idに紐づけられ、#account_idとは紐付けられていないケース
#distinct_id
と#user_id
に紐づけられ、#account_id
とは紐付けられていないケースには、受信した#account_id
は#account_id
と#distinct_id
と紐づけられます。
Step | #account_id | #distinct_id | #user_id |
---|---|---|---|
1 | null | A | 1 |
2 | A | A | 1 |
上記のケースでは、Step1で#distinct_id
と#user_id
に紐づけられ、#account_id
とは紐付けられていません。つまり、新しい#distinct_id
を受信し、新しい#user_id
を作成されています。その後のStep2では、新しい#account_id
を受信した後、#distinct_id
は紐付けされず、新しい#account_id
は#distinct_id
と紐づけられます。
# #distinct_idが#user_idと#account_idの両方で紐づけられているケース
#distinct_id
は#user_id
と#account_id
の両方で紐づけられているケースには、新しい#account_id
は#distinct_id
を紐づけられず、異なる#distinct_id
と紐づけられます。
Step | #account_id | #distinct_id | #user_id |
---|---|---|---|
1 | A | A | 1 |
2 | B | A | 2 |
3 | B | B | 2 |
4 | null | B | 2 |
5 | null | A | 1 |
6 | C | B | 3 |
上記のケースでは、Step1で#distinct_id
= Aと#account_id
= Aが紐づけられ、Step2で#user_id
= 2という条件だけでは、#distinct_id
= Aと紐づけられません。Step3で#distinct_id
= Bであり、#account_id
= Bであると通信された場合、#distinct_id
= Bは、いずれの#account_id
とも紐づけられていないため、新たに#account_id
= Bと#user_id
= 2 の両方で紐づけられている。
次にStep4では、#distinct_id
= Bは既に#user_id
= 2と紐づけられています。しかし、その後、#distinct_id
= Bが新たに#account_id
= Cを通知した場合には、新規ユーザーとして見做され、#user_id
= 3が新たに発行されます。
最終的な各IDの関係性は以下の通りです。
#account_id | #distinct_id | #user_id | |
---|---|---|---|
A | A | 1 | |
B | B | 2 | |
C | null | 3 |
# 複雑なシナリオの分析
理解を容易にするために、主要なステップのUserテーブル構造を示します。このステップの説明を比較することで理解できます。
Step | #account_id | #distinct_id | #user_id |
---|---|---|---|
1 | null | A | 1 |
2 | A | A | 1 |
3 | B | A | 2 |
4 | null | B | 3 |
5 | B | B | 2 |
6 | C | B | 3 |
7 | C | C | 3 |
8 | B | C | 2 |
9 | D | C | 4 |
10 | null | C | 2 |
#distinct_id
= Aと#account_id
= Aが紐づけられ、Step2で#user_id
= 2
#distinct_id
= Aが通知され、#user_id
= 1で紐づけられます#account_id
= Aが発行された場合、#distinct_id
= Aが他の#account_id
と紐づけがない場合、#distinct_id
= Aと#account_id
= A、#user_id
= 1と紐づけられます#account_id
= Bが新たに通知された場合、#distinct_id
= Aは#account_id
= Aと紐づけられているため、新たに#user_id
= 2と紐づけられます。この場合新たな#distinct_id
は発行されません。この状況での関係は以下の通りです。
#account_id | #distinct_id | #user_id |
---|---|---|
A | A | 1 |
B | null | 2 |
- この時、
#distinct_id
= BはどのIDとの紐づけられていないため、もし発行された場合、新たに#user_id
= 3が発行され紐付けられます。 - この状況においては、
#account_id
= Bと#distinct_id
= Bは2人のユーザーに属しています。この状況での関係は以下の通りです。
#account_id | #distinct_id | #user_id |
---|---|---|
A | A | 1 |
B | null | 2 |
null | B | 3 |
#distinct_id
= Bの状況下で#account_id
= Cが新たに通知された場合、#distinct_id
= Bと#account_id
= C、#user_id
= 3と紐づけられます。この状況での関係は以下の通りです。
#account_id | #distinct_id | #user_id |
---|---|---|
A | A | 1 |
B | null | 2 |
C | B | 3 |
#user_id
= 3と#distinct_id
= Bに紐付けられた#account_id
= Cは、現時点では#distinct_id
= Cに対して動作しません。#account_id
= Bと#distinct_id
= Cが通知された場合、#distinct_id
= Cは他の#account_id
とは紐付けられていないため、新たに紐付けられています。この状況での関係は以下の通りです。
#account_id | #distinct_id | #user_id |
---|---|---|
A | A | 1 |
B | C | 2 |
C | B | 3 |
- 新しい
#account_id
= Dで新しいユーザーがログインした場合、#distinct_id
= Cと#user_id
= 2に属するので、紐づく先がありません。この状況での関係は以下の通りです。
#account_id | #distinct_id | #user_id |
---|---|---|
A | A | 1 |
B | C | 2 |
C | B | 3 |
D | null | 4 |
- 最後の
#distinct_id
= Cは#user_id
= 2と結び付けられています
この状況での関係は以下の通りです。
#account_id | #distinct_id | #user_id |
---|---|---|
A | A | 1 |
B | C | 2 |
C | B | 3 |
D | null | 4 |
← Cookie**ポリシー** データルール →