様々な宛先タイプのプロファイル書き出し動作

Experience Platform には複数の宛先タイプがあります（下図を参照）。 これらの宛先は、後の節で説明するように、宛先の書き出しをトリガーするものと書き出しに含まれる内容に関して、書き出しパターンが少し異なります。

重要

このドキュメントページでは、図の下部でハイライト表示されている接続の場合のプロファイル書き出し動作についてのみ説明します。

宛先のタイプを示す図

マイクロバッチおよび集約ポリシー

宛先タイプごとの具体的な情報に立ち入る前に、ストリーミング宛先​のマイクロバッチ処理と集計ポリシーの概念を理解しておくことが重要です。

Experience Platform の宛先では、データを HTTPS 呼び出しとして API ベースの統合機能に書き出します。バッチ取り込み、ストリーミング取り込み、バッチセグメント化、ストリーミングセグメント化または ID グラフの変更の結果、プロファイルが更新されたことを宛先サービスが他のアップストリームサービスから通知されると、データが書き出され、ストリーミング宛先に送信されます。

プロファイルを HTTPS メッセージに集計してから宛先 API エンドポイントにディスパッチするプロセスを​マイクロバッチ処理​と呼びます。

設定可能な集計​ポリシーを持つ Facebook 宛先を例に取ります。データは集計されて送信されます。この場合、宛先サービスは、プロファイルサービスアップストリームから受信するすべてのデータを取得し、それを次のいずれかで集計してから Facebook にディスパッチします。

  • レコードの数（最大 10,000）または
  • 間隔（30 分）

上記のしきい値のいずれかに初めて達したときに、Facebook への書き出しがトリガーされます。では、 Facebook Custom Audiences ダッシュボードに追加すると、Experience Platformからのオーディエンスが 10,000 レコード増分で表示される場合があります。 10 ～ 15 分ごとに 10,000 個のレコードが表示される場合があります。これは、データの処理と集計が 30 分のエクスポート間隔よりも高速におこなわれ、送信も高速になるからです。つまり、すべてのレコードが処理されるまで、約 10 ～ 15 分ごとです。 10,000 個のバッチを構成するレコードが不十分な場合、現在のレコード数は時間枠のしきい値を満たした時点のまま送信されるので、Facebookに送信される小さなバッチも表示される場合があります。

別の例として、HTTP API 宛先について考えます。この場合は、ベストエフォート集計​ポリシーと maxUsersPerRequest: 10 の条件が適用されます。 つまり、最大 10 個のプロファイルが集計されてから、この宛先に対する HTTP 呼び出しが実行されます。ただし、Experience Platform は、更新された再評価情報を宛先サービスがアップストリームサービスから受け取るとすぐに、宛先へのプロファイルのディスパッチを試みます。

集計ポリシーは設定可能で、宛先の開発者が、API エンドポイントのダウンストリームでのレート制限に最もよく合うように集計ポリシーを設定する方法を決定できます。 詳しくは、Destination SDK のドキュメントで集計ポリシーを参照してください。

ストリーミングプロファイル書き出し宛先（エンタープライズ宛先）

重要

エンタープライズ宛先を使用できるのは、Adobe Real-time Customer Data Platform Ultimate のお客様だけです。

Experience Platform のエンタープライズ宛先は、Amazon Kinesis、Azure Event Hubs および HTTP API です。

Experience Platform では、セグメントの選定または他の重要なイベントに続いてプロファイルに関係する更新が発生したときに API エンドポイントにデータを書き出すためにのみ、エンタープライズ宛先へのプロファイル書き出し動作を最適化します。 プロファイルは、次の状況で宛先に書き出されます。

  • プロファイルの更新は、宛先にマッピングされた 1 つ以上のセグメントのセグメントメンバーシップの変更によって決定されました。例えば、プロファイルは、宛先にマッピングされたいずれかのセグメントに適合しているか、宛先にマッピングされたいずれかのセグメントから退出しています。
  • プロファイルの更新は、ID マップの変更によって決定します。例えば、宛先にマッピングされたセグメントの 1 つに対して既に適合しているプロファイルの ID マップ属性に新しい ID が追加されたとします。
  • プロファイルの更新は、宛先にマッピングされた属性のうち、少なくとも 1 つの属性が変更されたことで判断されました。例えば、マッピング手順で宛先にマッピングされた属性の 1 つがプロファイルに追加されます。

上記のすべての場合で、適切な更新が行われたプロファイルのみが宛先に書き出されます。例えば、宛先フローにマッピングされたセグメントに 100 人のメンバーがいて、5 つの新しいプロファイルがセグメントに適合している場合、宛先への書き出しは増分で行われ、5 つの新しいプロファイルのみが含まれます。

