のデフォルトのガードレール Real-time Customer Profile データ

Adobe Experience Platformでは、行動インサイトと顧客属性に基づいて、リアルタイム顧客プロファイルの形式で、パーソナライズされたクロスチャネルエクスペリエンスを提供できます。 プロファイルに対するこの新しいアプローチをサポートするために、Experience Platform では、従来のリレーショナルデータモデルとは異なる、高度に非正規化されたハイブリッドデータモデルを使用します。

このドキュメントでは、最適なシステムパフォーマンスを得るためにプロファイルデータをモデル化する際に役立つ、デフォルトの使用方法とレートの制限について説明します。次のガードレールを確認する際は、データが正しくモデル化されていることが前提になっています。データのモデル化方法に関するご質問は、カスタマーサービス担当者にお問い合わせください。

メモ

ほとんどのお客様は、これらのデフォルトの上限を超えることはありません。カスタムの上限について詳しくは、カスタマーケア担当者にお問い合わせください。

はじめに

次のExperience Platformサービスは、リアルタイム顧客プロファイルデータのモデリングに関係します。

  • Real-time Customer Profile:複数のソースのデータを使用して、統合された消費者プロファイルを作成します。
  • ID:Platform に取り込まれる際に、異なるデータソースから ID をブリッジします。
  • スキーマ:エクスペリエンスデータモデル (XDM) スキーマは、Platform が顧客体験データを整理する際に使用する標準化されたフレームワークです。
  • セグメント:Platform 内のセグメント化エンジンは、顧客の行動と属性に基づいて顧客プロファイルからセグメントを作成するために使用されます。

上限のタイプ

このドキュメントでは、次の 2 種類のデフォルトの上限について説明します。

  • ソフトリミット:​ソフトリミットを超えることは可能ですが、ソフトリミットはシステムのパフォーマンスに推奨されるガイドラインです。

  • ハードリミット: ハードリミットは絶対最大値を示します。

メモ

このドキュメントで概要を説明する上限は、常に改善されています。 定期的にアップデートを確認してください。カスタムの上限について知りたい場合は、カスタマーケア担当者にお問い合わせください。

データモデルの上限

次のガードレールは、リアルタイム顧客プロファイルデータをモデル化する際の推奨の上限を提供します。プライマリエンティティとディメンションエンティティについて詳しくは、付録のエンティティタイプ に関する節を参照してください。

プライマリエンティティのガードレール

ガードレール 上限 上限のタイプ 説明
XDM Individual Profile クラスデータセット 20 ソフト XDM Individual Profile クラスを利用する最大 20 個のデータセットを使用することをお勧めします。
XDM ExperienceEvent クラスデータセット 20 ソフト XDM ExperienceEvent クラスを利用するデータセットは、最大 20 個までにすることをお勧めします。
プロファイルに対して有効化されたAdobe Analyticsレポートスイートデータセット 1 ソフト プロファイルに対して有効にする Analytics レポートスイートデータセットは最大 1 つまでです。 プロファイルに対して複数の Analytics レポートスイートデータセットを有効にしようとすると、データ品質に意図しない結果が生じる可能性があります。 詳しくは、 Adobe Analyticsデータセット 付録の
複数エンティティの関係 5 ソフト プライマリエンティティとディメンションエンティティの間に定義されるマルチエンティティの関係は、最大 5 個を推奨します。既存の関係が削除されるか無効になるまで、追加の関係マッピングは行わないでください。
マルチエンティティ関係で使用される ID フィールドの JSON 深さ 4 ソフト 複数エンティティの関係で使用する ID フィールドの JSON の深さの推奨値は 4 です。 つまり、高度にネストされたスキーマでは、4 レベルを超える深さでネストされたフィールドは、関係の ID フィールドとして使用しないでください。
プロファイルフラグメント内の配列の基数 <=500 ソフト プロファイルフラグメントの最適な配列の基数(時間に依存しないデータ)は 500 未満です。
ExperienceEvent の配列基数 <=10 ソフト ExperienceEvent(時系列データ)の最適な配列の基数は 10 未満です。
個々のプロファイル ID グラフの ID 数 50 ハード 個々のプロファイルの ID グラフの ID の最大数は 50 です。 ID が 50 を超えるプロファイルは、セグメント化、エクスポート、検索から除外されます。

ディメンションエンティティのガードレール

