こんにちは、Customer Engineerのgamiです。

KARTEのサポートサイトでは、 「KARTEを使ってWebサイト上でレコメンドを表示できまっせ」 ということが謳われています。実際、KARTEの接客サービス配信機能とKARTE Datahubが使える環境であれば、KARTEで レコメンド用のデータ管理からWebサイトへのクリエイティブの配信までを一気通貫で実現 できます。

一方で、現状のKARTEにはレコメンド専用の機能があるわけではありません。いわゆる「レコメンド」と呼べるWebサイト上での表示を、KARTEの既存機能の組み合わせで実現することになります。

今回は、KARTEが言う所の「レコメンド」を実現する最低限の手順を簡単に紹介します。

「レコメンド」とは？

実際の手順を説明する前に、まずは前提の整理から始めます。
ここでは、「ユーザーが興味を持つ可能性が高いアイテムをWebページ上に表示したい」という状況を考えます。

一言に「レコメンド」と言っても、実際には様々な分類があります。たとえば次のような記事でレコメンドの分類について言及があります。

レコメンデーションの分類 | データ分析基礎知識

KARTEで実現する標準的なレコメンドでは、次の2つのロジックの組み合わせによってユーザーに表示するアイテムが決定されます。

A. 表示先の「ユーザー」が関心を持っている「アイテム」を特定する
B. その「アイテム」と関連性が高い「関連アイテム」を選出する

スクリーンショット2023-04-2811.37.12.png

たとえばECサイトにおける「商品詳細ページ」によく表示されるレコメンドに、 「この商品を見ている人がよく見ている他の商品」 というものがあります。
その例で言えば、「A: ユーザーが現在見ている商品」について、「B: その商品とよく一緒に見られている関連商品」をレコメンドするということになります。

以下、これらのロジックを 「A. ユーザーとアイテムの紐付け」 と 「B. アイテムと関連アイテムの紐付け」 と表現します。
KARTEの標準的なレコメンドでは、Aを「ユーザーデータ（を埋め込んだユーザー情報変数）」で、Bを「Datahubクエリ」で実現します。

今回はわかりやすさのためにECサイトでの商品レコメンドを例に説明します。なお、レコメンド対象の「アイテム」はいわゆる「商品」に限りません。たとえば「記事」のレコメンドや「スタッフ」のレコメンドなど、どんなアイテムでも同様にレコメンドできます。

レコメンドに必要なデータ

もちろん、データが全く無い状況からレコメンドを実現することはできません。具体的には、次の2種類のデータが存在することが前提になります。

「A. ユーザーとアイテムの紐付け」に必要なデータ
- α. ユーザーのアイテムに対する行動を計測するイベントデータ
  - ex) view_item（商品閲覧）、buy（商品購入）、favorite（お気に入り登録）
「B. アイテムと関連アイテムの紐付け」に必要なデータ
- β. アイテムのマスタデータ
  - ex) 商品マスタフォーマット
- α. ユーザーのアイテムに対する行動を計測するイベントデータ（同上）

それぞれについて簡単に説明します。

α. ユーザーのアイテムに対する行動を計測するイベントデータ

最も重要なのは、 「このユーザーがこのアイテムに興味を持った」ということが明らかに分かるイベント をKARTEで取得することです。
たとえば商品詳細ページの閲覧時にview_itemイベントを取得していれば、「このユーザーはこのアイテムの詳細情報を見た」ということがわかります。

こうしたイベントデータは、「A. ユーザーとアイテムの紐付け」と「B. アイテムと関連アイテムの紐付け」の両方で利用することができます。

スクリーンショット2023-04-2811.44.51.png

view_itemイベントを取得していれば、レコメンド表示先のユーザーが直近閲覧したアイテムがわかります。これにより、 「目の前のユーザーがどのアイテムに興味があるか？」 を特定でき、 「A. ユーザーとアイテムの紐付け」 を実現できます。

同時に、全ユーザーのアイテム閲覧データがview_itemイベントのログの形でKARTEに蓄積されます。それをDatahubクエリで集計すれば、 「ある商品を見ている人が他によく見ている商品」 を計算することができます。これが 「B. アイテムと関連アイテムの紐付け」 を実現するロジックになります。

β. アイテムのマスタデータ

