こんにちは、コンテンツ・メディア第1事業部の開発課のログチームのラヒルです。
本日は、データマイニングを始めるためにはどのようにデータを準備する必要があるかを紹介します。
オンラインサービスのデータについて
簡単に分けると、オンラインサービスから蓄積されるデータには大きく２つのタイプがあります。
- データベース － サービス運用のために必要なデータが保存される。ユーザーのステータスやユーザーのアクションの結果等が記録されていることが多い
- アクセスログ － ユーザーのページアクセスやタップイベント等が記録されている。ウェブサーバーやアプリケーションサーバーに、ログファイルとして保存されている。
データベースのデータは、サービスを維持するために必要なデータが保存されています。しかし、このデータは分析用としてそのまま使うには難しいケースが多いです。アクセスログは、ユーザーがサービスを利用する上で、どのように使ったか（UIの操作履歴）の履歴となっています。ほとんどの場合は、そのまま分析するには複雑すぎることが多いです。では、データベースとアクセスログデータから、データマイニングあるいは分析用にどうデータを変換した方が良いかを説明します。私達のチームでは、この元のデータを加工して、データ分析用のデータベースに（データウェアハウス）保存しています。データ加工とテーブル設計等は、どのようにした方が良いか等を紹介します。
データマイニング用のデータ設計方法
サービスのデータを以下のようなデータ構造に変換してから、データ分析に使っています。
- ユーザーのイベントデータ
- ユーザーのステータスデータ
- ユーザーのイベントの定期要約データ
- ユーザーのステータスの時系列変化
- システム要約データ
データマイニングは、ほとんどの場合、ユーザーの行動あるいは体験を分析するために行います。そのため、①～④のテーブルは、ユーザーの行動あるいは体験をどう表すかを意識して設計しています。上記のデータの5種類について詳細に見ていきましょう。
①ユーザーイベントデータ
このデータは、ユーザーのアクションと体験を表します。アクションと体験は、サービスのUX設計等をベースに考えると考えやすいと思います。一つのデータレコードは、一つのアクションと体験を表します。しかし、場合によっては、この一レコードは、ユーザーの複数のUIアクセスやタップによって行う操作を、一つのアクションして抽象化しているものもあります。例えば、画像管理と投稿できるようなSNSアプリを参考に考えてみましょう。
主に考えられるユーザーイベント
- 新規でアプリ登録する
- チュートリアルを完了する
- 友達を検索する
- 友達をフォローする
- 友達にフォローされる
- 画像をアップする
- 画像をアルバムに振り分け保存する
- 画像を投稿する
- 友達の画像にコメントする
- 自分が投稿した画像に「いいね」される
このイベントを見ると、大きく２タイプのものがあることに気が付くと思います。ユーザーが自分の意思で行うアクション、ユーザーが体験することの２つです。一つのイベントが複数のアクションを完了することによって発生することもあります。例えば、画像投稿のイベントは、画像を選ぶ、タイトルを入力する、コメントを入力する、カテゴリー設定、ハッシュタグ設定、公開範囲の設定、等の複数のアクションによって完了されます。もちろん、このアクションを別々にイベントとして保存するということもできます。しかし、分析という意味では、細かいアクションの単位では、なかなか分析が難しくて複雑になりやすいです。そのため、ユーザーの行動は、ある程度に抽象化した形で、ユーザーイベントを定義した方が効果的だと思います。
ユーザーイベントデータの形式：
データは、5W2Hで保存します。誰が（Who）、何を（what）、どこで(Where)、いつ（when）、どの位（How many）、なぜ(Why)、どのように（How）の項目を記録します。イベントによって、5W2Hのすべてが存在しない時もあります。
SNSアプリを例にして、画像を投稿した場合を考えてみると、
Who – ユーザーID
What – 投稿ID
When – 投稿時刻
Where – どこのページで投稿したか
How many – 画像が何枚か
Why – 目的
How – なし
定義が難しいものもあります。特にWhere、WhyやHowの定義はイベントに依存します。
②ユーザーのステータスデータ
ユーザーのステータスデータとは、ユーザーの現在の状態を表すデータを保存するテーブルを意味します。このデータは、毎日のユーザーの行動によって変化するものもあります。そのため、いつも最新状態で保存されています。データを管理する単位は、現在私達のチームでは、データウェアハウスのデータを一日単位で管理しているため、一日一回更新されています。
ユーザーステータスには、二種類のデータがあります。
- 固定情報：年齢、地域、性別、職業などのユーザーの情報
- ユーザーの行動から生まれてくるステータス 例：サービス利用期間、友達の人数、保存されている画像枚数の合計等
このデータの特性は、その時刻であるユーザーを説明できるということです。特に、短期間では、著しく変化しない、あるいは、短期間での行動を表すというよりも、長期的な行動状況を表すようなデータを表す変数にした方が良いユーザーの特性に関しては意味があります。
悪い例：最終アクセス時刻
良い例：月間平均滞在時間
データマイニング手法などに使うときは、ユーザーの特性として使えるかという意味で評価します。
③ユーザーイベントの定期要約データ
データマイニング手法を用いたデータ分析には、ユーザーは説明変数を用いて表さないといけません。そのためには、ユーザーのイベントデータをそのままデータマイニング手法に使うことはできないことが多いです。その問題を解決するためには、イベントデータを何らかの形で変数化しないといけません。ユーザーの行動イベントは、定期的に要約して変数に変換します。
例：ユーザーのイベントデータから、一ヶ月間でユーザーのある特定のアクション数をカウントして変数として保存します。アプリ起動回数、「いいね」した件数、画像を投稿した件数、新規フォロー作成件数
このように変数化することによって、ユーザーの行動イベントの情報量を減らし、説明変数として使えるようになります。私達のチームのデータウェアハウス上では、ユーザーのイベント情報を集約して、ユーザーイベントの定期要約データを作成し保存されるようにしています。現在は、データの集約期間は一ヶ月を期間としています。データ分析を行いたい時には、この定期要約データを使うことが多いです。
④ユーザーのステータスの時系列変化
ユーザーのステータスデータの値は、日々変化していきます。そのため、ユーザーの状態が過去はどうだったか、あるいはどのように変化していたかを後で見るとわからなくなります。そのため、ユーザーのステータスデータを一定期間ごとに、スナップショットとして保存するようにしています。私達のチームのデータウェアハウスでは、スナップショットの保存間隔は一ヶ月間としています。１ユーザー当たり一ヶ月に一回、ユーザーのステータレコードとしてテーブルに挿入されます。このデータを使うと、ユーザーの成長あるいはサービスの利用頻度の変化等はユーザーごとに時系列のデータとして作成できます。
⑤システム要約データ
ユーザーベースのデータだけではなく、サービス全体として集約するデータを作成しています。このデータは、ユーザーの特性や予測には使いませんが、時系列データとして、サービスとしては将来予測に使います。
例：
デイリーアクティブユーザー数、マンスリーアクティブユーザー数、PV数、
新規登録ユーザー数、課金したユーザー数
データによって、一日ごとに集計するものと一ヶ月に一回集計するものがあります。
終わりに
本日は、データマイニング用のデータ準備方法に関して説明しました。サービスのデータベースとアクセスログを用いて、ユーザーの行動や体験を表すようなデータの加工方法に関して説明しました。今後は、このデータをどのようなデータマイニング手法に用いて分析しているかを説明します。
