フィールドベースのステッチ
フィールドベースのステッチでは、イベントデータセットと、そのデータセットの永続 ID （cookie）および一時的な ID （ユーザー ID）を指定します。 フィールドベースのステッチでは、新しいステッチされたデータセットに新しいステッチ ID 列が作成され、その特定の永続 ID の一時的な ID を持つ行に基づいて、このステッチ ID 列が更新されます。
Customer Journey Analyticsをスタンドアロンソリューションとして使用する場合（Experience Platform ID サービスおよび関連する ID グラフへのアクセス権を持たない場合）、フィールドベースのステッチを使用できます。 または、使用可能な ID グラフを使用しない場合にも使用できます。
フィールドベースのステッチの仕組み
ステッチでは、特定のデータセット内のデータに対して少なくとも 2 つのパスが作成されます。
-
ライブステッチ：各ヒット（イベント）が発生するとそのヒットをステッチしようとします。 データセットに「新規」である（認証されたことのない）デバイスからのヒットは、通常、このレベルでは結び付けられません。 既に認識済みのデバイスからのヒットは、直ちに結合されます。
-
ステッチを再生：学習した一意の識別子（一時的な ID）に基づいてデータを「再生」します。 このステージでは、以前は不明だったデバイス（永続 ID）からのヒットが（一時的な ID に）結合されます。 再生は、頻度 および ルックバックウィンドウ の 2 つのパラメーターによって決定されます。 Adobeでは、次のパラメーターの組み合わせを使用できます。
- 毎日の頻度での毎日のルックバック：データは毎日、24 時間のルックバックウィンドウで再生されます。 このオプションには、再生がより頻繁に行われるという利点があります。ただし、認証されていない訪問者は、サイトを訪問した日に認証を行う必要があります。
- 毎週の頻度での毎週のルックバック：データは、毎週のルックバックウィンドウで週に 1 回再生されます（ オプションを参照）。 このオプションには、認証されていないセッションを後から認証できるという利点があります。ただし、1 週間未満の未ステッチデータは、次の週次再生まで再処理されません。
- 毎週の頻度での隔週ルックバック：データは、毎週 1 回、隔週ルックバックウィンドウで再生されます（ オプションを参照）。 このオプションには、認証されていないセッションを後から認証できるという利点があります。ただし、2 週間未満の未ステッチデータは、次の週別の再生まで再処理されません。
- 毎週の頻度での毎月のルックバック：データは、毎週、毎月のルックバックウィンドウで再生されます（ オプションを参照）。 このオプションには、認証されていないセッションを後から認証できるという利点があります。ただし、1 か月未満の未ステッチデータは、次の週次再生まで再処理されません。
-
プライバシー：プライバシー関連のリクエストを受信した場合、リクエストされた ID を削除する以外に、認証されていないイベントに対するその ID の関連付けを取り消す必要があります。
note important IMPORTANT ステッチ解除プロセスは、プライバシーリクエストの一環として、2025 年の初めに変更されます。 現在のステッチ解除プロセスでは、既知の ID の最新バージョンを使用してイベントが再ステッチされます。 イベントを別の ID に再割り当てすると、望ましくない法的結果が生じる可能性があります。 これらの懸念を修正するために、2025 年以降、新しいステッチプロセスにより、プライバシーリクエストの対象となるイベントが永続 ID で更新されます。
ルックバックウィンドウを超えたデータは再生されません。未認証の訪問と認証された訪問を一緒に識別するには、訪問者は、所定のルックバックウィンドウ内で認証する必要があります。 デバイスが認識されると、その時点からライブステッチされます。
手順 1：ライブステッチ
ライブステッチは、コレクション時に既知のデバイスとチャネルに各イベントをステッチしようとします。
次の例について考えてみます。Bob がイベントデータセットの一部として様々なイベントを記録する場合を考えてみましょう。
データが収集された日の状態：
| 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 8-row-5 9-row-5 10-row-5 11-row-5 12-row-5 13-row-5 | ||||
|---|---|---|---|---|
| イベント | タイムスタンプ | 永続 ID （Cookie ID） | 一時 ID （ログイン ID） | ステッチ ID （ライブステッチ後） |
| 1 | 2023-05-12 12:01 | 246
|
- | 246 |
| 2 | 2023-05-12 12:02 | 246 |
Bob
|
Bob |
| 3 | 2023-05-12 12:03 | 246 |
Bob
|
Bob
|
| 4 | 2023-05-12 12:04 | 246 |
- | Bob |
| 5 | 2023-05-12 12:05 | 246 |
Bob
|
Bob
|
| 6 | 2023-05-12 12:06 | 246 |
- | Bob |
| 7 | 2023-05-12 12:07 | 246 |
Bob
|
Bob |
| 8 | 2023-05-12 12:03 | 3579
|
- | 3579 |
| 9 | 2023-05-12 12:09 | 3579
|
- | 3579 |
| 10 | 2023-05-12 12:02 | 81911
|
- | 81911 |
| 11 | 2023-05-12 12:05 | 81911 |
Bob
|
Bob
|
| 12 | 2023-05-12 12:12 | 81911 |
- | Bob |
| 3 デバイス | 4 人:246、Bob、3579、81911 |
新しいデバイスでの未認証イベントと認証イベントは、両方とも別のユーザーとして（一時的に）カウントされます。認識されたデバイス上の未認証のイベントは、ライブステッチされます。
アトリビューションが機能するのは、識別するカスタム変数がデバイスに関連付けられている場合です。 上記の例では、イベント 1、8、9、10 を除くすべてのイベントがライブステッチされます（すべてのイベントが Bob 識別子を使用します）。 ライブステッチは、イベント 4、6、12 のステッチ ID を「解決」します。
遅延データ（タイムスタンプが 24 時間以上経過したデータ）は、「ベストエフォート」ベースで処理され、最高の品質を得るために現在のデータのステッチが優先されます。
手順 2：再生のステッチ
一定の間隔（選択されたルックバックウィンドウに応じて週に 1 回または 1 日に 1 回）で、再生のステッチは、認識されたデバイスに基づいて履歴データを再計算します。 デバイスが未認証の状態で最初にデータを送信してからログインした場合、再生のステッチにより、未認証のイベントが適切なユーザーに結び付けられます。
次の表は、上記と同じデータを示していますが、データの再生に基づいて異なる数字が表示されています。
再生後の同じデータ：
| 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 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 layout-auto | |||||
|---|---|---|---|---|---|
| イベント | タイムスタンプ | 永続 ID （Cookie ID） | 一時 ID （ログイン ID） | ステッチ ID （ライブステッチ後） | ステッチ ID （再生後） |
| 1 | 2023-05-12 12:01 | 246 |
- | 246 |
Bob |
| 2 | 2023-05-12 12:02 | 246 |
Bob
|
Bob |
Bob
|
| 3 | 2023-05-12 12:03 | 246 |
Bob
|
Bob
|
Bob |
| 4 | 2023-05-12 12:04 | 246 |
- | Bob |
Bob |
| 5 | 2023-05-12 12:05 | 246 |
Bob
|
Bob
|
Bob |
| 6 | 2023-05-12 12:06 | 246 |
- | Bob |
Bob |
| 7 | 2023-05-12 12:07 | 246 |
Bob
|
Bob |
Bob |
| 8 | 2023-05-12 12:03 | 3579
|
- | 3579 |
3579 |
| 9 | 2023-05-12 12:09 | 3579
|
- | 3579 |
3579 |
| 10 | 2023-05-12 12:02 | 81911 |
- | 81911 |
Bob |
| 11 | 2023-05-12 12:05 | 81911 |
Bob
|
Bob
|
Bob
|
| 12 | 2023-05-12 12:12 | 81911 |
- | Bob |
Bob |
| 3 デバイス | 4 人:246、Bob、3579、81911 |
2 人:Bob、3579 |
アトリビューションが機能するのは、識別するカスタム変数がデバイスに関連付けられている場合です。 上記の例では、イベント 1 と 10 が再生の結果としてステッチされ、イベント 8 と 9 のみがステッチされていない状態になります。 人物指標（累積）を 2 に減らします。
手順 3：プライバシーリクエスト
プライバシーリクエストを受け取ると、ステッチされた ID は、プライバシーリクエストのユーザー主体に対するすべてのレコードで削除されます。
次の表は上記と同じデータですが、Bob に対するプライバシーリクエストが処理後のデータに与える影響を示しています。 Bob が認証されたローは、他のローの一時的な ID として Bob を削除すると同時に、削除されます（2、3、5、7、11）。
Bob に対するプライバシーリクエスト後の同じデータ：
| table 0-row-8 1-row-8 2-row-8 3-row-8 4-row-8 5-row-8 6-row-8 7-row-8 8-row-8 9-row-8 10-row-8 11-row-8 12-row-8 13-row-8 | |||||||
|---|---|---|---|---|---|---|---|
| イベント | タイムスタンプ | 永続 ID （Cookie ID） | 一時 ID （ログイン ID） | ステッチ ID （ライブステッチ後） | ステッチ ID （再生後） | 一時 ID （ログイン ID） | ステッチ ID （プライバシーリクエスト後） |
| 1 | 2023-05-12 12:01 | 246 |
- | 246 |
Bob |
- | 246 |
| 2 | 2023-05-12 12:02 | 246 |
ボブ
|
Bob |
Bob
|
|
246 |
| 3 | 2023-05-12 12:03 | 246 |
ボブ
|
Bob
|
Bob |
|
246 |
| 4 | 2023-05-12 12:04 | 246 |
- | Bob |
Bob |
- | 246 |
| 5 | 2023-05-12 12:05 | 246 |
ボブ
|
Bob
|
Bob |
|
246 |
| 6 | 2023-05-12 12:06 | 246 |
- | Bob |
Bob |
- | 246 |
| 7 | 2023-05-12 12:07 | 246 |
Bob
|
Bob |
Bob |
|
246 |
| 8 | 2023-05-12 12:03 | 3579
|
- | 3579 |
3579 |
- | 3579 |
| 9 | 2023-05-12 12:09 | 3579
|
- | 3579 |
3579 |
- | 3579 |
| 10 | 2023-05-12 12:02 | 81911 |
- | 81911 |
Bob |
- | 81911 |
| 11 | 2023-05-12 12:05 | 81911 |
Bob
|
Bob
|
Bob
|
|
81911 |
| 12 | 2023-05-12 12:12 | 81911 |
- | Bob |
Bob |
- | 81911 |
| 3 デバイス | 4 人: 246、 Bob、3579、81911 |
2 人: Bob, 3579 |
3 人:246、3579、81911 |
前提条件
次の前提条件は、特にフィールドベースのステッチに適用されます。
-
ステッチを適用するAdobe Experience Platformのイベントデータセットには、訪問者の識別に役立つ次の 2 つの列が必要です。
- 永続 ID：各行で使用できる識別子。 例えば、Adobe Analytics AppMeasurementライブラリで生成された訪問者 ID や、Adobe Experience Platform ID サービスで生成された ECID などです。
- 一時的な ID：一部の行でのみ使用できる識別子。 例えば、訪問者の認証後にハッシュ化されたユーザー名やメールアドレスなどがあります。実質的に任意の識別子を使用できます。 ステッチでは、このフィールドを実際のユーザー ID 情報を保持すると見なされます。 最適なステッチ結果を得るには、データセットのイベント内で、永続 ID ごとに少なくとも 1 回、一時的な ID を送信する必要があります。 このデータセットをCustomer Journey Analytics接続内に含める予定がある場合は、他のデータセットも同様の共通の ID を持っていることが推奨されます。
-
両方の列（永続 ID と一時 ID）は、ステッチするデータセットのスキーマで、ID 名前空間を持つ ID フィールドとして定義する必要があります。
identityMapフィールドグループを使用してReal-time Customer Data Platformで ID ステッチを使用する場合、ID 名前空間を使用して ID フィールドを追加する必要があります。 Customer Journey Analyticsのステッチは ID フィールドグループをサポートしていないので、このidentityMapフィールドの ID は必須です。 スキーマに ID フィールドを追加し、同時にidentityMapフィールドグループを使用する場合は、追加の ID フィールドをプライマリ ID として設定しないでください。 追加の ID フィールドをプライマリ ID として設定すると、Real-time Customer Data Platformに使用されるidentityMapフィールドグループに干渉します。
制限事項
次の制限は、特にフィールドベースのステッチに適用されます。
- 現在のキー変更機能は、1 つの手順（永続 ID から一時的な ID への変更）に制限されます。複数手順でのキーの変更（例えば、永続 ID を一時的な ID に、その後別の一時的な IDに変更）はサポートされません。
- デバイスが複数のユーザーによって共有されていて、ユーザー間のトランジションの合計が 50,000 を超えている場合、Customer Journey Analyticsはそのデバイスに対するデータのステッチを停止します。
- 組織で使用されているカスタム ID マップはサポートされていません。
- ステッチでは大文字と小文字が区別されます。 Analytics ソースコネクタを通じて生成されたデータセットの場合、Adobeでは、一時的な ID フィールドに適用される VISTA ルールまたは処理ルールを確認することをお勧めします。 これにより、これらのルールによって同じ ID の新しいフォームが導入されることがなくなります。 例えば、VISTA ルールまたは処理ルールにより、イベントの一部のみで一時的な ID フィールドが小文字になっていないか確認する必要があります。
- ステッチでフィールドの結合や連結は行われません。
- 一時的な ID フィールドには、1 種類の ID （1 つの名前空間からの ID）を含める必要があります。 例えば、一時的な ID フィールドにログイン ID と電子メール ID の組み合わせを含めることはできません。
- 同じ永続 ID の同じタイムスタンプで複数のイベントが発生しても、一時 ID フィールドに異なる値がある場合、ステッチはアルファベット順に基づいて ID を選択します。 したがって、永続 ID A に同じタイムスタンプの 2 つのイベントがあり、1 つのイベントが Bob を指定し、もう 1 つが Ann を指定している場合、ステッチは Ann を選択します。
- 一時的な ID にプレースホルダー値（例：
Undefined）が含まれるシナリオでは注意が必要です。 詳しくは、FAQ を参照してください。