Show Menu
トピック×

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

オファー判定サービスは、顧客をオファーに引き付けるためのルールや予測を正式に策定し、一元的に管理するサービスの使用例です。 オファー判定は、 コンテンツ判定の一種と見なされます 。 この使用例では、 決定オプション オファー ​と呼ばれ、に付属するコンテンツによって特徴付けられます。 Decisioningサービスで使用されるオブジェクトモデルの紹介については、「Decisioningサービスドメインモデル Experience Decisioningドメインモデル 」を参照してください。
目標は、ターゲット条件、コストと頻度の制約に基づくチャネル、および提案された以前のオファーを含むチャネル間での事前のやり取りに基づいて、エンドユーザーに対して「最高のオファー」を提示することです。
すべての判定の使用例と同様に、決定オプション(オファー)は、任意の数のアプリケーションが共有するリポジトリで管理されます。 オファーは、組織の別の部署やパートナーが作成し、毎日そのオファーを追加および削除できます。
オファーは、エクスペリエンスを提供するアプリケーションによって、より大きなエクスペリエンスに視覚的に配置されます。 配置 (スポットやスロットとも呼ばれる)は、戦略を作成するための重要なコンポーネントです。 オファー戦略のデザインでは、多くの場合、配置の定義を開始に説明します。 通常、オファーは複数の コンテンツ表現を持ち 、様々なエクスペリエンスに正しく統合できます。各エクスペリエンスは、様々なディメンションや制約を持ち、様々なメディア形式を必要とします。
オファーは、物理的な商品やサービスとの関連性が高く、コストの計算が必要です。 組織は、オファーが消費するリソースを制限できる必要があるため、オファーの提案可能な合計回数を 制限できる
組織に対して受け入れられるオファーの予測値は最適化基準であり、オファーの費用に立ち向かいます。 コスト、受け入れの可能性、予測値を使用して、オファーをランク付けします。 最良のオファーは、オファーアクティビティの目標に対して予測される最も高いポジティブな影響を与えるです。
オファー判定は、エンドユーザーが持つインタラクションを多くのチャネル やアプリケーション にわたって考慮し、エンドユーザーのプロファイルとエクスペリエンスのイベントデータを利用します。 例えば、コールセンターアプリケーションは、オファー判定機能を使用して、エンドユーザーが行った購入やレビューに基づくオファーを有効または無効にできます。 または、電子メール管理アプリケーションは、webサイトの閲覧履歴に基づいて、週刊ニュースレターで「次に最適なオファー」をオファーの判定に依存します。
オファーには他にも興味深い特性があります。 多くの場合、オファーが有効な場合やオファーを無効にする必要がある場合に、 スケジュール 、または日時範囲が定義されています。
最後に、オファーの魅力は、提示頻度で劣化する。 繰り返し提案された後に受け入れられないオファーは、別のオファーが提示された可能性があるので、機会を失います。 そのため、エンドユーザの 疲労を管理する必要があります

オファーの意思決定戦略の概要

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

一般オファー

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

オファー内のコンテンツ

オファー配置

プレースメントは、コンテンツの制約を定義し、次に最良のエクスペリエンスを提供する場所を指定するためにアクティビティと共に使用されます。 これにより、考慮できるオプションの数がさらに減り、アクティビティによって課せられる別の制約が生じます。 これは配置拘束と呼ばれます。 オファーなど、配置の制約を満たすコンテンツを持つオプションのみが考慮されます。 これは、決定戦略の初期段階で評価されます。 optionオブジェクトで配置制約を変更すると、各アクティビティの配置制約が再評価され、1つ以上のアクティビティに対してその制約が考慮または除外される場合があります。
コンテンツ依存関係の複雑な詳細を正式に作成するのは、Decisioningサービスの責任ではありません。 代わりに、各クライアントはすべてのチャネルにわたる配置のリストを識別し、それらの配置に一意の識別子と名前を付けます。 デザイナーは、特定の配置を参照することで、指定したコンテンツが配置に適合すると主張します。
コンテンツが開発されると、オファーマーケティング担当者とコンテンツデザイナーは、「ホームページのヒーロー画像」または「サービスコールの開始スクリプト」の名の後ろにある「黙示的な契約」に同意する(同意する必要があります)。 前者は幅600px、高さ350pxの画像として認められ、後者は意味構造を持つ3 ~ 4文の中で50語以下の2つの言語の異形のテキストにコンテンツを制限している。 非表示の契約のすべての意味を格納しない場合の配置。

オファー表示域

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

代替オファー

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

オファー制約

カレンダーの制約

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

制限の制限

オファーには、オプションのキャッピング拘束を設定できます。 2つの値で構成されます。
  • グローバル上限値は、プロファイルセット全体(ターゲットオーディエンス)でオファーを提案できる頻度を制限します。
  • プロファイル単位の上限を指定し、そのオファーを同じプロファイルに提案できる頻度を決定します。

重複の制約

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

プロファイル制約 —実施要件ルール

これまでのところ、オファーの選択対象に関係なく、制約事項が適用されます。 Experience Decisioningは、個人化するプロポジションが顧客の記録と時系列のイベントに基づく使用例もサポートしています。 ルールはプロファイルごとに評価され、オファーがそのユーザーに対して資格を持つか、抑制する必要があるかを決定します。 実施要件ルールを各オファーに関連付けることができる。 エンドユーザーのプロファイルおよびエクスペリエンスのイベントに加えて、実施要件ルールはリアルタイムのコンテキストデータを考慮に入れます。 このデータは配信サービスによって提供され、在庫レベル、天候条件、フライトスケジュールなど、プロファイルに関係のないデータを取得できます。
ターゲット設定ルールとセグメント化ルールを区別し、適格性と判定の優先順位ルールを区別することが重要です。 一連のプロファイルをターゲット設定する場合、適格性の出力(オーディエンスの選択)は、一連のオプション(許可されているオファー)に基づき、評価の出力が行われます。

オファーコレクション

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

タグ

タグを使用すると、カテゴリのグループがオプションに属していることを表すことができます。
1つのオプションに複数のタグを付けることができるので、複数のカテゴリに同時に配置できます。 カテゴリは、重なり合ったり、別の画像を含んだりすることもできます。 タグ「A」を持つオファーでカテゴリ「S」を定義し、カテゴリ「R」をタグ「A」と「B」の両方で定義すると、「S」は「R」のスーパーセットとなります。

フィルター

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

オファーアクティビティ

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