この本書は2017年4月1日にTeradata Japanのブログに掲載された内容を、再掲載したものです。
掲載内容の正確性・完全性・信頼性・最新性を保証するものではございません。
また、修正が必要な箇所や、ご要望についてはコメントをよろしくお願いします。
著者 山本 泰史 （やまもと やすし）
「意思決定の自動化」と「リアルタイム・オファリング」
第11回： シナリオ#3 [Webサイト来訪顧客へのオファー]
リアルタイム･オファリングの実行シナリオ、最後にご紹介するのは Webサイト来訪顧客へのオファー案内です。想定としてオンライン旅行代理店を考え、サイト来訪顧客の閲覧ページに応じてオファー案内することを考えます。今回は顧客の中でも、「首都圏の一都三県に居住する顧客が、国内旅行」に出かけるというシーンを想定します。顧客は Webサイト上で「国内旅行」の希望旅行地をクリックし、それに伴って当該地域の旅行商品情報がリスト表示されます。このときにどんなオファーを案内すべきか検討していきます。顧客はサイト来訪段階で会員向けページにログオンし、これによりサイト内行動に関するクリックストリーム・ログを取得することができるという前提です。
図29 は、希望旅行地（例えば北海道等）を指定した後のサイト画面です。「指定条件部分」には顧客が指定した旅行商品の条件が表示されます。そしてその条件に従って、各商品が「表示結果部分」に表示されます。また、予約された商品に関しては「カート部分」に登録され、申込み／決済画面へと進みます。そしてオレンジ色の部分「掲載枠」がオファーを案内する枠です。そして、この掲載枠に掲載するオファーの内容に関して、以下 3種類の候補を検討しています。
１．A. 期間限定！ 方面格安旅行パック
２．B. 現地利用のレンタカー手配。今なら 10％オフ
３．C. 先着 100名様！ 何某ブランドのトラベルポーチプレゼント
ここで、A の 部分には顧客自身が指定した旅行地を埋め込む、可変フィールドです。ここをクリックすると、当該旅行先に関する格安旅行パックの一覧がリストされるように仕込んでおきます。B を選択した場合、レンタカーの申込み画面に遷移し、10％割引での予約がなされ、カートに含まれます。C を選択した場合にはトラベルポーチのイメージ写真と、キャンペーン申込みボタンが表示された画面に遷移し、ダミー商品としてカートに入れられ、旅行手配を申し込んだ時点で顧客に送付されます。
そしてここでの命題は、来店された任意の顧客に対して、A/B/C のいずれを案内すべきか決定するルールを構築し、自動的に最も受諾確率の高いオファーを案内することです。
事前の分析
ルールの構築にあたり、ここではロジスティック回帰分析を用いることとします。ロジスティック回帰分析は、既に発生した事象データ（結果変数）と、それに関連しそうなデータ（説明変数）を利用して数式モデルを構築し、顧客毎の発生確率を算出する手法です。理想的には A/B/C それぞれの広告をランダムに案内して、反応をした顧客群と反応しなかった顧客群のデータを取得し、それを用いて数式モデルを構築するのが望ましいです。しかしながら現実的にこのような試験的マーケティングを実施するのが難しい場合には、過去の類似のキャンペーン結果や、類似の購買行動を結果変数として代用します。上記オファー候補の場合には、以下のようなデータが結果変数に近しいです（あくまで代用です）。
１．A. 格安旅行パックに申し込んだ顧客群
２．B. レンタカーを手配した顧客群
３．C. グッズ特典（トラベルポーチに限らず）に反応した顧客群
ロジスティック回帰分析の数式モデルは、確率値 = 1/（1+e-F）で表され、F部分には F = a0 + a1x1 + a2x2 +...+ anxn が代入されます。ちょっと複雑に思われるかもしれませんが、e は定数で 2.718... という一定の値を意味します。an にはその数式モデル特有の定数が設定されます。xn はそれぞれの顧客に関する変数であり、顧客行動、属性等が当てはまります。そしてこの数式で表される確率値は 0 から 1 の間で算出され、それはそのまま事象の発生確率を意味します。今回は A/B/C それぞれに対して 3つの数式モデルを構築し、得られた 3つの確率値を比較して、もっとも高いスコアを得られたオファーを案内することにします。
ここで、得られた数式モデルの 1つが以下であったと仮定します。現実のモデルではありませんが、確率値が様々に分岐する例としてご紹介します。
１．確率値 = 1/（1+e-F）
２．F = 0.1 + 3x1 - 4x2 + 0.5x3 - 0.02x4 - 0.01x5
３．x1 = 旅行先： 沖縄
４．x2 = 旅行先： 京都
５．x3 = 旅行先： 北海道
６．x4 = 自社利用回数
７．x5 = 会員月数
x1 から x3 の変数は、例えば A であれば、格安旅行パックに申し込んだ顧客がどこに旅行したかを意味し、旅行した場合は 1、しなかった場合は 0 で表されます。本来はその他の旅行先も変数として組み入れられるべきかもしれませんが、ここでは割愛します。自社利用回数は何回、会員月数は何ヶ月という量的変数です。x1 から x3 の変数は、沖縄に行ったのであれば x1 = 1、行ったことがなければ x1 = 0 を付与します。このようなバリエーションを考えた場合、1人の顧客がどこに旅行したかで、反応確率（格安旅行パックに申し込む確率）が大きく変動することになります。これを示したのが、図30 です。前述の数式に x1 から x5 を代入して得られる確率を表しています。
ここで重要な点は、x1 から x3 の変数が変化することによって、確率値が限りなく 0 に近い場合、確率値が五分五分になる場合、確率値が限りなく 1 に近い場合に変化するという点です。そしてこれは、サイトに来訪する顧客がどの地域に旅行したいかによって、前述したオファーA/B/C それぞれの確率が変化し、案内すべきオファーが変化する可能性を意味します。
またデータ取得を考えた場合、顧客が Webサイトを訪問し、ログオンし、希望旅行地を設定した段階で、顧客がどこに旅行するかが判明することも考慮すべき点です。数式モデルは完成したのですが、x1 から x3 の変数は、この段階まで把握できず、であるが故にこのタイミングまで最終的な確率値を算出できないのです。このため、このオファーを案内するためには直近で得られた希望旅行地を取得してリアルタイムでスコアリングし、得られたスコア（確率値）をもとにオファーA/B/C を比較し、最も高いスコアを得られたオファーを案内することとします。
（実際に構築される数式モデルが利用する変数候補として、沖縄、京都、北海道だけでなく、国内各所が挙げられます。また、当然ながら数式モデルによってはこれらの変数が採用されない可能性や、一部の地域のみ採用される可能性もあります。従って、リアルタイムで得られる変数を利用する必要の無いモデルも存在するかもしれません。加えてリアルタイムでスコアリングを行うという選択肢だけでなく、想定される全ての旅行地と全ての顧客の組み合わせに関して、総当たり形式でスコアリングを実施しておき、スコア比較を行い、案内すべきオファーを確定しておくという選択肢も存在します。但しこの場合には膨大なコンピューター資源（バッチ処理時間とディスク領域）を用意して準備しなければならず、しかも顧客が来訪するタイミングはランダムかつ非同期であるため、努力のわりに報われない、無駄の多い作業になってしまう危険性も否めません。一方でリアルタイム･スコアリングの時間がチャネル上で顧客を待たせてしまう原因となる可能性もあります。リアルタイムで処理するか、事前処理をしておくかはトレードオフの関係にあり、コストと効果、顧客サービスの観点で考慮／決定する必要があります。）
ルール
顧客が図29 のページを表示させる要求をした段階で、以下のような情報を自社は取得できたことになります。また顧客番号をキーに、過去の履歴データ、属性データも利用可能です。
１．誰がアクセスしたのか？ （ログインID、顧客番号）
２．いつアクセスしたのか？ （訪問日時）
３．旅行予定日、期間
４．希望旅行地
この段階で、顧客番号と希望旅行地を変数として引き渡し、同時にデータウェアハウス内の過去の履歴データ、そして属性データから、変数として利用されるデータを引き渡し、オファーA/B/C の数式モデルそれぞれに投入します。引き渡されるデータはいずれもサイト訪問のあった単一顧客に関するデータです。得られた 3つの確率値を比較し、もっとも高い確率値を得たオファーを選択して、これを伝えるためのマルチメディアオブジェクト（バナー広告のイメージファイル等）を図29 内の掲載枠に表示させます。ここまでのルールを図示したのが、図31 です。
評価
この案内の実装、そして展開によって、顧客の反応度が理解できるようになります。これはオファー毎に異なり、それぞれのオファーが有している優秀さを示してくれます。単純に案内表示した顧客数に対して、反応を得られた顧客数を見ることでこの反応率を理解することが可能です。また、各モデルから得られる確率値の分布が異なることも理解できるはずです。オファーA に対する確率値の平均が 0.3、これに対してオファーC の確率値平均が 0.1 であるとするならば、オファーC がオファーA の確率値と比較されたときに勝利し、生き残る回数は少ないと想定されます。単純に確率の高いオファーを案内することが命題であれば、このような違いは無視して構いません。しかしながら、「オファーC： 先着 100名様に対するポーチプレゼント」のオファーをなるべく早く案内して先着 100名を確定したい場合には、意図的に確率値にバイアスをかけ、オファーC が選択される割合を高める必要もあります。方法は色々考えられますが、オファーC の確率値 *n で他のオファー反応確率と比較する、勝利した確率値の値が 0.3 未満の場合には優先的にオファーC に案内を変更する、...等です。
もう 1つ検討すべきテーマとして、モデルの改善があります。実施しているモデルを使って顧客にオファーをしていく中で、実績データは集まってきます。オファーに反応する顧客と反応しない顧客がいるため、このデータを利用して再度モデルを作りなおすことが可能となります。加えて導入段階では、案内機会そのものを半分に分け、旧モデルと新モデルを案内し、どちらが好ましい結果を得られるか比較することも可能です。例えば旧モデルと新モデルを来訪顧客それぞれに交互に試しても良いですし、それぞれ数週間ずつ展開して比較しても構いません。同じことは、複数の異なるマルチメディア･オブジェクト案を比較する際にも実施可能です。この手法は A/B テスト、スプリットラン等と呼ばれますが、異なるデザインイメージをそれぞれ提示し、好ましい反応を得られる方を最終的な案内メッセージとして利用します。反応データとして客観的な支持を示すに値するだけの一定データ量を確保できるのであれば、2つ以上の複数の選択肢も評価可能です。