同意ポリシールールの構築参照

この高度なルールロジックに関する参照を使用して、Adobe Experience Platformの同意ポリシービルダーの​ Then ​句に正確で法的に有効なルールを設定します。

ポリシールールが同意データの構造やタイプにどのように適用されるのか、また顧客の同意設定をどのように正確に適用するのかをご確認ください。

このドキュメントでは、XDM スキーマのコンテナフィールドに移動してプリミティブフィールドを選択することで、同意に基づいてプロファイルをフィルタリングする方法について説明します。 次に、適切な演算子を使用して、プロファイルが一致する必要がある正確な値を定義します。

前提条件

このリファレンスを使用する前に、同意ポリシーの設定が完了していること、およびAdobe Experience Platformのデータアーキテクチャとガバナンスフレームワークの基本概念を理解していることを確認してください。

次の前提条件を満たしていることを確認してください。

コアコンセプト：プリミティブフィールドとコンテナフィールド

この節では、同意ポリシールールがXDM スキーマで様々なフィールドタイプをどのように使用するかを説明します。 コンテナフィールドとプリミティブフィールドの違いを理解すると、ポリシー条件を定義する際に正しいフィールドと演算子を選択できます。

サポートされているフィールドタイプとルールロジック

同意ポリシーは、複数のフィールドタイプをサポートしており、それぞれに特定の演算子を使用してルール条件を構築できます。 フィールドタイプは、コンテナタイプ​と​ プリミティブタイプ ​の2つのカテゴリに分類されます。

コンテナタイプ（スキーマナビゲーション）

コンテナタイプは同意データを整理しますが、ポリシー条件で直接使用することはできません。 これらは、実際の値を保持するプリミティブフィールドに到達するためのナビゲーションパスとして機能します。

プリミティブタイプ（ルール条件）

プリミティブフィールドには、実際の同意データ値（例：trueまたは"weekly"）が格納され、ポリシー条件の定義に使用できる唯一のフィールドタイプです。

次の表に、サポートされている各プリミティブタイプと使用可能な演算子を示します。

複雑なデータ構造の操作

この節では、同意スキーマ内のネストされたコンテナを移動してプリミティブフィールドに到達する方法について説明します。 一般的なスキーマパターンを導入し、より詳細な構造によって、より詳細な同意ロジックをどのように実現するのかを解説します。

ネストされた複雑なスキーマ構造の処理

複雑な同意スキーマには、柔軟性と拡張性に優れたデータ管理をサポートする、ネストされたコンテナ構造が含まれていることがよくあります。 ポリシールールはプリミティブフィールドのみを参照できるため、同意ポリシー条件で使用できるフィールドに到達するには、コンテナ階層を移動する必要があります。 ネスト化を深めることで、より詳細で特定のルールのターゲティングが可能になります。

一般的なネストされたコンテナパターンには、次のものがあります。

フィールド構造の例

次の構造は、このガイド全体を通してルール例のビジュアルリファレンスとして機能します。

consent.marketing (Object)
├── email (Boolean)
├── sms (Boolean)
├── preferences (Map with dynamic keys)
│   ├── "email_preferences" (Object)
│   │   ├── frequency (String)
│   │   └── channels (Array of Strings)
│   ├── "sms_preferences" (Object)
│   │   ├── frequency (String)
│   │   └── opt_in_time (Date)
│   └── "push_preferences" (Object)
│       ├── frequency (String)
│       └── categories (Array of Strings)
└── lastUpdated (Date)

フィールドタイプ別の高度なルール構築

フィールドタイプに基づく同意ポリシールールの作成に関する詳細なガイダンスについては、この節を参照してください。 正確な同意条件を取得するために、ブール値、マップ、オブジェクト、配列のルールロジックを設定する方法について説明します。

ルール構築のコンポーネントとステップ

効果的な同意ポリシールールを構築するには、スキーマ構造をナビゲートし、各フィールドタイプに正しい演算子を適用する方法を理解する必要があります。 各ルールは、同じ基本的なアプローチに従います。プリミティブフィールドに移動し、適切な演算子を選択して、満たす必要がある条件を定義します。

ルールを作成するには、次の手順に従います。

ブール値フィールドの操作（暗黙的な同意ロジック）

ブール型フィールドには、trueまたはfalseの同意値が保存され、最も一般的な同意属性が表されます。 is not equal to演算子を使用すると、明示的にオプトアウトされていないプロファイルを含めることができ、暗黙的な同意シナリオをサポートします。

ブール演算子と結果

例：暗黙のメール同意

Field: consent.marketing.email (boolean)
Operator: is not equal to
Value: false
Result: Includes profiles who have not explicitly opted out of email marketing (includes both true and missing/null values).

マップフィールドの操作（動的な環境設定）

マップフィールドには、固定スキーマを持つオブジェクトとは異なり、動的キーを持つキーと値のペアが格納されます。 マップは、スキーマを更新することなく新しいカテゴリを追加できるプリファレンスセンターでよく使用されます。 特定のキーをターゲットにしたり、すべてのキーでワイルドカードマッチングを使用したりできます。

