本記事は ZOZO Advent Calendar 2023 シリーズ 7 の 20 日目の記事です
概要
こんにちは。推薦基盤ブロックの関口です。本記事では、ZOZOTOWNホーム画面上で実施したユーザーパーソナライズPJの一環として、「レコメンドモジュールのアイテム特徴推薦導入」についてご紹介いたします。
前提
ZOZOTOWNのHOME画面は、「タイトル、一覧ページ、コンテンツ（商品）」の3つのパーツで構成された多数のモジュールで構築されています。
これらのモジュールは以下の4つに大別されます。
| モジュール名 | 説明 |
|---|---|
| 導線モジュール | 閲覧した商品を軸としたリターゲティング系モジュール |
| 企画モジュール | トレンド商品や企画商品など企画チームが考案したモジュール |
| 広告モジュール | 広告商品用モジュール |
| レコメンドモジュール | ユーザーごとにパーソナライズされたモジュール |
本記事では、推薦基盤チームが開発・運用しているレコメンドモジュールの一つ、「チェックしたカテゴリーのおすすめアイテム」モジュールにおける施策を紹介します。このモジュールは、ユーザーの商品閲覧情報やお気に入りアイテムの情報から商品カテゴリーをもとに推薦するモジュールです。
今回の施策では、画像中の赤枠で示される商品群を、より確度の高い推薦商品に絞り込むために、「アイテム特徴推薦」を導入しました。
商品群を絞り込む手段として、ZOZOTOWNに既に存在する「こだわり条件絞り」機能を活用しました。
ユーザーが閲覧した商品に関連する「こだわり条件」を基に、レコメンドモジュールに適用する「こだわり条件」を設定し、より確度の高い商品推薦を実現しています。
実現したい目標
- ユーザーが頻繁に閲覧しているカテゴリ＋こだわり条件の商品を強調し、より確度の高い商品を提案する。
- 商品への導線を短縮し、ユーザーが探している商品に素早くアクセスできるようにする。
- ユーザーが明確に言語化できていない「探している商品」を発見しやすくする。
アイテム特徴推薦ロジック
推薦ロジックの観点は以下の通り
- ユーザーが頻繁に閲覧しているこだわり条件を適切に提示する。
- 同じようなこだわり条件ばかり（例: 無地ばかり）が付与される状況を避ける。
- 付与したこだわり条件に基づいて返却されるアイテムが、推薦として妥当であることを確認する。
ロジックのお気持ち
- ユーザーが閲覧した商品のこだわり条件の閲覧数が、そのこだわり条件の平均閲覧数よりも多い場合、推薦するこだわり条件として付与する。
- 特定のこだわり条件ばかりが付与されることを防ぐため、こだわり条件ごとに閾値を設定し、スコアを設けて推薦するこだわり条件を決定する。
ロジックの流れ
- カテゴリ推薦に至った商品の閲覧ログを集計。
- カテゴリ×こだわり条件ごとに閾値を算出。
a. 閾値(平均閲覧数) = 閲覧合計数 / 閲覧した会員数 - 閾値を超えた カテゴリ×こだわり条件 ごとに対してスコアを算出する
a. スコア = 閲覧数 - 閾値 - カテゴリ×こだわり条件のスコア上位2件を推薦こだわり条件として付与する。
a. 付与されるこだわり条件の件数は推薦子カテゴリごとに0~2件になる。
b. 0件の時は付与しない。
閾値とスコアの意味
閾値は、カテゴリ×こだわり条件の平均閲覧数 と定義します。
| 事象 | 説明 |
|---|---|
| 平均閲覧数が高いこだわり条件は閾値が高くなる | 全体的に閲覧頻度の高いこだわり条件(例：無地など)が付与されにくくなる |
| 平均閲覧数が低いこだわり条件は閾値が低くなる | 全体的に閲覧頻度の少ないこだわり条件が付与されやすくなる |
スコアは ユーザーが平均よりも頻繁に閲覧しているこだわり条件を示す指標 とする
| 事象 | 説明 |
|---|---|
| スコアが大きい | そのユーザーにとって平均閲覧数よりも多く閲覧しているため重要度の高いこだわり条件と仮定。付与されやすくする |
| スコアが小さい | そのユーザーの閲覧数が平均閲覧数に近いので、たまたま閲覧したこだわり条件の可能性が高いと仮定。付与されにくくする |
| 同じ閲覧数の場合 | 閾値が低い方がスコアが高くなる。つまり閲覧頻度の少ないこだわり条件の方が付与されやすくなる |
結果
レコメンドモジュールのアップデート効果を評価するために、パーソナライズ対象のユーザーに対して20日間のA/Bテストを実施しました。Controll群とTreatment群は以下のように設定されました。今回はレコメンドモジュールのアップデートでブランド推薦の導入も行ったため、Treatmentは2種類用意しています。
| C/T | 説明 |
|---|---|
| Controll | カテゴリ推薦 |
| Treatment1 | カテゴリ推薦+ブランド推薦 |
| Treatment２ | カテゴリ推薦+ブランド推薦+アイテム特徴推薦 |
以下の結果から、アイテム特徴推薦を導入したことで指標の多くが向上しました。また、ブランド推薦導入によるクリック率の減少も改善されました。全体を総合的に評価すると、決済ベースの受注額が最も高く、他のモジュールへのマイナスの影響が見られないことを考慮して、「カテゴリ推薦+ブランド推薦+アイテム特徴推薦」の本番リリースが決定しました。
| 指標 | T1/C比率 | T2/C比率 |
|---|---|---|
| HOME経由受注金額 | 100.12% | 100.42% |
| 訪問者1人あたりHOME経由受注金額 | 100.10% | 100.52% |
| 注文単価 | 99.68% | 99.70% |
| 受注点数 | 100.32% | 100.69% |
| 商品単価 | 99.80% | 99.73% |
| 受注件数 | 100.45% | 100.73% |
| CVR | 101.12% | 100.70% |
| HOMEクリックセッション数 | 99.33% | 100.02% |
| クリック率 | 99.28% | 99.90% |
| 全セッション数 | 100.06% | 100.12% |
| 訪問者数 | 100.0% | 99.9% |
苦労したこと
-
アイテムに付与されるこだわり条件の数の差異
- 多様性の担保が難しい課題。単純な閲覧数だけでなく、こだわり条件付与数の逆数を重みとして利用することで、偏りを軽減しましたが、まだ課題が残ります。
-
推薦結果の妥当性の評価
- 妥当性を検証するための実験を行いましたが、一部の指標だけでは十分な評価が難しい状況。今後も検証手法の改善に努めます。
-
無意味なこだわり条件の混入
- 推薦されたこだわり条件が実際には意味をなさない場合がある問題に取り組み、除外処理を追加して対応しました。
おわりに
今回はルールベースでモジュールの商品群にアイテム特徴を付与する推薦方法を試みました。アイテム特徴を用いた推薦により改善が見られたことが今回の収穫だと思っています。今後は機械学習を導入して商品群のアイテム特徴をより精緻に推薦するシステムに改善させたいと考えています。