プロファイルについては、変更箇所に関わらず、マッピングされたすべての属性が書き出されることに注意してください。 したがって、上の例では、属性自体が変更されていない場合でも、これら 5 つの新しいプロファイルに対してマッピングされた属性がすべて書き出されます。

データの書き出しを決定する要素と、書き出しに含まれる内容

特定のプロファイルについて書き出されるデータに関しては、エンタープライズ宛先へのデータ書き出しを決定する要因​と​書き出しに含まれるデータ​という 2 つの異なる概念を理解しておくことが重要です。

宛先の書き出しを決定する要素 宛先の書き出しに含まれる内容
  • マッピングされた属性とセグメントは、宛先の書き出しのキューとして機能します。 つまり、マッピングされたセグメントが ( null から realized またはから realized から exiting) またはマッピングされた属性が更新されると、宛先の書き出しがキックオフされます。
  • 現在 ID はエンタープライズ宛先にマッピングできないので、特定のプロファイルの ID が変わると、宛先の書き出しも決まります。
  • 属性の変更は、同じ値であるかどうかに関わらず、属性に対する更新として定義されます。 つまり、値自体が変更されていない場合でも、属性の上書きは変更と見なされます。
  • segmentMembership オブジェクトには、アクティブ化データフローでマッピングされたセグメントが含まれます。このセグメントについて、プロファイルのステータスが選定またはセグメント出口イベントの後に変更されました。 なお、これらのセグメントが、アクティブ化データフローでマッピングされたセグメントと同じ結合ポリシーに属する場合、プロファイルが適していた他のマッピングされていないセグメントを宛先の書き出しに含めることができます。
  • identityMap オブジェクト内のすべての ID も含まれます（Experience Platform では現在、エンタープライズ宛先での ID マッピングをサポートしていません）。
  • マッピングされた属性のみが宛先の書き出しに含まれます。
重要

エンタープライズ宛先は、プロファイルを宛先に対してアクティブ化する際に、バックフィルデータをストリーミングします。つまり、宛先へのアクティベーションワークフローを設定した後の最初のデータの書き出しには、セグメントが宛先にマッピングされる前にアクティブ化されたセグメントに適合したプロファイルが含まれます。

例えば、HTTP 宛先に対するこのデータフローについて考えてみましょう。ここでは、3 つのセグメントがデータフローで選択され、4 つの属性が宛先にマッピングされます。

エンタープライズ宛先のデータフロー

宛先へのプロファイルの書き出しは、3 つのマッピングされたセグメント​のいずれかに適合またはいずれかを離脱するプロファイルによって決定されます。ただし、データの書き出しでは、segmentMembership オブジェクトで、その特定のプロファイルがメンバーであり、書き出しをトリガーしたセグメントと同じ結合ポリシーを共有している場合、マッピングされていない他のセグメントが表示されることがあります。プロファイルが「デロリアンを保有している顧客」セグメントに適合すると同時に「映画『バック トゥ ザ フューチャー』を視聴済み」セグメントと「SF ファン」セグメントのメンバーでもある場合、他の 2 つのセグメントも（データフローでマッピングされていない場合であっても）データ書き出しの segmentMembership オブジェクトに表示されます（「デロリアンを保有している顧客」セグメントと同じ結合ポリシーを共有している場合）。

プロファイル属性の観点から、上記でマッピングした 4 つの属性に対する変更によって、書き出しの宛先が決定し、プロファイルに存在する 4 つのマッピング済み属性のいずれかがデータ書き出しに表示されます。

ヒント

Amazon Kinesis、Azure Event Hubs および HTTP API の宛先ドキュメントページで、様々なエンタープライズ宛先に書き出されたデータの例を確認できます。

ストリーミング API ベースの宛先

Facebook、Trade Desk およびその他の API ベースの統合などのストリーミング宛先のプロファイルの書き出しの動作は、上記のエンタープライズ宛先の動作と非常によく似ています。

ストリーミング宛先の例としては、カタログのソーシャルカテゴリと広告カテゴリに属する宛先があります。

Experience Platform は、セグメントの選定または他の重要なイベントに続いてプロファイルに関連する更新が発生した際にストリーミング API ベースの宛先へデータを書き出すためにのみ、ストリーミング宛先へのプロファイルの書き出し動作を最適化します。 プロファイルは、次の状況で宛先に書き出されます。

  • プロファイルの更新は、宛先にマッピングされた 1 つ以上のセグメントのセグメントメンバーシップの変更によって決定されました。例えば、プロファイルは、宛先にマッピングされたいずれかのセグメントに適合しているか、宛先にマッピングされたいずれかのセグメントから退出しています。
  • この宛先インスタンスの書き出し用にマークされた ID 名前空間の ID マップの変更によって、プロファイルの更新が決定された場合。例えば、宛先にマッピングされたセグメントの 1 つに対して既に適合しているプロファイルの ID マップ属性に新しい ID が追加されたとします。
  • プロファイルの更新は、宛先にマッピングされた属性のうち、少なくとも 1 つの属性が変更されたことで判断されました。例えば、マッピング手順で宛先にマッピングされた属性の 1 つがプロファイルに追加されます。
  • 同意の自動適用を設定し、プロファイルがオプトアウトされると、プロファイルの同意が変更される場合。同意の自動適用により、オーディエンスが終了したイベントが宛先に送信されるので、プロファイルが宛先のターゲティングに含まれません。

