On-lab data conferenceに行ってきた
去年書いてた記事ですが、まとめる必要性がでてきたのでうp。
西海岸のウェブサービスを提供している複数の会社から
データ解析の専門家を集めて彼らからデータをもとに開発していくとは
どうことなのかを教えてもらいました。
“フォーカスできる会社がのびる”
何にフォーカスするのか？＝データを正しく分析し、企業の成長につながるデータをみていく。
これができるためにはどうしたらいいのか？ということを
LinkedIn, KISSmetrics, Optimizely, AQ, GINZAmetrics
の中の人達から教えてもらいました。
その中から今でも自分の中に
残っているものを書いていく。
“データを眼で殺せるくらいになるまで見ろ”
Practical Problem Solving With Data : LinkedIn - Pete Skomoroch
“分析する”
データを眼で殺せるくらいになるまで見ろ。
中長期的なチャートを見てもだめ。
データを“見る”という事が大事なのだから眺める程度ではだめ。
アベレージや、傾向を探すのではなく、
実際にどのタイミングで何があったのかを知ることが大事。
映画のマネーボールがそのよい例だと。
“それぞれに見合う、適切な処理をしていく”
もし、路上で戦うはめになったらそこで
相手に勝つために落ちている割れたグラスをつかうように
（ピーターさんはストリートファイターを喩えして使っていたので）
そのシチュエーションにあった対応をしていくということが大事。
直感 vs データということではない。
なぜならスタートアップのような状況だと
早く決断して進んでいかなければならないから。
“即改善する”
しっかりとした方程式まで用意するのではなく、予測をたてる。
LinkedInでは 職業スキルを入れる欄をフリーテストから機械学習システムのhadoopを使いユーザーをサポートしてあげる試みをした。
"予測をたてる"
テストするということは、デザインがデータをサポートしているということ。
感覚で闇雲にかえていくのではなく、データから仮説をたて、そこに適したデザインを施していく。
LInkedInでは、職のレコメンド機能を作る際に、ユーザビューのアプリを作り、そこから実際にphysicistの人にされているレコメンドを確認し、なぜ適正なレコメンデーションがされていないのかをみて、解決した。
“適応させていく”
複雑なシステムを作っている場合は、以下の事をしているかちゃんとチェックする
- データの数値が正常かどうか：予測を立てておいて、それに見合っているか確認する
- エラーのトラッキングをする：もしとっていないと、色んな事を見落とす事になる
- エラーの中からパターンを見つける：上のphysicistのエラーもそうやって見つけた
- 新しい機能を追加する：例）physicistの場合は先攻の記入欄をもうける事で精度を改善した
- その機能モデルそのものを変える：時にはそのモデル自体が駄目な時もある、最初から作り直す事もひつよう。
読んどけって本：
The pragmatic programmer by Andre Hunt David Thomas
LinkedInには、複数のサイエンティストチームがいて、
それぞれ異なった分野のデータ分析をしているとのこと。
peteskomorochのチームは会員の'スキルセット'に関するデータの精度向上とマッチングに特化している。
表示されたスキルセットが受け入れられた／拒否されたなどのトラッキングはすべてに対して行っている。
無意味な指標をつかうな（タイトルは勝手に考えた）: KISSmetrics - Hiten Shah
行動に移せる指標に集中しろ
無意味な指標に踊らされるのは時間の無駄。
アクセス数とかを眺めていると楽しいかもしれないけど、かえって邪魔になるだけ。
トラフィックを集める事は必ずしもビジネスを向上するとは限らない。
適正でないところから沢山トラフィックがきても、コンバージョン率が下がるだけ＝お金にはならない
誰がなぜプロダクトにエンゲージされているのかを解明しろ
自分たちのプロダクトに適した顧客を集める事が全て。
- CUSTOMER ANALYTICS : 勝つ為には誰よりも早く顧客の事を学ばなければいけない
- BUILD : すぐにつくる、いつでもデプロイできるようにする。
- MEASURE : 一人一人が何をやっているかを見る。
- LEARN : 顧客にアプローチする、仮説を立て検証する。
Lifetime value(顧客生涯価値)が大切
スタートしたばかりのタイミングでどうやって割り出すか？：
例）定期購読型なら：週、月のチャージ費x顧客がサービスを使ってくれる期間
（これは最初はシンプルな形で割り出すべき）
Lean startupに忠実に
仮説からスタートする 例）このタイプのユーザーが、この機能／サービス／マネタイズプランに何々の問題を抱えている
そしてその仮説が誤りである事を証明することから始める→顧客に実際に会いにいって「なにをしたのか、なぜしたのか」の問題のコアを聞き出す。
新しい機能をリリースしたらどのくらい見守るべきか？
一般的には「80％既存の機能を改善する事に費やし、20％新しい機能に費やすべき。」と言われている。
でも私は「論理的でないなーと思う、もの、コード、なんでもみたら、それらを現状より２倍価値がない状態の物として捉えろ」
と思っている。
Instagramはburbnという多機能なサービスを作っていたが、一番アクティブなユーザー達がどういう使い方をしていたかを見て、
その一つの機能だけに集中したサービスをInstagramとして作った。
論理的にかなっていない、機能は削除しろ。
10人しかユーザーが居ない場合、その中で一番価値のあるユーザーをみつけ、彼が何をしているのか学べ！インタビューもしろ！
以上。
なかなか、時間が経つとこれらの重要なポイントを忘れがちになってしまいますからね。
しっかり目を向けて正しい判断をしていきたいです。
