スマートなランキングの作り方 / how_to_make_a_smart_ranking

by CyberAgent

Slide 1

Slide 1 text

スマートなランキングの作り方〜AWA,REQUへの適用事例〜技術本部秋葉原ラボ鈴木元也武内慎

Slide 2

Slide 2 text

１．ランキングについて２．スマートなランキングの作り方３．事例紹介・AWA ・REQU

Slide 3

Slide 3 text

ランキングについて

Slide 4

Slide 4 text

よくあるランキングの作成方法 ①データ抽出 ②集計 ③並び替え uid user_id product_id price 1 B8SbtiBOANqrwBRZNqBC 77 854 2 UaT3oAhmpQISx2zcXCAa 37 224 3 uK1irdbRRiHiZ8BHpP7o 66 972 4 qUMBtHI26hXJYu7eBfFD 96 454 5 iwq0khAXZl1Jea8wWrx3 40 826 6 e5LLuieSvuq6F811U7OG 15 134 7 kXBqFpOONoo0P0Up4jaz 40 480 8 fMqQUsfgJvY1Nxwf7ZDt 28 578 9 KpR5bzLRQlnOpyi1mgUa 6 210 10 FioKcVD9U46y6dHky2Zr 67 774 product_id price 1 9,715 2 3,628 3 2,655 4 5,163 5 2,719 6 6,722 7 6,082 8 8,210 9 3,565 10 3,968 rank product_id price 1 1 9,715 2 66 9,654 3 20 8,807 4 88 8,351 5 8 8,210 6 28 7,981 7 16 7,770 8 86 7,646 9 40 7,624 10 57 7,194

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

スマートなランキングの作り方

Slide 9

Slide 9 text

２つの重要なポイント • 目的の明確化 • アウトプットの明確化 • 評価方法の明確化 ①要件整理 • モデルタイプを定義 • スコアリングロジックの定義 • ランキングロジックの定義 ②ロジック

Slide 10

Slide 10 text

Slide 11

Slide 11 text

①要件整理【メリット / デメリット】 ①要件整理 ②ロジック • 目的の明確化 • アウトプットの明確化 • 評価方法の明確化 • モデルタイプを定義 • スコアリングロジックの定義 • ランキングロジックの定義ポイントするメリットしないデメリット目的の明確化 • プロジェクトがスムーズに進む • アウトプットも明確化する • 最終的にやりたいこととずれたランキングができる • 進めていくときに話が脱線しやすくなる • スコープがどんどん広がってタスクが増えるアウトプットの明確化 • 関係者が安心する • 以下も明確化する • ロジック • 活用方法 • 運用イメージ • 夢と希望に溢れたアウトプットが出てくると思われる • タスクが属人化しやすくなる • 手戻りが発生しやすくなる評価方法の明確化 • 上長やチーム外の人に成果を伝えやすい • 担当者のモチベーションが上がる • よかったのか、よくなかったのかわからないランキングができる • 成果を定義できないので評価されにくい

Slide 12

Slide 12 text

Slide 13

Slide 13 text

①要件整理【ヒヤリングシート】 ①要件整理 ②ロジック • 目的の明確化 • アウトプットの明確化 • 評価方法の明確化 • モデルタイプを定義 • スコアリングロジックの定義 • ランキングロジックの定義ポイント項目回答目的の明確化背景、課題実現したいことアウトプットの明確化既存システムある / なしユーザ表示方法パーソナライズ / セグメント / 一律更新頻度なし / 月 / 日 / 時間 / リアルタイムランキング対象 ※商品、人などランキング対象数・ランキング候補数・ランキング数・ランキング表示数ランキングの種類 ※総合、カテゴリ別などランキング利用KPI ※２つ以上も可ランキング利用データ 1つのDB内にある / ある / ない KPIの時系列変動大きい / 小さいランキングの表示場所評価方法の明確化評価指標評価方法 ABテスト / 前後比較 / その他成功判断条件 ※目標などその他スケジュールリソース項目回答担当者開始時期問題点・課題ロジックデータフロー ※左のヒヤリングシートと同様既存システム「ある」と回答した場合既存ランキングシステムについて追加ヒヤリング

Slide 14

Slide 14 text

Slide 15

Slide 15 text