上記のすべての場合で、適切な更新が行われたプロファイルのみが宛先に書き出されます。例えば、宛先フローにマッピングされたセグメントに 100 人のメンバーがいて、5 つの新しいプロファイルがセグメントに適合している場合、宛先への書き出しは増分で行われ、5 つの新しいプロファイルのみが含まれます。

プロファイルについては、変更箇所に関わらず、マッピングされたすべての属性が書き出されることに注意してください。 したがって、上の例では、属性自体が変更されていない場合でも、これら 5 つの新しいプロファイルに対してマッピングされた属性がすべて書き出されます。

データの書き出しを決定する要素と、書き出しに含まれる内容

特定のプロファイルに対して書き出されるデータに関しては、ストリーミング API 宛先へのデータ書き出しを決定する要素、および書き出しに含まれるデータという 2 つの異なる概念を理解することが重要です。

宛先の書き出しを決定する要素 宛先の書き出しに含まれる内容
  • マッピングされた属性とセグメントは、宛先の書き出しのキューとして機能します。 つまり、マッピングされたセグメントが ( null から realized またはから realized から exiting) またはマッピングされた属性が更新されると、宛先の書き出しがキックオフされます。
  • ID マップの変更は、プロファイルの ID グラフ、書き出し用にマッピングされた ID 名前空間に対して追加／削除される ID として定義されます。
  • 属性の変更は、宛先にマッピングされている属性の場合、属性に対する更新として定義されます。
  • 宛先にマッピングされ、変更されたセグメントは、segmentMembership オブジェクトに含まれます。シナリオによっては、複数の呼び出しを使用して書き出される場合があります。また、シナリオによっては、変更されていない一部のセグメントも呼び出しに含まれる場合があります。いずれの場合も、マッピングされたセグメントのみが書き出されます。
  • 同じように、identityMap オブジェクトで宛先にマッピングされた名前空間からの ID もすべて含まれます。
  • マッピングされた属性のみが宛先の書き出しに含まれます。
重要

ストリーミング API の宛先は、プロファイルを宛先に対してアクティブ化する際に、バックフィルデータをストリーミングします。つまり、宛先へのアクティベーションワークフローを設定した後の最初のデータの書き出しには、セグメントが宛先にマッピングされる前にアクティブ化されたセグメントに適合したプロファイルが含まれます。

例えば、ストリーミングの宛先に対するこのデータフローについて考えてみましょう。ここでは、3 つのセグメントがデータフローで選択されます。

ストリーミングの宛先のデータフロー

宛先へのプロファイルの書き出しは、3 つのマッピングされたセグメントのいずれかに適合またはいずれかを離脱するプロファイルによって決定されます。プロファイルが「デロリアンを保有している顧客」セグメントに適合している場合、これにより書き出しがトリガーされます。その他のセグメント (市区町村 — ダラス および 基本サイトアクティブ) は、プロファイルに、考えられるステータス (realized または exited) をクリックします。 マッピングされていないセグメント（「SF ファン」など）は書き出されません。

プロファイル属性の観点から、上記でマッピングされた 3 つの属性を変更すると、書き出し先が決定します。

バッチ（ファイルベース）の宛先

Experience Platform のファイルベースの宛先にプロファイルを書き出す場合、3 種類のスケジュール（以下に示す）と 2 つのファイル書き出しオプション（完全ファイルまたは増分ファイル）を使用できます。複数のセグメントが単一の宛先データフローにマッピングされている場合でも、これらの設定はすべてセグメントレベルで設定されます。

  • スケジュールされた書き出し：宛先を設定し、1 つ以上のセグメントを追加し、完全ファイルまたは増分ファイルを書き出すかどうかを選択し、ファイルを書き出す時刻を毎日または 1 日に数回選択します。例えば、書き出し時間が午後 5 時の場合、そのセグメントに適合するプロファイルはすべて午後 5 時に書き出されます。
  • セグメント評価後：書き出しは、毎日のセグメント評価ジョブが実行された直後にトリガーされます。つまり、ファイルに書き出されたプロファイルの数は、セグメントの最新の評価済み母集団にできる限り近くなります。
  • オンデマンド書き出し（ファイルを今すぐ書き出し）：最新のセグメント評価ジョブに基づき、定期的にスケジュールされた書き出しに加えて、完全なファイルが 1 回書き出されます。

