内製ログ収集ツールの GA4 化で学んだこと

これは Livesense Advent Calendar 2024 DAY 9 の記事です。

技術部データプラットフォームグループの池谷です。最近はフルマラソンのタイムを縮めるべく走り込んでいます。

長期間に渡るプロジェクトは多くの学びを与えてくれるものですよね。2 年以上かけて進めてきた、内製されたログ収集ツールを GA4 に置き換えるプロジェクトも、自分にとっては大きな成長機会となりました。本記事では、この経験を通して学んだことや、大事だと考えるようになったことをまとめました。

GA4 化プロジェクト
- 背景
- アプリログの GA4 化
学んだこと
さいごに

GA4 化プロジェクト

背景

もともとリブセンスでは、ウェブやアプリの行動ログを収集するツールを内製していました。ただ、長期間にわたって運用してきたシステムということもあり、メンテも難しくなり、負債化している部分もありました。

そこで、Google Analytics 4 (GA4) に乗り換えることで、システム課題を解決しようということになりました。自動収集イベントの機能性や、ウェブコンソールによる分析、Google 広告等との連携など、データ利用者にとっても多分にメリットがあります。また、プライバシー保護のような昨今のトレンドにも追従しやすくなるだろうとの考えもありました。

アプリログの GA4 化

以前記事にしたウェブログの GA4 化に続いて、アプリログの GA4 化も完了させることができました。ログの受け口になっていた Lambda や、加工を担っていた Airflow など、各種システムも廃止が完了しています。

新システムのデータフローはウェブログと揃え、BigQuery と Argo Workflow を主軸としたものになっています。Argo Workflow は機械学習基盤などにも利用しているもので、データプラットフォームグループ全体で利用技術が統一されつつあります。グループ全体の負債解消や利用技術の統一については富士谷さんの技術的負債解消LT会で「データ基盤の負債解消のためのリプレイス」を発表しましたもご覧ください。

学んだこと

このプロジェクトを通して学んだことはたくさんありますが、中でもデータエンジニアとして大切だと思うようになったことを 3 つ紹介します。

一連のデータフローを理解しよう

ここでのデータフローというのは、データ基盤内部だけではなく、データが生まれてから利用されるまでのフローのことです。ウェブログであれば Google タグを、アプリログであれば Google Analytics SDK を使って各種イベントを記録します。GA4 から BigQuery にエクスポートされたデータはデータ基盤で加工されて社内に提供されます。それを、プロダクトマネージャーや企画の方々が、施策立案や施策評価、日々のモニタリングに利用しています。

本プロジェクトでは、タグや SDK の実装はプロダクト側のエンジニアの方々にやっていただきました。実装依頼をするにあたって、タグや SDK の仕様を踏まえた上で、既存の内製ツールと同様のイベントを記録するための実装要件を策定する必要があります。そのため、これまでアプリ開発をしたことはありませんでしたが、Xcode や Android Studio でサンプルアプリを作成し、想定通りにイベントが記録できるかを確認するところまでやりました。ここまでやっておけば、プロダクト側のエンジニアの負担が減り、プロジェクトをスムーズに進めやすくなります。それだけではなく、データエンジニアとしてデータソースの特性は知っておくべきだという気持ちもありました。データ差分調査で SQL ばかり書いてたので、ちょこっと Xcode 動かすくらいでも楽しかったですね。

一方でデータの利用者には、新データの確認依頼をしました。データソースやデータフローが変わると、提供データにも差分が発生するため、利用者目線でその影響度合いを確かめてもらう必要があります。利用者が日頃モニタリングしているクエリを教えてもらい、新旧データ間で不可解な差分が生じていないかを予めチェックするようにしました。これも、主にプロジェクトをスムーズに進めるためでした。それだけでなく、分析クエリに目を通すことで、クエリの書き方の改善に繋がったり、どんな指標を見ているのかを知る機会にもなりました。

今回はプロジェクトの特性上、タグや SDK の実装から分析クエリまでを把握する必要がありました。しかし振り返ってみると、個別のプロジェクトによらず一連のデータフローを把握しておくことは非常に重要だと感じています。例えばデータが何かおかしいとき、データエンジニアの担当領域であるデータ基盤だけでなく、上流のデータソースや、下流の分析クエリに問題がある可能性もあります。自ら調査する場合はもちろんのこと、関係者と連携する場合であっても、データフローの全体像を見下ろせる視点は持っていたいですね。