【2014.8.28 ヒカラボ発表：ログ集計/解析システムについて】ログ集計システムを最初から自前で作るべきか？

2014.8.28 ヒカラボでログ集計/解析について発表しました、菊池佑太です。
それほど詳しく説明しなかった内容について皆さんに一度考えていただきたい事、
またもっと良い方法があれば教えていただきたいので内容を書いてみます。

僕の発表資料では集計システムを一から実装する話を当たり前のようにしてしまいましたが、
便利な集計ツール(GoogleAnalytics等)というのが既に出回っており、
その利用で集計の要件が満たせるのであれば独自開発の工数をほぼ0に抑える事も可能です。

ログ集計ツールの作成も簡単な物では無く、かなりの工数を必要とします。
便利な集計ツールと独自の集計ツール開発の機能が重ならないように
GAの足りない部分を補う形で独自の集計ツールを導入というでも最初の段階では問題無いと考えています。

ただし、発表の中でも触れましたが、便利ツールで集計された値と実際のサーバーログから集計された値が
イコールになる事はほぼ無いに等しいので、厳密な値を出したい場合にはどうしても自前で集計する
必要が出て来ます。

【質問内容】
・以上の内容を踏まえて皆さんがログ集計システムを作るとしたら最初から導入しますか？
・既に同じような事例を対応中の方はどのような導入手順を踏まれていますでしょうか？

行動規範の内容に同意します

回答2件

私はWEBメディア（非EC）の分析しかやったことがないので、情報に偏りがある前提で。

**>・以上の内容を踏まえて皆さんがログ集計システムを作るとしたら最初から導入しますか？ **
場合によりますが、私は基本的には最初からは導入しないです。

理由は、そもそも数値を見て改善していく文化がある企業が少ないので、まずはGoogle Analytics 等を導入して、数値を見る文化を作るところから始めるためです。
Google Analytics でもカスタム変数等を使えば、細かい数値を取ることができますし、APIを使えば複雑なレポートも自動化できるので、ある程度の範囲はカバーできると思います。
なので、まずは大雑把な数値を見る文化を、次にその数値を見て施策を出したり、意思決定したりすることを浸透させます。
そのうえで、より細かな数値を見て改善していきたいとなれば、別途システムを構築することを検討します。

個人的には「Google Analytics のこの数値の定義は怪しくないか？どう計測、集計されているんだ？」「◯◯の数値を取りたいけど、Google Analytics じゃ取れない、どうしよう」という話が出てきたら、独自の集計ツール導入を検討してもいいのではないか、と思っています。

また、恐らく以下の場合は最初から設計・導入することを検討したほうがいいと思います。
・EC系
→Google Analytics だと購入あたりの数値分析が難しくなるため
・スマートフォンアプリ
→サイト内での行動が見えづらいので
・数値を見る文化が強い組織
→より細かな数値を求められるため
・はじめから大規模化・複雑化することが決まっているメディア
→後から組み込みが複雑化するため

**>・既に同じような事例を対応中の方はどのような導入手順を踏まれていますでしょうか？ **
私がいる会社では、集計システムの導入はざっくりと
・社内データ、業務の洗い出し
・分析すべき内容の洗い出し
・取るべき情報の選定
・技術要件定義
・実装
というステップでやりました。

導入にあたっては
・そもそも広範囲について理解し、仕様を詰めることができる人がいない
・社内で優先順位が高まらず、リソースが調達できない
というところが問題でした。

投稿2014/08/29 05:59

Masafumi

総合スコア31

なかなか難しいテーマですね。

どこかのプラットフォームに所属してサービスをローンチするパターンと、完全に自社のメディアで1から細々やっていくパターンとで大きくことなるような気もしますが…。
まとまりないけれども、自分なりに解析周りについて、意見を述べさせていただきます。

（１）Hadoopを準備しなくてもログはしっかり落とすこと
ログさえあればHadoopに後から食べてもらうことが出来るので、その予定があろうがなかろうが、イベントのログはしっかり落としておくべきだと思います。

（２）DB→ログ or GoogleAnalytics→Hadoopの順
まずはDBを舐めて得られるデータもあるかと思います。そこすらも出来ていないなら、やったらいいと思います。
そして、行動の部分において、DBでは賄いきれないものがあれば、DBのIOを抑えるためにテーブルへのinsertではなく、ログで対応する。
もしくは、GoogleAnalyticsで対応する。ただ、GoogleAnalyticsは高度な分析には向かないので、そのような要件があればHadoopでと言う選択になるかと思ってます。

（３）メディアによって、GoogleAnalyticsでもOKな場合も。
ゲームだとユーザーの回遊状況の他に、レベル、カードのデッキ、アイテム保有、利用深度によってイベントを決定する必要があると思うので、GoogleAnalyticsでは不向きで、DBかHadoopによる解析基盤を作ることをオススメします。
一方でニュースサイト等であれば、GoogleAnalyticsで大半の要件は済んでしまうケースもあるのではないかと思います。少なくともゲームよりはニーズが低いです。
会員系のサービスは何となくHadoopがあれば便利だなぁとは感じております。

（４）サービスローンチに解析基盤は必須ではない
いくらログとそこからの分析の手法を検討してもサービスのローンチが遅れたり、クオリティが十分上がらないのであれば、最初から入れるのは諦めた方がよいかと思ってます。

（５）組織の成熟度合いにもよる
僕がコンサルしている組織では、GoogleAnalyticsに限界を感じている状態だったのですんなり通りましたし、そうすべきと言う意見も強かったです。
ただ、分析の文化がないところに無理やり導入しても、猫に小判的な感じであんまりワークしないような気がしています。

で、ここまできて回答となります。

【質問１】ログ集計システムを作るとしたら最初から導入しますか？
これについては、上述の通り、メディア、規模感に応じてだと思いますが、ゲーム系はその期間ログが欠損することとなり、あとからDBからデータを作ることが大変なことが予想されるのであれば、最初から導入しようよ、と働きかけます。ただし、それによってリリースが遅れるのであれば、せめてログだけ埋めてくれとお願いします。

【質問２】既に同じような事例を対応中の方はどのような導入手順を踏まれていますでしょうか？
（５）導入背景としては、記載の通りとなります。ただ、この場合あとから導入しているのでどうしても解析基盤導入前のデータは欠損として扱われるので、見えてこない部分もありつつ、そこを補完するかどうは上層部の判断に任せてしまっております。
ただ大事なのはログよりも、DBのデータが正値であるので、まずはDBにどんなデータがあるのか、ログとして補完しなくてはいけないのはどの辺なのかを判断するために、必ずER図は見るようにしています。
（DBのデータが正値と言うのは、ログ出力にトランザクション機能的なものが備わっていないことが一般的だと思いますし、その扱いもDBより厳密にはなり得ない辺りから、そのように考えております。）

で具体的な進め方については、
・ビジネススキームの理解
・既存で集計しているデータの確認
・組織的課題の洗い出し
・DBのER図確認
・必要そうなレポートの決定
・ログとして出力する内容の決定
・Hadoopテーブルの設計
・ログの設計
・ログ出力ライブラリの作成
・ログ出力ライブラリ組み込み
・Hadoopへの取り込み