Beyond Clicks: Dwell Time for Personalization | Yahoo Labs

Recsys2014のMetrics and Evaluationセッションで発表されてベストペーパーに選ばれた論文.新規手法や精度云々という話ではなく,新しい指標を作ってそれが実際に機能することを示したという内容.

概要

ウェブサイトのレコメンデーションは,だいたいCTRやクリックの有無をもとにしてユーザの趣向を推定するけれども,本当にユーザが記事の中身を見て読んだり気に入ったりしているとは限らない.そこでウェブページの滞留時間(Dwell Time)を新たな指標として提案する.サーバサイドとクライアントサイドの両方で検証して比較したほか,実際の応用としてランク学習や協調フィルタリングに適用して,クリックの情報を用いた解析と比較して同等の結果が得られた.

背景

これまでのユーザの趣向などを前提にしたレコメンデーションはユーザが付けたレートやCTRなどが使われてきたけれども,ユーザが何かアクションを起こす”explicit”なデータはスパースになりがちだし,CTRのような”implicit”な情報もノイズが多い.だから,ユーザがウェブページに滞在している時間を計測して,それらの代わりに使えるんじゃないかという話.

対象としたデータは,Yahooのトップページに表示されるストリームのログ情報.ここにはキュレーションサービスのようにユーザに合わせた記事が流れてくるらしい.

既存研究は当然ながら色々あって,滞在時間の情報を使ってウェブの検索結果の向上をやってたり,YouTubeなんかはクリックの情報ではなくユーザが見た動画の長さを使ったりしているらしい.詳細は論文参照.

滞留時間の解析

まずは滞留時間の測り方.現在のウェブ周りの環境として複数のタブを開くことができるブラウザが主流なので,あっちこっちタブを行き来する可能性がある.ユーザが実際にウェブページを見ている時間を推定したいので,今回はサーバサイドとクライアントサイドの両方の方法をまず試した.

クライアントサイドの方法は,javascriptのDOMのイベントを基本にして,読み込まれた時点をスタートとして,次のページに移動したタイミングや別画面を表示したタイミングをもとに測定した(Table 1).この方法は比較的精度が高く推定しやすいのだけれども,javascriptが無効だったりモバイルで通信が切れたりすると測定できない.

サーバサイドの方法はFBとLEの2つあって,FBはサーバのログに残っているクリックやコメントしたタイミングをもとに測定する方法.LEは同一ページで何らかのサーバを介するイベントがあったときに,その間の時間を計測する方法.どちらも明らかに精度に問題があるし欠点を上げればきりがないけれども,とりあえずクライアントサイドの方とサーバ再度のFBとLEの3つで測定してみた結果がTable2.これを見るとクライアントサイドとFBは同じくらいなのに対してLEは明らかに滞留時間が短いので,とりあえずメインはクライアントサイド,それが使えない環境ならサーバサイドのFBがいいという結果に.

滞留時間の統計情報

滞留時間は計測できたけれども,ユーザやウェブページによって滞留時間は大きく異ることが想定される.

  • ユーザがウェブページを見る環境(デバイス)
    • デスクトップ
    • タブレット
    • モバイル
  • 生地の種類
    • 文章の記事
    • スライドショー
    • ビデオ

Yahooのウェブページの1ヶ月のトラフィックを取って統計を取ったものがFigure 2,3,4,5,6になっている.なお,滞留時間やアクセス数などの単位は大人の都合で削られている.

Figure 2,5,6はデバイスごとの滞留時間の分布(滞留時間はlogで変換)を示していて,どれもだいたい正規分布っぽいベル・カーブを描く結果となった.ただし動画とかは必然的に見る時間が長くなるので,その辺を正規化するためにz-valueを考慮したりして変換している.

Figure 3,4は記事の内容と滞留時間の関係を見ていて,デバイスによってかなり相関が見られた.つまり,記事の文字数や写真の枚数が多くなれば,滞留時間も長くなるということ.特にデスクトップは全体的に長い間滞留する傾向にあった.ただし,長い記事も分散が大きくなるので注意が必要になる(Figure 3の右上のデスクトップのところ).

滞留時間の推定

