Repro Booster事業部におけるLookerを使ったデータ活用の取り組み

Reproで開発を担当しているRyoma Shindo です。前回の記事「ServiceWorkerの落とし穴」で紹介のあったRepro Boosterの開発と運用に携わっています。私達のチームでは少し前からLookerを使ったデータ活用を強化しています。その取り組みを通して定型業務の効率化など基本的なところはもちろん、もともと期待していた以上の効果も得られたため、取り組んだ内容についてLooker自体の話やそこから得られた示唆も踏まえつつご紹介します。

Lookerとは

LookerはいわゆるBIツールで、データソースをインプットとしてデータの可視化を行い、意思決定の手助けをしてくれます。類似のサービスとしてはTableauなどがあたります。Looker StudioというBIツールもあって非常に紛らわしいですがこれは別モノです。特徴としてはLookMLという独自言語を使ったデータモデリングが出来て、かつGitと連携してバージョン管理ができるためデータガバナンスを維持しやすいとされています。

なぜデータ活用の強化に取り組んだのか

実はLooker自体は去年から利用はしていたのですが、色々な事情があって活用があまり進まず一部のデータを見るときだけ利用している状況でした。しばらくはそれで運用が回ってはいたのですが段々と困ることが出てきました。

1つは、開発側とビジネス側とで異なるデータを見ていることがあった点です。それまでは各々が必要に応じて各々の方法でデータを取得していました。しかし、同じデータを見たかったとしても認識のズレや状況の違いによって微妙に条件が異なった状態で見ていることがあり、その結果人によってデータに対する認識のズレが発生することがありました。

もう1つは、複数のデータソース(弊社の場合は複数のGA property)を横断して分析するのが難しかった点です。BigQueryに直接クエリすれば何とかなることもありますが、ビジネス側のメンバーと密にコミュニケーションを取る上では非常に困ります。欲しいデータが気軽に見られず、必要に応じてクエリを作って共有するなどしかありませんが、これには限界があります。古いクエリを使い続けてある日突然動かなくなったり、人によって異なる条件でデータを見ていたりということが容易に起こり得ます。また必要なデータを取得するために定期的に手動でデータを更新する定型業務が発生しており、効率化の余地がある状態でした。

これらの課題を解消すべく、定型業務の効率化と事業部内へのデータの提供がやりやすくなることを期待してLookerをもっと横断的に活用してみることにしました。またこの判断は旧GA（Universal Analytics）がサポート終了に伴い使えなくなり、GA4に移行しないといけないタイミングだったことも1つの要因でした。今までは旧GA上で指標を見る機会が多かったのですが、GA4になると見れなくなる指標があったり操作性の面で扱いづらいと感じることがあり、別の使い勝手が良いツールでデータを見られるようにしたかったわけです。

やったこと

まず、現状のデータパイプラインがどうなっているかを簡単にご紹介します。以下はコアの部分だけ切り抜いてまとめた図です。

必要なデータをBigQueryに集約してLookerはそれを参照しています。私達固有の事情として、製品を導入頂いているお客様のサイト毎にGoogle Analyticsプロパティがあり、それが主な分析対象であるという点があります。その複数のプロパティを横断して分析したいため、それぞれのプロパティからBigQueryにExportした後にCloud Workflowsを使って分析しやすい形に加工しています。また一部の情報はスプレッドシートからExternal Data sourceを使ってBigQueryに入れています。

活用が進んでいなかった理由の1つに、Exportの方法としてDaily Batch Exportを使っていたのですが、無償版のGAだと1日100万イベントしか連携出来ない制約がありました。この制約に引っかからないようにする選択肢としては以下があります。

イベントを100万件以下に抑える
- イベントの送信時にサンプリングする
- BigQueryに連携しないイベントを個別で選択する
- etc
Streming Exportを使う
有償版GAを利用する

元々は有償版GAを利用する想定だったのですが元々の想定以上に従量課金が大きくなってしまってコストがかかりそうだったため、色々検証した上でStreaming Exportを利用するよう変更しました。当初はそういった制約を取っ払うための有償版なのではと考えていたので本当に1日100万件を超えても大丈夫なのか、大きく欠損したりしないかという疑念はありましたが現状まで問題なく稼働しています。ちなみにStreming Exportは固有の従量課金がありますが有償版GAと比べたら全然安いです。

