滞在時間(Dwell Time)という metrics をどうプロダクトで扱うべきか

〜「クリックされたその先」の体験品質を捉え、RecSysで改善し、もっと好きになってもらうために NewsPicksの事例から〜

Transcript

1. 滞在時間（ Dwell Time）という metrics を どうプロダクトで扱うべきか 2026-06-18　白金鉱業 Meetup Vol.24（若手DS交流編） 〜「クリックされたその先」の体験品質を捉え、 RecSysで改善 し、もっと好きになってもらうために NewsPicksの事例から〜 株式会社ユーザベース　森田大登
2. 最初に自己紹介です！初めまして！ 森田 大登 / Morita Masato • 株式会社ユーザベースにて、ソーシャル経済メディア NewsPicks のプロダクトエンジニア として働いています! • Xアカウント: @moritama7431 • RecSysやMLOps周りに興味があります!! (あとダンス) 📝 過去のブログ ! ・NewsPicks に推薦システムを本番導入する上で一番優先すべきだったこと (2024.08) ・新モデルの本番投入を加速せよ！ ML パイプライン追加の学習コスト & 開発工数の大幅削減 (2025.08) ・NewsPicks の MLOps における特徴量ストアの 4 つの重要観点 (2025.12) 「情報は発信する人のところに集まる」という考えのもと、 なんとか果敢に発表してぜひ情報交換を加速させたい気持ちです ...!! よろしくお願いしますー !!🎤
3. 本日の流れ 01 はじめに NewsPicks と推薦システムの関係性 02 なぜ、このテーマを？ CTR は改善。でも“もっと好き”には届かなかった実体験 03 どうやって改善したか？ 滞在時間を正しく捉え、プロダクトに活かす試行錯誤 04 おわりに 「その先」の体験品質を捉え、もっと好きになってもらう
4. NewsPicks と推薦システムの関 係性 | 01 |はじめに
5. NewsPicksについて 5
6. NewsPicksの3つの価値と推薦システムの関係 6 推薦システムは、キュレーション（編成）を強化し、限られた出面の中で良質 なコンテンツや多様なコメントを各ユーザに届けるためにも重要 ...!
7. コンテンツ推薦セクション「あなたへのおすすめ」について • NewsPicksアプリのトップ画面 にて「今日のニュース (全員向 けの厳選経済ニュース)」の下 に位置するセクション。 • 限られた出面の中で、各ユー ザ向けに興味・関心にfitする ニュース記事をパーソナライ ズして出し分ける重要な役割 7 図: ある日の私の「あなたへのおすすめ」の表示内容。
8. 滞在時間（ Dwell Time）という metrics を どうプロダクトで扱うべきか 2026-06-18　白金鉱業 Meetup Vol.24（若手DS交流編） 〜「クリックされたその先」の体験品質を捉え、 RecSysで改善 し、もっと好きになってもらうために NewsPicksの事例から〜 株式会社ユーザベース　森田大登
9. 経験: CTRは明確に改善した! で も、ユーザにプロダクトをもっ と好きにはなってもらえなかっ た...!! | 02 | なぜ、このテーマを？
10. まずCTRはRecSysで最もオーソドックスに活用されるシグナル ! CTR（Click Through Rate）＝ クリック数 / インプレッション数 ざっくり、表示されたコンテンツのうちクリックされた割合! RecSys と CTR の関係性 • 学術的な観点 : RecSys論文でも CTR予測タスクは頻出。特にモデルアーキテク チャ系の研究はCTR 予測タスクで記述・評価されることも多い印象...!! • 実務の観点 : クリックもインプレッションも最も容易・明確に集まるシグナル。なので CTR/クリック関連の評価指標・報酬関数が多くのRecSysで活用されてる...!! そもそも CTR（Click Through Rate）とは？
11. でもCTRだけを追求しても、ユーザによりプロダクトを好きになってもら えなかった苦い経験 ...!! 量を表す指標 (ex. CTR, クリック数・ 1日平均滞在時間 , …)は一貫して改善 ✅ だが「リテンション指標」はイーブン（横ばい）のまま ➡ 深ぼってみると「 1クリックあたり」の滞在（体験の質）はむしろ低下 ⚠ — 量は増えても、 1回ごとの記事閲読体験の品質は薄まっていた ! 指標 効果量（control 比） クリック率（CTR） 1.10 倍 ✅ 1人1日あたりクリック数 1.23 倍 ✅ リテンション指標 (施策の目的!) 1.00 倍 ➡ 1クリックあたり記事滞在時間 0.93 倍 ⚠ 1クリックあたりコメント欄滞在 0.90 倍 ⚠ 表: ある推薦モデル改善施策で「リテンション向上」を試みた A/Bテストの結果
12. 「クリックされたその先」の体験品質も組み込んだ RecSysへ移行して、リ テンション向上に貢献したい ...!! NewsPicksが届けたいユーザ体験的にも、各ユーザに “良質な閲読体験 ”を提 供すること目指す べき...!! 入力 ユーザ／コンテンツ情報 推薦モデル 報酬関数の期待値を推定 アプリ上で表示 ユーザの行動フィードバック imp / tap / reaction / 記事滞在 / コメント 滞在 / 読了 FBを元に継続的学習 ! ▼ 報酬関数（reward function）＝ モデルが推定する対象 Before　報酬関数 ＝ w₁×タップ ＋ w₂×リアクション(Pick) After　報酬関数 ＝ w₁×タップ ＋ w₂×リアクション(Pick) ＋ w₃×滞在時間など“質”を表す 指標 〔NEW〕 (w₁~w₃は各シグナルの重要度合いを制御するハイパーパラメータ )
13. 「クリックされたその先」の体験品質を捉 えるために、滞在時間（ Dwell Time）とい う metrics をどうプロダクトで扱うべき か!! | 03 | 主題
14. 滞在時間は確かに有用なシグナル ! だが侮るなかれ !! 今回、滞在時間 (dwell time) を報酬関数・目的関数として活用するのが初 だったた め、注意点・tips をいくつかの先行研究から情報収集 した!! Yahooさんの事例 Yi et al. (2014) “Beyond Clicks: Dwell Time for Personalization” Tencentさん (WeChat) の 事例 Xie et al. (2023) “Reweighting Clicks with Dwell Time in Recommendation” → click, 購買などの 2値の指標(binary metrics)とは異なる注意点・考慮点が ありそうだった ...!!
15. NewsPicksにて滞在時間をプロダクトに組み込む上での 2つの 誤解があった !! 01 「滞在時間 30秒はどんなコンテキストでも同じ 30秒である」 → No!! 実際にはコンテキストに応じて滞在時間の分布は大きく異なる !! 02 「滞在時間は長ければ長いほど嬉しいから最大化を狙えばいい」 → No!! 良い推薦は「長く拘束すること」ではなく「有益な情報を効率よく読ませること」 !
16. 「滞在時間 30秒はどんなコンテキストでも同じ 30 秒」 → No!! 誤解 ① 実際にはコンテキストに応じて滞在時間の分布は大きく異なる !!
17. 誤解①：「滞在時間 30秒はどんなコンテキストでも同じ 30秒」 → No!! 同じユーザでも、コンテキストによって滞在時間の分布は大きく異なる ! 01 デバイス ex. デスクトップは平均滞在が長い。タブレット /モバイルの 読書行動は似ている (Yi et al. 2014) 02 コンテンツタイプ ex. 動画は記事より長くなりがち。 NP内にも無料記事・オリジナル記事・動画・専門家のトピッ クス投稿など、多様なコンテンツタイプがある ! 03 記事の文字数 記事長と平均滞在は線形相関。文字数が多いほど滞在時 間の期待値は高い これらの分布の違いを考慮しないと ...例えばデスクトップのログを過剰に重視して学習し たり、動画コンテンツや長文記事ばかり推薦しちゃったりする ...!!
18. （余談）NP独自シグナル「コメント欄滞在時間」は扱いやすそう ! ▲ NewsPicks のコメント欄 コメント欄 ＝ NewsPicks内の各コンテンツに付く専門家・ビジネスパー ソンの実名コメント。 NewsPicks 独自価値の中核 であることから、「コメント欄滞在時間」は 「独自価値への接触度合い」を捉える重要シグナル ...!! また記事ページ滞在時間との違いは？ デバイス差 → 残る ⚠（記事滞在と同様、考慮が必要） コンテンツタイプ・記事長の差 →本文と独立した体験なのでほぼ無い ✅ →コンテキスト差を気にせず扱いやすいことからも、記事滞在時間に加え て「コメント欄滞在時間」も積極的に報酬関数に組み込む ...!
19. 「長ければ長いほど嬉しい → 最大化を狙えばい い」 → No!! 誤解 ② 良い推薦は「長く拘束すること」ではなく「有益な情報を効率よく読ませる こと」!
20. 誤解②：「長ければ長いほど嬉しい → 最大化を狙えばいい」 → No!! それを踏まえると...同じ滞在時間 +30秒の改善幅でも意味が異なる! 例えば、「5秒 → 35秒の改善」と「 300秒 → 330秒の改善」では、前者を重視したいし、後 者をかなり重視したくない ...!! NewsPicksで届けたいユーザ体験は「ユーザを長時間拘束して記事を読ませ ること」ではない ! 「価値ある経済情報を効率よく読んでもらうこと」である ! 上記のお気持ちを推薦モデルに落とし込むために 2 つの工夫を採用 ! 01 Valid Readを定義!(Xie et al. 2023) 滞在時間x秒以上を閾値として設定し「ちゃんと読ま れたclick」だけを正例として選別 する! 02 滞在時間を正規化関数に通す ! log(), Sigmoid()など、徐々に飽和していくような変 換関数に通すことで手前を重視 させる!
21. 結果として、どうなった？ 実践 ＆ 成果 設計した報酬関数を元に、同じモデルアーキテクチャ・同じ特徴量で学習 し、本番 A/Bテスト!
22. 報酬関数のみ変更して A/Bテストしてみた ! DiD：処置群 − 対照群の差分（指標別） 報酬関数 ＝ w₁·is_valid_read ＋ w₂·log(記事滞在) ＋ w₃·log(コメント欄滞在 ) ※ デバイス間の差を避けるためモバイルのログのみ使用! ※ is_valid_read ＝ 滞在時間x秒以上の閾値で精錬した高品質clickラベル! ※ ただし、それがリテンションへ明確なポジティブがあったかと言えばまだ試行錯誤中 ...! 今回設計した報酬関数を元に、CTRだけupしてた前回モデルと、同じモデルアー キテクチャ・同じ特徴量で学習 し本番 A/Bテスト! (差分は報酬関数のみ!) 結果として... 前回モデルのCTRやクリック数のポジティ ブ効果をほぼ落とさずに、クリック後の記 事閲読体験の品質を表す 滞在時間系の 指標を回復 できた! (報酬関数の設計パワー凄いな...!!)
23. 余談: A/Bテストしやすい ML基盤があるのが超重要なんです ! 今回の検証も「このモデル試すぞ」と決めてから1〜2日でA/Bテスト開始 できてる! モデルの良し悪しを高い確度で判断できる実験を、安心・安全・簡単にできる環境を 作ることが非常に重要 なんです...! 1〜2年前の自分ありがとうー!!! ↑安心・安全を維持しつつ簡単にした話 ! ↑安心・安全にした話 !
24. おわりに: 今回の試行錯誤からの抽象化 した学び・教訓 | 04 |
25. (完全に自戒です!) 論文や他社事例の指標を「考えなしにそのまま採用する」状 態からは脱却しよう! プロのDS/MLOpsエンジニアとして、貢献を狙うビジネス指 標や届けたいユーザ体験から逆算して自身で報酬関数や評価 指標を設計しよう! (むずかしいけど...!) 新しいシグナルを活用するときも、自分のプロダクトでその シグナルが持つ性質や、届けたいユーザ体験との接続を見通 して活用しよう! 25
26. Thank you 最後までご清聴ありがとうございました！ もし何か気になる点や感想などあれば、 ぜひカジュアルにコメントいただけたら嬉しいです :) 株式会社ユーザベース　森田大登　 /　@moritama7431
27. 工夫①：Valid Read で高品質な click だけを正例に残す ! 問題 すべての click を同じ positive label で扱うのは危険。釣りタイトル・中身とのズレ・誤クリック…満足度 は低いのに「1 click」として同じ扱いになってしまう。 Valid Read とは（Xie et al. 2023） 長く読まれた click ＝ valid read ではない！ ユーザ特性とアイテム特性を考慮した「高品質 click ラベル」 ＝ click をそのまま全て positive にせず、滞在時間を用いて精錬ステップをかますイメージ! Before click ベースの目的関数 → 釣りタイトルが強い → クリックされてもすぐ離脱 After valid read ベースの目的関数 →「ちゃんと読まれる 記事」を学習 → 無駄クリック減 → CTR も ACN も 改善