②ロジック【モデルタイプの定義】 1/2 ①要件整理 ②ロジック • 目的の明確化 • アウトプットの明確化 • 評価方法の明確化 • モデルタイプを定義 • スコアリングロジックの定義 • ランキングロジックの定義 [森内一朗, & 木村和央. (2009). 格付モデルの構築と検証.]を参考に作成タイプ説明利用用途単純モデル指標を１つ利用してランキングする例）売上ランキング、ダウンロード数ランキングなど • シンプルにランキングしたとき • 早くランキングを作りたいとき経験モデル指標を複数利用して人の経験に基づいて重みづけした合計スコアを利用してランキングする例）人気ランキング、影響力ランキングなど • 複数の指標を組み合わせたスコアでランキングしたいとき • スコアを定量評価ができないとき統計モデル指標を複数利用して統計学の知見に基いて重みづけした合計スコアを利用してランキングする例）レコメンドなど • 複数の指標を組み合わせたスコアでランキングしたいとき • スコアを定量評価できるとき • ユーザごとにランキングを出し分けたいとき

Slide 16

Slide 16 text

②ロジック【モデルタイプの定義】 2/2 ①要件整理 ②ロジック • 目的の明確化 • アウトプットの明確化 • 評価方法の明確化 • モデルタイプを定義 • スコアリングロジックの定義 • ランキングロジックの定義 [森内一朗, & 木村和央. (2009). 格付モデルの構築と検証.]を参考に作成項目単純モデル経験モデル統計モデル工数〇 △ △ 理解しやすさ〇〇 △ 根拠〇 △ 〇精度 △ △ 〇必要なデータ規模小小大

Slide 17

Slide 17 text

②ロジック【スコアリングロジックの定義】 ①要件整理 ②ロジック • 目的の明確化 • アウトプットの明確化 • 評価方法の明確化 • モデルタイプを定義 • スコアリングロジックの定義 • ランキングロジックの定義 • データの件数、合計値、平均値、欠損値などを確認しKPIを定義する • 異常値があるか確認し、必要であれば除外方法を定義する • 「rawデータ」「マスタデータ」「データ定義書」を担当者からもらう • データベースにある場合は、アクセス権限をもらう • 定義書とデータが一致しているか確認する • データ型、カラムずれ（区切り文字）などを確認する • ロジックを実装し、スコアを計算する • 評価指標を計算する • 責任者や担当者に結果を見せ評価してもらう • 承諾をもらえない場合は再度スコアリングデータ受領・抽出データアセスメント基礎集計スコアリング評価繰り返し

Slide 18

Slide 18 text

Slide 19

Slide 19 text

②ロジック【ランキングロジックの定義】 ①要件整理 ②ロジック • 目的の明確化 • アウトプットの明確化 • 評価方法の明確化 • モデルタイプを定義 • スコアリングロジックの定義 • ランキングロジックの定義基本ロジックスコアの降順でランキング ⇒ スコアのままだと不都合が発生する場合に用いるロジック ※例外条件みたいなものよくある不都合対処方法案スコアが同じ場合の扱いランダムで並び替える（再現性を考えるならばプライマリキーをハッシュ化）サービスに適していない対象マスタを作成して除外する（人力運用）特定の対象で寡占してしまう寡占率（Herfindahl-Hirschman Indexなど）を考慮する

Slide 20

Slide 20 text

事例紹介 AWA / REQU

Slide 21

Slide 21 text

音楽ストリーミングサービス AWA

Slide 22

Slide 22 text

REQUとは

Slide 23

Slide 23 text

AWA事例とREQU事例の違い項目 AWA REQU 実現したいこと順位にもっと流動性を持たせたいあらゆる要素を加味したい【訪問ユーザ向け】人気セラー、人気商品を紹介したい【セラー】上位掲載されることをモチベーションにして、活性化させたい既存システムあるなしランキング利用データ１つのDBにあるある ※１つのDBにまとまっていない評価指標納得感、ユーザ利用率納得感、送客率

Slide 24

Slide 24 text

事例紹介 AWA

Slide 25

Slide 25 text

AWA事例の場合項目 AWA 実現したいこと ①順位にもっと流動性を持たせたい ②あらゆる要素を加味したい既存システムあるランキング利用データ１つのDBにある評価指標納得感、ユーザ利用率取り組む問題 1. ロジックの改善 2. 評価の実施取り組まなくていい問題 • システムの検討 • データの受領要件整理

Slide 26

Slide 26 text

実現したいこと①② ロジック検討 & 参考文献評価

Slide 27

Slide 27 text

実現したいこと① 順位にもっと流動性を持たせたい

Slide 28

Slide 28 text

