Show Menu
トピック×

Decisioningサービスの概要

Decisioningサービスは、Adobe Experience Platform上で実行するアプリケーションで、パーソナライズされた、最適化された、調整されたエクスペリエンスを作成する機能を提供します。 Decisioningサービスを使用すると、選択可能な選択肢の中から最適な オプション を決定できます。 これらのオプションは、代替オプションとも呼ばれ、オファー、製品のレコメンデーション、Webエクスペリエンス用のコンテンツコンポーネント、会話スクリプト、実行するアクションなどがあります。 現在、 ** オファー判定の使用事例とドメインがサポートされています。具体的には、オファーとして判断オプションがモデル化され、今後さらに多くの使用事例がサポートされます。
Decisioningサービスを使用すると、ユーザーはビジネスロジックを再利用し、チャネルやアプリケーション間でオプションのカタログを共有できます。 決定オプションや選択戦略をアプリケーション内で十分に管理する代わりに、お客様のエンドユーザーがビジネスや組織とやり取りするチャネルや状況に関係なく活用できるようになりました。
判定戦略は、様々なチャネルやアプリケーションにわたって、顧客が行った多くのやり取りを引き起こす可能性があります。 例えば、コールセンターの申し込みアクティビティは、苦情の後しばらくの間、マーケティングメッセージを有効または無効にしたり、メッセージ自体は、顧客が行った購入やレビューに基づいている場合があります。
判定サービスは、進化したエクスペリエンスのパーソナライゼーションを容易にします。
Experience Decisioningの前
エクスペリエンスの判定後
1つのチャネル内または少数のエクスペリエンスタッチポイント内で、ユーザーのエクスペリエンスをパーソナライズし、最適化します。
エクスペリエンスは、インタラクション間で調整された応答です。
最適化は、エンドユーザーの遍歴の単一の短い段階に焦点を当てる
判断は、過去に検出された行動から最新の状況コンテキストまでにわたる、インタラクション履歴全体に基づいて行われます。
オプションや、顧客のエクスペリエンスの中でどのオプションを提示するかを選択する戦略は、通常、アプリケーション内で深くコード化されます。
最適なオプションを選択するための戦略は、チャネル固有のアプリケーションの外部で定義され、再利用可能になります。
顧客体験は、Webページのチェックアウト成功数の増加や、担当者とのインタラクションで提示されるオファーの受け入れなど、単純な目標に従ってパーソナライズされ、最適化されます。
顧客の現在のニーズの全体的な理解に基づいて顧客のエクスペリエンスが最適化され、ユーザーの持つすべてのエクスペリエンス(良い/悪い)に合わせて調整されます。 例えば、マーケティングキャンペーンが、最近製品やサービスに関する苦情を申し立てた顧客には適していない場合があります。
判定サービスは、エクスペリエンスのパーソナライズ機能を単一のチャネルでのターゲット設定から、チャネルに関係なく、顧客のブランドに対するエンゲージメントのライフサイクル全体的な段階を判断するまで移行させます。 ライフサイクルステージは、セグメントのメンバーシップよりもはるかに複雑で、ほとんど常に、複雑なイベントストリーム、ビジネスルール、予測属性に基づいています。
同様の使用例を目的とする商品やサービスで使用されるその他の用語。
  • Real-time Interaction Management(RTIM)
  • ジャーニー管理
  • オムニチャネルのマーケティングとパーソナライゼーション
  • Real-time decisioning

Decisioningサービスの仕組み

エクスペリエンスは、Decisioningサービスを使用してリアルタイムにカスタマイズできます。これは、顧客がサイトやモバイルアプリなどのインバウンドチャネルを介して自社のブランドに関与している場合と同様です。 判定は、電子メールやプッシュ通知など、送信チャネルを介したメッセージのカスタマイズにも使用できます。
決断は様々な方法で下せる。 1つのアプローチは、1つのオプションのみが残るか、オプションが切り下げられ、サブセットが残るか、または勝者が縮小セットからランダムに選択されるまで、オプションを連続的に削除します。 計算式に従って勝者オプションを選択するこの方法のバリアントです。 ランキングの対象となるオプションは、関数を使用して実行されます。 オファー判定の場合、その関数はコスト、ビジネスに対するオファーの値を計算し、エンドユーザーがオファーを受け入れる確率を事前に決定された方法で使用できます。 結果のスコアは、オファーの注文に使用できます。
または、戦略は、類似のオプションを提案された類似の顧客との以前の対話から収集された結果に基づくこともできます。 この方法では、優先度値を計算した関数を学習します。 最適な結果値はアクティビティの目標に結び付けられ、予測のパフォーマンスインジケーターは、選択肢の提案後に結果が達成された頻度です。

決定戦略

デシジョンストラテジーは、 アクティビティと呼ばれるオブジェクトを介して設定されます 。 各決定戦略は、基本的にN個のリスト{o1,o2,...oN}を入力とし、順に並んだ選択肢(o1,o2,...oK)を生成するアルゴリズムまたは関数で、リストの最初の選択肢を最適化基準に従って、結果の2番目の選択肢を2番目の最良と見なします。
お客様の遍歴の中でいつでも、特定のアクティビティに対する最適なオプションは、最新のコンテキスト変数、ルールおよび制約のセットに基づいて再評価されます。 コンテキスト変数には、リアルタイム顧客プロファイルに保存されたレコードが含まれます。 中央レコードエンティティは顧客のプロファイルですが、業務データなどの他のエンティティもアクティビティに同じように提供されます。
トップKのオプションのリストを生成するアルゴリズムや関数は、使用例によって異なります。 そのアルゴリズムの内部コンポーネントは、使用例によって異なります。 コンポーネントはデザイン時にリポジトリで定義され、ユースケース固有の意思決定戦略の指示に「コンパイル」されます。

