目录
此内容是否有帮助?

# ユーザー識別ルール

本章では、TA が採用しているユーザー識別ルールを紹介します。異なるユーザーの区別および同じユーザーのログイン状態と未ログイン状態での行動の連携方法について説明します。

要約:

    1. 1つのユーザーは3つのIDで識別
       具体的には：
        ゲストID      　　#distinct_id    ユーザーは未ログイン状态でのID
        アカウントID      #account_id     ユーザーのログインID
        TAユーザーID    　#user_id        TAでユーザーを識別するための一意のID

    2. ユーザーを識別するため最も重要なIDはアカウントID
       各データのユーザーIDはアカウントIDとゲストIDで生成される。
       ユーザーIDは優先的にアカウントIDに基づいて生成し、アカウントIDが存在しない場合は
       ゲストIDに基づいて生成する。

    3. TAバッググランドで新しいアカウントIDを含むデータを受信した際に、そのデータのゲスト
    　　IDとの紐づけが行われる。
      　ゲストIDが存在する、且つほかのアカウントに紐づいていない場合は紐づけが成功する。
        そのゲストIDとアカウントIDを使用しているデータは同じユーザーIDを使用する。
      　しかし、ゲストIDが存在しない、もしくはほかのアカウントIDに紐づけられた場合、紐づけが
       失敗する。紐づいていないIDはNULLになる。

    4. ユーザーID、アカウントIDとゲストIDはそれぞれ対応しており、一対多のケースは存在しない。

ユーザーは、さまざまなデバイスで本製品を使用したり、ログインしていない状態で使用する可能性もあるので、正確なユーザー識別が非常に複雑になります。TA はより正確で理解しやすい識別ルールを採用しました。本章では、ユーザー識別ルールについて詳しく説明するうえに、理解しやすくなるように事例を提供します。

# 1、識別ルール

TA プラットフォームには、主にゲスト ID（#distinct_id）、アカウント ID（#account_id）と TA ユーザー ID（#user_id）との 3 つの ID があります。本節では、この 3 つの ID 生成ルールについて説明します。

# 1.1 　ゲスト ID(#distinct_id)

ゲスト ID は、未ログイン状態でのユーザー ID であり、ユーザーが SDK を通してデータをインポートするならば、アプリをインストールする際に#distinct_id、いわゆるそのユーザーのゲスト ID が付与されます。ゲスト ID を作成する必要がある場合、イベントをアップロードする前にidentifyにて設定します。ゲスト ID は SDK に保存されるため、何度も作成する必要はありません。イベントアップロード後のidentifyでのゲスト ID 変更はユーザーのミスマッチや重複を引き起こす可能性があるので、ご注意ください。

loginでアカウント ID が作成されるまで、そのユーザーのデータには#distinct_idのみあり、#account_idがありません。そのため、そのデータは#distinct_idを用いてユーザー ID に紐づけます。

# 1.2 　アカウント ID（#account_id）

ユーザーがログインする、またはアカウントの作成が完了すると、loginでアカウント ID を設定することができます。その際のデータには#account_idと#distinct_id両方が含まれます。SDK はアカウント ID を保存し、loginで複数のアカウント ID を作成しても、最後の情報でしかアカウント ID が作成されません。また、logoutでアカウント ID を削除することができ、削除後のデータは#distinct_idのみあります。受信したデータには#account_idがある場合、プラットフォームでは優先的に#account_idを用いてユーザー ID に紐づけます。

# 1.3 　 TA ユーザー ID（#user_id ）

ユーザー ID は、ユーザーを識別する一意の識別子です。TA はデータを受信する際に、アカウント ID とゲスト ID をもとに紐づいているユーザー ID を検索し、各イベントに主キーとして挿入するか、ユーザーテーブル内で主キーに対応するプロファイルを検索してユーザープロパティを設定します。アカウント ID が存在する場合は優先的にアカウント ID をもとに紐づいているユーザー ID を検索するが、アカウント ID が存在しない場合はゲスト ID をもとに紐づいているユーザー ID を検索します。

アカウント ID に紐づいているユーザー ID が見つからない場合、またはアカウント ID が存在せず、ゲスト ID に紐づいているユーザー ID も見つからない場合、ユーザー ID が新規に作成され、アカウント ID またはゲスト ID（アカウント ID がない場合）に紐づけられます。ユーザー ID、アカウント ID、ゲスト ID の 3 つの ID はそれぞれに対応しています。アカウント ID に紐づいているユーザー ID が見つからない場合、以下のルールに従ってゲスト ID とアカウント ID の紐づけを行います。

# ２、ゲスト ID とアカウント ID の紐づけ

TA が新しいゲストユーザーからデータを受信すると、ゲスト ID をもとにユーザー ID を生成し、ゲスト ID に紐づけます。一方、新しいログインユーザーのデータを受信した場合、ゲスト ID が既にユーザー ID に紐づいている可能性があるので、それを確認し、ゲスト ID とアカウント ID を紐づけるどうかを判断する必要があります。その際に以下 3 つのケースが発生しする可能性があります。

  1. ゲスト ID はユーザー ID と紐づいておらず、ログインユーザーが初めてイベントを送信したと考えられます。また、ゲストの状態でイベントが発生していません。その場合、新しいユーザー ID が作成され、アカウント ID とゲスト ID に紐づけられます。
  2. ゲスト ID はユーザー ID に紐づいているが、アカウント ID に紐づいていません。つまり、ゲストユーザーがログインユーザーになります。その際に、アカウント ID はそのゲスト ID および対応するユーザー ID に紐づけ、新しいユーザー ID が生成されません。
  3. ゲスト ID はユーザー ID に紐づいており、アカウント ID にも紐づいています。新しいユーザーがログイユーザーが使用しているデバイスで自分のアカウントを作成した場合に発生する可能性があります。この場合、アカウント ID はゲスト ID との紐づけができなくなり、新しいユーザー ID が作成され、アカウント ID に紐づけられます。しかし、ゲスト ID は処理されません。

