Show Menu
トピック×

オファー判定ドメインモデルの概要

Offer decisioning is a use case of Decisioning Service within which you formalize and centrally manage the rules and predictions used for engaging customers with offers. オファー判定は、 コンテンツ判定 ​の一種と見なされます。この使用例では、 判定オプション ​は「 オファー 」と呼ばれ、添付されたコンテンツによって特徴付けられます。For an introduction of the object model used by the Decisioning Service, please refer to Decisioning Service Domain Model .
目標は、ターゲティング基準、コストと頻度の制約、および提案された以前のオファーを含むチャネル間の以前の相互作用に基づいて、エンドユーザーに任意のチャネルで「ベストオファー」を提示することです。
すべての判定の使用例と同様に、判定オプション(オファー)は、任意の数のアプリケーションで共有されるリポジトリーで管理されます。オファーは組織のさまざまな部門またはパートナーによって作成され、毎日追加および削除できます。
オファーは、エクスペリエンスを配信するアプリケーションによって、より大きなエクスペリエンスに視覚的に配置されます。 配置 ​は、スポットやスロットと呼ばれる場合もあり、戦略を作成するための重要なコンポーネントです。オファー戦略のデザインでは、多くの場合、配置の定義で始まります。通常、オファーには複数の​ コンテンツ表現 ​があり 、様々なエクスペリエンスに適切に統合できるようにします。各エクスペリエンスでは、寸法や制約が異なり、様々なメディア形式が必要です。
オファーは、頻繁に物理的な商品やサービスと関連しており、コストの計算が必要です。組織は、オファーによって消費されるリソースを制限できる必要があり、したがって、オファーを提案できる合計回数を​ 制限 ​できる必要があります。
組織への受け入れられたオファーの予測値は最適化基準であり、オファーを行うコストに抵抗します。コスト、受け入れの可能性、予測値を使用して、オファーをランク付けします。最良のオファーは、予測されるプラスの影響が最も高いオファーアクティビティです。
オファー判定では、エンドユーザーが持つインタラクションを​ 多くのチャネル ​やアプリケーションで考慮し、エンドユーザーのプロファイルとエクスペリエンスのイベントデータを活用します。例えば、コールセンターアプリケーションは、オファーの判定を使用して、エンドユーザーが行った購入やレビューに基づいてオファーを有効または無効にすることができます。また、メール管理アプリケーションは、Web サイト上の閲覧履歴に基づいて週刊ニュースレターで「次に最良のオファー」をオファー判定に依存させることができます。
オファーには他にも興味深い性質があります多くの場合、オファーが有効な場合、およびオファーを無効にする必要がある場合に、 スケジュール ​または日時範囲が定義されています。
最後に、オファーの魅力は、それが提示される頻度によって低下します。繰り返し提案しても受け入れられないオファーは、別の提案が提示された可能性があるため、機会を失います。そのため、エンドユーザーの​ 疲労 ​を管理する必要があります。

オファー決定戦略の概要

