この本書は2017年4月1日にTeradata Japanのブログに掲載された内容を、再掲載したものです。
掲載内容の正確性・完全性・信頼性・最新性を保証するものではございません。
また、修正が必要な箇所や、ご要望についてはコメントをよろしくお願いします。
著者 山本 泰史 （やまもと やすし）
「意思決定の自動化」と「リアルタイム・オファリング」
第7回： チャネルとコンテンツの種別
リアルタイム･オファリングの定義は、顧客からのインバウンド･コンタクトが発生したという、希少かつ絶好の機会を活用するということ、そしてそのタイミング／その場でオファリングを実施するということについて整理しました。今回はこの定義に基づいて、オファリングに利用されるチャネルおよびコンテンツについて類別することによって、リアルタイム・オファリングの構成要素を概観していきます。
利用可能なチャネル
リアルタイム･オファリングの定義から鑑みた場合、リアルタイム･オファリングを実装できるチャネルには限りがあることが分かります。まず顧客からのインバウンド･コンタクトを受け付けられるチャネルであること、そしてその場でオファーを返せることです。このような観点から考えた場合、以下のチャネルがこれに該当します。
コールセンター - 顧客が電話をかけ、オペレーターが応答します。オペレーターが個人識別可能な情報をお伺いし、それに基づいてプロファイルやオファー候補が呼び出されます。システム的にはオペレーターの画面を介してオファー候補がリストされます。オペレーターはリストアップされたオファーを顧客に伝え、顧客への提案を行ないます。
Webサイト - 顧客が Webサイトにアクセスし、顧客番号のような識別可能情報を入力します。これに基づいてブラウザー画面が個別化され、画面内の一部分が当該顧客向けのオファー表示部として利用されます。システム的にはコールセンターのオペレーター画面を、顧客が自ら操作するのと同じですが、オペレーター支援的なインターフェースは、顧客向けのインターフェースに取って代わられます。また、これは分けて考えるべきか迷うところですが、携帯端末用の Webサイトも考え方は同じです。識別情報に関しては携帯端末の固有情報が代替します。
キオスク端末 - キオスク端末は、支店店頭や空港等の商業施設で来場者への情報提供を目的に利用されるセルフサービス端末です。利用者は端末に付随した読み取り機器でカードをスリップしたり、スキャンさせたりすることによって、個人向けの画面が表示されます。多くの場合テクノロジーとしては Webブラウジングと同一のものが採用されていますが、タッチパネルで操作しやすいようにインターフェースは調整されています。また、オファー内容は画面、もしくは付属のプリンター等を経由して案内されます。
POS端末 - 小売店に設置された取引精算用の端末です。カード情報をスキャンし、買上商品をスキャンし、支払いを行ないます。このタイミングでレシート、もしくはレシートと一緒にクーポンを発行し、そこにオファーを印字します。顧客はそれを次回の買物に利用することができます。
ATM端末 - 金融機関が設置する現金引出／預入等の操作を行なう、セルフサービス端末です。カードをスリップし、暗証番号を入力することで個人を識別します。インターフェースは通常キオスク端末と同様、タッチパネルでの操作を前提としたもの（および幾つかのボタン）となっています。従ってこの画面インターフェースを介してオファーを案内します。
上述したチャネルはいずれも、多くの場合は Web のテクノロジーを利用しています。Webサーバーからのサービスを提供するクライアント端末（ブラウザー端末）としての役割を担っており、インバウンドチャネルとして顧客の要求に対してサービスを提供していく形態をとっています。従ってオファーコンテンツは、全てクライアント側のブラウザーでハンドリングできる形式で用意される必要があります。
オファーコンテンツの類別
ブラウザーでハンドリングできる情報の代表的なものとして、ファイル形式で保持されたテキスト、画像、文書（テキスト+画像）、動画（音声のみ or 音声 + 動画 or 動画のみ）、フラッシュ（画像 + 動画）のようなマルチメディアオブジェクト群が挙げられます。一方で各チャネル間では、表示インターフェースに関してスペース上の制約が存在します。例えばパソコンのブラウザーに向けた画像ファイルと、携帯端末のブラウザーに向けた画像ファイルでは、表示可能なスペースが異なります。また利用者側で可能なアクションも異なります。例えばプリンターデバイスを通じてオファーを実施する POS端末では、リッチなフラッシュコンテンツに載せてオファーを届けることは出来ません。コールセンターのオペレーター端末に画像や動画を表示させても、オペレーターは声でオファーを届けるしかありません。従ってこの場合に適したコンテンツ種別はテキスト（オペレーターが読める形式）に限定されます。このように、幾つかのチャネル間でコンテンツを共用したい場合には、オファーコンテンツの修正や、チャネル特性に応じたコンテンツ種別の選択が必要です。
コンテンツの中身にはオファー内容、例えば商品やサービスの紹介や訴求点、割引やインセンティブが盛り込まれます。また、特殊なものとしては顧客が印刷して実際に割引を適用してもらうためのバーコード画像等が挙げられます。これを POS端末やキオスク端末で実際にプリントアウトしてもらう形でオファー案内する場合には、他のコンテンツの一部としてバインドされてアウトプットされます。
データとしての捉え方
このようなチャネルとマルチメディア･オブジェクトの関係をデータとして捉えていくとき、その関係性は図15 のような形式となります。
実際のデータベースとして実装するにあたってはオブジェクトの作成者や更新日時、バージョン等が管理される必要があり、チャネルに関してもより詳細なレベルで管理すべきかもしれませんが、骨組みとしては大きくオブジェクトそのものを管理する部分、チャネルそのものを管理する部分、そしてチャネルとオブジェクトの関係を記述する部分がその骨格です。この例では、.jpgファイルとして用意されたバーコードイメージを管理しており、これを POS端末とキオスク端末にて利用することが可能であるという記述がしてあります。キャンペーンをセットアップする際にはこの .jpgファイルを呼び出すか、この .jpgファイルを含めた .htmlファイルや .bmpファイルを呼び出し、各チャネルでの表示や印刷用に用います。Webサイト上でのバナー広告や、コールセンター用のスクリプト、キオスク端末や ATM端末に表示させる動画に関しても、同様の形式で管理されます。また、実際のファイル位置に関しては、ここではローケーション情報（ファイルパスや URL）を記述しています。方法としてはデータベース上に管理する方法と、ディレクトリー上に管理する方法の両方が考えられます。当然ながらチャネル上で利用されることを考えると、高い頻度でダウンロードされた際にパフォーマンス上の問題とならない場所に配備されなければなりません。
さらにこれを、本稿で述べてきた意思決定の文脈で考えた場合、それぞれのオブジェクトが実際のオファーを表現してくれる対象であり、1つないしは複数のオブジェクトによって単一のオファーが表現される関係にあります。意思決定=最も適したオファーの選択であるとした場合、もっとも高い反応確率を得られるであろうオファーを選択することによって、自動的に利用されるオブジェクトが決定され、チャネル上で表現されることになります。また、チャネル側でオファー案内をするスロットが、単一の顧客コンタクトにおいてどの程度あるかも考慮しなければなりません。仮に Webサイト上でオファーをすることを考え、自社が膨大な品揃え（例えば書籍や音楽 CD等）を有していて、表示可能なオファーのスロットが 6つあるとします。この場合、確率上位 6つまでのオファー候補が表示され、顧客に対して提案されます。一方で例えば ATM端末上。端末を引き出したい顧客の時間的な制約や、インターフェース上の制約から、スロットが 1つしかないのであれば最も確率の高いオファーが選択されます。そしてこのようなオファーの選択プロセスが、本連載第5回で紹介した確率の算出と、それを利用したオファーの選択ルールです。次回からは、実際に顧客がチャネル上に現れてから、ルールを使ってオファーを選択／案内し、それを確定するまでの流れについて概観していきます。