オーディエンスの検証

Adobe Experience Platformでオーディエンス定義を記述すると、オーディエンス検証には、オーディエンスが正確であるだけでなく、安定してスケーラブルであることを確認するための組み込みの検証とガードレールが用意されています。

オーディエンス定義のベストプラクティスに準拠することで、オーディエンスがより迅速に評価され、オーディエンスサイズが大きくなってもロジックの効率が維持され、トラフィック量の多い期間に評価が失敗するリスクが軽減されます。 また、最適化されたオーディエンスは、宛先へのアクティベーション速度を向上させ、リアルタイムのパーソナライゼーションの待ち時間を短縮し、サンドボックス全体の安定性を維持します。

セグメントビルダーでオーディエンスを作成すると、Experience Platformによってこれらの検証がリアルタイムで実行されます。 検証しきい値を超えるイベントまたは属性を追加すると、セグメントビルダーインターフェイス内ですぐにフィードバックが届きます。

検証タイプ validation-types

オーディエンスの検証がオーディエンスに対して実行される場合、違反する可能性のある構成には、重要な検証構成とパフォーマンス最適化構成の 2 種類があります。

重要な検証構造に違反した場合、システムは、サンドボックスの安定性を保護するためにオーディエンスを保存するのを防ぎます。 パフォーマンス最適化の構造に違反した場合は、オーディエンスを保存できますが、パフォーマンスの問題を回避するために、オーディエンス定義を更新することを 強くお勧めします。

検証チェック validation-checks

現在、次の検証がサポートされています。

[​ 重要な検証 ​]{class="badge negative"} 論理的な複雑さ logical-complexity

論理的複雑さの検証では、オーディエンス定義内の論理文（AND、OR、NOT）の構造を分析します。 特に、プロファイルごとに過剰な数の比較をシステムで強制的に実行するオーディエンス定義を探します。

オーディエンス定義のプロファイルごとの比較数が多すぎる場合、複雑さが増し、プロファイル単位の評価が遅くなります。 その結果、オーディエンスの評価に要する全体的な時間が長くなります。

この検証がトリガーされないようにするには、オーディエンスの定義をシンプルにします。 独自のオーディエンス定義を理解できない場合は、定義が複雑すぎて、Experience Platformでのオーディエンスの評価に時間がかかる可能性があります。

例

例えば、特定の州に住んでいる顧客を検索するとします。 こ は 次のように、プロファイルがリストされた 45 個の値のいずれかに一致する状態の値を持っているかどうかを確認することで、効率的に記述できない場合があります。

State.equals("AL", "AK", "AZ", "AR", "CA", "CO", "CT", "DE", "FL", "GA","HI", "ID", "IL", "IN", "IA", "KS", "KY", "LA", "ME", "MD", "MA", "MI", "MN", "MS", "MO", "MT", "NE", "NV", "NH", "NJ", "NM", "NY", "NC", "ND", "OH", "OK", "OR", "PA", "RI", "SC", "SD", "TN", "TX", "UT")

ただし、非チェックを使用すると、プロファイルにリストされた 5 つの値のいずれかが存在しないかどうかを確認するだけで、クエリの効率が大幅に向上します。

not(State.equals("VT", "VA", "WA", "WV", "WI", "WY" ))

または、体験版プランでカナダ人のお客様を見つけたいとします。 効率の悪いアプローチは、他のすべてのプランを 1 つずつ手動で除外し、プロファイルがそれらのいずれにも含まれていないことを確認して、トライアルプランでカナダ人を探すことです。

NOT(
    plan.equals("basic") OR
    plan.equals("standard") OR
    plan.equals("premium") OR
    plan.equals("enterprise")
) AND NOT (
    region.equals("us-east") OR
    region.equals("us-west") OR
    region.equals("eu-central") OR
    region.equals("apac")
)

代わりに、含める特定のプランを直接ターゲットにする必要があります。

plan.equals("trial") AND region.equals("canada")

[​ 重要な検証 ​]{class="badge negative"} シーケンシャル・イベントの複雑性 sequential-event-complexity

順次イベントの複雑さの検証では、シーケンス内の順次イベントの数が 6 個に制限されます。

順次セグメント化は、Experience Platformで最も計算的に複雑な操作の 1 つです。顧客のエクスペリエンスイベントの履歴全体をスキャンし、タイムスタンプで並べ替え、指定した順序がクエリに一致するかどうかを確認する必要があるからです。 その結果、チェーンが大きくなると、システムで計算する必要がある順列の数が大幅に増加します。