全体的なアプローチは、すべての制約が満たされるまでオファーの選択を絞り込むことです。次に、残りのオプションにランキングモデルを適用し、キャッピング制約を使用して複数のアクティビティ全体で最適化します(重複除外とフォールバックの選択の回避)
戦略コンポーネント
実現形式
判定アクティビティ
オファーアクティビティ
判定オプション
オファーとコンテンツ表現
フォールバックオプション
コンテンツ表示を持つフォールバックオファー
判定オプションの有限セット
オファーの在庫(オファーライブラリ)
話題カテゴリ
タグとオファー ID に基づくオファーフィルター
判定出力
アクティビティごとに 1 つのオファーの提案(複数のアクティビティを一度に)
判定の結果
エクスペリエンスイベントが期待され、オファーを参照している場合(例: eventType='opened'
判定アルゴリズム
内部サービスロジック(パラメーター化)
制約
配置制約、カレンダー制約、グローバルおよびユーザー単位の制限、重複除外制約
判定ルール
実施要件ルール
期待されるユーティリティ ​のモデル
オファーの順位または優先順位
オプションの在庫に含まれるオファーの総数は、通常は非常に多く(万単位)、各オファーアクティビティは、異なるカテゴリ(トピック)に含まれるオファーに焦点を当てることがあります。このオファー判定戦略は、オファーフィルターをオファーアクティビティに付加します。追加の制約は、判定がリクエストされた時点で評価されます。 次の節では、オファー判定ドメインのコンポーネントについて詳しく説明します。

一般オファー

一般的なオファーは、パーソナライズされたオファーとも呼ばれ、オファー判定アクティビティの中心にあるオプションです。名前やステータスなどの属性を持ちます。ステータス属性は、エンティティがアクティブな承認済みエンティティのリストに含まれる準備ができているかどうかを示します。一般オファーには、いくつかの制約が追加されます。詳しくは、下の「 制約 」の節を参照して‎ください。

オファーコンテンツ

オファー配置

配置は、コンテンツの制約を定義し、アクティビティと共に使用して、次に最高のエクスペリエンスを提供する場所を指定します。これにより、考慮可能なオプションの数がさらに減り、アクティビティによって課せられるもう 1 つの制約になります。これは配置制約と呼ばれます。配置制約に適合するコンテンツ(オプションなど)を持つオファーのみが考慮されます。これは、判定戦略の初期段階で評価されます。オプションオブジェクトが変更されると、各判定アクティビティの配置制約が再評価され、オプションが 1 つ以上のアクティビティの考慮に入るか、または考慮から外れる場合があります。
It is not the responsibility of the Decisioning Service to formalize the complex details of content dependencies. 代わりに、各クライアントはすべてのチャネルにわたる配置のリストを識別し、それらの配置に一意の識別子と名前を付けます。デザイナーは、特定の配置を参照することで、指定したコンテンツが配置に適合すると主張します。
コンテンツが開発されると、オファーマーケターとコンテンツデザイナーは、「ホームページのヒーロー画像」または「サービスコールを開くスクリプト」の名前の後ろにある「黙示的な契約」に同意する(同意する必要がある)だけです。前者は、幅 600px、高さ 350px の画像として合意され、後者は、意味構造を持つ 3 文または 4 文で 50 単語以下の 2 つの言語バリアントのテキストにコンテンツを制限する場合があります。非表示の契約のすべての意味を保存しない場合の配置。

オファー表示域

チャネル内の配置の様々なパラメーターでオファーを適切に表示できるようにするには、そのオファーの様々な表現を作成する必要があります。配置に添付されるコンテンツは、オファー別にグループ化されます。各オファーは、1 つ以上の表現を持つことができ、これらの各表現は、定義された配置の 1 つを参照します。1 つの表現内の各オファーは、異なる配置を使用する必要があります。表現が多いほど、オファーが異なる配置コンテキストでオファーを使用する機会が多くなります。
配置は、表現に追加できるコンテンツ項目のタイプを制限します。

フォールバックオファー

フォールバックオファーは、配置ルール以外に追加の制約がない判定オプションです。フォールバックオファーには、他のオファーと同様に、配置に関連付けられたコンテンツ表現が含まれます。
フォールバックオファーは、アクティビティで指定され、組み合わされた制約ですべての絞り込みオプションが無効な場合に、使用できるコンテンツエクスペリエンスを示します。実行時のコンテキストやプロファイルに依存しないので、配置制約は、アクティビティのアセンブリ時に事前にチェックできます。フォールバックオファーを使用すると、現在「最良」の選択肢は何かという質問に対する答えが常にあるようになります。

オファー制約

カレンダーの制約

オファー判定ドメインでは、オファーに有効期間があります。つまり、オファーの開始日時より前や終了日時が過ぎた後では提案することはできません。オファーエンティティは、これらのカレンダー制約を定義する単純な構造を持ちます。
定期的に、期限切れのオファーは、考慮されるオプションのリストから削除されます。ただし、カレンダーフィルターは、決定がリクエストされた時点で適用され、制約が正確に適用されます。

キャッピング制約

オファーには、オプションのキャッピング制約を設定できます。これは 2 つの値で構成されます。
  • グローバル上限値は、プロファイルセット全体(対象ユーザー)全体でオファーを提案できる頻度を制限します。
  • プロファイルごとの上限と、そのオファーを同じプロファイルに提案できる頻度を決定します。

重複制約

判定がリクエストされると、クライアントは一度に複数のアクティビティの提案を求めることができますこれは、コンテンツ判定の一般的なシナリオです。各アクティビティは、エクスペリエンス全体に 1 つ以上のコンテンツオプションを提供します。構成の面から判断する場合は、重複を避けるために、アクティビティ間で判断をおこなう必要があります。ただし、各アクティビティがオプションの在庫全体の別々のサブセットを選択する場合を除きます。上位のオプションは、すべてのアクティビティで高く順位付けされる可能性が高く、すべてのアクティビティが同じオプションを提案した場合は、エクスペリエンスが乏しくなります。一方、配信システムがすべてのチャネルで「次に最適なコンバージョン」が何かを知りたがり、制限がない場合は、異なるアクティビティ間で同じオプションを提案しても構いません。
重複制約は、現在、ビジネスオブジェクトリポジトリーに書き込まれていません。実行時のデフォルトの方法は、重複除外です。リクエストパラメーターは、デフォルトの動作を上書きして、重複除外手順を抑制できます。

Profile 制約 —実施要件ルール

これまでのところ、どのユーザーに対して選択を行ったかに関係なく、オファーの制約が適用されています。エクスペリエンス判定は、顧客のレコードと時系列のイベントに基づいて提案をパーソナライズする使用例もサポートします。ルールはプロファイルごとに評価され、オファーに該当するか、抑制する必要があるかを決定します。これをおこなうために、実施要件ルールを各オファーに関連付けます。エンドユーザーのプロファイルイベントとエクスペリエンスイベントに加え、実施要件ルールはリアルタイムのコンテキストデータを考慮に入れます。このデータは配信サービスによって提供され、在庫レベル、気象状況、フライトスケジュールなどのプロファイルに関連しないデータの形式をとることができます。
ターゲティングとセグメント化ルールを区別し、実施要件と優先度のルールを判断することが重要です。ターゲティングでは、プロファイルのセットは実施要件の出力(オーディエンスの選択)で、オプションのセット(許可されたオファー)が評価の出力です。

オファーコレクション

在庫とは、判定の対象となるオプションの全体的なプールです。在庫は、さらにコレクションまたはカテゴリに分けることができます。オプションのコレクションは、これらのオプションに共通のタグで表されます。フィルターは、オファーが特定のカテゴリに該当するか、より具体的には同じタグを共有するかをテストするために使用されます。

タグ

タグを使用すると、オプションのグループが 1 つのカテゴリに属していることを表すことができます。
1 つのオプションに複数のタグを含めることができるので、複数のカテゴリに同時に含めることができます。カテゴリは、別のカテゴリと重なったり、別のカテゴリを含んだりすることもできます。カテゴリ「S」がタグ「A」を有するオファーで定義され、カテゴリ「R」がタグ「A」とタグ「B」の両方のオプションで定義される場合、「S」は「R」の上位集合となります。

フィルター

フィルターは、カテゴリに属する一連のオプションの条件を定義するために使用されます。フィルターは、一般オファーのの在庫に対するクエリと考えることができます。フィルターを形成するには、オファーに 1 つ以上のタグがあることを示す方法と、オファーのセットを明示的に選択する方法の 2 つの基本的な方法があります。前者の方法は、そのコレクション内のオファーに指定されたすべてのタグが必要であること、またはオプションが指定されたタグの少なくとも 1 つを持っている場合に修飾されることを示すように構成できます。
オプションがコレクションに明示的に配置されている場合、そのコレクションのタグセットは無視されます。

オファーアクティビティ

アクティビティは、判定プロセスを設定および制御します。現在、判定戦略は主に事前に決定されていますが、今後のオファー判定ドメインモデルの繰り返しで、モデル、追加のルールおよび制約を選択できます。
エクスペリエンスは、複数のアクティビティを同時に使用してアセンブルできます。現在、1 回の判定リクエストで最大 30 アクティビティに対処できます。エクスペリエンスの 30 を超えるアクティビティまたはスロットにコンテンツを入力する必要がある場合、同じプロファイルに対して複数のリクエストを作成できます。ただし、アクティビティが同じ判定リクエストに含まれる場合は、それらのオファーの提案間で重複が排除されます。
アクティビティーが分離されたオファーのセットから選択する方法で定義されている場合、アクティビティが同じリクエストで結合されているか、別々のリクエストに分割されているかにはほとんど違いがありません。ただし、ネットワークと応答時間の制約により、同じリクエストにアクティビティを組み合わせることが必要になる場合があります。異なるリクエストが異なるサービスノードにルーティングされる場合があるので、同じプロファイルデータを異なるノードにフェッチする必要がある場合があります。これにより、他のリクエストで使用できる有効な I/O 帯域幅が削減されます。
アクティビティは、エクスペリエンスにコンテンツを挿入するために使用されます。コンテンツ項目が正しく「適合」することを容易にする(保証ではない)ため、アクティビティは単一の配置を参照します。配置は必ずしも具体的な場所やスロットではなく、それらの場所やスロットを抽象化したもののようなものです。例えば、タイルのグリッドを含む Web ページでは、すべてのタイルの形状とサイズが同じで、類似したコンテンツを保持できると仮定して、各タイルを同じ配置で管理できます。ただし、個々のタイルは通常、独自のアクティビティで提供されます。
次の図は、ビジネスエンティティが相互にどのように関連しているかを示しています。
クライアントが判定のためにオブジェクトグラフを作成し、リンクする場合、通常は 3 つの異なるワークストリームが存在します。これらは次のとおりです。
  • タグや配置などのサポートエンティティの設定これらのエンティティは、他のエンティティの構造化、フィルタリング、グループ化に使用されます。また、2 番目と 3 番目のワークフローの間の調整をおこなうためにも使用されます。このワークフローは、事前の作業を構成しますが、いつでも設定を調整できます。タグは比較的簡単ですが、配置にはあと少し計画が必要です。少なくとも、ビジネスでは、判定がおこなわれるすべての場所の在庫を作成する必要があります。
  • 様々な表現とオファールール(制約)を使用してビジネスを作成する。この中央ワークフローは、最適なものを選択するオプションを提供します。最初のワークフローのタグはオファーの分類に使用され、配置は表示できるオプションと場所を示すために使用されます。
    • このワークフローは、オファーの絶対制約も定義します。これらは常に強制され、単に一連のオファーのランキングに影響を与えるのではなく、絶対的なものです。例えば、カレンダー制約が設定されると、オファーは設定開始の日時より前や終了日時より後には選択されなくなります。このワークフローで設定される制約は、 カレンダー制約 上限制約 実施要件制約 です。ここのサブワークフローは、特定のオファーを受け取る資格がある人を決定する追加のルールの定義です。
      • 制約が作成されると同時に、そのオファーの表現が選択されます。このワークフローは、コンテンツがすでにどこかに作成されており、単にコンテンツリポジトリーにアップロードされ、そこから選択されることを前提としています。ここで、最初のワークフローの配置が役に立ちます。オファーは配置を選択し、その 配置 の下にコンテンツを関連付けることができます。
      • 適切なフォールバックオファーを作成することは、このワークフローの最後の手順です。フォールバックオファーは、制約のない一般的なオファーに非常に似ています。
  • 最後のワークフローは、アクティビティの作成に関するものです。ただし、この手順は、オファーを作成するワークフロー後に必ずしも連続しておこなわれるわけではありません。両方のプロセスが継続中で、同時に実行されています。アクティビティは、トピック別、および判定が表示される場所別に、オプションの範囲を絞り込むために使用されます。アクティビティは、 コレクション と配置を参照します。また、適格なオファーを判断できない場合に使用する フォールバックオファー も指定する必要があります。