特定のキーが​に一致

このアプローチを使用して、特定の嗜好カテゴリをターゲティングします。

Field: consent.preferences["email_preferences"].frequency (string) - navigated to from the map container
Operator: is equal to
Value: "weekly"
Result: Includes profiles who set the email frequency to weekly (for the "email_preferences" key)

一致する任意のキー

「一致する項目を検索」チェックボックスオプションを使用して、マップ内のすべての動的キーに一致させます。

すべての動的キーの値を一致させるために使用される、マップフィールドの「一致する項目を検索」チェックボックスを表示する

Field: consent.preferences.*.frequency (string)
Operator: is equal to
Value: "weekly"
Result: Includes profiles who set frequency to weekly in ANY preference category (for example, email_preferences, sms_preferences, or push_preferences)

オブジェクトフィールドの操作（固定ナビゲーション）

オブジェクトフィールドは、固定スキーマを持つコンテナとして機能します。 これらはナビゲーションにのみ使用され、ポリシー条件で直接参照することはできません。

ナビゲーションの例

consent.marketing (object) → consent.marketing.email (boolean)

使用例：

Field: consent.marketing.email (Boolean) - navigated to from the object
Operator: is equal to
Value: true
Result: Include profiles who have explicitly consented to marketing emails

配列フィールドの操作（複数の値）

配列フィールドには同じタイプの複数の値が含まれており、プリミティブまたはオブジェクトを格納するかどうかに応じて異なる処理が必要です。 ナビゲーションオプションとオペレーターオプションは、配列タイプによって異なります。

プリミティブの配列の例

contains演算子を使用して、配列内の特定の値に基づいてプロファイルを識別します。

Field: consent.communication_channels (array of strings)
Operator: contains
Value: "email"
Result: Include profiles who have consented to email communication

オブジェクトの配列の例

配列に移動して、ネストされたオブジェクト内のプリミティブフィールドにアクセスします。

Field: consent.preferences["email_preferences"].categories[].type - navigated to from the array
Operator: is equal to
Value: "promotional"
Result: Include profiles where any email category is "promotional"

ルールと複雑なロジックの結合

この節では、ANDまたはOR ロジックを使用して複数のルール条件を組み合わせる方法について説明します。 論理演算子が連携して、高度な複数条件の同意ポリシーを定義する方法について説明します。

複数の条件（ANDまたはOR ロジック）の組み合わせ

ANDまたはOR ロジックを使用して複数のルール条件を組み合わせると、特定のプロファイルセグメントをターゲットとする、より高度な同意ポリシーを構築できます。
AND ロジック​では、すべての条件がtrueである必要があり、オーディエンスの一致が狭くなります。
OR ロジック​を使用すると、任意の条件をtrueにすることができ、オーディエンスのリーチが拡大されます。

同意ポリシーインターフェイスで、ルール条件間に表示されるロジックセレクターを使用して、ANDとORのロジックを切り替えます。

一般的な複雑なルールの例

次の例では、基本的な同意ステータスと環境設定の頻度を組み合わせて、ターゲットとなるセグメントを作成します。

Field: consent.marketing.email
Operator: is equal to true
AND
Field: consent.preferences.frequency
Operator: is not equal to "daily"
Result: Include profiles who consent to email marketing but not to a daily frequency

オブジェクトの配列の高度なロジック

オブジェクトの配列内で条件を組み合わせる場合、動作は、条件間でANDまたはOR ロジックを使用するかどうかに依存します。

例：AND条件を持つオブジェクトの配列

すべての条件を​ same ​配列要素に適用する必要がある場合は、AND ロジックを使用します。

Field: consent.preferences["email_preferences"].categories[].enabled (boolean)
Operator: is equal to
Value: true
AND
Field: consent.preferences["email_preferences"].categories[].type (string)
Operator: is equal to
Value: "promotional"
Result: Includes profiles where the same category entry has both enabled=true and type="promotional".
Note: AND conditions apply to the same array entry. Using OR logic would include profiles if any array entry matches any of the conditions.

例：OR条件を持つオブジェクトの配列

OR ロジックを使用して、任意の条件を配列エントリ全体でtrueにすることで、包括的なオーディエンスマッチを作成します。

Field: consent.preferences["email_preferences"].categories[].enabled (boolean)
Operator: is equal to
Value: true
OR
Field: consent.preferences["email_preferences"].categories[].type (string)
Operator: is equal to
Value: "newsletter"
Result: Includes profiles where any category entry has enabled=true or any entry has type="newsletter".
Note: OR logic allows matching across different array entries. One entry can meet the first condition while another meets the second.

次の手順

同意ポリシールールを構築して調整したら、次のリソースを使用して設定を確定し、ポリシーの適用を検証して、基盤となるデータモデルをレビューします。