ガードレール 上限 上限のタイプ 説明
非に対して時系列データは許可されていませんXDM Individual Profile エンティティ 0 ハード 時系列データは、非に対しては許可されていませんXDM Individual Profile エンティティを作成します。 時系列データセットがXDM Individual Profile ID。データセットを有効にしないでください Profile.
ネストされた関係なし 0 ソフト 2 つの非 XDM Individual Profile スキーマ間に関係を作成しないでください。Profile 結合スキーマの一部ではないスキーマでは、関係を作成する機能は推奨されません。
プライマリ ID フィールドの JSON 深さ 4 ソフト プライマリ ID フィールドに推奨される JSON の深さの上限は 4 です。 つまり、高度にネストされたスキーマでは、フィールドが 4 レベルを超える深さでネストされている場合、フィールドをプライマリ ID として選択しないでください。 ネストされた 4 番目のレベルにあるフィールドは、プライマリ ID として使用できます。

データサイズの上限

次のガードレールは、データサイズを参照し、意図したとおりに取り込み、保存し、クエリできるデータの推奨される上限を提供します。プライマリエンティティとディメンションエンティティについて詳しくは、付録のエンティティタイプに関する節を参照してください。

メモ

データサイズは、取得時に JSON で非圧縮データとして測定されます。

プライマリエンティティのガードレール

ガードレール 上限 上限のタイプ 説明
ExperienceEvent の最大サイズ 10 KB ハード イベントの最大サイズは 10 KB です。 取り込みは続行されますが、10 KB を超えるイベントは削除されます。
最大プロファイルレコードサイズ 100 KB ハード プロファイルレコードの最大サイズは 100 KB です。 取り込みは続行されますが、100 KB を超えるプロファイルレコードは削除されます。
最大プロファイルフラグメントサイズ 50 MB ハード 1 つのプロファイルフラグメントの最大サイズは 50 MB です。 セグメント化、エクスポート、参照は、 プロファイルフラグメント が 50 MB を超える場合にのみ有効です。
最大プロファイルストレージサイズ 50 MB ソフト 保存されるプロファイルの最大サイズは 50 MB です。 新規の追加 プロファイルフラグメント を 50 MB を超えるプロファイルに追加すると、システムのパフォーマンスに影響します。 例えば、50MB の単一のフラグメントをプロファイルに含めたり、合計サイズが 50MB の複数のデータセットをまたいで複数のフラグメントを含めたりできます。 50MB を超える単一のフラグメントを持つプロファイル、または合計サイズが 50MB を超える複数のフラグメントを保存しようとすると、システムのパフォーマンスに影響します。
1 日に取り込まれたプロファイルまたは ExperienceEvent バッチの数 90 ソフト 1 日に取り込まれるプロファイルまたは ExperienceEvent バッチの最大数は 90 です。 つまり、1 日に取り込まれるプロファイルバッチと ExperienceEvent バッチの合計数の合計は 90 を超えてはなりません。 追加のバッチを取り込むと、システムのパフォーマンスに影響します。

ディメンションエンティティのガードレール

ガードレール 上限 上限のタイプ 説明
すべてのディメンションエンティティの合計サイズ 5 GB ソフト すべてのディメンションエンティティの推奨合計サイズは 5 GB です。大きなディメンションエンティティの取り込みは、システムのパフォーマンスに影響を与える可能性があります。例えば、10 GB の製品カタログをディメンションエンティティとして読み込むことはお勧めしません。
ディメンショナルエンティティスキーマごとのデータセット 5 ソフト 各ディメンショナルエンティティスキーマに関連付けるデータセットの数は、最大で 5 個にすることをお勧めします。 例えば、「products」のスキーマを作成し、関連する 5 個のデータセットを追加する場合、products スキーマに関連付けられる 6 個目のデータセットを作成しないでください。
1 日に取り込まれるディメンションエンティティバッチ エンティティごとに 4 個 ソフト 1 日に取り込まれるディメンションエンティティバッチの推奨最大数は、エンティティあたり 4 個です。 例えば、製品カタログのアップデートを 1 日に最大 4 回取り込むことができます。同じエンティティに対して追加のディメンションエンティティバッチを取り込むと、システムのパフォーマンスに影響を与える可能性があります。

セグメンテーションガードレール

このセクションで概説するガードレールとは、Experience Platform 内に組織が作成できるセグメントの数と特性のほか、宛先に対して可能なセグメントのマッピングやアクティブ化のことを指します。

ガードレール 上限 上限のタイプ 説明
サンドボックスごとのセグメント 10,000 ソフト 組織は合計 10,000 個を超えるセグメントを持つことができます(各 サンドボックスのセグメント数が 10,000 個未満となっている必要があります)。 追加のセグメントを作成しようとすると、システムのパフォーマンスに影響を与える可能性があります。
サンドボックスごとのセグメントのストリーミング 500 ソフト 個々のサンドボックスに 500 個未満のストリーミングセグメントがある限り、組織は合計で 500 個を超えるストリーミングセグメントを持つことができます。 追加のストリーミングセグメントを作成しようとすると、システムのパフォーマンスに影響を与える可能性があります。
サンドボックスごとのバッチセグメント 10,000 ソフト 個々のサンドボックスに 10,000 個未満のバッチセグメントがある限り、組織は合計 10,000 個を超えるバッチセグメントを持つことができます。 追加のバッチセグメントを作成しようとすると、システムのパフォーマンスに影響を与える可能性があります。

