Experience Platform には複数の宛先タイプがあります(下図を参照)。これらの宛先は、後の節で説明するように、宛先の書き出しをトリガーするものと書き出しに含まれる内容に関して、書き出しパターンが少し異なります。
このドキュメントページでは、図の下部でハイライト表示されている接続の場合のプロファイル書き出し動作についてのみ説明します。
宛先タイプごとの特定の情報を調べる前に、次のメッセージを集計する概念を理解しておくことが重要です。 ストリーミングの宛先.
Experience Platform の宛先では、データを HTTPS 呼び出しとして API ベースの統合機能に書き出します。バッチ取り込み、ストリーミング取り込み、バッチセグメント化、ストリーミングセグメント化または ID グラフの変更の結果、プロファイルが更新されたことを宛先サービスが他のアップストリームサービスから通知されると、データが書き出され、ストリーミング宛先に送信されます。
プロファイルは、宛先 API エンドポイントにディスパッチされる前に、HTTPS メッセージに集計されます。
例えば、設定可能な集計ポリシーを持つ Facebook 宛先の場合、データは、集計されて送信されますが、その際に、宛先サービスは、プロファイルサービスアップストリームから受信するすべてのデータを取得し、それを以下のいずれかで集計してから、Facebook にディスパッチします。
上記のしきい値のいずれかに初めて達したときに、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 のドキュメントで集計ポリシーを参照してください。
エンタープライズ宛先を使用できるのは、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 が処理されるかについて説明します。