もちろん、最終的にレコメンドを表示するには、レコメンドの表示に必要なアイテム関連データが必要になります。具体的には、下記のようなデータです。

アイテムID
アイテム名
アイテム画像URL
アイテムページURL

また、カテゴリやブランド等での絞り込みを実現したい場合はそれらの情報も必要になります。なおECサイトにおける標準的な商品マスタフォーマットについては、KARTEでも次のページにあるような形で定義されています。

商品・在庫マスタフォーマット | レシピ / データハブ / アクション | KARTEサポートサイト

レコメンドの実装手順

前提の説明が長くなりました。
ここからは、実際にレコメンドを実装してみましょう。

まず、レコメンド表示に必要なデータ連携の全体像を図で示します。

スクリーンショット2023-04-2814.02.03.png

view_itemイベントの実装

商品の閲覧をベースにしたレコメンドを実現するには、view_itemイベントの実装が必要になります。
ユーザーが商品詳細ページを閲覧したタイミングで、次のようなKARTEのタグが実行されるようにします。

<script>
krt('send', 'view_item', {
    item_id: '0001' // アイテムID. 実際には閲覧ページ毎に動的に値が変わるようにする
});
</script>

ここでは、最低限必要なitem_id（閲覧した商品のID）だけをフィールドに含めています。
実際には、他にも取れるフィールドがあれば全て取得しておいた方がいいでしょう。

view_itemイベントの実装については、次のページに記載されています。

閲覧商品情報を計測する | スタートガイド / タグ設置・イベント計測 / カスタムイベントタグ | KARTEサポートサイト

もちろん、「このユーザーがこの商品に興味を持った」ということがわかるイベントであればview_itemイベントに限らずどんなイベントもレコメンドに利用できます。

商品マスタの連携

商品マスタデータがDatahubに連携されていない場合は、新規に連携を開始する必要があります。
具体的には、次のような連携が必要です。

自社の商品管理システム等から、商品マスタデータを格納したCSVファイルを、Google Cloud Storageなどのストレージに対して定期的に出力する
Datahubジョブフローで、そのCSVファイルをインポートするためのジョブを定期実行する

これにより、新しい商品データが増えた場合にも、定期的に（たとえば日次などで）新商品の情報をレコメンドに反映できるようになります。
もちろん、Datahubに格納された商品マスタデータは、レコメンド以外にも活用することができます。

ここでは、次のようなカラムを持つ商品マスタがDatahubデータセットに連携されているとします。

field	sample
item_id	001
name	デニムジャケット
image	https://example.com/item001.jpg
url	https://example.com/items/001/

ここでは、商品マスタを格納しているテーブル名を
prd-karte-per-client.item_master_{{api_key|safe_param}}.item_master
とします。

レコメンド用クエリ作成

必要なデータが準備できたら、いよいよ 「B. アイテムと関連アイテムの紐付け」 を計算するためのクエリを作成します。
といっても、Datahubではよく使うクエリをダウンロードできる「クエリコレクション」機能があります。今回は 「商品軸での商品レコメンド」 というクエリコレクションをベースにクエリを作成します。

クエリコレクションから「商品軸での商品レコメンド」を選び、 [このクエリを利用] をクリック
最低限のデータでレコメンドを実現したいので、クエリを次のような観点で修正
- アイテム間の関連性の計算には、view_itemイベントだけを利用し、buyイベントは使わない
- サンプルデータが少ない検証環境を想定し、 HAVING users >= 5 という条件を除外
- 不要なカラムをコメントアウト

