レコメンドエンジンのサイトへの応用

　今回は、前回「レコメンドエンジンの概要 - デジタル社会を泳ぐイルカ」で紹介したレコメンドの概要に続く記事となっております。少し裏側の技術的な部分もあるので、他の記事も参考にして頂きながら内容を見て頂けるといいかなと思っております。

目次

全体的なサイトレコメンドにおけるデータの流れ

　内容が少し難しい部分もあると思いますので、前回の記事と少し被せながら本日はお話ししていきます。まず前回もお見せしたように、元となる履歴明細データや所品データからレコメンドの計算結果を出し、そこからレコメンドを表示するためのレコメンド表示用DBを作るまでの流れを思い出してください。

レコメンドの仕組み①

　そして、今回はレコメンド表示用DBがそもそもどのような形でデータを保持しているのか、そして、それがサイトとどのようにやり取りするのかを示していきたいなと思います。

レコメンド表示用DBのデータの持ち方

　レコメンドのデータを出す部分までは、上記の図で何となくわかるかと思いますが、「レコメンド計算結果やレコメンド表示用DBってどのような項目を持っているの？」と聞かれればまだわからないなという部分も多いと思います。
　今回、少し遠回りしながらになりますが、持っている項目が何かを考えていきましょう。
　そこで、今回もアパレルショップの店員に自分がなったと考えて、リアルの世界ではどのようにレコメンドしているかを抽象化していきます。

　ある日、あなたが店員をしているセレクトショップに30代男性のDolphinさんという常連客が来店してくれました。
　来店時にあなたはDolphinさんという方を見て、30代男性だったというのを昔の会話の中から思い出し、その属性情報*1を元にこの人って、商品Aや商品Bがおすすめできそうだなと考えたりしてました。
　その後、Dolphinさんは商品Cの売場に移動し、商品Cを見てました。その際、あなたは商品Cを見ているということは、商品Dや商品Eをおすすめできるなと考えてました。
　少し迷った後、Dolphinさんは商品Cの売場で、あなたに対して、「他にも自分合いそうな商品はありますか？」と聞いてきました。
　その際、あなたはDolphinさんの見た目からわかる属性情報や見ている商品に基づいて、「商品A、商品B、商品D、商品Eなどがおすすめです！」とDolphinさんに合った商品をおすすめしました。
　そうするとDolphinさんからは「ありがとうございます！そうしたら、商品Dも見てみたいです！」という形で商品Dを次に見ていきました。

　最終的に商品を買ったか分かりませんが、確実にDolphinさんにとっては、あなたに商品をおすすめされることにより、購買に繋がる可能性は高くなったでしょう。では、上記の話をオンラインショップで考えるならどうでしょうか？少し冗長ですが、オンラインショップの場合にどうなるかを下に書いていきます。

　ある日、あなたが運営しているオンラインのセレクトショップに30代男性のDolphinさんという方が会員登録・ログインして、あなたのサイト上を回遊していました。
　トップページには、ログイン時にDolphinさんという方の属性情報を入力してもらい、30代男性という属性情報を取得しているため、この人っておすすめできる商品Aや商品Bをサイト上には「あなたへのオススメ」という形で表示します。
　その後、Dolphinさんは商品Cの商品詳細ページに移動し、商品Cを閲覧してました。その際、商品Cを閲覧しているということは、商品Dや商品Eをおすすめできるということで、「あなたへのおすすめ」という形で商品Dや商品Eを表示しました。
　少し商品Cの詳細ページに滞在した後、Dolphinさんは「あなたへのおすすめ」という部分の商品Dの詳細を見ようとリンクをクリックして、商品Dの商品詳細ページに遷移していきました。

　このように、正直オフラインの行動がオンラインでも同じように行われているんだということをまずは理解していただけると少し今回の話も分かりやすいかと思ってます！（少し希望的かもしれませんが。笑）
　では、上のオンラインショップでのストーリーの中で何が起こっていたのかを少し技術的に解釈してみましょう。そこで各フローを少し分解してみます。分解することが理解を深める上で非常に重要なので、わからないときには本当に理解できる粒度にちゃんと分解するようにしてみてください。
　今回のシチュエーションを、以下の2つに分解します。
　A．　トップページ（来店時の状態）
　B．　商品Cの商品詳細ページ（商品Cを見ている状態）

