メルカリホーム画面におけるレコメンド改善事例 - Long-tailを考慮した辞書拡張

メルカリホーム画面におけるレコメンド改善事例 - Long-tailを考慮した辞書拡張

Transcript

1. 1 メルカリホーム画面におけるレコメンド改善事例 Long-tailを考慮した辞書拡張 柳沼 慎哉（@yaginuuun） 2024/1/17, Recommendation Industry Talks #1
2. 2 自己紹介 • Data Analyst → SWE • Data Analystの頃はA/Bテスト周りのワークフロー改善周 りに取り組む ◦ メルカリにおけるA/Bテスト標準化への取り組み ◦ メルカリにおけるA/Bテスト分析自動化の取り組み • 最近はホーム画面を中心にレコメンド改善 • 趣味：ポケカ、Podcast配信 柳沼 慎哉（@yaginuuun）
3. 3 メルカリにおけるレコメンドの特徴、課題 今日話すこと 実際に行った改善施策の紹介 02 01
4. 4 メルカリにおけるレコメンド
5. 5 メルカリのレコメンド機能 ホーム画面 商品詳細画面
6. 6 メルカリのレコメンド機能 ホーム画面 商品詳細画面
7. 7 ポイント①：全ての出品は一点もの メルカリで発生する購買の特徴 ポイント②：同一商品内での比較検討
8. 8 ポイント①：全ての出品は一点もの • 全ての出品の在庫は一つしかない（Shops商品を除く） • 同一の出品を複数のお客様にレコメンドしても、実際に購入できるのは一人 これが最安で状態も 良い商品です！ あのキーボー ドが欲しいな あ。。 あのキーボー ドが欲しいな あ。。 キーボードが 欲しい。。 いいね！ Happy!! Sad...
9. 9 ポイント②：同一商品内での比較検討 • 同一商品（SKU*）内での比較検討が一般的な行動として存在する • なぜ？ → 同一商品でも属性にばらつきがあるから • 商品の状態 • 写真からの印象 • 出品者の評価 • 出品価格 • 配送までの日数 • 配送料負担 • （本当に出品によって様々！！） ※ SKU: Stock Keeping Unit
10. 10 ホーム画面におけるレコメンド • トピックをベースとしたレコメンドを提供 • トピック：メルカリに存在している購買ニーズのまとまり（例：書籍タイト ル、カード名）
11. 11 ホーム画面におけるレコメンド • トピックをベースとしたレコメンドを提供 • トピック：メルカリに存在している購買ニーズのまとまり（例：書籍タイト ル、カード名） タイトル部分（タップで検索結果画面に遷移） - 検索結果画面には豊富な数の出品があるため、 ある出品が売り切れていてもすぐに他の出品を 見つけることができる。 - 検索結果画面は一覧性や追加の絞り込み機能に 優れ、比較検討が行いやすい。
12. 12 ホーム画面におけるレコメンド • トピックをベースとしたレコメンドを提供 • トピック：メルカリに存在している購買ニーズのまとまり（例：書籍タイト ル、カード名） サムネイル部分（タップで商品詳細画面に遷移） 画像いくつか表示することによって、そのトピック にどんな出品が含まれているのか説明性を持たせる （ウィンドウショッピングに近い感覚）
13. 13 ハイレベルアーキテクチャ Finalization • ビジネスロジックの 組み込み • 推薦トピックの deduplication Retrieval • 複数の候補生成器が 存在 • キーワード辞書を活 用して推薦トピック を生成 Ranking • MLモデル • 複数の候補生成器か ら得られた推薦ト ピックを共通の尺度 で並び替える
14. 14 ハイレベルアーキテクチャ Finalization • ビジネスロジックの 組み込み • 推薦トピックの deduplication Retrieval • 複数の候補生成器が 存在 • キーワード辞書を活 用して推薦トピック を生成 Ranking • MLモデル • 複数の候補生成器か ら得られた推薦ト ピックを共通の尺度 で並び替える この後はRetrievalステップで活用しているキーワード辞書に焦点を当てた改 善事例を紹介します
15. 15 改善事例：Long-tailを考慮した辞書拡張
16. 16 存在していた課題 カテゴリによってレコメンド体験に 大きな差がある
17. 17 なぜ？ • 当時のキーワード辞書はPopularityベースで構築されていた • でも … カテゴリごとにPopularityは大きく異なる サービス開始10周年記念インフォグラフィックス より
18. 18 なぜ？ サービス開始10周年記念インフォグラフィックス より • 当時のキーワード辞書はPopularityベースで構築されていた • でも … カテゴリごとにPopularityは大きく異なる • Popularityの高いカテゴリにおいてはキーワード数が多いため精 度の高い レコメンドが提 供できるが、Popularityが低くなるに従ってキーワード数 が減少しレコメンドの精度も低くなる • その結果、カテゴリ間でレコメンドの表示率やエンゲージメントに大きな 差がある状態に
19. 19 改善方針：UU Weighted Keyword Coverage の導入 キーワードに興味を持っているUU数 以下の形で定義 カテゴリに興味を持っているUU数 カテゴリごとに上の数値を合計したものが一定以上に保たれるように辞書を構築 UUを考慮することによって良い体験を提供できる人数が増えることを期待
20. 20 拡張方法による比較 • 横軸：拡張前の UU Weighted Keyword Coverage の値 • 縦軸：拡張後の UU Weighted Keyword Coverage の値の上がり幅 青：拡張前 赤：カバレッジ考慮なし 緑：カバレッジ考慮 黄：カバレッジ考慮 + UU重み付け
21. 21 拡張方法による比較 • 横軸：拡張前の UU Weighted Keyword Coverage の値 • 縦軸：拡張後の UU Weighted Keyword Coverage の値の上がり幅 赤に比べて黄はTail部分にあたるカテゴリに おいてカバレッジを大きく向上できている
22. 22 拡張方法による比較 • 横軸：拡張前の UU Weighted Keyword Coverage の値 • 縦軸：拡張後の UU Weighted Keyword Coverage の値の上がり幅 緑に比べて黄はUU Weighed Keyword Coverageの向上幅が大きい
23. 23 実験設計 • variant 1: control（Popularityベース） • variant 2: Popularityベースで更にキーワードを追加したもの • variant 3: UU Weighed Keyword Coverageを考慮しつつキーワードを追 加したもの ※ variant 2, 3での追加キーワード数は同じ
24. 24 実験設計 • variant 1: control（Popularityベース） • variant 2: Popularityベースで更にキーワードを追加したもの • variant 3: UU Weighed Keyword Coverageを考慮しつつキーワードを追 加したもの ※ variant 2, 3での追加キーワード数は同じ variant 3だけでなくvariant 2を用意することで提案手法がうまく行った際に 要因の切り分けがしやすいように設計されている
25. 25 実験結果
26. 26 実験結果 • variant 2, 3にてホーム画面経由の購買が増加
27. 27 実験結果 • variant 2, 3にてホーム画面経由の購買が増加 • variant 3ではvariant 2と比較して1.5倍程強いリフトが見られた
28. 28 実験結果 • variant 2, 3にてホーム画面経由の購買が増加 • variant 3ではvariant 2と比較して1.5倍程強いリフトが見られた • 加えてvariant 3では目立ったcannibalizationが見られなかった
29. 29 実験結果 • variant 2, 3にてホーム画面経由の購買が増加 • variant 3ではvariant 2と比較して1.5倍程強いリフトが見られた • 加えてvariant 3では目立ったcannibalizationが見られなかった variant 3（提案手法）がプロダクションリリース
30. 30 まとめ
31. 31 まとめ メルカリにおけるレコメンドの特徴、課題 • 全ての出品は一点もの • 同一商品内での比較検討 → ホーム画面ではトピックベースのレコメンドによって適応 実際に行った改善施策の紹介 • カテゴリによってレコメンド体験に大きな差があった • Popularityベースでのキーワード辞書構築に起因 → UU Weighted Keyword Coverageを考慮しつつ辞書拡張することで改善
32. 32 終わりに 他のチームメンバーの過去の発表もあるのでもし良ければご覧ください！ • すべてが一点物だから難しい、メルカリのパーソナライズ機能とその開発体制 • ホーム画面レイアウトのパーソナライゼーション