アカウント ID とユーザー ID の紐づけの判断は、バッググランドで新しいアカウント ID を含むデータが受信された場合のみに行われ、つまり、アカウント ID の紐づけの判断は 1 回のみ行われるので、ご注意ください。3 番目のケースは、アカウント ID とゲスト ID の紐づけが永遠にできなくなります。

# 3、事例分析

TA のユーザー識別ルールをより理解しやすくするために、この節では事例を用いて識別ルールの仕組みを示します。事例は、プラットフォームでデータを受信した後のユーザー ID 付与の流れを示します。#user_idの値および関連の仕組みにご注意ください。

# 3.1 　ゲスト ID のみの場合

ゲスト ID のみある場合は、#distinct_idのみでユーザー ID を生成します。

#acount_id
 #distinct_id
 #user_id
null
 A
 1
null
 B
 2
null
 C
 3
null
 A
 1

上記のケースでは、プラットフォームは 3 つの新しいゲスト ID を受信したため、3 つの新しいユーザー ID を作成しました。一方、ステップ 4 では、ゲスト ID「A」が対応するユーザー ID「1」が存在するため、新しいユーザー ID が作成されず、以前に作成したユーザー ID「1」と見なされます。

# 3.2 　ゲスト ID はユーザー ID に紐づいているが、アカウント ID に紐づいていない

ゲスト ID に対応するユーザー ID があるが、紐づいているアカウント ID がない場合、受信したアカウント ID はゲスト ID に紐づけます。

#acount_id
 #distinct_id
 #user_id
null
 A
 1
ア
 A
 1

上記のシナリオでは、プラットフォームは新しいゲスト ID を受信したため、新しいユーザー ID を作成しました。その後、新しいアカウント ID を受信したが、ゲスト ID はアカウント ID に紐づいていないため、新しいアカウント ID はゲスト ID に紐づけます。

# 3.3 　ゲスト ID はユーザー ID とアカウント ID とも紐づけ済

ゲスト ID に対応するユーザー ID があり、紐づけ済みのアカウント ID もある場合、新しいアカウント ID との紐づけができないが、そのユーザー ID がほかのゲスト ID と紐づけができます。

#user_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」が同時に受信しても、紐づけが行われず、新しいユーザーと見なされます。以下は最終的な対応関係です。

#user_id
 #acount_id
 #distinct_id
1
 ア
 A
2
 イ
 B
3
 ウ
 null

# 四、複雑な場面の分析

最後に複雑なケースでのユーザー識別を示します。理解しやすくするために、重要なステップのユーザーテーブル構造を示します。

ステップ
 #acount_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
 エ
 C
 4
10
 null
 C
 2

上記の複雑なケースを少しずつに説明します。

(1) 新しいゲスト ID「A」を受信し、新しいユーザー ID「1」と紐づけます。

(2) 新しいアカウント ID「ア」は、ゲスト ID「A」にはアカウント ID が紐づいていないため、「ア」、「A」、「1」が紐づけを行います。

(3) 新しいアカウント ID「イ」は、ゲスト ID「A」が既にアカウント ID「ア」に紐づいているため、新しいユーザー ID「2」に紐づけます。その時、ゲスト ID に紐づいていません。ユーザーテーブルは次の通りです。

#user_id
 #acount_id
 #distinct_id
1
 ア
 A
2
 イ
 null

(4) その時、ゲスト ID「B」は何の ID にも紐づいておらず、新しいゲスト ID とみなされ、新しいユーザ ID「3」に紐付けます。

(5) アカウント ID「イ」とゲスト ID「B」は既にに 2 つのユーザーに属しているため、紐づけられません。

#user_id
 #acount_id
 #distinct_id
1
 ア
 A
2
 イ
 null
3
 null
 B

(6) 新しいアカウント ID「ウ」は、ゲスト ID「B」がアカウント ID に紐づいていないため、「丙」、「B」、「3」が紐付けを行います。ユーザーテーブルは次の通りです。

#user_id
 #acount_id
 #distinct_id
1
 ア
 A
2
 イ
 null
3
 ウ
 B

(7) アカウント ID「ウ」は、既にユーザ ID「3」及びゲスト ID「B」に紐づいているため、ゲスト ID「C」が操作されません。

(8) アカウント ID「イ」とゲスト ID「C」は同時に受信し、ゲスト ID「C」は他のアカウント ID と紐づいていないため、その 2 つ ID の紐づけが行われます。ユーザーテーブルは次の通りです。

#user_id
 #acount_id
 #distinct_id
1
 ア
 A
2
 イ
 C
3
 ウ
 B

(9) 新しいアカウント ID「エ」は新しいユーザーであり、ゲスト ID「C」はユーザー ID「2」に属しているため、紐づけが行われません。ユーザーテーブルは次の通りです。

#user_id
 #acount_id
 #distinct_id
1
 ア
 A
2
 イ
 C
3
 ウ
 B
4
 エ
 null

(10) ゲスト ID「C」は、既にユーザ ID「2」と紐づいているため、最終的なユーザーテーブル構造は次の通りです。

#user_id
 #acount_id
 #distinct_id
1
 ア
 A
2
 イ
 C
3
 ウ
 B
4
 エ
 null

← データルール →