データマイニング+WEB勉強会資料第6回

9,765 views

Published on

Published in: Technology

データマイニング+WEB勉強会資料第6回

  1. 1. ソーシャルアプリのデータマイニング̶アプリの開発現場から̶山田直行2010年8月22日第6回 データマイニング+WEB 勉強会@東京 (Tokyo.Webmining#6)
  2. 2. 自己紹介(1)• 山田 直行 (やまだ なおゆき)• Twitter @satully Facebook http://www.facebook.com/yamadanaoyuki• ソーシャルアプリ.jp http://www.socialapplication.jp/• 株式会社イストピカ所属 (ソーシャルゲーム専業のベンチャー企業) 職種:アプリエンジニア・インフラエンジニア
  3. 3. 自己紹介(2)技術的バックグラウンド• 言語・フレームワーク LAMP構成の携帯アプリ開発 CentOS Apache PHP(CakePHP Zend etc)MySQL Memcached シェルスクリプト JavaScript Perl少し Python少し 最近の興味はKey Value Store型データベース(NoSQL)やMapReduce関連、あとFlash• 小学6年生の時、Logo(Rubyみたいな教育用言語)でRPGを作っていくつか受賞• 東京大学経済学部在学中、松島斉ゼミでゲーム理論を専攻し、戦略的取引シミュレーションのプログラムを書い て実際に被験者を集めて実験(z-Treeを使用)• Second LifeのLSL(Linden Script Language)にはまる(前職では仕事にも)• ウェブアプリケーション関連の技術は本格的にはイストピカに入社してから習得
  4. 4. 自己紹介(3)開発・運営してきたソーシャルアプリ• ビストランテレストラン経営ゲーム2009年12月下旬リリースモバゲータウンDeNAとの協業(内製)• ともだち市場ザッカニア雑貨屋経営ゲーム2010年6月下旬リリースGREEプラットフォーム
  5. 5. ソーシャルアプリのデータマイニング(1)運営の改善/効果測定/経営判断のためのデータ集計・分析(2)アプリのパフォーマンスのチューニング(3)カスタマーサポートのためのデータ提供(4)ユーザーがアプリをより楽しむ・深く利用するためのユーザーへのレコメンデーション    →これはまだ本格的には手をつけられていない→近いうちに取り組む!
  6. 6. ざっくりと数値感を• 例としてこんなアプリがあるとします(仮定) モバイル(日本の主要3キャリア)向けソーシャルアプリ モバイル対応Flash+HTMLを使ったウェブアプリ mixi モバゲー GREEのどこかに出している 10,000,000PV/日 (300,000,000PV/月) 500アクセス/秒 40,000UU/日 リリース後1ヶ月経過 MySQL(innodb)のデータ量 5GB→メモリに全部載る 一日あたりのテキストログの量 1GB→圧縮・整理して100MBくらい 一日のカスタマーサポートへのお問い合わせ100件※イストピカで出しているアプリとは何の数値的関連性もありません
  7. 7. サーバー構成 ユーザーアクセス Load Balancer WEB MySQL Memcached LVS admin WEB MySQL Memcached LVS admin WEB MySQL Memcached WEB MySQL WEB MySQL ログ集積 マイニング用DB マスター1台 スレーブ x台 バックアップ1台 管理用アクセス ※データベースは分割する場合もある
  8. 8. 分析対象となるデータソース• サービスに使っているMySQLデータベース バックアップDBを利用することで、サービスへの影響を回避• adminサーバーにあるMySQLデータベース バッチ処理の集計結果を格納 テキストログの集計結果を格納• テキストログ syslog-ngを利用してadminサーバーに集める (a)Apacheのアクセスログ (b)ユーザーのページアクセスログ(PVそのもの) (c)ユーザーのアクションログ(アプリ特有のユーザーの行動結果) (d)デバッグ・エラーログ(アプリに使われているSQLを出力)
  9. 9. 集計方法は主に2つ• cronを使ってシェルスクリプト+PHP or Perlで集計 1日に1回、1時間に1回など i)1日のレポートを作成(UU/PV/売上などもろもろ) ii)テキストログの整理と集計    csvにしてMySQLに load data することが多い• ウェブ上で集計・表示 リアルタイム性の高いもの・定時集計不要のものはSQLを直接実行・集計 →キャッシュに結果を入れて、2回目以降はすぐ表示 →ここをCakePHPのShell機能を用いてcronに入れ、はじめて閲覧する場合も重く ならないように変更中
  10. 10. 閲覧方法は主に2つ• メールで毎日1回、サマリーを送信 UU/PV/売上 その他重要指標を毎日早朝に前日分を集計して送信• 管理用ウェブ 社内の人なら誰でも見られる(認証なし・IP制限あり) CakePHPで構築
  11. 11. ウェブの画面
  12. 12. なぜCakePHPを選んだか• データマイニング専任ではないので、とにかく短期間で仕上げる必要がある (全部含めて1アプリあたり10人日くらいで構築)• エラーメッセージが親切で、ウェブ上でも関連情報が検索しやすく、学習速度が速 い• メジャーなPHPフレームワークなので、他の人に引き継ぎやすい• バックエンドで少数の人が閲覧する目的なのでチューニングが不要→多少重くても 構わないので、とにかく高速・シンプルに開発できるものを、ということで選定• bakeが便利• Shell機能でcronとの連携がしやすい
  13. 13. 各種データと集計方法(1)総登録者数• そのアプリに登録しているユーザーの総計 users id int SELECT count(*) FROM users; count(*)の利用には注意。データ量によっては非常に重い(InnoDBの場合)
  14. 14. 各種データと集計方法(2)登録者数(時間別)• 登録ユーザー数を、日別や時間帯別など、 時間で区切って数える users id int registeration_time int SELECT count(*) FROM users WHERE registration_time BETWEEN 123456 AND 234567
  15. 15. 各種データと集計方法(3)売上(時間別)• 課金売上を時間別に集計 sales id int coin int created int SELECT sum(coin) FROM sales WHERE created BETWEEN 123456 AND 234567
  16. 16. 各種データと集計方法(4)課金UU(日別・時間帯別)• 課金したユーザー数を集計 sales id int user_id int coin int created int SELECT count(distinct user_id) FROM sales WHERE created BETWEEN 123456 AND 234567
  17. 17. 各種データと集計方法(5)ページビュー(PV)(日別)• まず当日のページビューログのカウントし、 結果をバッチ処理でDBに入れておく pageviews.20100822.log Aug 22 00:01:02 app_a [pageview]u=12345,page=home Aug 22 00:01:05 app_a [pageview]u=6789,page=item_shop ... pageviews_cron.sh ... perl -wnl -e /,p=(.+?),/ and print $1; /var/log/httpd/pageviews.THISDAY_YMD.log ¦ sort ¦ uniq -c ¦ perl -wn -e "s/s+/,/g and print "$THISDAY_UNIX" and print $_ and print "n";" > /tmp/accesspv.csv mysql -h admin_master -u datamining -p -e LOAD DATA LOCAL INFILE "/tmp/ accesspv.csv" INTO TABLE datamining.pageviews FIELDS TERMINATED BY "," ...
  18. 18. 各種データと集計方法(5)ページビュー(PV)(日別)• そのテーブルを使って結果を取得 pageviews time int page_name varchar pv_count int SELECT pv_count FROM pageviews WHERE time = unix_timestamp( 2010-08-22 00:00:00 ) AND page_name = hoge ;
  19. 19. 各種データと集計方法(6)ユニークユーザー数(UU)(日別)• まず当日のページビューログを集計し、 結果をバッチ処理でDBに入れておく pageviews.20100822.log (さっきと同じ) Aug 22 00:01:02 app_a [pageview]u=12345,page=home Aug 22 00:01:05 app_a [pageview]u=6789,page=item_shop ... uu_cron.sh ... perl -wnl -e /[pageview]u=([0-9]+?),/ and print $1; /var/log/httpd/pageviews. $THISDAY_YMD.log ¦ sort ¦ uniq -c ¦ perl -wn -e "s/s+/,/g and print "$THISDAY_UNIX" and print $_ and print "n";" > /tmp/accessuu.csv mysql -h admin_master -u datamining -p -e LOAD DATA LOCAL INFILE "/tmp/accessuu.csv" INTO TABLE datamining.uniqueusers FIELDS TERMINATED BY "," ...
  20. 20. 各種データと集計方法(6)ページビュー(PV)(日別)• そのテーブルを使って結果を取得 uniqueusers time int user_id int pv_count int SELECT count(user_id) FROM uniqueusers WHERE time = unix_timestamp( 2010-08-22 00:00:00 );
  21. 21. 各種データと集計方法(7)課金率・ARPU・ARPPU• 課金率 (ユニークユーザー数) (課金したユーザー数)• ARPU (Average Revenue Per User) ユーザー1人あたりの売上 (売上) (ユニークユーザー数)• ARPPU (Average Revenue Per Payed User) 課金したユーザー1人あたりの売上 (売上) (課金ユニークユーザー数)
  22. 22. 各種データと集計方法(8)SQL負荷・実行時間• SQLが実行された際に一定の割合(特定のサーバーのみ)でログを出力し、 結果をバッチ処理でDBに入れておく sql.20100822.log Aug 22 00:01:02 app_a [sql]place=home (10),count=10,time_sum=0.1,time_min=0.01,time_max=0.5,host=m1,query=SELECT id FROM users WHERE id = 12345 Aug 22 00:01:03 app_a [sql]place=top (15),count=20,time_sum=0.1,time_min=0.01,time_max=0.5,host=m1,query=SELECT price FROM items WHERE id = 123 ... sql_cron.sh ... 長いので略 ...
  23. 23. 各種データと集計方法(8)SQL負荷・実行時間ウェブ上でアプリエンジニアが確認し、修正・改善作業を行う これ以外に、explain(クエリの実行計画)を実行して問題があったクエリを出力・集計もしている
  24. 24. 各種データと集計方法(9)ページのレスポンス時間• Apacheのログにレスポンスタイムを出力してあるので集計し、結果をバッチ処理でDBに入れておく apache.20100822.log (簡略化しています) Aug 22 00:00:00 app_a GET /index.php 34567 Aug 22 00:00:01 app_a GET /top.php 456789 ... apache_cron.sh ... scp web01:/var/log/httpd/apache.$DATE.log /tmp/ perl -wnl -e /^.*(dd:dd:dd)s.*(GET¦POST)s/(.*?).php.*s(d+?)$/ and print "$4 $3 $1"; /tmp/apache.$DATE.log > /tmp/apache_stat.log (以下略 
  25. 25. 各種データと集計方法(9)ページのレスポンス時間レスポンスタイムはユーザビリティに直結するだけでなく、プラットフォームからのJOIN停止の原因にもなるため、対処は必須
  26. 26. 各種データと集計方法(10)カスタマーサポート用ログユーザーの行動ログはアプリケーション(PHP)からsyslog関数で出力 useractivity.20100822.log Aug 22 00:01:02 app_a [buyitem]user_id=12345,item_id=101,serial_id=98765 Aug 22 00:01:05 app_a [comment]user_id=6789,friend_id=1234,body=仲間申請ありがとう ...データベースに存在するテーブル名と上記テキストログのキー名を一致させておき、自動でログをDBに入れる useractivity_cron.sh ... for x in `mysql -h $HOST -u $USER -p$PASS -e use datamining;show tablesG ¦ perl -wnl - e /Tables_inS+s(S+?)$/ and print $1` do /usr/local/bin/activitylog2csv --type $x --date $DATE --hour $HOUR mysql -h $HOST -u $USER -p$PASS -e load data infile "/tmp/$DATE.$HOUR.$x.log" into table datamining.$x fields terminated by "," >> $LOG 2>&1 done
  27. 27. 各種データと集計方法(10)カスタマーサポート用ログ前ページのログの例だと、こんなテーブルを作っておくようにする timeとuser_idのフィールドは必ず存在するように buyitem comment し、インデックスを貼っておく。 time time それ以降のフィールドはログ出力時にカンマ区切り int int にすることでcsvにしたときに順番にデータベースに user_id user_id 入れられるので、途中からのフィールドの追加も問 int int 題ない。 item_id friend_id int int ログを追加するのに必要な作業はPHP側でログを出 serial_id body 力することと、データベース側でそれに合わせた bigint varchar テーブルを作成するだけ。
  28. 28. 各種データと集計方法(10)カスタマーサポート用ログModel(右図)とController(下図)アクションの引数にテーブル名が入る appname/models/cslog.php (CakePHP)この他、config/bootstrap.php(設定ファイル)でテー <?phpブル名やフィールド名と日本語名をマッピングしておく class Cslog extends AppModel{ var $name = cslog; var $useTable = false;appname/controller/cslog_controller.php (CakePHP) var $useDbConfig = datamining;<?php }class CslogController extends AppController { var $uses = null; (中略) function view($modelname=null) { if(!$modelname){ ※関係者しかアクセスしない用途のた $this->redirect(array("action"=>"index")); め、セキュリティが甘いです。外部公 } 開用のコードに使わないでください App::import(Model,Cslog); $cslog = new Cslog(cslog,$modelname,datamining);(以下略)
  29. 29. 各種データと集計方法(10)カスタマーサポート用ログこのように検索・閲覧できるユーザー行動履歴は約40種類ほど
  30. 30. 各種データと集計方法その他• リピート率 ユーザーが登録後、どれくらい継続してプレイしているか• 到達度別分布 チュートリアル、レベル、所持ポイント、友達の数• 離脱したユーザーの分析 どのページで離脱しているか 集計・分析するときのパターン 定量的なデータ 定性的なデータ 時間軸で絞り込み まず集計対象のユーザーの集 それらの母集団に対して、定 月・日・時間などで別個に集 団を指定(ログインUU・登録 性的な属性で絞り込みをかけ 計して出力する 日別・最終ログイン日別・招 る(男女・地域・生年月日・ 待者など) レベル・所持金・到達度 課金の有無) つまりやっていることはテーブルJOINしてWHERE句でしぼりこんでいるのがほとんど
  31. 31. 開発・運用するうえで思うこと(1)• 運営関係者なら誰でも気軽に見られること社内LANからであれば認証なしにしている。ウェブ上でディレクターだけでなく運営に携わる誰でもが気軽に閲覧・チェックできることでデータに対する意識やメンバーの士気が高まる1日1回のメール送信でさらにプッシュ施策の成果が売上・アクティビティなどの形で明確に現れることがソーシャルアプリ運営の醍醐味• 運営関係者なら誰でも理解できること難しい分析結果をそれっぽく出してもディレクターが十分に理解できないと活用されない→いかに分かりやすく見せるか• データは時に誤解を招く集計しているデータのみで何かを判断することの危険性 多面的にみる必要があるグラフにすると見やすさの一方、誤解しやすいのであえて入れていない面もある• 「仮説を立てる力」が問われているログはとにかく膨大にあるが、どんなデータがどんな意味を持っているかを見いだすのが難しい
  32. 32. 開発・運用するうえで思うこと(2)• データをユーザーにとっての資産ととらえ、責任を持って大切に扱う マイニングの話題からは逸れるかもしれないが、データはもちろん運営側にとって貴重なのは当然だが、利用し ているユーザーにとっても大事な資産。ユーザーは時間をかけてそのゲームをプレイし、人間関係やゲーム内ア イテムなどさまざまなものを蓄積している。 そのことに対して運営側としては責任を持ってデータをお預かりしているという意識を持ち続けていきたい。 それがあるのが前提で、それに加えてどう楽しませるか、というサービスが提供できる。 ソーシャルアプリの利益の源泉は、ユーザーがサービスに持っているデータに価値を感じてもらえること•

×