目录
此内容是否有帮助?

# ユーザー識別ルール

ユーザーは異なるデバイスでアプリを使用することがあり、ログインしていない状態でアプリを使用することもあるため、正確なユーザー識別が非常に複雑になります。

本章では、わかりやすいケースで TA のユーザー識別ルールを紹介します。

要約:

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

    2. ユーザーを識別するため最も重要なIDは「TAユーザーID」
       TAに受信された各データは「アカウントID」と「ゲストID」に基づいて「TAユーザーID」に関連を付けます。
       データに「アカウントID」と「ゲストID」の両方が含まれる場合、「アカウントID」を優先で「TAユーザーID」に関連を付けます。
       データに「アカウントID」が存在しない場合、「ゲストID」より「TAユーザーID」に関連を付けます。

    3. TA に「アカウントID」か「ゲストID」が含まれたデータを受信する際に：
      　データに「ゲストID」があり、且つ「TAユーザーID」に関連を付けられ、「アカウントID」に関連を付けられない場合、「ゲストID」と「アカウントID」と関連を付け、同じ「TAユーザーID」を使用します。
       データに「ゲストID」がない場合、または別の「アカウントID」に関連を付けられた場合、「ゲストID」への処理をしません。「アカウントID」を新しい「TAユーザーID」に関連を付けます。

    4. TA に新しい「ゲストID」が含まれたデータを受信する際に：
        データに「アカウントID」がある場合、当「アカウントID」に関連を付け、同じ「TAユーザーID」を使用します。
        データに「アカウントID」がない場合、当「ゲストID」は新しい「TAユーザーID」に関連を付けます。
    5. 「TAユーザーID」、「アカウントID」と「ゲストID」はそれぞれ対応関係があり、シングル「アカウントID」に複数の「ゲストID」と関連を付けられ、一つ「ゲストID」は一つ「アカウントID」のみ関連を付けられます。

# 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

← データルール →