ガードレールと制限 guardrails

このページ: オーケストレーションキャンペーンでのデータの保存、取り込み、データモデリング、アクティビティ、チャネルに適用されるガードレールと制限について説明します。

次に、オーケストレーションキャンペーンを使用する際のガードレールと制限を示します。

データフローの制限

データデザインとストレージ

  • 最大テーブル数 - リレーショナルデータストアは、最大 200 個のテーブル(スキーマ)をサポートします。

  • スキーマサイズ - オーケストレーションキャンペーンの場合、個々のスキーマの合計サイズは 100 GB を超えないようにします。

  • 1 日あたりの更新ボリューム - パフォーマンスと安定性を維持するために、スキーマの 1 日あたりの更新を、合計レコード数の 20%未満に制限する必要があります。

  • リレーショナルデータモデル - リレーショナルデータは、取り込み、データモデリング、セグメント化のユースケースでサポートされるプライマリモデルです。

  • ID フィールド - ターゲティングに使用されるスキーマには、定義済みの ID 名前空間にマッピングされた、少なくとも 1 つのタイプ String の ID フィールドを含める必要があります。

  • スキーマあたりの属性 - 管理性とパフォーマンスを維持するために、スキーマあたりの属性の平均数は 50 列を超えないようにしてください。

  • プロファイルの有効化 - Adobe Experience Platform プロファイルでは、リレーショナルスキーマを有効にできません。 Adobe Experience Platform プロファイルでは、標準 XDM スキーマのみがサポートされています。 リレーショナルスキーマは、オーケストレーションキャンペーンまたはアクションキャンペーンに対して有効にできます。 詳細情報

データ取り込み data-ingestion

  • プロファイルとリレーショナルの取り込み - プロファイル + リレーショナルデータ取り込みが必要です。

  • 変更データキャプチャソース - すべての取り込みは、変更データキャプチャソースを通じて行う必要があります。

    • ファイルベースのソース - _change_request_type フィールドは必須です。 サポートされている値は、u(アップサート)または d(削除)です。 これらの値は、大文字の UD ではなく、小文字の ud にする必要があります。

    • クラウドベースのソース - テーブルログを有効にする必要があります。

  • 完全なレコードのみ - 部分的なレコード更新は許可されていません。各行を完全なレコードとして提供する必要があります。

  • バッチ取り込みの頻度 - キャンペーンオーケストレーションのバッチ取り込みは 15 分ごとに 1 回に制限されています。

  • 取り込み待ち時間 - リレーショナルストアでの取り込み待ち時間は、次の条件に応じて通常 15 分から 2 時間の範囲になります。

    • データ量

    • システムの同時実行性

    • 操作のタイプ(例:挿入は更新よりも高速です)

  • データフローとデータセットの関係 - データフローとデータセットの関係は一対一です。 特定の時間に 1 つのデータセットをフィードできるソースは 1 つだけです。 ソースを切り替えるには、既存のデータフローを削除し、新しいソースを使用して新しいデータフローを作成します。

データモデリング

  • バージョン記述子 - ファクトテーブルを含むすべてのスキーマには、適切なバージョン管理とトレーサビリティを確保するためのバージョン記述子を含める必要があります。

  • プライマリキー - データの整合性とダウンストリーム操作をサポートするには、各テーブルにプライマリキーを定義する必要があります。

  • 永続的なテーブル名 - データセットの作成中に割り当てられた table_name は永続的であり、セグメント化およびパーソナライゼーション機能全体で使用されます。

  • フィールドグループ - 現在のデータモデリングフレームワークでは、フィールドグループはサポートされていません。

  • 複合プライマリキー - 現時点では、ファイルのアップロードフローを使用した複合プライマリキーのサポートは使用できません。

オーディエンス

  • スカラー属性のみ - オーディエンス定義では、スカラー属性のみがサポートされます。マッピングと配列は許可されません。

  • セグメント化用リレーショナルデータ - セグメント化アクティビティは主にリレーショナルデータに依存します。 プロファイルデータを含めることができますが、大きなプロファイルデータセットを使用すると、パフォーマンスに影響を与える場合があります。

  • プロファイル属性の制限 - システム効率を維持するために、バッチオーディエンスとストリーミングオーディエンスの両方で使用できるプロファイル属性の数には制限が適用されます。

  • 定義済みリスト - 定義済みリストは完全にサポートされています。

  • オーディエンスを読み取りはキャッシュされません - オーディエンスを読み取りはキャッシュされず、キャンペーン実行ごとに基になるデータからの完全なオーディエンス評価がトリガーされます。

  • Audience Optimization - パフォーマンスを確保するために、大きなオーディエンス定義や複雑なオーディエンス定義を操作する際は、最適化を強くお勧めします。

  • 保存したオーディエンス

    • 保存したオーディエンスのアクティビティは静的です - 保存したオーディエンスのアクティビティは静的で、キャンペーン実行時に使用可能なデータを反映します。
  • 保存したオーディエンスアクティビティへの追加なし - 保存したオーディエンスアクティビティへの追加はサポートされていません。 変更を行う場合は、オーディエンスを完全に上書きする必要があります。

アクティビティの制限 activities-limitations

  • チャネルアクティビティ制限 - オーケストレーションキャンペーンでは、最大 10 個のチャネルアクティビティ(メール、SMS、プッシュ、ダイレクトメール)がサポートされます。 チャネルアクティビティのみがこの制限にカウントされます。 ターゲティング、データ管理、フロー制御アクティビティはカウントされません(例:オーディエンスを作成、ファイルを読み込み、待機、分割、エンリッチメント、紐付け、分岐、終了、テスト)。

    保存または公開時に制限を超えると、操作が失敗します。 制限内に維持させるには、チャネルアクティビティの数を減らしたり、複数のオーケストレーションキャンペーンをまたいでメッセージ配信を分割したりします。

  • キャンバスアクティビティの制限 - オーケストレーションキャンペーンキャンバスのアクティビティ数は 500 に制限されます。 この制限は、キャンバス上のすべてのアクティビティタイプに適用されます。 これは、公開時に適用されるチャネルアクティビティの制限とは別です。 メンテナンス性とパフォーマンスを確保するために、実際のワークフローは 100 個以下のアクティビティに抑えることをお勧めします。

チャネルの制限

オーケストレーションキャンペーンでは、SMS、プッシュ、メール、ダイレクトメールチャネルのみがサポートされます。

recommendation-more-help
journey-optimizer-help