Monthly Archives: June 2015

「Bizreach✕Cookpad✕Gunosy✕UserLocal 分析プラットホームとその技術」参加レポート

CookpadとGunosyの中の人の顔を見てみたいというミーハー根性と、やっぱりWeb業界の方々のスピード感は見習わなければいけないなあいう尊敬の念から行かざるを得なかった勉強会の参加レポートです。

connpass : Bizreach✕Cookpad✕Gunosy✕UserLocal 分析プラットホームとその技術

I. とあるディレクターのデータ分析の日常

クックパッド 伊藤さん

クックパッド

  • ユーザー数5000万人突破
  • レシピ数200万品突破

データ分析✕ディレクター✕エンジニアとの関わり

  • クックパッドのミッション : ユーザーニーズを抽象化してシンプルに解決する → 料理を楽しくする

開発フレームワーク

  • LEANスタートアップが基本
  • クックパッドでは入社したらとりあえずLEANスタートアップなどのLEANの本を輪読
  • LEANフレームワークを説明した各書籍の中で、分析は LEAN ANALYTICS に記述がある

LEAN

  1. サービス開発を実験のように仮説検証を通じて行う
  2. 検証のための最小の製品(MVP)を作る
  3. 検証する

検証するときにデータの分析が発生

サービス開発とデータ活用

  • サービス開発は、新しい価値を生み出す
  • データ活用は、データを利用してビジネスを伸ばす

データ分析

  • ダッシュボード最強。
  • KPIを設定してダッシュボードを作ってそれを眺める。

ダッシュボードを観察するときの辛さ

  • 日々の変動で一喜一憂してしまって辛い
  • スムージングしたKPIのモニタリングがオススメ(30日でスムージングしている)

機械学習(バズワード)への対応

  • Deep Learning, トピックモデル, word2vec, などなど
  • まずは足元を確認してからやる

分析技術

  1. Google Analytics : 最も有名なダッシュボード、ざっくりみたいとき
  2. Mixpanel
  3. Hakari
  4. papa : クックパッド製のダッシュボード
  5. SQL
  6. TreasureData
  7. Redshift
  8. MySQL

ディレクターとエンジニアとの関わり

ディレクターの仕事 : エンジニアの仕事を減らすこと(私見として)

情報の共有

  • Groupad : ブログみたいなクックパッド内製ツール
  • エンジニアもディレクターもみんなここに投稿している
  • ツールを導入してフォローする

技術的負債への対処

  • サービス開発すると技術的負債がついて回る
  • 新規機能を開発するのか、リファクタリングするのか判断する

データ分析のポイント

  1. 分析対象への理解
  2. 分析手法についての理解
  3. 分析結果から施策へ

1. 分析対象への理解

  • どのようにしてデータが生まれてきているのか誰もしらないことがある。
  • マスターデータなのかユーザーデータなのか
  • 行動ログデータなのか
  • トランザクティブメモリー(組織内で誰が何を知っているか)を把握することが重要

2. 分析手法についての理解

  • 問題として適切に表現すること
  • 分析手法を適切に選択すること

3. 分析結果を活かすこと

  • マーケティングシナリオ
  • 広告戦略策定
  • A/Bテスト

グロースハック事例

クックパッドの過去の事例は加藤さんのSlideshare参照

Q&A

1. ダッシュボードに表示すべきKPIはどのように選定しているのか?

  • ダッシュボード自体に誰が見ているのか計測する仕組みを導入している
  • LEAN ANALYTICSに記述がある

2. ダッシュボードをチームごとに分けているか?

  • 基板は共通にしている、その中で階層を分けている
  • 一元管理するために基板は分けていない
  • KPIの数は4つか5つ、中身はチームごとに異なる

3. 固めるべき足元とは?

  • データの環境について、社内的な整理を行うこと
  • 社内のデータが一元管理されている、必要な組織が管理している、など組織面の整理
  • 権限設定を適切に実施
  • 適切なダッシュボードの作成

4. SQLをどのように習得したのか

  • 必要に迫られてやった
  • ログの分析をする必要があったが、MySQLのDBにしかない状況があったのがきっかけ

5. 事業部ごとの整合性、進むべき方向を向いているか

  • 会社としてどのような数字を見ているかはオープンにしている
  • 定例会(毎週)で確認している

Reference

  1. MLCT(Machine Learning Casual Talk)
  2. ReBuildfm
  3. クックパッド開発者ブログ
  4. 10年戦えるデータ分析入門

II. ユーザーローカルの顧客企業のデータ分析担当者はどうサイト解析しているのか

ユーザーローカルCTO 三上さん

内容

  • どう解析しているか
  • 解析のためにどのようなインフラを構築しているか

データ分析に望まれる3つの点

  1. 社内説得に役立てる
  2. ユーザー像、改善策を知る
  3. 取得したデータを売上アップに繋げたい

