JADEファウンダーの長山です。
いよいよ Universal Analytics (以下UA) の死が近づく中、Google Analytics 4 (以下GA4) が使いづらい、という声を聞くことが増えてきました。特に広告運用者にとってはまだまだ使いづらいことが多い、という点は、すでに弊社ブログでも小西が書いた通りです。しかし、どうしてこうなっているのか、について考察した記事は今まであまり無かったように思います。
少し歴史を振り返ってみましょう。現在のUAは Google が一から開発したものではありません。Urchin Software という会社が開発したアナリティクスサービスを Google が 2005 年に買収したものです。Urchin は買収時点ですでに10年近い歴史を持つソフトウェアで、Web におけるユーザー訪問の分析に特化する形でプロダクト開発が続けられていました。現在でも、utm_source などの接頭語として使われる utm が “urchin traffic monitor” の略語であることはよく言われる通りです。実は Urchin そのものも 2012 年までは独立したサポートが継続していましたし、ヘルプ記事もまだアクセスできます。
UA は、Google 買収以後もずっと改善を続けており、マーケティングプラットフォームの一部として、さまざまな Web 解析独自の要望を取り込みながら進化を続けてきたプロダクトです。非常に古いプロダクトなのでインフラの仕組みなどで開発を続けていくことが難しいことがあったのかもしれませんが、アナリティクス市場をほぼ独占する、熟成、完成したものに進化していました。自らログ分析パイプラインを作らなくても、さまざまな処理をプラットフォーム側でやってくれており、コードを書かないマーケターには非常に重宝されました。一方で、Urchin 独自の概念やログ処理パイプラインのブラックボックス感などがあり、エンジニアにはとっつきにくさもあったかもしれません。
一方で GA4 はもともと Firebase Analytics として誕生したものです。Firebase もまた Google が一から開発したものではなく、2011 年に創業された Firebase Realtime Database というデータストアプロダクトから始まった企業を買収したものです。Firebase は基本的にはアプリ開発者向けのプラットフォームです。 Firebase Analytics は Google 買収後の 2016 年に発表されたものですが、開発チームはあくまで Firebase であり、モバイルアプリ向けのアナリティクスプロダウトとして作られました。
ここは個人的には重要なポイントだと思っています。Firebase はそもそもが開発者向けのプラットフォームであり、マーケター目線のプロダクトとして出発したわけではありません。GA4 といえば BigQuery という感じもありますが、それも「生データをそのままダンプするから、自由に加工して分析してね！」というエンジニア向けのノリがベースにあると考えています。自分でログ分析を行い、パイプラインを作ることが前提にあるわけです。*1あくまでユーザーは技術に精通したエンジニアで、その独自の要求にできるだけプラットフォームとして応える、というスタンスのプロダクトだと思います。だからこそ GA4 は機械学習への対応もしやすいですし、ダンプされた生ログを加工する際のスキーマも比較的わかりやすく、全体としてブラックボックスは少ないように見えます。
しかしだからこそ、技術的バックグウランドのないマーケターにとっては、難しいプロダクトになっています。エンジニアなら BigQuery に出力されたテーブルを見て、「あ、まず UNNEST しないといけないんだな、そのやり方は…」と調査することができますが、マーケターはそれが専門ではないのでできません。セッションレベルの分析も events_* からの生データでは行えません。その場合は独自に unique_session_id のようなものを生成してそれをキーにした sessions テーブルを生成する必要があります。JADE では独自処理を施して sessions テーブルに基づいた分析を行えるようにしていますが、データアナリストやデータエンジニアの助けなしでは難しいと言えます。
GA4 のプロダクト側もこれを理解はしており、どうにかしてマーケターにとって使いやすいようにしようと追加的なデータ処理や強力なレポートUIを入れたりしているのですが、やはり元々の設計思想的に「わかっている人のためのプロダクト」になってしまっています。
UA はいい意味でも悪い意味でもいい加減でした。データ分析の作法や、元に合っているデータ構造がわかっていなくても使えるようになっていたのです。存在論の異なるディメンションと指標の組み合わせを指定したとき、UA はなんとかして数値を捻り出すような挙動をしていましたが、GA4 は素直に「そこに数値はない」と言ってきます。これはデータ分析としては「正しい」挙動ですが、マーケターは「なんで？」となってしまうわけです。
Google としても、もっとマーケターにわかりやすくなるようにプロダクト改善を続けていくでしょうが、出発点が異なるので、それに追いつくのにはしばらくかかるでしょう。根底にあるプラットフォームとしての設計思想が異なる、ということは、利用者としては意識しておいた方がいいかもしれません。
現状、ビジネスとして GA4 をしっかりと使うなら、内製でしっかりとしたデータ処理チームを作るか、最初だけでも専門家にデータ基盤の設計を依頼する必要があると思います。Web サイト上のユーザーデータをどのように計測し、どのようにログ分析を行うか、ということを見越して、イベント設計だけでなく、ダッシュボードのデリバリーまで考える必要があります。例えば Looker Studio を利用するとして、データソースを API にするのか、BigQuery にエクスポートされたテーブルにするのか。BigQuery ベースにするのであれば、どのような前処理や集計を行っておくのか。データパイプラインを設計した上で Looker Studio のダッシュボードを構築する必要が出てきます。こういったことは、元々はデータアナリストやデータエンジニアの領域であり、マーケターの領域ではありませんでした。
その意味では、UA の終焉は、独立したマーケティングの領域としてのいわゆる「Web解析」の終焉でもあるかもしれません。今までは UA のプロダクトとしての細かい仕様や挙動を把握することが専門性として成立しており、UA があるデータをどう処理しているか、どのような挙動を示しているか、を理解する必要がありました。しかし GA4 の側には、「把握しなければならない細かい仕様や挙動」があるというよりかは、「どのようなデータを収集し、計測し、どのように分析を行うのかを自ら決定し、設計し、実装する」という必要があります。今までよりもさらにマーケターの領域からエンジニアリングの領域に近づいてきた、ということができます。
「Web 解析」は終わり、「Web サイトユーザーログのデータ分析」が始まる、という気がします。
最後に宣伝。BigQuery を契約し、エクスポートを管理することが難しい企業さま向けに、BigQuery データの管理代行サービスを始めました。いまなら Looker Studio でのダッシュボード例も無料で配布しています。
*1:UA でも 360 を利用すれば BigQuery へのエクスポートが可能でしたが、なかなかに加工しづらいスキーマでした…