WITH view AS (
  SELECT
    sync_date
    , visitor_id
    , JSON_EXTRACT_SCALAR(values, '$.view_item.item_id') AS item_id
  FROM {% karte_event period[0], period[1] %}
  WHERE event_name = 'view_item'
)
-- , buy AS (
--   SELECT
--     sync_date
--     , visitor_id
--     , REGEXP_EXTRACT_ALL(JSON_EXTRACT(values, '$.buy.items'), r'"item_id":"([^"]+)"') AS item_ids
--     , REGEXP_EXTRACT_ALL(JSON_EXTRACT(values, '$.buy.items'), r'"quantity":(\d+)') AS quantities
--   FROM {% karte_event period[0], period[1] %}
--   WHERE event_name = 'buy'
-- )
-- , buy_with_item AS (
--   SELECT
--     sync_date
--     , visitor_id
--     , item_id
--     , IFNULL(SAFE_CAST(quantity AS INT64), 1) AS quantity
--   FROM buy, UNNEST(buy.item_ids) AS item_id , UNNEST(buy.quantities) AS quantity
-- )
, action_log_raw AS (
  SELECT
    'view' action
    , sync_date
    , visitor_id
    , item_id AS item_id
    , null as quantity
  FROM view
  -- UNION ALL
  -- SELECT
  --   'purchase' action
  --   , sync_date
  --   , visitor_id
  --   , item_id AS item_id
  --   , quantity
  -- FROM buy_with_item
)
, action_log AS (
  SELECT
    action
    , sync_date
    , visitor_id
    , item_id
    , quantity
  FROM action_log_raw
)
, ratings AS (
  SELECT
    visitor_id
    , item_id
    , SUM(CASE WHEN action = 'view'     THEN 1 ELSE 0 END) AS view_count
    -- , SUM(CASE WHEN action = 'purchase' THEN quantity ELSE 0 END) AS purchase_count
    -- , 0.7 * SUM(CASE WHEN action = 'view' THEN 1 ELSE 0 END) + 0.3 * SUM(CASE WHEN action = 'purchase' THEN quantity ELSE 0 END) AS score
    , 1 AS score
  FROM action_log
  GROUP BY visitor_id, item_id
)
, product_base_nomalized_ratings AS (
  SELECT
    visitor_id
    , item_id
    , score
    , SQRT(SUM(score * score) OVER (PARTITION BY item_id)) AS norm
    , SAFE_DIVIDE(score, SQRT(SUM(score * score) OVER (PARTITION BY item_id))) AS norm_score
  FROM ratings
)
, item_master AS (
  SELECT *
  FROM `prd-karte-per-client.item_master_{{api_key|safe_param}}.item_master`
  -- WHERE recommend_f = 1
  -- AND item_id IS NOT NULL
)
, aggregate_ratings AS (
  SELECT
    a.item_id AS target
    , b.item_id AS related
    , COUNT(a.visitor_id) AS users
    , SUM(a.norm_score * b.norm_score) AS score
  FROM product_base_nomalized_ratings AS a
  JOIN product_base_nomalized_ratings AS b
  ON a.visitor_id = b.visitor_id
  WHERE a.item_id != b.item_id
  GROUP BY target, related
  -- HAVING users >= 5
)
, aggregate_ratings_with_items AS (
  SELECT *
  FROM aggregate_ratings AS a
  INNER JOIN item_master AS b
  ON a.related = b.item_id
)
, aggregate_ratings_with_key AS (
  SELECT
    ROW_NUMBER() OVER(PARTITION BY target ORDER BY score DESC) AS rank
    , CONCAT(target, '_', FORMAT('%02d', ROW_NUMBER() OVER(PARTITION BY target ORDER BY score DESC))) AS key
    , *
  FROM aggregate_ratings_with_items
)

SELECT
  key
  , target
  , related
  , name
  -- , price
  -- , display_price
  , image
  , url
  -- , l_category_cd
  -- , s_category_cd
  -- , brand_cd
  -- , sex_cd
  -- , brand_name
  -- , TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL {{ttl_hour}} HOUR) AS expired_at
FROM aggregate_ratings_with_key
WHERE rank <= 20

スクリーンショット2023-04-2812.36.05.png

アクションテーブルの作成と更新

レコメンド用の接客サービスからデータ参照するためのアクションテーブルを作成します。
ここでは、 itembase_recommend という名称でアクションテーブルを作成するものとします。

アクションテーブルを新規作成する
- [ウィジェットからの参照] をONにする
- スキーマは下記の通り

field	type	description
key	文字列	主キー
target	文字列	元となる商品ID
related	文字列	レコメンドされる商品のID
name	文字列	レコメンドされる商品の名前
image	文字列	レコメンドされる商品の画像URL
url	文字列	レコメンドされる商品のWebページURL

スクリーンショット2023-04-2813.21.30.png

なおアクションテーブルでは主キーが必須なので、クエリの中で #{target}_#{順位}という形式のkeyを生成し、主キーとしています。

