Experience Platform には複数の宛先タイプがあります(下図を参照)。 これらの宛先は、後の節で説明するように、宛先の書き出しをトリガーするものと書き出しに含まれる内容に関して、書き出しパターンが少し異なります。
このドキュメントページでは、図の下部でハイライト表示されている接続の場合のプロファイル書き出し動作についてのみ説明します。
宛先タイプごとの具体的な情報に立ち入る前に、ストリーミング宛先のマイクロバッチ処理と集計ポリシーの概念を理解しておくことが重要です。
Experience Platform の宛先では、データを HTTPS 呼び出しとして API ベースの統合機能に書き出します。バッチ取り込み、ストリーミング取り込み、バッチセグメント化、ストリーミングセグメント化または ID グラフの変更の結果、プロファイルが更新されたことを宛先サービスが他のアップストリームサービスから通知されると、データが書き出され、ストリーミング宛先に送信されます。
プロファイルを HTTPS メッセージに集計してから宛先 API エンドポイントにディスパッチするプロセスをマイクロバッチ処理と呼びます。
設定可能な集計ポリシーを持つ Facebook 宛先を例に取ります。データは集計されて送信されます。この場合、宛先サービスは、プロファイルサービスアップストリームから受信するすべてのデータを取得し、それを次のいずれかで集計してから Facebook にディスパッチします。
上記のしきい値のいずれかに初めて達したときに、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 エンドポイントにデータを書き出すためにのみ、エンタープライズ宛先へのプロファイル書き出し動作を最適化します。 プロファイルは、次の状況で宛先に書き出されます。
上記のすべての場合で、適切な更新が行われたプロファイルのみが宛先に書き出されます。例えば、宛先フローにマッピングされたセグメントに 100 人のメンバーがいて、5 つの新しいプロファイルがセグメントに適合している場合、宛先への書き出しは増分で行われ、5 つの新しいプロファイルのみが含まれます。
プロファイルについては、変更箇所に関わらず、マッピングされたすべての属性が書き出されることに注意してください。 したがって、上の例では、属性自体が変更されていない場合でも、これら 5 つの新しいプロファイルに対してマッピングされた属性がすべて書き出されます。
特定のプロファイルについて書き出されるデータに関しては、エンタープライズ宛先へのデータ書き出しを決定する要因と書き出しに含まれるデータという 2 つの異なる概念を理解しておくことが重要です。
宛先の書き出しを決定する要素 | 宛先の書き出しに含まれる内容 |
---|---|
|
|
エンタープライズ宛先は、プロファイルを宛先に対してアクティブ化する際に、バックフィルデータをストリーミングします。つまり、宛先へのアクティベーションワークフローを設定した後の最初のデータの書き出しには、セグメントが宛先にマッピングされる前にアクティブ化されたセグメントに適合したプロファイルが含まれます。
例えば、HTTP 宛先に対するこのデータフローについて考えてみましょう。ここでは、3 つのセグメントがデータフローで選択され、4 つの属性が宛先にマッピングされます。
宛先へのプロファイルの書き出しは、3 つのマッピングされたセグメントのいずれかに適合またはいずれかを離脱するプロファイルによって決定されます。ただし、データの書き出しでは、segmentMembership
オブジェクトで、その特定のプロファイルがメンバーであり、書き出しをトリガーしたセグメントと同じ結合ポリシーを共有している場合、マッピングされていない他のセグメントが表示されることがあります。プロファイルが「デロリアンを保有している顧客」セグメントに適合すると同時に「映画『バック トゥ ザ フューチャー』を視聴済み」セグメントと「SF ファン」セグメントのメンバーでもある場合、他の 2 つのセグメントも(データフローでマッピングされていない場合であっても)データ書き出しの segmentMembership
オブジェクトに表示されます(「デロリアンを保有している顧客」セグメントと同じ結合ポリシーを共有している場合)。
プロファイル属性の観点から、上記でマッピングした 4 つの属性に対する変更によって、書き出しの宛先が決定し、プロファイルに存在する 4 つのマッピング済み属性のいずれかがデータ書き出しに表示されます。
Amazon Kinesis、Azure Event Hubs および HTTP API の宛先ドキュメントページで、様々なエンタープライズ宛先に書き出されたデータの例を確認できます。
Facebook、Trade Desk およびその他の API ベースの統合などのストリーミング宛先のプロファイルの書き出しの動作は、上記のエンタープライズ宛先の動作と非常によく似ています。
ストリーミング宛先の例としては、カタログのソーシャルカテゴリと広告カテゴリに属する宛先があります。
Experience Platform は、セグメントの選定または他の重要なイベントに続いてプロファイルに関連する更新が発生した際にストリーミング API ベースの宛先へデータを書き出すためにのみ、ストリーミング宛先へのプロファイルの書き出し動作を最適化します。 プロファイルは、次の状況で宛先に書き出されます。
上記のすべての場合で、適切な更新が行われたプロファイルのみが宛先に書き出されます。例えば、宛先フローにマッピングされたセグメントに 100 人のメンバーがいて、5 つの新しいプロファイルがセグメントに適合している場合、宛先への書き出しは増分で行われ、5 つの新しいプロファイルのみが含まれます。
プロファイルについては、変更箇所に関わらず、マッピングされたすべての属性が書き出されることに注意してください。 したがって、上の例では、属性自体が変更されていない場合でも、これら 5 つの新しいプロファイルに対してマッピングされた属性がすべて書き出されます。
特定のプロファイルに対して書き出されるデータに関しては、ストリーミング API 宛先へのデータ書き出しを決定する要素、および書き出しに含まれるデータという 2 つの異なる概念を理解することが重要です。
宛先の書き出しを決定する要素 | 宛先の書き出しに含まれる内容 |
---|---|
|
|
ストリーミング API の宛先は、プロファイルを宛先に対してアクティブ化する際に、バックフィルデータをストリーミングします。つまり、宛先へのアクティベーションワークフローを設定した後の最初のデータの書き出しには、セグメントが宛先にマッピングされる前にアクティブ化されたセグメントに適合したプロファイルが含まれます。
例えば、ストリーミングの宛先に対するこのデータフローについて考えてみましょう。ここでは、3 つのセグメントがデータフローで選択されます。
宛先へのプロファイルの書き出しは、3 つのマッピングされたセグメントのいずれかに適合またはいずれかを離脱するプロファイルによって決定されます。プロファイルが「デロリアンを保有している顧客」セグメントに適合している場合、これにより書き出しがトリガーされます。その他のセグメント (市区町村 — ダラス および 基本サイトアクティブ) は、プロファイルに、考えられるステータス (realized
または exited
) をクリックします。 マッピングされていないセグメント(「SF ファン」など)は書き出されません。
プロファイル属性の観点から、上記でマッピングされた 3 つの属性を変更すると、書き出し先が決定します。
Experience Platform のファイルベースの宛先にプロファイルを書き出す場合、3 種類のスケジュール(以下に示す)と 2 つのファイル書き出しオプション(完全ファイルまたは増分ファイル)を使用できます。複数のセグメントが単一の宛先データフローにマッピングされている場合でも、これらの設定はすべてセグメントレベルで設定されます。
上記の書き出し状況のいずれにおいても、書き出し対象の XDM 属性として選択した列と共に、書き出しに適合したプロファイルが書き出しファイルに含まれます。
ストリーミングセグメントがバッチ宛先にマッピングされると、書き出されたファイル内のプロファイル数がセグメント内のユーザー数に近づく可能性が高くなります。これは、最新のセグメント評価が書き出し時間により近く実行された可能性が高いからです。
プロファイルのすべてのアップデートが、プロファイルを増分ファイルの書き出しに含めることに適合しているわけではありません。例えば、属性がプロファイルに追加またはプロファイルから削除された場合、そのプロファイルは書き出しに含まれません。書き出されたファイルには、segmentMembership
属性が変更されたプロファイルのみが含まれます。つまり、プロファイルがセグメントの一部になるか、セグメントから削除された場合にのみ、増分ファイルの書き出しに含まれます。
同様に、新しい ID(新しいメールアドレス、電話番号、ECID など)が ID グラフのプロファイルに追加された場合、そのプロファイルを新しい増分ファイルの書き出しに含める理由にはなりません。
新しいセグメントが宛先マッピングに追加されても、別のセグメントの選定および書き出しには影響しません。書き出しスケジュールはセグメントごとに個別に設定され、セグメントが同じ宛先データフローに追加されている場合でも、ファイルはセグメントごとに個別に書き出されます。
例えば、以下の図の書き出し設定では、セグメントが増分ファイルのアップデートを書き出している場合、プロファイルが増分ファイルの書き出しに含まれているかどうかに関係なく、次の状況に注意してください。
xdm: loyalty.points
、xdm: loyalty.tier
、xdm: personalEmail.address
などのマッピングされた XDM フィールドのいずれかの値がプロファイルで更新された場合、プロファイルは増分ファイルの書き出しに含まれません。segmentMembership.status
XDM フィールドが宛先アクティベーションワークフローでマッピングされると、セグメントを終了するプロファイルも書き出された増分ファイルに含まれ、exited
ステータスになります。上記の節の情報に基づいて、ファイルベースの宛先へのプロファイルの書き出し動作は、次のように要約できます。
ファイル全体の書き出し
セグメントのアクティブな母集団全体が毎日書き出されます。
宛先の書き出しを決定する要素 | 書き出されたファイルに含まれる内容 |
---|---|
|
完全ファイル書き出しでは、最新のセグメント評価に基づいて、セグメントのアクティブなプロファイル母集団全体が各ファイル書き出しに含まれます。書き出し用に選択された各 XDM 属性の最新の値も、各ファイルの列として含まれます。なお、離脱済みステータスのプロファイルはファイルの書き出しには含まれません。 |
増分ファイルの書き出し
アクティベーションワークフローを設定した後の最初のファイルの書き出しでは、セグメントの母集団全体が書き出されます。以降の書き出しでは、変更されたプロファイルのみが書き出されます。
宛先の書き出しを決定する要素 | 書き出されたファイルに含まれる内容 |
---|---|
|
セグメントメンバーシップが変更されたプロファイルと、書き出し用に選択された各 XDM 属性の最新情報。
|
プロファイルの属性値または ID マップを変更しても、増分ファイルの書き出しに含まれるプロファイルが適合されることはありません。
このドキュメントを参照すると、ストリーミング宛先、エンタープライズ宛先およびファイルベースの宛先へのプロファイルの書き出しで表示される内容がわかります。
次に、アクティベーションワークフローでどのように ID が処理されるかについて説明します。