【特別連載】さぁ、社内でデータ分析を始めよう!(第2回:新しくログを作成してみる)

はじめに

 

こんにちは。

前回は「現在あるデータを活用してみる」という話でした。

※第1回はこちらから

今回は「新しくログを作成してみる」という話です。

今回も例としてECサイトを運営していると仮定します。

 

このフェイズではシステムからログを送信することになるため、システムを操作できるエンジニアの協力が必要不可欠になります。

システムにログを仕込むとなるとハードルが高くなりそうですが、それを出来るだけ簡単に実現できればと思っています。

若干エンジニアリングの内容も含んでしまいますがご容赦ください。

システムからログを送るには

 

システムからログを送る際、いくつかの選択肢があると思います。

  1. システムから直接ログを書き出す機能を作る
  2. Webサーバのシステムログ機能を利用する
  3. fluentdに代表されるログ収集ソフトウェアを利用する

代表的な例を挙げてみましたが、2015年現在では3.が圧倒的にオススメです。

 

自分でログを書き出す機能を作るならば、複数のユーザが同時にアクションログを残す場合の処理やログのローテート(日や容量によるログファイルの切り替え)を考慮しなければなりません。

これらの機能を実装するには高度なプログラミングスキルが必須となるため、あまりオススメはできません。

 

Webサーバのシステムログに残すだけでもひょっとしたら十分かもしれません。

しかしログ収集ソフトウェアにはログを記録するだけではなく様々な機能があります。

この機能を使えばより高度にログを扱うことも可能になります。

代表的なログ収集ソフトウェア

 

代表的なログ収集のソフトウェアは下記のものが挙げられます。

・fluentd

・flume

・Scribe

 

なかでもfluentdは2015年現在利用実績が多く、多くのウェブサイトで紹介されています。

そのため深い理由でもない限りfluentdの利用をオススメします。

簡単なfleuntdの紹介

 

fluentdは、クラウド型のビッグデータサービスとして知られているTreasureData社が提供しているOSS(Open Source Software)です。Rubyで実装されており、軽快に動作します。

また(一般的な利用をするかぎり)ログの欠損はほぼなく、非常に高い信頼性もあります。

 

多くのコンピュータ言語をサポートしており、ライブラリを導入しシステムからfluentdを呼び出すだけで簡単にログを残すことができます。

プラグインを導入することで、特定のログに対して様々な処理を行うことができます。

プラグインはオープンソースとして非常に多くのものが公開されており、rubyを用いて自分で書くことも可能です。

 

AWS(Amazon Web Service)のS3などのクラウドストレージにログを送信するプラグインも公開されているため、

前回紹介したようにアクションログをクラウドストレージに保存することも簡単です。

アクションログとは

 

アクションログとはシステムの機能からユーザの行動をログに落としたものです。

任意にログとして残したい項目を設定できるため、Webサーバのログよりも更に詳しい分析ができるようになります。

例えば購買のアクションログに、購入時間、商品の種別、価格、個数などを残しておけば、どの時間に購入されているかや商品種別の売上高を知ることができます。

アクションログはそれぞれに種別を持ち、それぞれに特有の項目を持ちます。

下記はあくまで一例です。

 

アクションログ取得項目例
種類 ユーザーID 時間 項目1 項目2 項目3 項目4 ・・・
購買 購買ユーザーID 購入時間 商品ID 販売個数 単価 売上 ・・・
検索 検索ユーザーID 検索時間 検索キーワード ヒット数 ・・・

 

 

アクションログはシステムの機能が正常に実行された時にログが書き出されるよう設定することが多いです。

backstage_analysis_env_vol2_1

アクションログを発行する際のコツ

 

さてアクションログを書き出すことについてはできていると仮定して、実際にアクションログを定義してみましょう。

 

アクションログを残す際はユーザの行動よりもシステムの機能を意識したほうがスマートにログを残すことができます。

例えばユーザが新規登録をして同時にログインも行う処理の場合、

・新規登録+ログインで1つのログを残す

・新規登録機能で1つのログ、ログイン機能で1つのログを残す

といった2つのパターンが考えられます。

しかし後ほど全ユーザのログイン数を集計する際、

前者の場合は新規登録のログインと登録済みのログインのログをそれぞれ集計する必要があります。

しかし後者だとログインのログを集計するだけで済みます。

 

また複数の種類の商品をまとめて購入した際も

・複数の種類を購入したという1つのログを残す

・商品の種類ごとに複数のログを残す

といったパターンが考えられます。

前者の場合はログが複雑になり集計が大変になることが多いため、後者の形式でログを残すほうがよいです。

アクションログの項目作成のコツ

 

記事などを書く上で重要になる要素に5W1Hという言葉があります。

 

・Who(誰が)

・Where(どこで)

・When(いつ)

・What(何を)

・Why(なぜ)

・How(どうした)

 

アクションログの項目についてもこれらの要素は非常に重要になります。

ただしアクションログにおけるWhyとはユーザの行動の理由であり、非常に取得することが難しいです。

むしろWhyを知るためにデータ分析を行っていると言っても過言ではありません。

そのためアクションログの項目を作成する際は4W1Hを満たしているか意識しましょう。

backstage_analysis_env_vol2_2

無理してフォーマットを揃えない

 

わたしも実際にアクションログの定義を行い、エンジニアさんに実装をお願いする機会が何度もありました。

お願いした項目の中にその機能の中では取得が難しい項目があり、ログのためにシステムやエンジニアさんに負荷をかけてしまったことがあります。

確かにアクションログの項目で4W1Hを網羅していることは望ましいです。

しかしログのためにシステムに負荷をかけるのはナンセンスです。

ログはシステムのためにあり、システムのためにログがあるわけではないことを念頭に置く必要があります。

おわりに

 

次は「DWH(データ・ウェア・ハウス)を検討してみる」になります。

DWHを通して(または通さずに)更にデータを活用することができればと思います。

 

DATUM STUDIO株式会社では『アクションログ』を利用した分析も行っています。

興味を持たれた場合はご連絡お願いいたします。

 

<<お問い合わせ窓口>>