オーディエンスの検証

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")

ただし、「not」チェックを使用すると、プロファイルにリストされた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内で最も計算が複雑な処理のひとつです。システムは、顧客のExperience Eventsの履歴全体をスキャンし、タイムスタンプで並べ替え、指定した順序がクエリに一致するかどうかを確認する必要があります。 その結果、連鎖が成長すると、システムが計算する必要がある置換数が大幅に増加します。

このような検証をトリガーしないようにするには、ジャーニーの始まり、中間、終わりを定義することで、シーケンシャルチェーンの基本に焦点を当てます。 直近のステップは、多くの場合、最終的なコンバージョンに含まれます。

例

例えば、商品を閲覧し、カートに追加して購入したオーディエンスをターゲティングするとします。 より非効率的なアプローチでは、ユーザーのパスのすべての個々の状態を確認します。 例えば、次のクエリは、次の一連のイベントを実行します。Web サイトにログインします。> Searches for product -> Views a product page -> Adds to cart -> Navigates to checkout -> Purchase event

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回エンゲージメントしたかどうかだけを知る必要がある場合は、「Count > 0」イベントを使用するのではなく、標準の「Exists」ロジックを使用できます。

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

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

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

詳細にネストされた属性に対して頻繁にセグメント化を実行する場合は、簡単にアクセスできるように、データエンジニアリングチームに連絡して、属性をプロファイルスキーマ内のより高いレベルにコピーする必要がある場合があります。

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

オーディエンスサイズの検証では、サンドボックス内の合計プロファイルの30%以上がオーディエンスの対象となるほど幅広いオーディエンス定義があるかどうかを確認します。

Experience Platformは大規模なオーディエンスに対応できますが、オーディエンス定義が曖昧な場合（すべてのアクティブ顧客など）は、評価時間やアクティベーションの遅延が増加する可能性があります。

プロファイルストアの30%以上を占めるオーディエンスを作成する必要がある場合は、オーディエンスの最初の評価が、柔軟なオーディエンス評価にもとづいて実施されるようにしましょう。 オンデマンド評価でオーディエンスを評価することで、大規模なオーディエンスが日々のセグメンテーションに与える影響を全体的に軽減することができます。

次の手順

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

付録

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

よくある質問 faq

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

シーケンシャルイベントの上限の引き上げをリクエストできますか？

これらの新しい検証によって既存のオーディエンスが壊れますか？

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

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