データ分析基盤を作ったらUX,UIデザインがもっと面白くなった話
サービス改善に取り組む中で、ユーザーのことを正しく知り、適切なサービス改善をスピード感持って進めるために、データ基盤を作ってみました。
分析基盤を作るに至った経緯
そもそも何故分析基盤を作ろうとしたのか。
もともと私はデータを見ることが好きですが、携わっているサービスにおいて、現状把握がとてもしづらい、という課題に直面したことがきっかけでした。
2023年7月にGoogleAnalyticsがGA4に完全移行されたものの、GA4からCSV出力した結果をWahaとTableauで加工し、手作業でレポーティングしている状況でした。
また、KGIに近い数値は見ているものの、そこに至るまでのユーザー行動の観察が不足していると感じました。
当時の課題
サイト改善の影響、効果がわからない
全体の数値は下がっていないから良いんじゃないか？という粒度で判断することが多かった。分析レポートを手作業で更新しており、運用に追われがちだった。
BigQueryとLookerStudioの導入
GA4やGoogleSearchConsoleのデータをBigQueryに集積、自動集計した結果をLookerStudioで可視化することにしました。
補足）
BigQuery（以下、BQ）の必要性について
GA4はUA（UniversalAnalytics）のように、画面上での細かな集計がしづらく、今や行動ログをCRM施策に活用することが当たり前になりつつある今、ローデータを自在に集計できる仕組みが、どうしても必要でした。
導入までの難関
BQでいくらかかるのか問題
BQは私がプロジェクトに加わる前から、何度か検討にはあがっていたものの、従量課金制でどの程度費用がかかるのかわからないために、導入できずにいたことが発覚しました。
集積するデータ量とクエリ実行でどのぐらい課金されるか試算して説得することも考えましたが、そんなものはやってみないとわかりません。
というわけで、試しに1ヶ月、GA4のデータをBQに取り込み、ユーザー行動や主要画面の改善を行なっていく上で必要な自動集計レポートを作成し、課金額の確認と導入によりどんな良いことがあるのかを、自ら形にしてみて社内調整することにしました。
データの取り込み方法がわからない問題
やってみると決めたのは良いのですが、肝心のデータ取り込みの仕組みはおろか、GoogleTagManagerにどんな設定があり、どんなことができるのかも理解できていませんでした。SQLは書けるけど、GA4からBQにどうやってデータを取り込むのか、クリックイベントも細かく追えるようにしたいけど、やり方がわからない、という状態でした。
そこで、ここは思い切ってBQ活用の経験が豊富な以前の職場の同僚に力を貸していただくことにしました。
実現したい状態、必要な項目やテーブル構成のイメージはあったので、それらを伝えてベースの仕組みを整えていただくところを委託させていただきました。
やったこと
１）分析時に扱いやすい汎用テーブルの定義
先述の通り、BQに取り込まれるGA4のデータは、特殊な構造のため、そのままだと扱いにくい状態です。
keyとvalueで入れ子構造で保持している値があり、そのままではSQLで都度ちょっと特殊な書き方をしなければいけません。
また、GA4に集積されているデフォルト項目に加え、ページのカテゴリやログイン有無、求人状況など、ページ閲覧時にフロントからGA4に都度渡したい項目もありました。
これらの状況を踏まえて、どんな分析にも使いやすい、汎用テーブルを作りシンプルなリレーショナルDBを扱う感覚で分析できるようにすることにしました。
汎用テーブルに持たせたい項目を伝えて、項目の取り込み手段を初期設定を委託した友人に教えてもらいながら整理しました。
結果、データの取得方法は以下の3種類になりました。
GA4のデフォルト項目
GTMに定義されたjavascriptでGTMに取り込みGA4に渡す項目（クリックイベントでページ内のどの要素をクリックしたのかなどはこの方法で取り込むことにしました）
フロントエンドのdatalayer変数定義により、GTM経由でGA4に渡す項目
上記をもとに、知人にGTMの設定とBQでデイリー実行して汎用テーブルを生成するためのスケジュールクエリを作成してもらいました。
並行して、社内では足りないdatalayer変数の実装や、クリック測定タグの埋め込みなどを進めました。
２）汎用テーブルから定点レポート用のデータを生成する
おおよそどんな指標で観察したいかは、イメージがありました。
LPのカテゴリ別の傾向や求人や施設カテゴリ別の傾向、サイト全体の流入傾向などなど。
それらをmonthly、weekly、dailyで自動集計し、LookerStudio（以下、Looker）でビジュアライズすることにしました。
Lookerでのビジュアライズにおいても、いくつかの方法があります。
方法1
BQのテーブルをデータセットに追加して、LookerでSQLを書いて集計結果をグラフにする方法。
方法2
BQのスケジュールクエリを使ってLooker用の集計結果テーブルを生成しておき、Lookerのデータセットは集計結果テーブルを読み込ませる方法。
Lookerは無料で使えますが、LookerからBQを参照した場合、BQ側のクエリ実行にかかるメモリ量により、BQの料金は発生します。
Lookerには取得したデータセットを一定期間キャッシュしておける設定もありますが、なるべくBQの課金リスクは下げておきたい、というわけで、方法２で運用することにしました。
３）社内DBの一部情報の取り込み
プロダクションDBから、分析用に個人情報などを除いた状態でデータを入れているサーバーがあり、その中のマスター系のデータをBQに取り込み、汎用テーブルと結合して集計できるようにしました。
また、一部のマスタ情報は社内DBにあったので、こちらはひとまず手動でBQに取り込み、グラフに使うテーブルを生成しました。
ここまでで分析基盤をいったん完成としました。
やってみてどうだったか？
チーム内のコミュニケーションの変化
レポートをチームに共有し、日々レポートを元に会話するうちに、デザイナーやマーケターなど、特に近くで働いているメンバーを中心に、レポートを見て自分の目標と照らし合わせたり、何が起きているのかをデータから推察しようとする動きが見られるようになりました。
このデータからすると、ここはこうした方が良いんじゃないか？
こういう理由でユーザーはこの行動をとっているんじゃないか？
など、見た目の話ではなく、
ユーザーに何を届けるべきだろう？
今解決すべきことは何だろう？
という性質のコミュニケーションが増えました。
目的やむ
さらに、これらのレポートがほぼ人の手を介さず更新されるので、メンバーがレポート作成のルーティーンに充てていた時間を、サービスについて考えたり手を動かす時間に充てられるようになりました。
サービス理解度の変化
どんな利用者がどのぐらいいるのか
どんなワードで流入してどんな行動を取る方が多いのか
どこがうまくいっていて、どこがうまくいっていないのか
ということを知る方法に、データという手段が加わり、それがグラフによって、直感的に理解しやすい状態になりました。
これにより、自分たちのサービスが、ユーザーにどんな形で伝わっていそうかを感じ取りやすくなりました。
サービス改善効率の変化
様々な切り口でデータを切り分けて、何が起きているのかをグラフで見られる、前年と比較できるようにしたことで、施策の効果や外的要因による変化などに素早く気づけるようになりました。
先述の汎用テーブルを使えば、大体の分析は即座にできます。
例えば、特定ページにランディングしたユーザーのうちどのぐらいのユーザーがどんな行動を取ったのか、CVR、離脱率、閲覧数、閲覧しているコンテンツの傾向、などもすぐに出すことができます。
この分析基盤が整う前は、集計用のデータのみを集めてきて、tableauに入れて、をかなりアナログな手順で行っていましたが、今は SQL一つで瞬時に結果が返ってきます。
リリースの翌日や数日後に結果を見て、
ここがうまくいっていなそうだよ、
さてどうしようか？
という会話ができるようになり、さらなる一手を打つまでのスピードも上がりました。
まとめ
実施後すぐに結果を見られる、うまくいっているものもいっていないものもフラットに把握できるのは、とても面白いものです。
一喜一憂することもありますが、ユーザーが喜んでいるかどうか、を感情ではなくデータという極めて平等なものをベースに考えられ、フラットに話し合えるのは、士気の高い健全なチームづくりにおいても有効だと感じました。