Decisioningサービスの使用

Decisioningサービスは、他のプラットフォームサービスと同様、APIの最初の考え方を採用しています。 つまり、APIは、管理機能を含むすべての機能をAPI経由で使用できる主要なインターフェイスです。 また、他のプラットフォームサービス、アドビソリューションおよびサードパーティ統合でも同じAPIが使用されます。
簡単なHTTP REST APIで容易に実行できる同期リクエスト応答インタラクションモードで、Decisioningサービスを使用できます。 API呼び出しは、単一のプロファイルに対して現在最適なオプションを返します。 「現在最適なオプション」の選択は、特定のアクティビティが考慮するすべてのオプションに適用されるルールと制約に基づいて変更されます。 REST APIを使用すると、複数のアクティビティに対して同時に次に最適なオプションを取得できます。 これにより、複数のチャネル間でのオプションの調停が可能になります。 複数のアクティビティの応答をまとめて取得する場合、追加のルールが適用される場合があります。

他のプラットフォームワークフローとの統合

Decisioningサービスの使用はオプションです。プロファイルエンティティの作成と管理に必要な一般的な手順に加えて、いくつかの手順で行う必要があります。
リアルタイム顧客のプロファイルを最大限に活用するために、Decisioningサービスはプロファイルストアと直接統合されています。 API呼び出しは、特定のプロファイルのIDの1つを示すだけで済みます。
プロファイルの構築に関する開始の一般的な手順は次のとおりです。
  • エクスペリエンスプラットフォームに対する認証。
  • プロファイルクラスに基づいてスキーマを定義し、必要に応じて、エクスペリエンスイベントクラスに基づいてスキーマを定義します。
  • レコードと時系列のデータを顧客プロファイルにアップロードするようにデータセットを設定します。
  • 前の手順で設定したデータセットを追加介したデータ、またはパイプラインを介したストリームインスタンスデータ。
  • エクスペリエンスのイベントをプラットフォームにストリーミングし、行動データによってプロファイルを強化します。
また、Decisioningサービスを使用するには、次の手順を実行します。
  • Repository APIを使用して、決定コンポーネントを定義します。 これらは、決定戦略を構成するビジネスロジックエンティティです。 決定コンポーネントは、Decision Service Runtimeで使用される形式に自動的にコンパイルされます。 Repository APIを下の図の左側に示します。
  • 前の手順で定義したビジネスロジックに従って最適なオプションを取得するには、Runtime APIを呼び出します。 Decision Service Runtime APIを下の図の右側に示します。
ビジネスロジックエンティティのアクティベーションは、自動的に、連続的に行われます。 新しいオプションがリポジトリに保存され、「承認済み」とマークされるとすぐに、使用可能なオプションのセットに含める候補になります。 決定ルールが更新されるとすぐに、ルールセットが再アセンブルされ、実行時の実行に備えられます。 この自動アクティベーション手順では、ビジネスロジックによって定義された、実行時のコンテキストに依存しない制約が評価されます。 このアクティベーション手順の結果はキャッシュに送信され、キャッシュがDecisioningサービスランタイムで使用できるようになります。 次の図に示します。
オプションセット、ルールセットおよび制約がアクティブ化され、Decisioningサービスノードにプッシュされると、単純なAPIを使用して、決定のリクエストを投稿します。 通常、APIは配信サービスによって呼び出され、その後、提案されたオプション(次に最適なアクションや次に最適なオファーなど)を取得して、エクスペリエンスをアセンブルするか、そのアクションを実行します。 提案がオファーの場合は、そのオファーを表すコンテンツが検索され、エンドユーザーに提供されるエクスペリエンスに挿入されます。 次の図に示します。
配信サービスは、デシジョンリクエスト用のデータをアセンブリします。 最適なオプションが決定されるプロファイルエンティティのIDを決定します。 また、顧客プロファイルに保存されず、決定ロジックで使用される可能性のあるコンテキストデータもアセンブルします。
決定ロジックはアクティビティで構成され、各要素では、このアクティビティで考慮する必要があるオプションのサブセットのフィルターと、1つのフォールバックオプションを指定します。
各決定は、最初に制約を適用してオプションの数を減らし、残りのオプションをランキングすることで行われます。 ほとんどのロジックはDecisioningサービス内で評価されますが、これらの2つの側面を支援するために様々な補助サービスが使用されます。 例えば、制限サービスは、任意の決定でオプションを使用できる頻度の上限を管理し、別のサービスは、プロファイルおよびオプションのスコアの計算に使用される機械学習モデルをホストする場合があります。
Repository APIの使い方について詳しくは、APIを使用したDecisioningのエンティティとルールの 管理に関するチュートリアルを参照してください。
Decisioning Serviceランタイムの使用について詳しくは、APIを使用したDecisioning Service runtimeの 操作に関するチュートリアルを参照してください