実現したいこと① 満たすべき性質：流動性順位にもっと流動性を持たせたい順位 1/1 1/2 1/3 1/4 1/5 1 A A A A A 2 B B B B C 3 C D C E B 4 D C E C E 順位 1/1 1/2 1/3 1/4 1/5 1 A A B E C 2 B B A B E 3 C D C A B 4 D C E C D これが、、、世の中やAWA内の流りが、より反映されるようにしたい順位 1/1 1/2 1/3 1/4 1/5 1 A C B E D 2 B D A B A 3 C B C D C 4 D A E C E ランダムに順位が変わって欲しいわけではない

Slide 29

Slide 29 text

順位 1/1 1/2 1/3 1/4 1/5 1 A A B E C 2 B B A B E 3 C D C A B 4 D C E C D 理想状態世の中やAWA内の流りが、より反映されるようにしたい順位 1/1 1/2 1/3 1/4 1/5 1 A C B E D 2 B D A B A 3 C B C D C 4 D A E C E ランダムに順位が変わって欲しいわけではない要件整理・〇っぽいパターン同士の比較基準は？・他にも × なパターンあるかも？方針案①：理想状態を、定量的に定義する方針案②：理想状態を、担当者の「納得感」で定義する案①：定量的に、結果を評価する案②：担当者の「納得感」で、結果を評価する評価方法実現したいこと① 理想状態を定義する理想状態を定義して、タスクを明確に

Slide 30

Slide 30 text

実現したいこと② あらゆる要素を加味したい

Slide 31

Slide 31 text

あらゆる要素を加味したい・「要素」の候補となる「ユーザー行動」例・楽曲の再生(普通の再生、リピート再生、オート再生 etc.) ・楽曲のskip ・検索(手入力、履歴、音楽認識 etc.) ・表示・クリック・お気に入り・ダウンロード・SNSシェア・playlist作成 … 実現したいこと② 満たすべき性質：あらゆる要素

Slide 32

Slide 32 text

あらゆる要素を加味したい(スマートに) ・「要素」の候補は限りなくあるので、重要な行動に絞る。・各「要素」の重み付けをパラメータで調整する。・モデルは「経験モデル」(複数の指標を経験に基づいて重み付け)。・具体的にどの行動を「要素」に採用するかは、基礎集計をして決める。要件整理ロジック実現したいこと② 必要なユーザー行動は？変数を増やすことはトレードオフメリット：表現力が増えるデメリット：結果の解釈が困難、作業コストが増える

Slide 33

Slide 33 text

ロジック検討基礎集計をするときの気持ち再生お気に入りピークの範囲、立ち方ピークの減衰曲線時間(日次) 例えば、、、気持ち・行動の意味から、傾向の違いを理解・パラメータ調整時に役立つ・似た行動の重複を除去

Slide 34

Slide 34 text

ロジック検討基礎集計から垣間見るAWAらしさ音楽の集合知(playlist文化) 再生 Playlist作成時間(日次) 検索発売 & 配信開始読み取れる「要素」検索：需要、話題性 Playlist作成：アーリーアダプター再生：全体からのフィードバック

Slide 35

Slide 35 text

参考 (音楽に限らない)人の集団行動分析の例・ R. Crane, D. Sornette , Robust dynamic classes revealed by measuring the response function of a social system(2008) Google Trends YouTubeの視聴データ外因性のピーク内因性のピーク

Slide 36

Slide 36 text

評価納得感とパラメータ調整時間(日次) ランク(降順)

Slide 37

Slide 37 text

評価ユーザーからのフィードバック時間再生数の割合

Slide 38

Slide 38 text

事例紹介 REQU

Slide 39

Slide 39 text

１．要件整理２．ランキング作成内容詳細３．結果

Slide 40

Slide 40 text

１．要件整理２．ランキング作成内容詳細３．結果

Slide 41

Slide 41 text

ヒヤリングシートを使って要件整理ポイント項目回答アウトプットの明確化既存システムなしユーザ表示方法一律更新頻度日ランキング対象商品とセラーランキング対象数ランキング対象は商品マスタすべて表示数は未定ランキングの種類総合とカテゴリ別ランキング利用KPI 閲覧数、販売数、売上金額、評価、鮮度ランキング利用データ DBとGAに基本あるが「評価」はない KPIの時系列変動？ランキングの表示場所ランキングページ評価方法の明確化評価指標納得感 ※サブ：回遊率 or 離脱率評価方法前後比較成功判断条件納得感があるランキングを作る ※サブ：回遊率 or 離脱率が改善されるその他スケジュール 2か月後くらいに作りたいリソースディレクター1人、エンジニア1人ポイント項目回答目的の明確化背景、課題【背景】現状ランキングページはあるが、KPIレポートを参考に担当者が毎日、人手で並び替えている【課題】定量的でないランキングかつ人的コストがかかっている実現したこと【訪問ユーザ向け】人気セラー、人気商品を紹介したい【セラー】上位掲載されることをモチベーションにして、活性化させたい ⇒ これらを満たしたランキングを作りたい

