# ユーザー識別ルール

このドキュメントでは、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

← プライバシーポリシーデータルール →