上記の書き出し状況のいずれにおいても、書き出し対象の XDM 属性として選択した列と共に、書き出しに適合したプロファイルが書き出しファイルに含まれます。

ヒント

ストリーミングセグメントがバッチ宛先にマッピングされると、書き出されたファイル内のプロファイル数がセグメント内のユーザー数に近づく可能性が高くなります。これは、最新のセグメント評価が書き出し時間により近く実行された可能性が高いからです。

増分ファイルの書き出し

プロファイルのすべてのアップデートが、プロファイルを増分ファイルの書き出しに含めることに適合しているわけではありません。例えば、属性がプロファイルに追加またはプロファイルから削除された場合、そのプロファイルは書き出しに含まれません。書き出されたファイルには、segmentMembership 属性が変更されたプロファイルのみが含まれます。つまり、プロファイルがセグメントの一部になるか、セグメントから削除された場合にのみ、増分ファイルの書き出しに含まれます。

同様に、新しい ID（新しいメールアドレス、電話番号、ECID など）が ID グラフのプロファイルに追加された場合、そのプロファイルを新しい増分ファイルの書き出しに含める理由にはなりません。

新しいセグメントが宛先マッピングに追加されても、別のセグメントの選定および書き出しには影響しません。書き出しスケジュールはセグメントごとに個別に設定され、セグメントが同じ宛先データフローに追加されている場合でも、ファイルはセグメントごとに個別に書き出されます。

例えば、以下の図の書き出し設定では、セグメントが増分ファイルのアップデートを書き出している場合、プロファイルが増分ファイルの書き出しに含まれているかどうかに関係なく、次の状況に注意してください。

複数の属性を選択した設定の書き出し。

  • プロファイルは、セグメントに適合または不適合な場合、増分ファイルの書き出しに含まれます。
  • 新しい電話番号が ID グラフに追加されると、プロファイルは増分ファイルの書き出しに含まれま​せん。
  • xdm: loyalty.points、xdm: loyalty.tier、xdm: personalEmail.address などのマッピングされた XDM フィールドのいずれかの値がプロファイルで更新された場合、プロファイルは増分ファイルの書き出しに含まれま​せん。
  • segmentMembership.status XDM フィールドが宛先アクティベーションワークフローでマッピングされると、セグメントを終了するプロファイルも書き出された増分ファイルに含まれ、exited ステータスになります。

データの書き出しを決定する要素と、書き出しに含まれる内容

上記の節の情報に基づいて、ファイルベースの宛先へのプロファイルの書き出し動作は、次のように要約できます。

ファイル全体の書き出し

セグメントのアクティブな母集団全体が毎日書き出されます。

宛先の書き出しを決定する要素 書き出されたファイルに含まれる内容
完全ファイル書き出しでは、最新のセグメント評価に基づいて、セグメントのアクティブなプロファイル母集団全体が各ファイル書き出しに含まれます。書き出し用に選択された各 XDM 属性の最新の値も、各ファイルの列として含まれます。なお、離脱済みステータスのプロファイルはファイルの書き出しには含まれません。

増分ファイルの書き出し

アクティベーションワークフローを設定した後の最初のファイルの書き出しでは、セグメントの母集団全体が書き出されます。以降の書き出しでは、変更されたプロファイルのみが書き出されます。

宛先の書き出しを決定する要素 書き出されたファイルに含まれる内容
  • UI または API で設定された書き出しスケジュールによって、宛先の書き出しの開始が決定します。
  • プロファイルのセグメントメンバーシップを変更しても、セグメントの選定か選定解除に関係なく、増分書き出しに含まれるプロファイルが適合されます。 プロファイルの属性または ID マップを変更しても、増分書き出しに含まれるプロファイルが適合されること​はありません。

セグメントメンバーシップが変更されたプロファイルと、書き出し用に選択された各 XDM 属性の最新情報。

segmentMembership.status XDM フィールドがマッピングステップで選択されている場合、離脱済みステータスのプロファイルは宛先の書き出しに含まれます。
ヒント

プロファイルの属性値または ID マップを変更しても、増分ファイルの書き出しに含まれるプロファイルが適合されることはありません。

次の手順

このドキュメントを参照すると、ストリーミング宛先、エンタープライズ宛先およびファイルベースの宛先へのプロファイルの書き出しで表示される内容がわかります。

次に、アクティベーションワークフローでどのように ID が処理されるかについて説明します。

このページ