A．　トップページ（来店時の状態）
　早速ですが、トップページにおいて、取得できる情報なんでしょうか。今回は、ログインしている前提を設けますが、ログインしていれば、Dolphinさんの「顧客ID」の情報を取得することが出来ます。実は個人情報保護の観点で、サイト上に性別や年代といった情報はログインしてれば表示されているということではないというのは、覚えておいてください。ちなみに、少し脱線しますが、その「顧客ID」の情報を自社のデータベースを参照することで初めて、Dolphinさんの「性別」や「年代」という情報を取得することが出来、その取得の際には、以前紹介したSQLが実際に活躍している部分です。*2
　そして、「顧客ID」の情報を元に、商品A、商品Bというおすすめ商品を出しているということで、実は以下のようなリクエストとレスポンスのやり取りがブラウザとレコメンドサーバーの中でやり取りしています。（この辺は上級者にとっては当たり前かもしれません）

ブラウザとレコメンドサーバーのやり取り1

　上の図の中でもわからない単語がいくつか登場しているかと思いますので、少しだけ補足させて頂きます。まず、図の左側にあるブラウザに、「<レコメンドタグ>」と書いてありますが、これはブラウザ上で表示しているHTMLの中に存在するjavascriptを実行するためのタグ（scriptタグで記載）で、ブラウザからレコメンドサーバーへの商品情報の要求（request）をする役割を担ってます。また、①で記載したrequestの際にはブラウザ側からは「顧客ID」の情報をレコメンドサーバーに送信し、その「顧客ID」を元に、②でレコメンドする商品情報を抽出します。そして、③では、その商品情報をレコメンドサーバー側からブラウザ側に応答（response）します。
　ちなみに、この際に、レコメンド表示用DBにはどのようなデータが入っているべきでしょうか？図の②の過程で起こっていることにもつながりますが、②ではrequestとして送信された「顧客ID」を元にレコメンド表示用DBにて、絞り込みを実施しております。そして、DBの絞り込みでは以前お話ししたSQLにて実施しております。そのため、「顧客ID」の項目は存在しますが、それ以外にも商品情報をresponseとして返しているため、「商品ID」や「商品名」などの情報もレコメンド表示用DBには存在しているでしょう。*3加えて、レコメンド表示の際には、1番目おすすめなのか、2番目におすすめなのかを判別するためのランク若しくはスコアの情報が入っていることがほとんどでしょう。ゆえに、レコメンド表示用DBとしては、以下のようなデータを保持していることが多いです。

レコメンド表示用DBの例1

顧客ID	商品ID	商品名	商品画像URL	商品詳細URL	価格	ランク
c001	A	商品A	xxx	xxx	¥10,000	1
c001	B	商品B	xxx	xxx	¥20,000	2
c002	J	商品J	xxx	xxx	¥15,000	1
c002	K	商品K	xxx	xxx	¥25,000	2
c002	L	商品L	xxx	xxx	¥5,000	3

　そして、このレコメンド表示用DBに対して、Dolphinさんの顧客IDが仮に"c001"として、送信されてくる際には、以下のようなSQLが実行されて、"c001"に対する商品情報が抽出されます。

顧客IDが"c001"に対するレコメンド表示商品の抽出SQL

SELECT
　,商品ID
　,商品名
　,商品画像URL
　,商品詳細URL
　,価格
FROM
    レコメンド表示用DB
WHERE
    顧客ID LIKE 'c001'
ORDER BY
　ランク ASC
;

顧客IDが"c001"に対するレコメンド表示商品

商品ID	商品名	商品画像URL	商品詳細URL	価格
A	商品A	xxx	xxx	¥10,000
B	商品B	xxx	xxx	¥20,000

　さらに、③でレコメンドサーバー側で抽出されたデータはjson形式で戻されることが多いため、以下のようなjsonの値がサイト側には戻されます。*4

顧客IDが"c001"に対するjson形式のレコメンド表示商品データ