その後は事業部として見れたら嬉しいであろうデータを想定しつつ最終的にどういうダッシュボードがあると良いかを設計しました。まず、Repro Boosterで扱うデータは大きく分類すると3つに分けられます。

ユニークユーザー数、セッション数、コンバージョンイベント数などGAで扱う基礎的な情報
TTFBやLCPなど、Core Web Vitalsという形で定義されているウェブサイトの速度指標
製品の内部的な動作を観察するための情報

これらの情報をどのように提供するかを考えます。最初に作ったダッシュボードは2つで、1つは特定のサイトについて詳細な情報を表示するものです。これは主に当該サイトの担当者がどの程度改善効果が出ているか見たり、より改善するためのアクションを探すために利用します。もう1つは全サイト横断して情報を表示するもので、これは主に開発者が製品バージョン毎の傾向を見たり、新しいバージョンに問題がないか、また全体としてどの程度改善効果があるかを把握するためのものになっています。

設計が出来たら後はデータモデリングと可視化を地道に行っていきました。公開した後は使ってもらってはFBを受けてまた改善して、というサイクルを回しています。

得られた効果

まず基本的なところとして定型業務の効率化が図られました。以前は複数のデータソースからデータをかき集めて更新しなければいけませんでしたが、ダッシュボード化することでいつでも見られるようになりました。利用者側は見たい数値を出すためにデータベースのややこしい構造を理解したり計算したりする必要はなく、予め開発側で定義した指標を利用できます。これは全員が同じ数値、方向を見れるということでもあり、認識のズレが生まれることがありません。ちなみにフィールド毎にDescriptionを記載しておくことでホバー時にそれを表示することが出来たりするのでそういった細かいところでも配慮が出来て便利です。

そして大きな点として事業部全体がLookerダッシュボードを中心に業務を回すようになっていきました。 サイトごとの状況であったり事業部としてのKPIもダッシュボードとして管理されており、これは事業部内での共通言語になりますし、データドリブンな意思決定がやりやすいです。特に開発側とビジネス側が垣根を超えてコラボレーションする場として「導入中サイトのパフォーマンスウォッチ会」があります。これは開発側とビジネス側が合わせて参加する定例で、ダッシュボードを見ながら全体の導入／運用状況や傾向を把握する場です。これによって開発が導入サイトにおけるBoosterの速度改善効果について俯瞰して把握することが出来ますし、ビジネス側から個々のサイトの傾向やシステム構成を念頭に「もっとこういった機能があると速度改善効果を最大化できるんじゃないか」といった提案をもらえる場にもなっています。こういったフィードバックを通して製品のチューニングや改善にクイックに実施でき、翌週の定例の場でその効果を振り返る、といったサイクルが回せています。同等のことはLookerのような基盤がなくても出来なくはないと思いますが、こういった活動が根付くにはいつでも誰でも同じデータが見られること、それによるダッシュボードを活用する文化の形成などの要因は大きいでしょう。

得られた効果について更に付け加えると、アドホックな分析が手軽に行えるようになったこと、またそれによってより深掘りした分析・探索分析をしたり、創造的な発見がしやすくなったことも挙げられます。ふと気になったことをその場で画面を開いてすぐ探す事ができますし、異なるデータを組み合わせて分析するなどSQLでやるには中々面倒な作業もLooker上でポチポチ操作するだけで手軽に試せるのでので非常に捗ります。実際、これまで相関の存在を気にかけてこなかったデータを組み合わせて分析したところ、相関がありそうな組み合わせが見つかったことがあります。まだハッキリと相関があると断言できないのですが、この相関はビジネスにとって重要な意味を持つので、この分析に資するデータをさらに収集してより精度を上げていこうというアクションにも繋がっています。

総括すると、定型業務が効率化し、事業部全体がダッシュボードを中心に業務を回すようになり、アドホックな分析も手軽に出来るようになり、想定以上に事業部としてデータ活用が大きく進んだので取り組んでとても良かったと感じています。とはいえやりたいことはまだまだ沢山あり、これからもっと活用の幅を広げていきたいです。