はじめに
こんにちは、ML・データ部推薦基盤ブロックの寺崎（@f6wbl6）と佐藤（@rayuron）です。
ZOZOTOWNのホーム画面は2021年3月にリニューアルされ、「モジュール」と呼ばれる単位で商品が表示されるようになりました。
本記事ではユーザーごとにパーソナライズされたモジュール（以降、パーソナライズモジュール）のロジックやシステム構成、および導入時に実施したA/Bテストの内容と結果をご紹介します。
先に結論から言ってしまいますが、今回のパーソナライズモジュールでは機械学習モデルを使わず、ユーザーの回遊行動を分析した結果を元にしたルールベースのロジックを使用しています。本記事のポイントは大きく以下の3点です。
- ルールベースのパーソナライズロジック
- 機械学習モデル導入を見越したシステム設計
- ホーム画面のパーソナライズによる効果
本記事がこれから同様のタスクに取り組む方の参考になれば幸いです。
ZOZOTOWNのホーム画面とモジュールについて
まずはじめに、ZOZOTOWNのホーム画面とモジュールについて簡単にご紹介します。
ZOZOTOWNのホーム画面は「すべてのアイテム」・「シューズアイテム」・「コスメアイテム」の3つのモールと「すべて」・「メンズ」・「レディース」・「キッズ」の4つの属性に分かれています。この3モール×4属性の合計12個の組み合わせで表示するモジュールを切り替えています。
※ 上記は2022年6月10日時点でのZOZOTOWNホーム画面です
またモジュールは更新頻度や用途に応じた「定常モジュール」と「運用モジュール」の2種類に大別されます。各モジュールの違いを以下の表にまとめます。
| 用途 | 更新頻度 | |
|---|---|---|
| 定常モジュール | 施策内容に依らず常に同じ訴求をする | ほぼ更新なし |
| 運用モジュール | ビジネスサイドの要望に応じて訴求内容を変える | 1か月あたり数回更新 |
ファッションECの特性上、トレンドや季節に応じてユーザーへ訴求する商品は常にアップデートし続けなければいけません。またZOZOTOWNへ出店していただいているブランド様やショップ様で販売する新商品を訴求する場合もあるため、ビジネスサイドの担当者が月に数回運用モジュールを企画し、開発サイドでリリースしています。
モジュールのパーソナライズ
目的と背景
ホーム画面のモジュールをパーソナライズする目的は複数ありますが、ZOZOTOWNでの購入経験の有無という観点では以下の2つに大別できます。
- 新規購入者の増大
- 既存購入者の来訪頻度・購入頻度の増大
1点目は「ZOZOTOWNに訪れたことがあるが、まだ商品購入に至っていない」というユーザーを想定しています。ZOZOTOWNに訪れてはいるものの商品を購入していない様々な理由があると思いますが、ユーザーの嗜好に合った商品を訴求できていないような場合は適切なパーソナライズにより購入に繋げられると考えられます。ただ、こうしたユーザーの多くは会員登録をしていないため、ZOZOTOWN上での回遊行動を捕捉しにくいという難しさがあります。
2点目は既存顧客に対してより良いコンテンツを提供し、ZOZOTOWNで再度購入してもらうことを意図しています。ユーザーが興味を持ちそうな商品群をホーム画面で訴求できれば来訪頻度が増え、結果として購入頻度も増加すると考えられます。
どちらもZOZOTOWNの成長には必要な切り口ですが、今回は回遊行動ログの集めやすさと既存顧客へのパーソナライズによる効果の大きさから、2点目に挙げた「既存購入者の来訪頻度・購入頻度の増大」を目的としてパーソナライズを進めることとしました。
アルゴリズム選定
パーソナライズアルゴリズムを構築する上で機械学習モデルを使用するか、ルールベースを使用するかを検討し、以下2点の理由からルールベースのアルゴリズムを採用しました。
- 機械学習モデル導入コストの問題
- 機械学習モデル導入による効果が未知
機械学習モデル導入コストの問題
機械学習モデルを導入する場合、ルールベースと比べてシステムアーキテクチャが複雑化することに加え、機械学習モデルに関連する様々な資産の導入・管理コストが発生します。また、機械学習モデルが正しくワークしていることを担保するためのデータドリフト検知やモデルメトリクスのモニタリングなど、システムに機械学習を導入する際には様々なコストを支払うことになります。
今回はベースラインとなるモデルをリリースするにあたってできるだけコストをかけないこと、また既存アーキテクチャの複雑化を避けることを優先しました。
機械学習モデル導入による効果が未知
今回が初めてのパーソナライズモジュールの導入となるため、当然ですがパーソナライズモジュールの効果はリリースしてみないと分かりません。つまり、パーソナライズモジュールのリリースによる効果を最適化するためのオフライン評価の設計が難しい状況でした。
そのため今回は機械学習モデルを最適化するための指標に時間を費やすのではなく、ヒューリスティックに設計したルールでベースとなるパーソナライズの効果を測ることとしました。
アルゴリズム概要
前提
今回のパーソナライズモジュールでは開発スピードと売り上げへの影響の大きさという観点から、訴求対象について以下の前提を置いています。
- ZOZOTOWN会員かつお気に入りブランドを持つユーザー
- 直近で何らかの回遊行動があるユーザー
ZOZOTOWNでは以下の図のように特定のブランドをお気に入り登録する機能があります。今回のパーソナライズでは開発スピードを優先して推薦ブランドリストを一から作ることはせず、このお気に入り登録されたブランドから商品を推薦します。
パーソナライズのアルゴリズムを考えるにあたり、以下の2点を検討の軸にしました。
- 推薦するブランド
- 推薦するカテゴリ
いずれも商品の閲覧や購買行動といったImplicit Feedbackを使って分析を行い、「ユーザーが直近で閲覧している商品カテゴリほど購入に結びつきやすい」というシンプルな仮説のもとルールを策定しました。
推薦するブランドを決定するルール
前述した通り、今回のモジュールではユーザーのお気に入りブランドの中からブランド群を選択します。お気に入り登録しているブランドの数は人によってまちまちで、登録数が1つだけのユーザーもいれば数十個登録しているユーザーもいます。そこでまずは、今回設ける条件によって推薦対象ユーザー数が大きく減ることを防ぐためにユーザー毎のお気に入りブランドの登録数の分布を概観しました。
その後お気に入りブランドの中でも、ユーザーにとって興味があるブランド群のみを選別するための条件を作成することを考えました。今回は購入があったアイテムの最初の閲覧日から購入日までの期間を分析し、ユーザー毎に直近n日間で商品閲覧があるブランド群を推薦するというルールを作成しています。
推薦するカテゴリを決定するルール
推薦するカテゴリは以下の二軸で決めました。
- 除外するカテゴリの選定
- 推薦するカテゴリの優先順位付け
今回のモジュールで推薦可能なカテゴリは300個弱あったため、ここから推薦候補となる一覧を決定します。購入済みのカテゴリの商品が再度推薦される状況を避けることと、多様なカテゴリを訴求することを目的として、「直近で購入済みのカテゴリは訴求しない」という方針を決めました。
この方針のもと、各ユーザーの商品カテゴリごとの購入周期を分析し、購入履歴のあるカテゴリのモジュールはm日間表示しないというルールを作成しました。
次に、候補となったカテゴリのうち、どのカテゴリをユーザーへ訴求するかを決めます。今回は前述した「直近のユーザーが多く閲覧している商品カテゴリほど購入に結びつきやすい」という仮説に基づき、以下の流れで推薦カテゴリを決定しています。
- カテゴリの閲覧回数に時系列の重みを掛け合わせたものを評価値として算出
- その評価値順に推薦するカテゴリを決定
アーキテクチャ概要と処理の流れ
ここからはモジュールのパーソナライズを行うためのシステム構成と処理の流れをご紹介します。前述の通り今回のパーソナライズでは機械学習モデルを使っていませんが、将来的に機械学習モデルを導入することを見越したシステム構成を意識しています。
モジュールAPIはホーム画面リニューアル時に導入されたもので、前述したモールやユーザーの属性に応じてホーム画面に表示するモジュールの設定情報を返却しています。この構成のうち、パーソナライズモジュールの開発に合わせて導入された要素について説明します。
ワークフロー管理
パーソナライズを行うための一連のワークフローはVertex AI Pipelinesで管理しており、このワークフローが毎時間実行される構成となっています。Vertex AI Pipelinesは今や弊社の機械学習パイプライン実行基盤であり、MLをプロダクトに載せて運用に携わる全てのチームが利用していると言っても過言ではありません。Vertex AI Pipelinesに関する知見は弊社テックブログで公開されていますので、こちらも是非参照ください。
Vertex AI Pipelinesによるワークフロー構築に際し、こちらの記事で今後の展望として挙げられていたパイプラインテンプレートというものを利用しています。パイプラインテンプレートはGitHubのテンプレートリポジトリと呼ばれる機能を利用したもので、Vertex AI Pipelinesの実行・スケジュール登録・CI/CD・実行監視等をテンプレート化しています。例えばパイプラインのRunとスケジュール登録は以下のコマンドで実行できます。
# 単発のRunを実行 $ poetry run python pipelines/sample-features run-pipeline --pipeline-name sample-features --env dev # スケジュール実行の登録 $ poetry run python pipelines/sample-features schedule-pipeline --pipeline-name sample-features --env dev
またパイプライン実行状態の監視や公式ドキュメントに記載されている定期実行の仕組みまで、パイプラインテンプレートで簡単にデプロイ・実行できるようになっています。このパイプラインテンプレートによりワークフローのデバッグやデプロイのサイクルを高速に回すことができました。パイプラインテンプレートのより詳細な機能や具体的な実装については別途テックブログで公開できればと思います。
パイプラインは毎時間実行してユーザーの情報を差分更新します。この更新処理バッチが落ちた場合、その時点で再実行等はせずに1日1回の全件更新するバッチを別で実行してリカバリする構成となっています。
データ取得と書き込み
パーソナライズに使用するユーザーログは弊社のリアルタイムデータ基盤であるBigQueryから取得し、集計した結果をGoogle Cloud Storage（GCS）へと出力します。GCSへのデータはデータサイズ節約の観点からparquet形式で出力しており、このデータをDataflowで読み込んでBigtableへ投入しています。実際に投入されるデータは概ね以下のような形式となっています。
002-SS3
r:h @ 2022/06/09-03:30:00.000000
"{\"id\": \"075-A20\", \"field_A\": \"xxx\", \"personalize_category\": [{\"id\": 1234, \"title\": \"カテゴリA\", \"category_url\": \"category_A\"}, {\"id\": 5678, \"title\": \"カテゴリB\", \"category_url\": \"category_B\"}]}"
----------------------------------------
075-A20
r:h @ 2022/06/09-04:30:00.000000
"{\"id\": \"002-SS3\", \"field_A\": \"yyy,zzz\", \"personalize_category\": []}"
上記はユーザーのIDがそれぞれ002-SS3と075-A20のデータを想定したダミーデータです。1つのセルにまとめて文字列形式でパーソナライズ用のデータを格納しており、モジュール返却用のAPIにリクエストが来るとこの文字列をパースしてパーソナライズされた情報を取得する形にしています。
パイプライン側の処理は全て自前で実装していますが、2022年6月現在ではBigQueryやDataflowにジョブを投げるといった汎用的な処理はGCPの公式コンポーネントとして提供されています。他にも様々なコンポーネントが提供されていますので、これから実装する際には用途に適したコンポーネントがないかドキュメントを一読することをオススメします。
機械学習モデルを導入する場合はどうなるか？
今回はルールベースでのパーソナライズのためBigQueryでの集計で事足りていますが、仮に今回の推論バッチで機械学習モデルでのパーソナライズを行う場合のアーキテクチャを以下に示します。
変更点はBigQueryとGCSの処理の間に機械学習モデルによる予測が入るだけで、データの入出力方法に変更はありません。今回BigQueryからGCSへ一度データを配置してDataflowでの処理を行う構成としているのは、こうしたロジックの追加・変更に柔軟に対応する意図があります。
当然、機械学習モデルを再学習・デプロイするための学習パイプラインやCI/CDの構築は別途必要になりますが、推論パイプラインの構成を大きく変更する必要がないのは大きなメリットになります。
A/Bテスト
概要
パーソナライズモジュールの効果を評価するために、リリース時にパーソナライズ対象のユーザーに対して約1か月間A/Bテストを行いました。今回のA/Bテストではテスト対象となるユーザーがControl群とTreatment群で1:1の振り分けとなるように設定しています。Treatment群に対しては以下画像のようにパーソナライズモジュールが表示されます。
モジュールの並び順に関してはビジネス的な要望もあり、定常モジュールの間に挟む形で決め打ちしています。
また、パーソナライズモジュールは推薦するカテゴリに応じてモジュールのタイトル・表示される商品・「すべて見る」を押下した際の遷移先が変わるようになっています。
結果
A/Bテストの結果サマリを以下に示します。
| 指標 | 備考 | 結果（T/C比・T/C差） |
|---|---|---|
| ZOZOTOWN全体の受注金額 | GMVと代替となる指標 | 100.4 (％) |
| ホーム画面経由の受注金額 | ホーム画面に表示されている商品をクリックしたセッション内での受注金額 | 104.6 (％) |
| ホーム画面ランディングセッション直帰率 | ホーム画面の直帰セッション数÷ランディングセッション数 | -0.1 (pt) |
| 訪問者1人あたりホーム画面クリックセッション率 | ホーム画面でのクリックセッション数÷全セッション数 | +0.8 (pt) |
ZOZOTOWN全体の受注金額で有意差は見られませんでしたが、ホーム画面経由の受注金額は増加していました。またホーム画面経由の受注金額をKPIツリーに分解してみると、ホーム画面全体でのクリック率向上に伴うクリックセッション数の増加が影響していることがわかります。
またモジュール全体の指標を見ると、パーソナライズモジュールに引っ張られる形で各種指標が増加していることが確認できます。
| 指標 | T/C比率 |
|---|---|
| モジュールインプレッション数 | 103.4 (％) |
| モジュールインプレッションUU数 | 107.8 (％) |
| 商品クリック数 | 108.5 (％) |
| 商品クリックUU数 | 122.7 (％) |
| 「すべて見る」クリック数 | 106.7 (％) |
| 「すべて見る」クリックUU数 | 126.5 (％) |
| 商品CTR（PVベース） | 104.9 (％) |
| 商品CTR（UUベース） | 113.9 (％) |
| 「すべて見る」CTR（PVベース） | 103.2 (％) |
| 「すべて見る」CTR（UUベース） | 117.4 (％) |
結論として、パーソナライズモジュールの導入によりZOZOTOWN全体での指標改善までは及んでいませんが、少なくともホーム画面ではユーザーの関心を引けているものと考えられます。
課題と今後の展望
ホーム画面へのパーソナライズモジュール導入により、当初目的としていた「既存購入者の来訪頻度・購入頻度の増大」に一定の効果があるというポジティブな結果となりました。一方で、以下のような課題もあります。
- パーソナライズモジュールを表示されるユーザーが限定されている
- ルールベースロジックによるパーソナライズに限界がある
- リアルタイム性に欠く
パーソナライズモジュールを表示されるユーザーが限定されている
現在パーソナライズモジュールが表示されるユーザーはZOZOTOWN会員かつお気に入りブランド登録しているユーザーであり、限定されたユーザーセグメントへの訴求にとどまっています。今回はパーソナライズモジュールの第一歩としてこのような限定されたセグメントへの訴求としましたが、今後はより多くのユーザーにパーソナライズした商品をモジュールという形で届けたいと考えています。
ルールベースロジックによるパーソナライズに限界がある
仮にユーザーセグメントを広げた場合、ルールベースのロジックではパーソナライズできる商品に限界があります。今回作成したルールで言えば「ユーザーがお気に入りブランドに追加しているブランド」に限定した商品を訴求しており、「ユーザーが興味を持ちそうなまだ見ぬブランド」という軸では訴求できません。
ホーム画面という多くのユーザーが最初に訪れる場所だからこそ、見知っているブランドだけではない新しい出会いを機械学習モデルで提供していきたいと考えています。
リアルタイム性に欠く
現状のシステム構成では1時間に1回推論パイプラインが実行されてユーザーのパーソナライズ情報を更新しています。 ユーザーの閲覧に基づいて商品を訴求するのであれば、ユーザーが商品を閲覧してホーム画面へ戻る度、閲覧履歴に基づいた推薦商品が表示されていることが好ましいと考えられます。
一方で閲覧履歴に基づいて表示される商品がリアルタイムで変わっていると、「後でこの商品を見よう」と思ってブラウザバックしてもその商品はホーム画面で表示されていない、という状態となることも考えられます。 ユーザー体験を考えると表示される商品がリアルタイムで入れ替わることは必ずしも良いと一概には言えないため、ここの塩梅を今後探っていきたいと考えています。
最後に
本記事ではZOZOTOWNホーム画面へ導入したパーソナライズモジュールを紹介しました。今後の展望に挙げた項目については絶賛進行中で、これからもZOZOTOWNのパーソナライズはどんどん進んでいきます。
一緒にZOZOTOWNのパーソナライズ化を進めることに興味のある方は以下リンクから是非ご応募ください！