Slide 42

Slide 42 text

Slide 43

Slide 43 text

３つのポイント 1. 「人気」「モチベーション」といった定性指標を定量化する • 考慮してほしいKPIが多い（データが存在しないKPIもある） • 「納得感」という定性指標で評価する 2. 複数の新規システム開発が必要 • データ統合システムの開発（データソースがばらばらなのため） • ランキングロジックシステムの開発 • ランキング結果をサービスにつなぐシステムの開発 3. リソース不足 • エンジニア（別プロジェクトが同時進行） • 分析者（別プロジェクトが同時進行）

Slide 44

Slide 44 text

３つのポイント 1. 「人気」「モチベーション」といった定性指標を定量化する • 考慮してほしいKPIが多い（データが存在しないKPIもある） • 「納得感」という定性指標で評価する • ロジックがブラックボックスにならないように分かりやすくする 2. 複数の新規システム開発が必要 • データ統合システムの開発（データソースがばらばらなのため） • ランキングロジックシステムの開発 • ランキング結果をサービスにつなぐシステムの開発新規で開発しないよう既存システムを活用する 3. リソース不足 • エンジニア（別プロジェクトが同時進行） • 分析者（別プロジェクトが同時進行）誰かがボトルネックにならないよう並列して進められるようにする工夫ポイント① 工夫ポイント③ 工夫ポイント②

Slide 45

Slide 45 text

１．要件整理２．ランキング作成内容詳細３．結果

Slide 46

Slide 46 text

ランキング作成フローデータアセスメントロジックのたたき作成システム全体像の設計ロジックの決定ランキングシステムプロトタイプ開発レポート作成データ統合システムの開発分析者エンジニアランキングシステムの開発サービスにつなぐシステムの開発

Slide 47

Slide 47 text

ランキング作成フローデータアセスメントロジックのたたき作成システム全体像の設計ロジックの決定ランキングシステムプロトタイプ開発レポート作成データ統合システムの開発分析者エンジニアランキングシステムの開発サービスにつなぐシステムの開発 ↑ 分析者視点を話します

Slide 48

Slide 48 text

Slide 49

Slide 49 text

データアセスメント閲覧数販売数売上金額評価鮮度 × 定義書の確認データベースの確認 KPI定義データマート作成データが存在しないデータマート ※KPIを１つのデータにまとめたもの • どんなテーブル構造？ • どんなデータがある？ • KPIが存在する？ • アクセス権限がある？ • 定義書の記載とあっている？ • キーの紐づけできる？ • 基本統計量の計算(違和感,NULL などある？ ) • 売上は受注時？決済時？ • 閲覧の対象ページはどこ？ • キーを何にする？ • カラムはどれを対象にする？ • 元データと数値は一致する？売上データ

Slide 50

Slide 50 text

Slide 51

Slide 51 text

ロジックのたたき作成 1/2 モデルタイプ • 単純モデル • 経験モデル • 統計モデル選択理由 • 並び替える対象が多くない（レコード数が多くない） • ランキングはユーザ一律 ⇒ 統計モデルの適切な学習ができなさそう ⇒ 開発・運用工数を考えるとコスパが悪い懸念事項 • 経験モデルは人力でパラメータをチューニングする • 考慮する要因が多すぎるとパラメータチューニングが非常に大変 ⇒ 考慮すべき要因とパラメータを最低限まで減らす【モデルタイプの定義】

Slide 52

Slide 52 text

ロジックのたたき作成 2/2 【スコアリングロジック】 : 商品, セラー : 対象日 : 日前工夫ポイント① , = 1 − × , + × , , = ෍ =1 (,− × ) Score, = , + , ※RE：residual effect ロジックをわかりやすくする

Slide 53

Slide 53 text

, = 1 − × , + × , ロジックのたたき作成 2/2 【スコアリングロジック】残存効果人気 n日前の人気人気残存効果時間重み : 商品, セラー : 対象日 : 日前人気の持続性を持たせることを「モチベーション」とし考慮する売り切れが発生するので売り切れ後も残存効果としても考慮できる（鮮度）閲覧数売上金額工夫ポイント① , = ෍ =1 (,− × ) Score, = , + , 売上重み ※RE：residual effect ロジックをわかりやすくするコマースKPI 閲覧数売上金額 Cunsumer Business KPIツリー

