（83億レコード移行の続編）BigQueryを導入して改善サイクルがスピードアップした話

みなさん、こんにちは。
PFM本部（家計簿アプリのマネーフォワードをつくってる組織）の伊藤です。

先日、当ブログでこんな記事をアップしました。
83億レコードを移行し、日々2,500万レコードのアクセスログをBigQueryに記録している話（インフラ編）

ありがたいことに良い反響を多くいただき、沢山のブクマを頂戴しました。
そんな中で、

83億レコードを移行し、日々2,500万レコードのアクセスログをBigQueryに記録している話（インフラ編） | Money Forward Engineers’ Blog次回はこのビッグデータを何に使ってんのか書いてほしい2016/08/03 19:00

というコメントをいただいているので、導入してどのように活用しているかの記事を書いてみたいと思います。

まとめ

なぜBigQueryを推進したのか詳細な分析をするのに便利なツール RにBigQueryのデータを読み込むデータの可視化多変量解析や機械学習の取り組み

なぜBigQueryを推進したのか

まず、BigQueryの導入背景からご説明します。

すでに記載の通り、導入以前ではMySQLで分析を行っていました。

様々なテーブルが存在し複雑なクエリを書くこともしばしばありますが、ある程度条件や規模を絞りその上で集計をかける分にはそれほど問題なく分析を実施することはできていました。

しかし、ユーザー行動を詳細に分析しようとすると、
・まともに施策の効果測定ができない
・分析しようとしても非常に時間と手間のかかる
といった状況となっていました。

当初はクエリを分割して並列に処理を走らせたり、サブクエリを多用して細かな粒度でクエリを実行していましたが、さすがにストレスのかかる状況でした。
また、新機能の効果検証をするために夜な夜な重たいクエリを投げては長い待機時間を待ちながら分析をしているという状態でした。

SQLは覚えれば10年は戦えると言われるほどの便利なものです。
弊社では、エンジニアだけでなく、企画などを考える担当も、CSの担当者もSQLを実行しています。
マネーフォワードに学ぶ「カスタマーサポート」が発揮すべき価値。プロダクトへ本音で改善提案も。

クエリ実行が遅いままでは改善サイクルを早く回すことができないし、やるにしても負荷が高すぎるということで、インフラチームに協力を依頼し分析基盤を早急に構築するに至ったという背景があります。

これは最終的に分析者の負荷を軽減すると同時に、今までできなかった分析を可能にし、さらにサービス改善の余地を広げることにもつながり、最終的にサービスを利用してくださっているユーザー様に価値を還元することが大きくなったため、取り組んでよかったなという印象があります。

また、個人的にはMySQLではWindow関数を扱うことができず、ユーザー行動分析に対して大きな足かせとなっていることも課題の１つとしてありました。
GoogleのBigQueryではWindow関数も扱うことができ、今年に入って標準のSQL構文も採用され、SQL言語として扱うことができるのであれば既存のシステムを利用している人に取ってもスムーズに移行できるはずだということも推進する理由の大きな要因となりました。

改善後は行いたい分析も実施することができ、大変満足しています。

詳細な分析を実施するのに便利なツール

私は主に、様々なデータを分析するためにR言語を用いて分析を行っています。
R言語はオープンソースの分析ツールで主に統計解析を行いたいときに活用する際に便利ですが、近年ではデータ処理系のパッケージも充実しており、非常に便利なツールです。

R言語はコンソール画面での利用なので、便利なRstudioというツールを使うことでIDEのようにRを使うことができます。

RにBigQueryのデータを読み込む

RにBigQueryで集計したデータを接続するには、[httpuv]パッケージと[bigquery]パッケージを利用します。あらかじめ自身のR環境にこのパッケージをインストールしておくと良いでしょう。また、[bigquery]パッケージはHadlyさんというR界隈では神と崇められている方の自作パッケージなので、彼のGithubからインストールするために[devtools]パッケージも必要です。

install.packages('httpuv')
install.packages('devtools')
devtools::install_github("hadley/bigrquery")
library(bigrquery)

次に、Google認証を行う必要があります。
[httpuv]パッケージのquery_exec関数を用いて、自身のBigQuery環境に接続します。

query_exec(project = 'プロジェクト名', 'SELECT COUNT(*) FROM [テーブル名];' )

すると、ブラウザが立ち上がりGoogle認証を行う画面が出ます。指定したBigQueryのプロジェクトに適切に追加されていれば、これで接続は完了です。

先ほどのquery_exec関数内の引数に適切なクエリを書いて、欲しいデータをR内にインポートしましょう。

この際に注意すべき点は読み込んだ際のデータの形式がdataframeで型がstringであるという点です。必要に応じてデータ型を変更するようにすると良いでしょう。
また、デフォルトだと上限が100,000件なので、必要に応じてpage_sizeやmax_pagesの引数指定を変更しましょう。最初にこの制限にかかったことがわからず右往左往してしまいました。

私は個人的にR内でSQLを書くことに抵抗感があるため、BigQuery内で演算した結果をtmpテーブルとして保存し、そのデータを引っ張り出すということをしています。
読み込むデータ量が大きいとエラーになるケースもあり、多少の工夫が必要でしょう。

データの可視化

様々な可視化の方法がありますが、ユーザーの行動状況を分析できるようになったので、曜日や時間ごとに可視化を行い、どの時間帯に施策を実施すれば効果が高く見込めるかなどの事前検証にも役立っています。

ggplot2を利用した行動可視化の例

*x軸=時間、y軸=人数

これによって、新機能の告知の時間や曜日などを最もホットな時間帯に設定し、実行することでより効果の高い施策にすることができています。

多変量解析や機械学習の取り組み

R上で簡単に行動データが取れるようになったので、行動分析でよく使われる決定木というアルゴリズムでいかにユーザーに使ってもらえるかの分析を実施した結果です。

あまり詳細はお見せできませんが、3.5日以上利用してもらうことで今後もリテンションしてもらえる確率が格段に上昇することがわかりました。そのため、登録後の導線を見直したり、活用方法を補助するステップメールの施策などにこの閾値を使って施策が企画され、まさに動き始めている段階です。

これらの施策が実装され、またユーザー行動が変化する時期に新たな分析を実施して、その結果をもとに改善施策の立案を行うなど、施策のサイクルスピードが以前に比べて格段に早くなりました。
データ分析から施策の企画、実装、実施後の効果検証までを自分自身で完結できるようになったため、ピボットする場合もアプリケーション側に実装する場合も非常にスピーディーにできるようになりました。

このようなスピーディーな動きが結果としてユーザーに対して価値を大きく還元できるものだと考え、日々取り組んでいます。

まだまだじっくりと腰を据えて分析などをできていませんが、今後はより詳細な分析を実施したり、その結果をもとにさらなる改善施策を実施していく予定です。