必要な要件

  1. 集計処理(大規模かつ素早く)
  2. 可視化(数値だけでなくビジュアル)
  3. 蓄積データをビジネスに活用

1. 集計処理

  • 大量のデータを取得しておきたい
  • 結果をできるだけ素早く、高速に見せる

難しさ

  • この両立はとても難しい。
  • サンプリングしてデータを保存するのでは、後からデータが必要になったときどうしようもなくなってしまう。

実装方法

  • 一日一回のバッチ : 日別のユニークユーザーなど
  • 数十分に一回のバッチ : サイトからの離脱など
  • リアルタイム処理

一日一回のバッチを実装する方法

  • 最も簡単
  • 大規模ならHadoop
  • 事業担当者が待ってくれなかったりする

数十分に一回のバッチを実装する方法

  • Hadoopで作ったとき、リトライ可能にするのは難しい
  • TV CMなどのときでは10分単位だと遅い

リアルタイム処理

  • KVSなどで実装
  • 単純なカウントアップに向いているが、メモリの上限値との戦いが発生

ラムダアーキテクチャーでの解決

  • バッチレイヤーとスピードレイヤーに処理を分岐させる
  • 設計が複雑化し、システムコストが多重にかかる

実装例 : リアルタイム・ダッシュボード

  • 差分を最初に持ってくる
  • 経営者・営業にウケがいいとのこと

2. ユーザー像、改善策を知る

  • どういった人に見せるのかを把握することが重要
  • 経営者 : 短時間で全体像を把握したい
  • ディレクター : デザイナーを説得したい
  • 分析担当者 : レポート作成時間を短縮したい
  • 営業担当 : コンバージョン数が知りたい

デザイナー・ディレクター向けの可視化

  • ヒートマップで可視化
  • クリック数が多い場所
  • どこまで読まれているか

  • 表示した後に分析は別途必要

3. 取得したデータを売上アップに繋げたい

レコメンドサービスに結局繋がる場面が多い

目的から考える

  • ブログ記事に関連する記事を出す
  • サイトの回遊率を上げる

協調フィルタリング

  • 新着維持には十分な情報がない
  • 興味が近いから両方見ていたのか、たまたま目に入った時間が近いのか区別が難しい

コンテンツベース

  • 新着の記事でもレコメンド可能
  • 単語の出現回数で関連度が決まるため、関連度が擬似的なものになってしまう

人気ランキング

  • 人気のものなのである程度質も良い
  • 目を引く

Q&A

1. データを取得してから分析にかかる時間はどれだけか

  • 1時間程度

2. ヒートマップはどのような動作を反映しているのか

  • 表示されている領域
  • マウスの位置

Reference

3. AmazonRedshift✕Tableauを活用したデータ分析のススメ

ビズリーチ 工藤さん

ビズリーチ データサイエンスチームの構成

  • サービス企画部
    • データサイエンス
    • ビジネス力
    • エンジニアリング

データサイエンスチームの役割

1. 間接的な効果

  • BIツールによるデータの可視化
  • アドホックな分析

2. 直接的な効果

  • メールやweb上でのユーザーへのレコメンド
    • レコメンド用アルゴリズムの開発を実施している
  • リアルタイムな事前検知

About 400

  • KPIが400あった
  • 集計はすべてExcelで行っていた
  • 集計するだけでコストが高い(人手がかかる、DBへの負荷がかかる)

データ可視化プロジェクト

  • Amazon Redshift✕Tableau
  • Amazon Redshift : 既存のMySQLがAWS上にあった
  • Tableau : 使いやすかった

事例紹介 広告媒体別の費用対効果の可視化

  • Excelで行っていた集計作業を対象
  • コストと売上を対比できるようにした
  • Tableauをダッシュボードとして利用して可視化

事例紹介 リアルタイムな事前検知

  1. 転職意欲が低く、サイトを積極的には利用していないユーザー
    • プロジェクト中で忙しく手が出せない方も含む
  2. 急に転職意欲が高くなってきたユーザー
  3. 転職意欲が高く、既にサイト上で行動しているユーザー

このうち、急に転職意欲が高くなってきたユーザーの出現を検知したい。

処理内容

  • 行動ログを取得
  • Redshiftにためる
  • Python(pandasで前処理・正規化, NetworkX)で処理

Q&A

1. Redshiftのデーブル設計

  • MySQL(Webアプリで利用しているもの)に似せている
  • ユーザに関する個人情報は省いている

2. Streaming Insertを利用した理由

  • fluentを使ってみたかった

3. 集計単位はユーザー単位での集計だと思うが、計算量的に考えた負荷は高くないのか

  • 全員を対象にすると計算の負荷が高くなる
  • 現在はアクティブなユーザーに限って実施している

4. 比較した結果、RedshiftとTableauとしたとあったが、何を比較したのか