アクションテーブル更新用ジョブフローの作成・実行

作成したアクションテーブルにデータを投入するジョブフローを作成・実行します。

ジョブフローを新規作成する
- エクスポート元: クエリの実行結果
  - 作成したクエリを選択
- エクスポート先: KARTEアクションテーブル
  - 作成したアクションテーブルを選択
- 適当なジョブ名やジョブフロー名を付けて保存
ジョブフローを [今すぐ実行] する

スクリーンショット2023-04-2812.46.13.png

ジョブが無事に終了したら、レコメンド用アクションテーブルの更新に成功したことになります。

アクションテーブルクエリの作成

今回実現したいレコメンドでは、商品IDを1つ指定してレコメンド用アクションテーブルにアクセスし、複数の関連商品データを取得する必要があります。
1つのitem_id（ target ）に対してレコメンド対象商品のレコードを複数返す必要があるため、主キーでの取得ではなくアクションテーブルクエリを使ったデータ取得（getByQuery）をする必要があります。

アクションテーブルクエリを新規作成し有効化
- クエリ名: 今回は related_items と設定
- 抽出条件
  - Limit: 20
  - Filter: target = #{target}
  - Sort: key, 昇順

このアクションテーブルクエリを利用することで、 targetというパラメータ名で商品IDを連携すると関連する商品を最大20件取得 できます。またkeyの昇順で並び替えることで、関連性の高い商品が先に並ぶようになります。

スクリーンショット2023-04-2813.28.17.png

レコメンド用接客サービスの作成・配信

KARTEレコメンドプラグインがONのプロジェクトでは、レコメンド用のアクションテンプレートを利用することができます。

ここでは、 「KARTEレコメンド（商品軸）prod_mr_v3.4」 というテンプレートを利用してみます。

テンプレートのJavaScriptでは予め様々な処理が記述されていますが、要するに下記のようなプログラムでアクションテーブルからレコメンド商品のリストを取得できます。

var TABLE_NAME = 'itembase_recommend'; // アクションテーブル名
var QUERY_NAME = 'related_items'; // アクションテーブルクエリ名
var viewedItemId = #{viewedItemId}; // 配信先ユーザーの閲覧商品ID（「ユーザー情報変数」）
var table = widget.collection('v2/' + TABLE_NAME);
table.getByQuery(
    QUERY_NAME,
    { target: viewedItemId },
    function(err, items) {
        console.log('items: ',items);
    }
);

ここで重要なのは、「ユーザー情報変数」を使って配信先ユーザーが直近で閲覧した商品のIDを取得している点です。
スクリーンショット2023-04-2813.03.39.png

これにより、 「A. ユーザーとアイテムの紐付け」 を実現しています。

アクションの作成ができたら、下記の注意点を意識して接客サービスの配信設定を行います。

view_itemイベントを配信トリガーに設定することで、ユーザー情報変数でも「まさに今閲覧している商品ID」を参照できる
まずは検証のためにテストユーザーだけに限定して配信する

レコメンドの表示確認

これですべての準備が整いました。
いよいよ接客サービスを公開し、実際のWebサイトでレコメンドが表示されることを確認します。

スクリーンショット2023-04-2813.38.28.png

以上で、下記のデータフローを一通り実装することができました。簡単ですね！

スクリーンショット2023-04-2814.02.03.png

最後に

今回は、KARTEでレコメンドを表示するための最低限の手順について紹介しました。
見て分かるように、KARTEで実現するレコメンドでは様々な部分でカスタマイズする余地があります。たとえば次のカスタマイズ観点があります。

どんなユーザー行動データ（イベント）を使って「A. ユーザーとアイテムの紐付け」を計算するか？
どんなユーザー行動データ（イベント）「B. アイテムと関連アイテムの紐付け」を計算するか？
「B. アイテムと関連アイテムの紐付け」をどんなロジックで計算するか？
レコメンドを画面上のどこにどう表示するか？
どんなセグメントのユーザーにどんなロジックのレコメンドを表示するか？

こうしたカスタマイズを、KARTE上の設定やJavaScript / SQLの実装を変更するだけで実現できます。こうした拡張性の高さが、KARTEで実現するレコメンドの魅力の1つだなと感じました。

KARTEでレコメンドを実装してみた