この本書は2017年4月1日にTeradata Japanのブログに掲載された内容を、再掲載したものです。
掲載内容の正確性・完全性・信頼性・最新性を保証するものではございません。
また、修正が必要な箇所や、ご要望についてはコメントをよろしくお願いします。
著者 山本 泰史 （やまもと やすし）
「意思決定の自動化」と「リアルタイム・オファリング」
第8回： リアルタイム･オファリングの枠組み
リアルタイム･オファリングを実現する上、ルールを利用したオファリングの決定ロジックを構築すること、そしてオファリングを顧客に表現するためのマルチメディア･オブジェクトとしてのコンテンツ、それを顧客と接触させるためのチャネルが必要であることを解説してきました。今回は、これらをつなぎ合わせ、顧客がチャネルに接触した際にどのように働くのか、そしてそのつなぎ合わせ方にどのような選択肢があるのかを整理していきます。
処理の流れ
顧客はいずれかのチャネルを通じて、自社へのコンタクトを開始します。そして企業側では、このコンタクトをトリガーにオファーの案内を行ないます。オファーが提示された段階で、顧客はこのオファーを受諾する、拒否してチャネルを立ち去る、特に何の態度を表明することも無く、チャネル側に存在し続ける - この 3つの選択肢からいずれかを選択します。このような流れを図示したのが、以下の図16 です。
このプロセスの中におけるそれぞれのステップを概観していきます。まず、顧客がチャネルに接触した段階で、明示的、非明示的に幾つかの情報がインプットされます。
１．顧客識別子: 会員番号や電話番号等、顧客を識別するデータ
（カードのスキャン、ユーザーID／パスワードの入力等により取得）
２．行動情報: ボタンクリックや入力、画面タッチによるログデータ、口頭での回答等
３．環境情報: 顧客識別、及び行動情報が発生した場所や時間に関するデータ
（ログデータのタイムスタンプ、チャネル／端末の設置場所、表示ページやディレクトリーの位置等）
そして、顧客識別子と、場合によっては行動情報、環境情報の組み合わせによって、オファー案内を行なうトリガーが発生し、同一チャネル上でオファーが案内されます。案内されたオファーは顧客の目に留まり、顧客は以下の反応を示します。
１．オファーを受諾する：例えば Webサイト上であれば、表示されたオファーオブジェクトをクリックする
２．オファーを拒否する：最終的にチャネルから離れ、オファーは実現されないままその機会を終える
３．オファーを無視する：顧客はチャネルから離れず、次のオファー案内機会が残っている
ここでオファーが無視された場合、顧客は当該チャネルで何かしら次の行動を実施し、それに伴って次のログデータが発生します（また、非明示的には案内したオファーを無視したという実績データも得られます）。このため、このような情報をベースに次のオファーを組み立てることも考えられますが、その場合には再度顧客からのインプットが発生し、それに伴ってオファーを案内する流れに戻ることになります。そして最終的に顧客がオファーを受け入れることの無いままチャネルを離れた場合には「失敗」、何らかのオファーを受け入れていただけたのであれば「成功」とみなされます。ここでの「成功」とは、何かしら顧客が商品やサービスを契約、購入した／すること、もしくはそれに対して必要な次のステップ（詳細カタログの送付依頼、見積依頼、ショッピングカートに商品を追加等）に進んだことを意味します。
リアルタイム･オファリングのデザイン類型
ここで、インプットを受け取ってからオファーを案内するまでの流れは、以下図17 に記載した 3+1 つにパターン化可能です。
各パターンに共通することとして、オファーを起動させるためには顧客識別子（場合によっては付随するインプット情報も含める: 識別子プラス特定ページにアクセス等）をトリガーに利用する点が挙げられます。そしてこれも、単純ではありますがルールです。一方で本来、どのオファーを案内するべきかを決定付けるルールが存在します。ルールにどのデータを活用するかがパターン類別にあたっての重要なポイントです。まず、ルールに利用するデータとして、直近のデータを用いるか否か、履歴データを用いるか否かという点が 1つ目のポイントです。直近データとは顧客のチャネル接触によって発生したインプットデータ（識別子、行動情報、環境情報）であり、履歴データとは今回のチャネル接触以前に顧客が発生させたデータを意味します。直近データのみを利用する場合には、その場でデータを受け取ってルールを適用し、得られたスコアに基づいてオファーを特定します（パターン1 が該当）。これに対して履歴データのみを利用する場合、チャネル接触の前、つまり事前に履歴データを活用してルールを実行、スコアリングを済ませておくことが可能です。これによって、顧客にオファーを返すまでの時間を短縮することが可能となります（パターン3 が該当）。
直近データと履歴データの両方を利用する場合、パターンは 2つに分かれます。ルール実行をシンプルに保ちたい場合には、直近データが得られた時点で履歴データをルールに取り込み、ルール実行、スコアリング、オファー特定を行ないます（パターン2 が該当）。これに対して、途中まででもルール実行をしておき、中間スコアを算出しておくことによって処理時間を短縮できるかもしれません。この場合には直近のデータを得られた時点で追加の計算ルールを実行してスコアリング、オファー特定を実施するという流れになります（パターン2' が該当）。この場合、両方のデータを活用でき、なおかつレスポンスタイムの最小化も図ることができますが、事前の仕組みづくりは若干複雑となります。以下の図18 にそれぞれのパターン毎に処理フローを記述しました。
)
クリックでパターンごとの処理フローをご覧になれます
いずれのパターンも顧客が直近データ（図16 におけるインプット）をチャネル経由で生成させ、それをキックにルールが廻り、オファーが案内されます。そして顧客がオファーを受け入れてくれれば、何らかの更新処理がOLTPシステムに対して実行されます。パターン3 の場合、事前にスコアを作成し、案内するオファーは決定されていますが、「顧客が直近データを発生させたことをトリガーに事前準備したオファーが案内される」というシンプルなルールを実行します。
ルールの置き場所
レスポンスタイムと利用するデータを考えた場合、ルールを実行させる場所に関しても検討、考慮が必要になります。履歴データを用いてルールを事前実行し、事前スコアを得るのであれば、そのデータが存在するデータウェアハウス上で実行するのが合理的です。同様の理由で、直近データを利用するパターン1 のケースはチャネルシステム（Webサーバーやその裏で動く業務用データベース）側で実行されるのが合理的といえます。検討が必要になるのはパターン2 とパターン2' です。結局どちらが顧客サービス上問題の無いレスポンスタイムを得られるかで決定すればよいのですが、ルールを廻す処理が重いのであれば、他のサービスを実施しているチャネルシステム上ではなく、データウェアハウスに任せ、直近データもデータウェアハウスに持ってくるのが合理的です。パターン2' のように利用するデータを特定でき、なるべくシンプルな形式（事前にジョインした形式等）で準備しておけるのであれば、そのデータをデータウェアハウスからチャネルシステム側に渡しておき、そこで直近データと合わせて最終スコアリング、オファー特定という流れが良いかもしれません。システム・アーキテクチャ（どんなコンピューターとネットワークがあって、どんな処理がそれぞれ動いているか）は企業毎に異なり、往々にして複雑なので「これが最適解」と呼べる一般化記述はできませんが、指針を挙げるとするならば、「指針#1: 顧客を待たさないこと」と「指針#2: オファーの訴求力で妥協しないこと」の 2つです。この 2つの観点に合致する「ルールの置き場所」を探すのが、肝となります。