様々な宛先タイプのプロファイル書き出し動作
Experience Platform には複数の宛先タイプがあります（下図を参照）。これらの宛先は、後の節で説明するように、宛先の書き出しをトリガーするものと書き出しに含まれる内容に関して、書き出しパターンが少し異なります。
ストリーミング宛先でのメッセージの集計
宛先タイプごとの特定の情報を調べる前に、次のメッセージを集計する概念を理解しておくことが重要です。 ストリーミングの宛先.
Experience Platform の宛先では、データを HTTPS 呼び出しとして API ベースの統合機能に書き出します。バッチ取り込み、ストリーミング取り込み、バッチセグメント化、ストリーミングセグメント化または ID グラフの変更の結果、プロファイルが更新されたことを宛先サービスが他のアップストリームサービスから通知されると、データが書き出され、ストリーミング宛先に送信されます。
プロファイルは、宛先 API エンドポイントにディスパッチされる前に、HTTPS メッセージに集計されます。
例えば、設定可能な集計 ポリシーを持つ Facebook 宛先の場合、データは、集計されて送信されますが、その際に、宛先サービスは、プロファイルサービスアップストリームから受信するすべてのデータを取得し、それを以下のいずれかで集計してから、Facebook にディスパッチします。
- レコード数（最大 10,000 件）または
- 時間枠の間隔（300 秒）
上記のしきい値のいずれかに初めて達したときに、Facebook への書き出しがトリガーされます。そのため、Facebook Custom Audiences ダッシュボードには、Experience Platform からオーディエンスが 10,000 件の増分で取り込まれることがあります。データの処理と集計が 300 秒の書き出し間隔よりも高速におこなわれ、送信も高速になるので、2 ～ 3 分ごとに 10,000 件のレコードが表示される場合があります。つまり、すべてのレコードが処理されるまで、約 2 ～ 3 分ごとにです。 10,000 件から成るバッチを構成できるだけの十分なレコードがない場合は、期間のしきい値に達した時点で現在のレコード数がそのまま送信されます。これにより、より小さなバッチが Facebook に送信される場合もあります。
別の例として、HTTP API 宛先について考えます。この場合は、ベストエフォート集計 ポリシーと maxUsersPerRequest: 10 の条件が適用されます。つまり、最大 10 個のプロファイルが集計されてから、この宛先に対する HTTP 呼び出しが実行されます。ただし、Experience Platform は、更新された再評価情報を宛先サービスがアップストリームサービスから受け取るとすぐに、宛先へのプロファイルのディスパッチを試みます。
集計ポリシーは設定可能で、宛先の開発者が、API エンドポイントのダウンストリームでのレート制限に最もよく合うように集計ポリシーを設定する方法を決定できます。詳しくは、Destination SDK のドキュメントで集計ポリシーを参照してください。
ストリーミングプロファイル書き出し宛先（エンタープライズ宛先） streaming-profile-destinations
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 つのマッピング済み属性のいずれかがデータ書き出しに表示されます。
ストリーミング API ベースの宛先 streaming-api-based-destinations
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 もすべて含まれます。 - マッピングされた属性のみが宛先の書き出しに含まれます。
例えば、ストリーミングの宛先に対するこのデータフローについて考えてみましょう。ここでは、3 つのオーディエンスがデータフローで選択されます。
宛先へのプロファイルの書き出しは、3 つのマッピングされたセグメントのいずれかに適合またはいずれかを離脱するプロファイルによって決定されます。プロファイルが「デロリアンを保有している顧客」セグメントに適合している場合、これにより書き出しがトリガーされます。その他のオーディエンス（市区町村 - ダラス および 基本サイトアクティブ）は、考えられるいずれかのステータス（realized または exited）でそのオーディエンスがプロファイルに存在する場合に、同様に書き出される可能性があります。マッピングされていないオーディエンス（「SF ファン」など）は書き出されません。
プロファイル属性の観点から、上記でマッピングされた 3 つの属性を変更すると、書き出し先が決定します。
バッチ（ファイルベース）の宛先 file-based-destinations
Experience Platform のファイルベースの宛先にプロファイルを書き出す場合、3 種類のスケジュール（以下に示す）と 2 つのファイル書き出しオプション（完全ファイルまたは増分ファイル）を使用できます。複数のオーディエンスが単一の宛先データフローにマッピングされている場合でも、これらの設定はすべてオーディエンスレベルで設定されます。
- スケジュールされた書き出し：宛先を設定し、1 つ以上のセグメントを追加し、完全ファイルまたは増分ファイルを書き出すかどうかを選択し、ファイルを書き出す時刻を毎日または 1 日に数回選択します。例えば、書き出し時間が午後 5 時の場合、そのオーディエンスに適合するプロファイルはすべて午後 5 時に書き出されます。
- セグメント評価後：書き出しは、毎日のオーディエンス評価ジョブが実行された直後にトリガーされます。つまり、ファイルに書き出されたプロファイルの数は、セグメントの最新の評価済み母集団にできる限り近くなります。
- オンデマンド書き出し（ファイルを今すぐ書き出し）：最新のオーディエンス評価ジョブに基づき、定期的にスケジュールされた書き出しに加えて、完全なファイルが 1 回書き出されます。
上記の書き出し状況のいずれにおいても、書き出し対象の XDM 属性として選択した列と共に、書き出しに適合したプロファイルが書き出しファイルに含まれます。
増分ファイルの書き出し incremental-file-exports
プロファイルのすべてのアップデートが、プロファイルを増分ファイルの書き出しに含めることに適合しているわけではありません。例えば、属性がプロファイルに追加またはプロファイルから削除された場合、そのプロファイルは書き出しに含まれません。書き出されたファイルには、segmentMembership 属性が変更されたプロファイルのみが含まれます。つまり、プロファイルがオーディエンスの一部になるか、オーディエンスから削除された場合にのみ、増分ファイルの書き出しに含まれます。
同様に、新しい ID（新しいメールアドレス、電話番号、ECID など）が ID グラフのプロファイルに追加された場合、そのプロファイルを新しい増分ファイルの書き出しに含める理由にはなりません。
新しいオーディエンスが宛先マッピングに追加されても、別のセグメントの選定および書き出しには影響しません。書き出しスケジュールはオーディエンスごとに個別に設定され、オーディエンスが同じ宛先データフローに追加されている場合でも、ファイルはセグメントごとに個別に書き出されます。
例えば、以下に示す書き出し設定では、オーディエンスが増分ファイルのアップデートを書き出していますが、プロファイルが増分ファイルの書き出しに含まれているかどうかに関係なく、次の状況に注意してください。
- プロファイルは、セグメントに適合または不適合な場合、増分ファイルの書き出しに含まれます。
- 新しい電話番号が ID グラフに追加されると、プロファイルは増分ファイルの書き出しに含まれま せん。
xdm: loyalty.points、xdm: loyalty.tier、xdm: personalEmail.addressなどのマッピングされた XDM フィールドのいずれかの値がプロファイルで更新された場合、プロファイルは増分ファイルの書き出しに含まれま せん。segmentMembership.statusXDM フィールドが宛先アクティベーションワークフローでマッピングされると、オーディエンスを終了するプロファイルも書き出された増分ファイルに含まれ、exitedステータスになります。
データの書き出しを決定する要素と、書き出しに含まれる内容
上記の節の情報に基づいて、ファイルベースの宛先へのプロファイルの書き出し動作は、以下のように要約できます。
ファイル全体の書き出し
オーディエンスのアクティブな母集団全体が毎日書き出されます。
- UI または API で設定された書き出しスケジュールとユーザーアクション（UI で「ファイルを今すぐ書き出し」を選択するか、アドホックアクティベーション API を使用すること）によって、宛先の書き出しの開始が決定します。
増分ファイルの書き出し
アクティベーションワークフローを設定した後の最初のファイルの書き出しでは、オーディエンスの母集団全体が書き出されます。以降の書き出しでは、変更されたプロファイルのみが書き出されます。
- UI または API で設定された書き出しスケジュールによって、宛先の書き出しの開始が決定します。
- プロファイルのオーディエンスメンバーシップを変更した場合、その変更がセグメントに適格か不適格かに関係なく、そのプロファイルを増分書き出しに含めることができます。プロファイルの属性または ID マップを変更しても、増分書き出しに含まれるプロファイルが選定されることは ありません。
オーディエンスメンバーシップが変更されたプロファイルと、書き出し用に選択された各 XDM 属性の最新情報。
segmentMembership.status XDM フィールドがマッピングステップで選択されている場合、離脱済みステータスのプロファイルは宛先の書き出しに含まれます。
次の手順 next-steps
このドキュメントでは、ストリーミング宛先、エンタープライズ宛先およびファイルベースの宛先へのプロファイルの書き出しで表示される内容を確認しました。
次に、アクティベーションワークフローでどのように ID が処理されるかについて説明します。