[ベータ版]{class="badge informative"}

Experience Platform Data Mirrorに関する検討事項

この記事では、Data Mirror データセットを設定する際に考慮すべき要素について説明します。

ソーステーブルへの新しい列

CDC対応データミラーデータセットのソーステーブルに新しい列が追加されると、その変更により、既存のすべての行の更新がトリガーされる可能性があります。 これらの更新は、次のようなCDCを通じて変更として処理されます。

ソーステーブルの列に推奨される戦略：

新しい列を追加する場合は、遡及的なバックフィルが必要かどうかに応じて、次の2つのオプションがあります。

この戦略：

Privacy Service

プライバシー要求は、データの構造化の方法に関係ないため、今日は非関係スキーマに対してプライバシー要求が処理されるのと同じ方法で処理する必要があります。

外部リレーショナルスキーマからミラーリングされたデータは、Adobe エコシステムの一部となり、Customer Journey Analytics Audience Publishingを通じてエコシステム全体で共有できます。 プライバシーリクエストを送信すると、Adobe エコシステム全体でIDと関連データが適切に処理されます。

したがって、プライバシー要求はミラーリングされたデータセットに限定するのではなく、外部データベース内のソースデータの更新も含める必要があります。

衛生行動

ハイジーンサービスは​ プライマリ ID ​で動作しますが、ミラー化された外部データベース内のテーブルには、プライマリ IDではなく​ プライマリキー ​が含まれています。

プライマリ IDとプライマリ キーの違いの結果は、ハイジーン削除をこれらのリレーショナル テーブルに対して直接実行できないことです。 その結果、次のことが必要になります。

プライマリ IDとプライマリ キーの違いは、共有の責任モデルを導入します。

ガバナンスの違い

XDM ​ スキーマ ​と​ フィールドグループ ​などの基本概念では、フィールドグループ内の定義された​ フィールド ​が、フィールドグループが使用されるすべてのデータセットにラベルを反映します。 例えば、フィールドグループ identitiesの電子メールフィールド emailIDは、フィールドグループ identitiesが使用されているすべてのデータセットで同じラベルが付けられます。

リレーショナルスキーマでは、列名は独立しています。 テーブル customersのemailという名前の列は、テーブル prospectsのemailという名前の列とは独立しており、異なります。 この動作は、ラベル（DULE使用ラベルやポリシーなど）をミラーデータセットのフィールドに個別に適用する必要があることを意味します。 上記の例に基づいて、customers データセットのemail フィールドとprospects データセットのemail フィールドの両方にラベルを適用する必要があります。

ガバナンスの違いは、次のような影響を与えます。

ステッチ

関係スキーマには、ステッチに関連する次の考慮事項があります。

システムキーとフィールド

システムキーとフィールドには、次の考慮事項が適用されます。