付録

このセクションでは、このドキュメントに記載の上限に関する追加の詳細を示します。

エンティティタイプ

この Profile ストアデータモデルは、次の 2 つのコアエンティティタイプで構成されます。

  • プライマリエンティティ:​プライマリエンティティ、別称プロファイルエンティティは、データを結合して個人の「単一の信用できるソース」としたものです。 この統合データは、「結合ビュー」と呼ばれるものを使用して表されます。統合ビューは、同じクラスを実装するすべてのスキーマのフィールドを、1 つの結合スキーマに集約します。Real-time Customer Profile の結合スキーマは、すべてのプロファイル属性と行動イベントのコンテナとして機能する、非正規化されたハイブリッドデータモデルです。

    時間に依存しない属性(「レコードデータ」とも呼ばれる)は、XDM Individual Profile、時系列データ(「イベントデータ」とも呼ばれる)は XDM ExperienceEvent を使用してモデル化されます。レコードと時系列データが Adobe Experience Platform に取り込まれると、Real-time Customer Profile がトリガーされ、使用可能なデータの取り込みが開始されます。 取り込まれるインタラクションや詳細が多いほど、個人プロファイルは正確になります。

  • ディメンションエンティティ:​プロファイルデータを保持しているプロファイルデータストアはリレーショナルストアではありませんが、シンプルで直感的にセグメントを作成できるようにするために、プロファイルでは小さなディメンションエンティティとの統合が可能になっています。 この統合は、マルチエンティティセグメンテーションとも呼ばれます。組織では、店舗、製品、資産など、個人以外のものを記述する XDM クラスを定義することもできます。 これらの XDM Individual Profile 以外のスキーマは「ディメンションエンティティ」と呼ばれ、時系列データを含みません。 ディメンションエンティティは、複数エンティティのセグメント定義を支援および簡素化するルックアップデータを提供します。また、セグメントエンジンが、処理の最適化(高速ポイントルックアップ)のためにデータセット全体をメモリに読み込めるようディメンションエンティティのサイズは小さくする必要があります。

プロファイルフラグメント

このドキュメントでは、「プロファイルフラグメント」を参照するガードレールがいくつかあります。 Experience Platformでは、複数のプロファイルフラグメントが結合されて、リアルタイム顧客プロファイルが形成されます。 各フラグメントは、一意のプライマリ ID と、特定のデータセット内のその ID に対応するレコードまたはイベントデータを表します。 プロファイルフラグメントについて詳しくは、 プロファイルの概要.

結合ポリシー

複数のソースからデータを統合する場合、結合ポリシーは、データの優先順位付け方法と、統合ビューを作成するためにどのデータを組み合わせるかを決定する際に Platform が使用するルールです。 例えば、顧客が複数のチャネルをまたがって自社のブランドとやり取りを行う場合、1 人の顧客に関連する複数のプロファイルフラグメントが複数のデータセットに表示されます。これらのフラグメントが Platform に取り込まれると、それらのフラグメントが結合され、その顧客用に単一のプロファイルが作成されます。複数のソースのデータが競合する場合、結合ポリシーによって、個人のプロファイルに含める情報が決定されます。 結合ポリシーの詳細については、まず 結合ポリシーの概要.

Platform のAdobe Analyticsレポートスイートデータセット

プロファイルに対して最大 1 つのAdobe Analyticsレポートスイートデータセットを有効にする必要があります。 これはソフトリミットです。つまり、プロファイルに対して複数の Analytics データセットを有効にできますが、データに予期しない結果が生じる可能性があるので、お勧めしません。 これは、Experience Platformのデータのセマンティック構造を提供し、データ解釈の一貫性を保ち、Adobe Analyticsの eVar とコンバージョン変数のカスタマイズ可能な特性を可能にする、Experience Data Model(XDM) スキーマの違いが原因です。

例えば、Adobe Analyticsでは、1 つの組織に複数のレポートスイートがある場合があります。 レポートスイート A がeVar4 を「内部検索語句」と指定し、レポートスイート B がeVar4 を「参照ドメイン」と指定した場合、これらの値は共にプロファイルの同じフィールドに取り込まれ、混乱とデータ品質の低下を招きます。

このページ