var items = [
    {
        "商品ID" : 'A',
        "商品名" : '商品A',
        "商品画像URL" : 'xxx',
        "商品詳細URL" : 'xxx',
        "価格" : 10000
    },{
        "商品ID" : 'B',
        "商品名" : '商品B',
        "商品画像URL" : 'xxx',
        "商品詳細URL" : 'xxx',
        "価格" : 20000
    }
]

　最終的には、このjson形式でブラウザ側に戻った際に、レコメンド表示する箇所に対して、レコメンド商品情報が表示される形になります。

B．　商品Cの商品詳細ページ（商品Cを見ている状態）
　一方で、商品詳細ページの場合の違いはあるのでしょうか？結論、違いはあります。図で見ると分かりやすいかと思いますので、改めて以下に図を示します。

ブラウザとレコメンドサーバーのやり取り2

　先ほどは、「顧客ID」をレコメンドサーバーに送信し、その「顧客ID」を元にレコメンド表示用DBからレコメンド商品情報を抽出し、ブラウザ側に応答しておりましたが、今回は「商品ID」をレコメンドサーバーに送信し、その「商品ID」を元にレコメンド表示用DBからレコメンド商品情報を抽出し、ブラウザ側に応答する形になります。そのため、レコメンド表示用DBも以下のように少し変わります。

レコメンド表示用DBの例2

商品ID	商品ID	商品名	商品画像URL	商品詳細URL	価格	ランク
C	D	商品D	xxx	xxx	¥15,000	1
C	E	商品E	xxx	xxx	¥25,000	2
P	Q	商品Q	xxx	xxx	¥15,000	1
P	R	商品R	xxx	xxx	¥25,000	2
P	S	商品S	xxx	xxx	¥5,000	3

　そして、先ほどと同様にSQLで以下のようにデータを抽出し、データをjsonに変更します。

商品IDが"C"に対するレコメンド表示商品の抽出SQL

SELECT
　,商品ID
　,商品名
　,商品画像URL
　,商品詳細URL
　,価格
FROM
    レコメンド表示用DB
WHERE
    商品ID LIKE 'C'
ORDER BY
　ランク ASC
;

商品IDが"C"に対するレコメンド表示商品

商品ID	商品名	商品画像URL	商品詳細URL	価格
C	商品D	xxx	xxx	¥15,000
C	商品E	xxx	xxx	¥25,000

"C"に対するjson形式のレコメンド表示商品データ

var items = [
    {
        "商品ID" : 'D',
        "商品名" : '商品D',
        "商品画像URL" : 'xxx',
        "商品詳細URL" : 'xxx',
        "価格" : 15000
    },{
        "商品ID" : 'E',
        "商品名" : '商品E',
        "商品画像URL" : 'xxx',
        "商品詳細URL" : 'xxx',
        "価格" : 25000
    }
]

さいごに

　このようにページごとに送信できる情報（顧客IDや商品ID）が異なると当然レコメンド表示用DBのデータの持ち方が異なる形になります。今回はそれぞれ別のデータの持ち方でお話ししましたが、実際には同じになるようなデータの持ち方をするケースの方が多いと思います。また、前回の記事でご紹介したユーザー相関やアイテム相関に、顧客IDを送信するパターンと商品IDを送信するパターンがそれぞれ対応することも覚えておけると良いと思います。ただ、この記事では、レコメンドのデータベースの項目やそもそもどのようなデータのやり取りがブラウザとレコメンドサーバーで発生しているのかを理解してもらいたいと考えております。そのため、今日はその2点をしっかりと抑えておいてください！

*1:デモグラフィックといったりもします。ちなみに、デモグラとマーケティングの世界で出てくるのはこのことです。

*2:参考1：データベースとは？ - デジタル社会を泳ぐイルカ、参考2：SQLの基礎① 〜 簡単なSQL文のご紹介（SELECT句、FROM句、WHERE句） 〜 - デジタル社会を泳ぐイルカ）

*3:レコメンドの仕様にも依存します

*4:参考3： データとは何か？ - デジタル社会を泳ぐイルカ