この検証がトリガーされないようにするには、ジャーニーの開始、中間、終了を定義して、順次チェーンの基本に焦点を当てます。 多くの場合、最終的な変換内で即座に実行される手順が示されます。

例

製品を表示し、買い物かごに追加して購入したユーザーをターゲットにするとします。 非効率的なアプローチでは、ユーザーのパスの個々の状態を確認します。 例えば、次のクエリでは、一連のイベントを処理します。web サイトにログイン/製品を検索/製品ページを表示/買い物かごに追加/チェックアウトに移動/購入イベント

chain(xEvent, timestamp, [ A: WHAT(eventType = "login"), B: WHAT(eventType = "search"), C: WHAT(eventType = "productView"), D: WHAT(eventType = "addToCart"), E: WHAT(eventType = "checkout"), F: WHAT(eventType = "purchase") ])

ただし、シーケンスを開始、中間、終了に短縮することで、長さが 3 つのイベントのシーケンスを作成するだけで、より効率的なクエリを実現できます。 例えば、次のクエリは、この一連のイベントを処理します。製品ページを表示/買い物かごに追加/購入イベント

chain(xEvent, timestamp, [ A: WHAT(eventType = "productView"), B: WHAT(eventType = "addToCart"), C: WHAT(eventType = "purchase") ])

[​ パフォーマンスの最適化 ​]{class="badge yellow"} 集計数 aggregated-count

集計数のチェックでは、オーディエンス内で使用される集計イベントの数が 3 つの条件に制限されます。

標準イベントは、ユーザーを選定するために、1 つの一致するイベントのみを見つける必要があります。 ただし、集計イベントは、決定を下す前にユーザーのイベントの 履歴 を読み取って分析する必要があり、より多くの集計イベントが使用されるため、処理時間が長くなります。

この検証のトリガーを避けるために、オーディエンスの定義に厳密に必要な場合にのみ、特定のカウントを使用します。 例えば、ユーザーが 1 回エンゲージしたかどうかを知るだけで済む場合、「カウント > 0」イベントを使用するのではなく、標準の「存在」ロジックを使用できます。

[​ パフォーマンスの最適化 ​]{class="badge yellow"} ネストされたデータの複雑さ nested-data-complexity

ネストされたデータの複雑さの検証では、オーディエンス定義内のネストされたデータの数が 2 つのレイヤーに制限されます。

Experience Platformでは配列オブジェクトとマップオブジェクトを使用して複雑なデータタイプを格納できますが、ネストされた構造を展開して値を見つけるには、より複雑なトラバーサルロジックが必要です。 深いデータは配列にネストされるので、検証のための取得に時間がかかります。

深くネストされた属性に対して頻繁にセグメント化を実行する場合、アクセスを容易にするために、データエンジニアリングチームに連絡して、属性をプロファイルスキーマ内の上位レベルにコピーする必要がある場合があります。

[​ パフォーマンスの最適化 ​]{class="badge yellow"} オーディエンスサイズ audience-size

オーディエンスサイズの検証では、オーディエンス定義が非常に広いために、サンドボックス内の合計プロファイルの 30% 以上がオーディエンスに適合するかどうかを確認します。

Experience Platformでは大きなオーディエンスを処理できますが、オーディエンス定義が曖昧すぎる（すべてのアクティブな顧客など）場合、評価時間が長くなり、アクティベーションの待ち時間が長くなる可能性があります。

プロファイルストアの 30% 以上に該当するオーディエンスを作成する必要がある場合は、オーディエンスの最初の評価が柔軟なオーディエンス評価を使用して行われていることを確認します。 オンデマンド評価でオーディエンスを評価すると、大規模なオーディエンスが毎日のセグメント化ジョブに与える全体的な影響を軽減できます。

次の手順

このガイドを読むことで、Experience Platformが自動検証を実行して評価、安定性、スケーラビリティを向上させる方法について、理解が深まりました。 UI を使用したオーディエンスの作成について詳しくは、​ セグメントビルダーのドキュメント ​ を参照してください。

付録

次の付録では、Experience Platformでのオーディエンスの検証に関するよくある質問を示します。

よくある質問 faq

警告を無視してオーディエンスを保存するとどうなりますか？

「順次イベント」の上限を増やすリクエストはできますか？

これらの新しい検証により、既存のオーディエンスが破損することはありますか？

複雑なデータ要件がある。 「ネストされたデータ」の警告を回避するにはどうすればよいですか？

これらのチェックは、ドラフトと公開済みオーディエンスの両方に適用されますか？