滞留時間と記事の関係がこれだけくっきり出ているからといって,滞留時間の推定が楽勝というわけにはいかない.ユーザごとの滞留時間を個別に見ていくと,記事とほとんど相関が無い結果が得られたので,文字数とかの記事の内容だけからユーザごとの滞留時間を推定するのは厳しいとのこと.じゃあデバイスの情報とか記事の種類を使えばということで,Support Vector Regressionを使ってやってみた結果がTable 3.ここではSVRの重みしか表示されていないが,やはり効くのはデバイス情報.あとは政治や科学などの記事や長さも次いで重みが大きく,滞在時間の長さに寄与していると思われる.

滞留時間を使ったレコメンデーション

滞留時間を使ったユースケース2つは正直良くわかっていないので,適当なこと書いてます…….

ケース1:ランク学習

まずはランク学習に適用する例.ランク学習を使ったレコメンデーションの評価にはいままでユーザのクリックの有無が使われてきたので,それを滞留時間に置き換えようという話.手法としてはGradient Boosting Regression Treeを使うらしいけれども,ちょっとこの辺はよくわかっていない.滞留時間を応答変数に使う場合と重みに使う場合があるらしい.

検証にはYahoo Propertyのデータを使ってMAP,NDCG,NDCG@10の3つの指標を比較.滞留時間を重みに使用した場合にもっとも良い結果になった.

ケース2:協調フィルタリング

協調フィルタリングにはMatrix Factorizationを用いる.ユーザが付けたレートの値やクリックの情報のかわりに,滞留時間を用いるというもの.滞留時間の値は正規化して$[0,6]$に収まるようにしている.

Yahoo Propertyの3ヶ月分のデータを使って評価.クリック数10回以下のユーザとアイテムは除去して,約15万ユーザ,1万アイテム,合計435万のイベントデータをトレーニングセットとして,約20万のイベントデータをテストセットにした.あと,3ヶ月を日ごとと週ごとにずらして行って推定するということもやっている.評価方法は先ほどと同じMAP,NDCG,NDCG@10.結果としては,クリックの情報を使った時と同等の結果が得られた.

感想

やっていること自体に華々しさや奇抜さはないものの,データの定義から始まってクライアントサイド・サーバサイドの実装を含めたデータ収集,ランク推定や協調フィルタリングに実際に適用して有効性を確認するという一連の流れが評価されたのかなという感じ.こういう分野の研究者はだいたいはクリックのログだけでは駄目だと常々思っていても,データ生成からやるの!?という感じで,なかなかそこから抜け出せないんだろうと思う.それこそ被験者集めて実験しないと本当の滞留時間なんて測定できないわけだし.そういった意味で,Yahooのウェブページという大規模かつ多様なユーザが集まる環境において,こういった基本的な解析が行われるのは純粋に面白い.中山先生もおっしゃっている通り「完成度が高い」研究だと思う.

一方で,結局ランク学習や協調フィルタリングで滞留時間の優位性を示すことができなかったのは少し残念.著者らは”competitive performance”と表現しているけど,結局はクリックの情報を使った場合と同等のもしくはわずかなスコアの上昇しか達成できなかったのが厳しい.より精度が良い滞留時間のデータが出てくるとかアルゴリズムへの組み込み方を工夫すればもっと良い結果が出てくるかもしれないけれども…….

そういう意味で,滞留時間の推定はひとつ大きな問題設定になりうるのかもしれない(分野に疎いので良くわからないけれども).そもそも滞留時間の推定が難しいのはそもそもユーザのトラッキングが厳しくて,ユーザあたりの滞留時間のデータが少ないからだろうか.この論文ではアクセスしてきた時のUAやIPアドレスのみで判定しているだろうし,その辺りは使える情報が少なすぎる気がする.ウェブサイトにログイン情報とかcookieを使ったユーザ推定の方法もあるけれども,ユーザによってデータがあったりなかったりで推定精度がまちまちなのは良くないかも.そもそもこの論文ではユーザから得られる情報を”explicit”と”implicit”に分けていて,ユーザに明示的に何か起こさせないで得られるデータのみで頑張っているから,そこをjavascript等の技術的な方法で工夫できれば精度の高いデータが取れるんじゃないかと期待してしまう.

参考