Slide 54

Slide 54 text

, = 1 − × , + × , , = ෍ =1 (,− × ) ロジックのたたき作成 2/2 【スコアリングロジック】残存効果人気 n日前の人気人気残存効果時間重み : 商品, セラー : 対象日 : 日前パラメータは２つだけ工夫ポイント① Score, = , + , 売上重み ※RE：residual effect ロジックをわかりやすくする

Slide 55

Slide 55 text

ロジックのたたき作成 2/2 【スコアリングロジック】残存効果人気 n日前の人気人気残存効果時間重み : 商品, セラー : 対象日 : 日前売上重み λ n λ^n 0.5 1 0.5 0.5 2 0.25 0.5 3 0.125 λは n前日前をどのくらい考慮するか？ λが0.5の場合1日前の「Popularity」は半分考慮して2日前は半分の半分を考慮する数値イメージ工夫ポイント① , = 1 − × , + × , , = ෍ =1 (,− × ) Score, = , + , ※RE：residual effect ロジックをわかりやすくする

Slide 56

Slide 56 text

Slide 57

Slide 57 text

システム全体像の設計売上データマスタデータエクスポート機能を利用データを転送データを転送 REQU システムアカウント設定済みの既存プロジェクトを利用工夫ポイント② 既存システムの有効利用レポーティング

Slide 58

Slide 58 text

システム全体像の設計売上データマスタデータエクスポート機能を利用データを転送データを転送マスタテーブル GAテーブル売上テーブルデータマートテーブルスコアリング結果テーブルロジック計算 ↓ 工夫ポイント③ ボトルネック解消 REQU システムテーブル作成フローアカウント設定済みの既存プロジェクトを利用工夫ポイント② 既存システムの有効利用スキーマを定義 ⇒ input, outputデータが明確化 SQL SQL レポーティング

Slide 59

Slide 59 text

Slide 60

Slide 60 text

ロジックの決定パラメータチューニングロジックに関するレポーティング RANK ID Popularscore Re Popularity 1 149 10.784 0.87 9.91 2 8352 10.759 0.98 9.78 3 8056 10.735 0.87 9.87 4 3234 10.623 0.65 9.97 5 2477 10.463 0.94 9.52 6 1165 10.423 0.84 9.58 7 4012 10.240 0.34 9.90 8 6349 10.168 0.45 9.72 9 4649 10.163 0.67 9.49 10 388 10.085 0.80 9.29 11 4564 9.980 0.61 9.37 12 6585 9.829 0.60 9.23 13 6827 9.649 0.29 9.36 14 7720 9.624 0.51 9.11 15 3608 9.581 0.74 8.84 16 8548 9.442 0.27 9.17 17 5598 9.432 0.79 8.64 18 9497 9.419 0.54 8.88 19 7491 9.408 0.33 9.08 20 6695 9.398 0.65 8.75 例）パラメータ探索範囲の提案 ID ※数値、パラメータはダミーの値です

Slide 61

Slide 61 text

Slide 62

Slide 62 text

プロジェクト名 test_popularranking prd_popularranking dm_table dm_table popularscore_table popularscore_table ランキングシステムプロトタイプ開発マスタテーブル GAテーブル売上テーブルデータマートテーブルスコアリング結果テーブルデータセットを管理してプロトタイプと本番を切り分ける分析者がバッチで本番同様にスコアリングを行う ※cronとかでもOK メリット • システム化するときのイメージが明確になる • 数値やシステムの挙動確認ができる • この後のタスク「レポート作成」を進めることができるデメリット • サーバーが必要（ローカルPCでもできなくはないが、、、） ※テーブル名は任意の名前です

Slide 63

Slide 63 text

Slide 64

Slide 64 text

レポート作成今日

Slide 65

Slide 65 text

１．要件整理２．ランキング作成内容詳細３．結果

Slide 66

Slide 66 text

結果 • 納得感があるランキングを作成することができた • 実は途中で「単純モデル」でランキングを作成しており、単純モデルと比較して離脱率が6%程度改善した • ほとんど手戻りなくプロジェクトを進めることができた

Slide 67

Slide 67 text

さいごに

Slide 68

Slide 68 text

みなさんも理想状態を見極めながらスマートにランキングをしましょう！