Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
メルカリホーム画面におけるレコメンド改善事例 - Long-tailを考慮した辞書拡張
Search
yaginuuun
January 17, 2024
Technology
3
1.3k
メルカリホーム画面におけるレコメンド改善事例 - Long-tailを考慮した辞書拡張
メルカリホーム画面におけるレコメンド改善事例 - Long-tailを考慮した辞書拡張
yaginuuun
January 17, 2024
Tweet
Share
More Decks by yaginuuun
See All by yaginuuun
メルカリにおけるA/Bテストワークフローの改善 これまでとこれから
shyaginuma
2
1.6k
メルカリにおけるA/Bテスト標準化への取り組み
shyaginuma
21
13k
A/BテストにおけるVariance reduction
shyaginuma
2
2.3k
初めての機械学習PJを やってみて得た知見
shyaginuma
2
4.5k
過去コンペベースの学習をやってみたら意外と良かった話
shyaginuma
0
690
Kaggleもくもく会イントロ
shyaginuma
0
180
1on1 SQL Introduction at Globis
shyaginuma
1
1.3k
SlackへのKPI通知Botを作ったら いろいろ捗った話
shyaginuma
1
2.2k
BigQueryMLハンズオン勉強会
shyaginuma
3
910
Other Decks in Technology
See All in Technology
脳波を用いた嗜好マッチングシステム
hokkey621
0
280
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
230
エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 / product discovery accelerated by engineers
rince
4
560
大規模アジャイルフレームワークから学ぶエンジニアマネジメントの本質
staka121
PRO
3
1.1k
実は強い 非ViTな画像認識モデル
tattaka
2
1.2k
株式会社Awarefy(アウェアファイ)会社説明資料 / Awarefy-Company-Deck
awarefy
3
11k
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
81k
4th place solution Eedi - Mining Misconceptions in Mathematics
rist
0
140
RemoveだらけのPHPUnit 12に備えよう
cocoeyes02
0
270
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
2.5k
OPENLOGI Company Profile
hr01
0
60k
組織におけるCCoEの役割とAWS活用事例
nrinetcom
PRO
4
120
Featured
See All Featured
The Cult of Friendly URLs
andyhume
78
6.2k
How GitHub (no longer) Works
holman
314
140k
The Pragmatic Product Professional
lauravandoore
32
6.4k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
How STYLIGHT went responsive
nonsquared
98
5.4k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Code Review Best Practice
trishagee
67
18k
Bash Introduction
62gerente
611
210k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Transcript
1 メルカリホーム画面におけるレコメンド改善事例 Long-tailを考慮した辞書拡張 柳沼 慎哉(@yaginuuun) 2024/1/17, Recommendation Industry Talks #1
2 自己紹介 • Data Analyst → SWE • Data Analystの頃はA/Bテスト周りのワークフロー改善周
りに取り組む ◦ メルカリにおけるA/Bテスト標準化への取り組み ◦ メルカリにおけるA/Bテスト分析自動化の取り組み • 最近はホーム画面を中心にレコメンド改善 • 趣味:ポケカ、Podcast配信 柳沼 慎哉(@yaginuuun)
3 メルカリにおけるレコメンドの特徴、課題 今日話すこと 実際に行った改善施策の紹介 02 01
4 メルカリにおけるレコメンド
5 メルカリのレコメンド機能 ホーム画面 商品詳細画面
6 メルカリのレコメンド機能 ホーム画面 商品詳細画面
7 ポイント①:全ての出品は一点もの メルカリで発生する購買の特徴 ポイント②:同一商品内での比較検討
8 ポイント①:全ての出品は一点もの • 全ての出品の在庫は一つしかない(Shops商品を除く) • 同一の出品を複数のお客様にレコメンドしても、実際に購入できるのは一人 これが最安で状態も 良い商品です! あのキーボー ドが欲しいな
あ。。 あのキーボー ドが欲しいな あ。。 キーボードが 欲しい。。 いいね! Happy!! Sad...
9 ポイント②:同一商品内での比較検討 • 同一商品(SKU*)内での比較検討が一般的な行動として存在する • なぜ? → 同一商品でも属性にばらつきがあるから • 商品の状態
• 写真からの印象 • 出品者の評価 • 出品価格 • 配送までの日数 • 配送料負担 • (本当に出品によって様々!!) ※ SKU: Stock Keeping Unit
10 ホーム画面におけるレコメンド • トピックをベースとしたレコメンドを提供 • トピック:メルカリに存在している購買ニーズのまとまり(例:書籍タイト ル、カード名)
11 ホーム画面におけるレコメンド • トピックをベースとしたレコメンドを提供 • トピック:メルカリに存在している購買ニーズのまとまり(例:書籍タイト ル、カード名) タイトル部分(タップで検索結果画面に遷移) - 検索結果画面には豊富な数の出品があるため、
ある出品が売り切れていてもすぐに他の出品を 見つけることができる。 - 検索結果画面は一覧性や追加の絞り込み機能に 優れ、比較検討が行いやすい。
12 ホーム画面におけるレコメンド • トピックをベースとしたレコメンドを提供 • トピック:メルカリに存在している購買ニーズのまとまり(例:書籍タイト ル、カード名) サムネイル部分(タップで商品詳細画面に遷移) 画像いくつか表示することによって、そのトピック にどんな出品が含まれているのか説明性を持たせる
(ウィンドウショッピングに近い感覚)
13 ハイレベルアーキテクチャ Finalization • ビジネスロジックの 組み込み • 推薦トピックの deduplication Retrieval
• 複数の候補生成器が 存在 • キーワード辞書を活 用して推薦トピック を生成 Ranking • MLモデル • 複数の候補生成器か ら得られた推薦ト ピックを共通の尺度 で並び替える
14 ハイレベルアーキテクチャ Finalization • ビジネスロジックの 組み込み • 推薦トピックの deduplication Retrieval
• 複数の候補生成器が 存在 • キーワード辞書を活 用して推薦トピック を生成 Ranking • MLモデル • 複数の候補生成器か ら得られた推薦ト ピックを共通の尺度 で並び替える この後はRetrievalステップで活用しているキーワード辞書に焦点を当てた改 善事例を紹介します
15 改善事例:Long-tailを考慮した辞書拡張
16 存在していた課題 カテゴリによってレコメンド体験に 大きな差がある
17 なぜ? • 当時のキーワード辞書はPopularityベースで構築されていた • でも … カテゴリごとにPopularityは大きく異なる サービス開始10周年記念インフォグラフィックス より
18 なぜ? サービス開始10周年記念インフォグラフィックス より • 当時のキーワード辞書はPopularityベースで構築されていた • でも … カテゴリごとにPopularityは大きく異なる
• Popularityの高いカテゴリにおいてはキーワード数が多いため精 度の高い レコメンドが提 供できるが、Popularityが低くなるに従ってキーワード数 が減少しレコメンドの精度も低くなる • その結果、カテゴリ間でレコメンドの表示率やエンゲージメントに大きな 差がある状態に
19 改善方針:UU Weighted Keyword Coverage の導入 キーワードに興味を持っているUU数 以下の形で定義 カテゴリに興味を持っているUU数 カテゴリごとに上の数値を合計したものが一定以上に保たれるように辞書を構築
UUを考慮することによって良い体験を提供できる人数が増えることを期待
20 拡張方法による比較 • 横軸:拡張前の UU Weighted Keyword Coverage の値 •
縦軸:拡張後の UU Weighted Keyword Coverage の値の上がり幅 青:拡張前 赤:カバレッジ考慮なし 緑:カバレッジ考慮 黄:カバレッジ考慮 + UU重み付け
21 拡張方法による比較 • 横軸:拡張前の UU Weighted Keyword Coverage の値 •
縦軸:拡張後の UU Weighted Keyword Coverage の値の上がり幅 赤に比べて黄はTail部分にあたるカテゴリに おいてカバレッジを大きく向上できている
22 拡張方法による比較 • 横軸:拡張前の UU Weighted Keyword Coverage の値 •
縦軸:拡張後の UU Weighted Keyword Coverage の値の上がり幅 緑に比べて黄はUU Weighed Keyword Coverageの向上幅が大きい
23 実験設計 • variant 1: control(Popularityベース) • variant 2: Popularityベースで更にキーワードを追加したもの
• variant 3: UU Weighed Keyword Coverageを考慮しつつキーワードを追 加したもの ※ variant 2, 3での追加キーワード数は同じ
24 実験設計 • variant 1: control(Popularityベース) • variant 2: Popularityベースで更にキーワードを追加したもの
• variant 3: UU Weighed Keyword Coverageを考慮しつつキーワードを追 加したもの ※ variant 2, 3での追加キーワード数は同じ variant 3だけでなくvariant 2を用意することで提案手法がうまく行った際に 要因の切り分けがしやすいように設計されている
25 実験結果
26 実験結果 • variant 2, 3にてホーム画面経由の購買が増加
27 実験結果 • variant 2, 3にてホーム画面経由の購買が増加 • variant 3ではvariant 2と比較して1.5倍程強いリフトが見られた
28 実験結果 • variant 2, 3にてホーム画面経由の購買が増加 • variant 3ではvariant 2と比較して1.5倍程強いリフトが見られた
• 加えてvariant 3では目立ったcannibalizationが見られなかった
29 実験結果 • variant 2, 3にてホーム画面経由の購買が増加 • variant 3ではvariant 2と比較して1.5倍程強いリフトが見られた
• 加えてvariant 3では目立ったcannibalizationが見られなかった variant 3(提案手法)がプロダクションリリース
30 まとめ
31 まとめ メルカリにおけるレコメンドの特徴、課題 • 全ての出品は一点もの • 同一商品内での比較検討 → ホーム画面ではトピックベースのレコメンドによって適応 実際に行った改善施策の紹介
• カテゴリによってレコメンド体験に大きな差があった • Popularityベースでのキーワード辞書構築に起因 → UU Weighted Keyword Coverageを考慮しつつ辞書拡張することで改善
32 終わりに 他のチームメンバーの過去の発表もあるのでもし良ければご覧ください! • すべてが一点物だから難しい、メルカリのパーソナライズ機能とその開発体制 • ホーム画面レイアウトのパーソナライゼーション