プロダクト開発初期からの行動ログ計測のすすめ

皆さん、プロダクトリリース時に計測を意識していますでしょうか？

プロダクト開発時からきちんと計測検討・実装することで、リリース後の問題仮説の精度が高まるため、非常にメリットがあります。
リリース後、より素早く正しく仮説を検証することが重要であるため、はじめから意識しておきたいところです。
特に計測は、全体の集計だけではなく、個人の行動を特定し追えるようにする行動ログを考えています。

ここでは、計測の方法と、データ基盤構成をお伝えします。

対象者

データを基に、施策検討や課題分析をする人
・プロダクトマネージャー
・データアナリスト
データ基盤を構築する人
・ソフトウェアエンジニア
・データエンジニア

行動ログの計測の方法

ユーザーの行動の何を計測したいのかを決めます。

普通にシステム開発をすると、ユーザーの重要な行動（ECで言えば、注文時の注文データ）などは、データベースに保存していると思いますが、それまでの過程がどうなっているのかが計測できていないと思います。例えば、カートに入れた後、配送先情報の入力前で止まって離脱してしまった、などです。（※ECの場合、この画面ごとにデータベースに保存しているケースもあると思います。例です。）

Google Analyticsを組み込めば、全体としての集計はできますが、デフォルトではユーザー単位の測定はできません。GoogleAnalyticsのイベントトラッキングでも代替可能ですが、自前で実装する方法を共有します。
会社では、行動ログとその他データベースを紐付けながら分析がしたかったため、拡張性を考え自前で実装しています。

ユーザーに関係する全ての行動を計測したかったため、
以下のような項目を画面遷移時と重要なアクションボタン押下時に、行動ログとして、計測しています。（ログ項目はREST前提になっています。）

・時刻（タイムスタンプ）
・ユーザーID（ユーザーを一意に特定するID）
・オリジナルパス
　URLのパス部分。
　例）Note検索画面の場合
　https://note.com/search?context=note&mode=search&q=pdm
　=> /search?context=note&mode=search&q=pdm
・グルーピング用パス
　オリジナルパスから、クエリパラメータ（?以降）を外し、IDをグルーピングしやすいよう置換して同一に扱えるようにした文字列。あとでSQLで集計しやすいため。
　例）Note編集画面の場合
　https://note.com/junpei0029/n/n8588b1991b54/edit
　=> /notes/id/edit
・HttpMethod（GET/POSTなど）
・クエリパラメータ（URLの?以降の文字列）
・リソースID：パス内のリソースのID。置換する前に取得しておく。
　例）Note編集画面の場合
　https://note.com/junpei0029/n/n8588b1991b54/edit
　=> n8588b1991b54

行動ログの例
2021年1月1日に、ユーザーIDが100のユーザーが、商品IDが10の商品ページを参照した場合

時刻：2021-01-01T10:21:23+09:00
ユーザーID：100
オリジナルパス：/products/10?type=AAA
グルーピング用パス：/products/id
HTTPMethod：GET
クエリパラメータ：type=AAA
リソースID：10

2021年1月2日に、ユーザーIDが100のユーザーが注文を完了した場合

時刻：2021-01-02T13:12:34+09:00
ユーザーID：100
オリジナルパス：/order
グルーピング用パス：/order
HTTPMethod：POST
クエリパラメータ：（空）
リソースID：（空）

これでユーザーの4W1H（誰がいつ何の行動をどのような手順で実行にしたか）がわかるようになります。※whyはわからない。

データ基盤構成

次に上記の行動ログをダッシュボードで見れるようにします。

仕組みとしては、行動ログAPIを作成し、サーバー上で標準出力に行動ログを出力します。その標準出力の内容をfluentdでS3にリアルタイム保存。
S3からembulkでBigQueryに日次で連携しています。
データ見るときは、Metabase、DataPortalを利用しています。

基盤構成イメージ
（行動ログだけではなく、アプリのデータベースの構成も載せています。）

注）行動ログは、自前実装しないとできないのか？

自前実装でなくてもできます。
前述した通り、GoogleAnalyticsでもイベント機能で似たようなことはできますし、グロース分析ツールである、Mixpanel、Amplitudeでもできます。
会社では拡張性とSQLがかけるエンジニアは多いことを考慮し、SQLで自由に分析しやすい構成にしています。

計測後のメリット

ここまで準備できれば、後はSQLを書けば大概の分析ができ、実態がわかるようになります。

例えば、ECシステムの購入を増やしたいとします。計測がない状態だと、今の問題は、商品のページの表示内容なのか、商品の購入フローなのかは、推測で考えることになります。

計測ができている場合、例えばファネル分析を行うことで、
商品の購入フローには流入があるが、入金方法を入力するという箇所で、数字が落ちているといったことがわかるようになります。これにより、仮説の確からしさやここから新たな問題仮説を生み出すことができるようになります。

まとめ

Webサイトの行動ログは、事実を知る上で重要なのでプロダクト初期から取り入れよう！