Databaseの選定について

  • BigQuery
  • Redshift

金額的にはBigQueryが良かったが、既存の知見が使いやすいという理由でRedshiftに。

BIツールの選定について

  • RedshiftをベースにしたときにTableauが使いやすいという事例紹介があった
  • ほぼ一択で決めた

5. Tableau以外に検討したツールの名前は

  • ClickViewのツール?

6. Tableauをエンジニア以外が触ることがあるか、苦労した点は

  • Tableauは集計単位をどんどん変えることができる、社内に広めるときには苦労しなかった
  • データの整形や入力ルールについてまとめることが非常に難しかった

7. 過去データのトランザクションも全て入れているのか、集約したデータは

  • Redshiftにはすべてのデータを入力している
  • 時系列でサマリーを作ったテーブルも作成して保持している

8. Tableauで表示されるまでの時間は?

  • ベストで3sec

9. NetworkXで解析しているグラフとは何なのか

  • ページのユーザーの回遊状況(有向グラフ)

Reference

4. Gunosyでの分析と改善

Gunosy 吉田さん (Co-Foundar)

最初期

  • Webアプリだけ
  • MySQL+Rails

アプリリリース時の分析基板

  • MySQL排除
  • fluentd, MongoDB, S3導入
  • MongoDBのMapReduceで集計
  • iPython Notebookで集計

データ多すぎ対策後での分析器版

  • MongoDB遅すぎ
  • 古いデータを消していたのでWAU算出負荷
  • Redshift(+BigQuery)
  • アドホックな分析にSpark導入
  • MongoDB排除

分析改善タスクの考え方、流れ

基本方針

  • 数字は神より正しい : 上位者の意見ではなくユーザーの数字で意思決定を行う
  • 迷ったら挑戦する : 迷ったらやってみる
  • 機会が得意なところは機会に、人間が得意なところは人間に

タスクの流れ

  1. 目標設定
  2. 仮説立案
  3. 簡易実験
  4. モデル実装・自動化

1. 目標設定

  • 改善目標となる数値を決める

2. 仮説立案

  • 仮説を上げるための仮説を立てる
  • 新しい技術やモデルがあるから飛びつく、のはNG

3. 簡易な実験

  • ルールベースや手動でもいいからユーザーに試して見る
  • ルールが記述できないのであればそれは仮説が詰め切れていない、と考える

4. モデル実装・自動化

  • ここでやっと機械学習が出てくる
  • 複雑なモデルではなく、効率のいいポイントを考える
  • サービスが変化したときに、スピード感をもって変更できるモデルを構築することが必要
    • 複雑な精緻なモデルではなく、シンプルで変更できるモデルを立てる

進め方

  • やる/やらないのジャッジはしない
    • 小規模にやってみて数値を見ながら拡大していく
  • どの数値がどのくらい上がるかはわからない、どの数値を上げたいかを見積もる
  • あたる/あたらないは八卦なので、数を打つ

分析改善の例1. 新規ユーザーの獲得

課題

  • 新規のユーザーの継続率が下がっていく
    • 新規登録後7日後、どれだけ継続しているか

仮説

  • SNSから個人の興味を得ることができなくなっているのでは
  • 過去のコンテンツから得られた特徴量がマスの人々には満足しない
    • 評価指標がアーリーアダプターに偏っていた

対策

  • SNSだけでは無理
  • アンケートを導入してカテゴリーをユーザーが入力できるように改善

分析改善の例2. コンテンツの偏り

課題

  • コンテンツの収集が偏っている

仮説

  • サービス拡大に伴いユーザー層が変化しているのでは
  • ユーザーをカテゴリ別に分別すると、得意なところととくいでないところがでてきた

対策

コンテンツをふやす
手動でテレビで流れたコンテンツを導入した

本当に必要なのかの議論

  • 分析するとき、精緻で複雑なモデルを立てたくなってしまう
  • 必要なのは、素早く検証できることなので、過度に複雑なモデルは立てない

意見交換

タスクの優先順位付けはどのようにしているのか

  • プロダクトチームがえいやでやっている部分もある

機械学習のfeatureの選定はどのように行っているのか

  • 手動で頑張った

可視化はRailsで今も行っているのか?

  • メインはRailsで現在もやっている

所感

  • 「スピード感大事」というのはデータ分析も同じ。
  • データを分析する前に、データを分析できるようにすること、そのための可視化。
  • 仮説をどう立てるか考えるのは難しい、簡単に試せること、結果から学ぶ方法で対処。
  • ビール✕ピザはやっぱり正義。
  • Deep learningはH2Oで敷居がかなり下がったのでやってみたい

  • ダッシュボード類は気になる。一部使ってるけれど、他のものも使ってみたい。Tableauとか
  1. Mixpanel
  2. Tableau

BizReachさんありがとうございました!