グラフベースのステッチ
グラフベースのステッチでは、イベントデータセットと、そのデータセットの一時的な ID (ユーザー ID)の永続 ID (cookie)および名前空間を指定します。 グラフベースのステッチでは、新しいステッチされたデータセットのステッチ ID に新しい列が作成されます。 次に、永続 ID を使用して、指定された名前空間を使用してExperience PlatformID サービスから ID グラフをクエリし、ステッチされた ID を更新します。
グラフベースのステッチの仕組み
ステッチでは、特定のデータセット内のデータに対して少なくとも 2 つのパスが作成されます。
-
ライブステッチ:は、永続 ID を使用して、ID グラフにクエリを実行し、選択した名前空間の一時的な ID を検索し、発生した各ヒット(イベント)をステッチしようとします。 ルックアップから一時的な ID を使用できる場合、この一時的な ID は直ちにステッチされます。
-
ステッチを再生:再生 ID グラフから更新された ID に基づいてデータを再生します。 このステージでは、ID グラフが名前空間の ID を解決したので、以前は不明だったデバイス(永続的な ID)からのヒットがステッチされます。 再生は、頻度 および ルックバックウィンドウ の 2 つのパラメーターによって決定されます。 Adobeでは、次のパラメーターの組み合わせを使用できます。
- 毎日の頻度での毎日のルックバック:データは毎日、24 時間のルックバックウィンドウで再生されます。 このオプションには、再生がより頻繁に行われるという利点があります。ただし、認証されていない訪問者は、サイトを訪問した日に認証を行う必要があります。
- 毎週の頻度での毎週のルックバック:データは、毎週のルックバックウィンドウで週に 1 回再生されます( オプションを参照)。 このオプションには、認証されていないセッションを後から認証できるという利点があります。ただし、1 週間未満の未ステッチデータは、次の週次再生まで再処理されません。
- 毎週の頻度での隔週ルックバック:データは、毎週 1 回、隔週ルックバックウィンドウで再生されます( オプションを参照)。 このオプションには、認証されていないセッションを後から認証できるという利点があります。ただし、2 週間未満の未ステッチデータは、次の週別の再生まで再処理されません。
- 毎週の頻度での毎月のルックバック:データは、毎週、毎月のルックバックウィンドウで再生されます( オプションを参照)。 このオプションには、認証されていないセッションを後から認証できるという利点があります。ただし、1 か月未満の未ステッチデータは、次の週次再生まで再処理されません。
-
プライバシー:プライバシー関連のリクエストを受信した場合、ソースデータセットからリクエストされた ID を削除する以外に、認証されていないイベントに対するその ID のステッチも取り消す必要があります。 また、その特定の ID に対してグラフベースのステッチが今後行われないようにするために、ID を ID グラフから削除する必要があります。
note important IMPORTANT ステッチ解除プロセスは、プライバシーリクエストの一環として、2025 年の初めに変更されます。 現在のステッチ解除プロセスでは、既知の ID の最新バージョンを使用してイベントが再ステッチされます。 イベントを別の ID に再割り当てすると、望ましくない法的結果が生じる可能性があります。 これらの懸念を修正するために、2025 年以降、新しいステッチプロセスにより、プライバシーリクエストの対象となるイベントが永続 ID で更新されます。
ルックバックウィンドウを超えたデータは再生されません。未認証の訪問と認証された訪問を一緒に識別するには、訪問者は、所定のルックバックウィンドウ内で認証する必要があります。 デバイスが認識されると、その時点からライブステッチされます。
永続 ID 246
および 3579
の次の 2 つの ID グラフ、これらの ID グラフが時間の経過と共にどのように更新されるか、およびこれらの更新がグラフベースのステッチの手順にどのように影響するかを考えてみましょう。
ID グラフビューアを使用して、特定のプロファイルの ID グラフを経時的に表示できます。 ID のリンク時に使用されるロジックの理解を深めるには、ID サービスリンクロジックも参照してください。
手順 1:ライブステッチ
ライブステッチは、コレクション時に、各イベントを ID グラフからその時点での既知の情報にステッチしようと試みます。
table 0-row-5 1-row-5 2-row-5 3-row-5 4-row-5 5-row-5 6-row-5 7-row-5 1-align-right 7-align-right 13-align-right 19-align-right 25-align-right 31-align-right 37-align-right 43-align-right layout-auto | ||||
---|---|---|---|---|
時間 | 永続 IDECID |
NamespaceEmail
|
ステッチ ID (ライブステッチ後) | |
1 | 2023-05-12 11:00 | 246 |
246
|
246 |
2 | 2023-05-12 14:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
3 | 2023-05-12 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
4 | 2023-05-12 17:00 | 3579 |
3579
|
3579 |
5 | 2023-05-12 19:00 | 3579 |
3579
ted.w@gmail.com
|
ted.w@gmail.com |
6 | 2023-05-13 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
7 | 2023-05-13 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
a.b@yahoo.co.uk |
ステッチされた ID がイベントごとにどのように解決されるかを確認できます。 時刻、永続 ID、指定された名前空間の ID グラフのルックアップに基づきます(同時)。
参照が複数のステッチ ID に解決される場合(イベント 7 の場合など)、ID グラフによって返される辞書的な最初の ID が選択されます(この例では a.b@yahoo.co.uk
)。
手順 2:再生のステッチ
一定の間隔(選択したルックバックウィンドウに応じて)で、再生のステッチを行うと、その間隔の時点での ID グラフの最新バージョンに基づいて、履歴データが再計算されます。
2023-05-13 16:30 に再生のステッチが行われ、24 時間のルックバックウィンドウ設定では、サンプルの一部のイベントが再ステッチされます(「再生
table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 layout-auto | |||||
---|---|---|---|---|---|
時間 | 永続 IDECID |
NamespaceEmail
|
ステッチ ID (ライブステッチ後) |
ステッチ ID (再生 24 時間後) |
|
2 | 2023-05-12 14:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
bob.a@gmail.com |
3 | 2023-05-12 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
bob.a@gmail.com |
|
2023-05-12 17:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
ted.w@gmail.com |
|
2023-05-12 19:00 | 3579 |
3579
ted.w@gmail.com
|
ted.w@gmail.com |
ted.w@gmail.com |
|
2023-05-13 15:00 | 246 |
246
a.b@yahoo.co.uk
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
|
2023-05-13 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
a.b@yahoo.co.uk |
a.b@yahoo.co.uk |
2023-05-13 16:30 に再生のステッチが行われ、7 日間のルックバックウィンドウ設定がある場合、サンプルからのすべてのイベントが再ステッチされます。
table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 layout-auto | |||||
---|---|---|---|---|---|
時間 | 永続 IDECID |
NamespaceEmail
|
ステッチ ID (ライブステッチ後) |
ステッチ ID (再生 7 日後) |
|
|
2023-05-12 11:00 | 246 |
246
|
246 |
a.b@yahoo.co.uk |
|
2023-05-12 14:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
|
2023-05-12 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
|
2023-05-12 17:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
ted.w@gmail.com |
|
2023-05-12 19:00 | 3579 |
3579
ted.w@gmail.com
|
ted.w@gmail.com |
ted.w@gmail.com |
|
2023-05-13 15:00 | 246 |
246
a.b@yahoo.co.uk
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
|
2023-05-13 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
a.b@yahoo.co.uk |
a.b@yahoo.co.uk |
手順 3:プライバシーリクエスト
プライバシーリクエストを受け取ると、ステッチされた ID は、プライバシーリクエストのユーザー主体に対するすべてのレコードで削除されます。
次の表は上記と同じデータですが、サンプルイベントに対するプライバシーリクエスト(例:2023-05-13 18:00)の効果を示しています。
table 0-row-5 1-row-5 2-row-5 3-row-5 4-row-5 5-row-5 6-row-5 7-row-5 1-align-right 7-align-right 13-align-right 19-align-right 25-align-right 31-align-right 37-align-right 43-align-right layout-auto | ||||
---|---|---|---|---|
時間 | 永続 IDECID |
NamespaceEmail
|
ステッチ ID (プライバシーリクエスト後) | |
|
2023-05-12 11:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
|
2023-05-12 14:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
|
2023-05-12 15:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
|
2023-05-12 17:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
|
2023-05-12 19:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
|
2023-05-13 15:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
|
2023-05-13 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
246 |
前提条件
次の前提条件は、特にグラフベースのステッチに適用されます。
- ステッチを適用するAdobe Experience Platformのイベントデータセットには、各行で訪問者を特定する 1 つの列(永続 ID が必要です。 例えば、Adobe Analytics AppMeasurementライブラリで生成された訪問者 ID や、Experience Platform ID サービスで生成された ECID などです。
- 永続 ID も、スキーマで ID として定義する必要があります。
- Experience PlatformID サービスの ID グラフには、ステッチ中に 一時的な ID を解決するために使用する名前空間(
Email
やPhone
など)が必要です。 詳しくは、Experience Platform ID サービスを参照してください。
制限事項
次の制限は、特にグラフベースのステッチに適用されます。
-
指定された名前空間を使用して一時的な ID をクエリする場合、タイムスタンプは考慮されません。 そのため、永続的 ID が、以前のタイムスタンプを持つレコードからの一時的な ID でステッチされる可能性があります。
-
グラフ内の名前空間に複数の ID が含まれる共有デバイスシナリオでは、最初の辞書作成 ID が使用されます。 名前空間の制限と優先度がグラフリンクルールのリリースの一部として設定されている場合は、最後に認証されたユーザーの ID が使用されます。 詳しくは、 共有デバイスを参照してください。
-
ID グラフへの ID のバックフィルには、3 か月というハードリミットがあります。 Real-time Customer Data PlatformのようなExperience Platformアプリケーションを使用していない場合は、ID グラフへの入力にバックフィル ID を使用します。
-
ID サービスガードレールが適用されます。 例えば、次の 静的制限を参照してください。
- グラフ内の ID の最大数:50。
- 単一のバッチ取得での ID へのリンクの最大数:50。
- グラフ取り込み用の XDM レコードの ID の最大数:20。
- グラフ取り込み用の XDM レコードの最小 ID 数:2.