目次
Google アナリティクス エキスパートが語る、Google アナリティクスのこれまでとこれから
2020年は「Google アナリティクス4（以下：GA4） プロパティ」が発表されたり、Google アナリティクスのヘルプ コミュニティが試験的に復活したりなど、Google アナリティクス周りで大きな変化のあった年でした。そこで、現Google アナリティクス コミュニティ シルバー プロダクト エキスパートである、株式会社プリンシプルの木田さん、山田さん、Rayさん、株式会社JADEの村山さんに、アタラの大友がこれまでのGoogle アナリティクスの変遷から、GA4 プロパティの実情、今後どのように変わっていくのかまでを伺いました。本記事は前編です。
今回の話し手：プリンシプルの木田和廣さん、山田良太さん、Rayさん、JADEの村山佑介さん
座談参加者
株式会社プリンシプル
取締役副社長 木田和廣さん（シルバー プロダクト エキスパート）
チーフテクノロジーマネージャー 山田良太さん（シルバー プロダクト エキスパート）
Google アナリティクススペシャリスト Rayさん（シルバー プロダクト エキスパート）
株式会社JADE
コンサルタント 村山佑介さん（シルバー プロダクト エキスパート）
アタラ合同会社
コンサルタント 大友直人
15歳を迎えたGoogle アナリティクス
大友：本日のテーマは、2020年のGoogle アナリティクスの総括と、今後どうなっていくのか、についてです。読者の皆さんはおなじみかもしれませんが、まずは皆さんの自己紹介と会社概要を伺えますか。
木田：株式会社プリンシプルの木田です。弊社は主にウェブマーケティング支援とデジタルマーケティング支援の領域で、SEOやウェブ広告、UI・UX改善に携わっています。また、今秋からはDX支援事業もはじめました。例えばCDP構築や、CDPに溜まったデータを各部署で使えるようTableauでダッシュボード化するコンサルティングを行います。
私自身はGoogle アナリティクスのトップランナーとして業界を駆け抜けてきましたが、今は専門領域をTableauにずらしてきています。今一番興味があるのはSQLですね。
山田：同じくプリンシプルの山田です。特に技術周りを得意としていて、Google アナリティクスやGoogle タグ マネージャーの実装、API領域をカバーしています。
Ray：プリンシプルのRayです。プリンシプルに入社してから特にGoogle アナリティクスの計測周りの案件を多く担当しており、最近だとFirebaseを実装する上でのKGI・KPI設計、それに伴う外部設計が業務の中心です。
村山：株式会社JADEの村山です。弊社は、ウェブのコンサルティング、具体的にはSEOや検索連動型広告など、検索関連を中心にコンサルティングを提供しています。他にもディスプレイ広告やソーシャルメディアでの広告、コンテンツマーケティング支援も行っていますし、私個人としてはアプリの分析も行います。まとめると、インターネットをよくするための戦略から施策までをご支援しています。
私自身は、2019年10月にアユダンテ株式会社からJADEに移籍しました。これまでは有料版のGoogle アナリティクスの導入支援やサポートを行っていたのですが、現在はお客様のデータを使って分析するのが業務の中心となっています。なので、木田さんもおっしゃっていたTableauもほぼ毎日使っています。
大友：ありがとうございます。私の所属するアタラ合同会社も、運用型広告の最適化やインハウス支援、BI導入支援、Google アナリティクスの導入支援を通してお客様のデジタルマーケティングのご支援を行っています。
まずは2020年のGoogle アナリティクス関連の動きを振り返りたいのですが、まず皆さんがアクセス解析に触れられたのはいつ頃でしょうか。
村山：私は前々職の時に入れていたトラッキングコード、Urchinがアクセス解析との初接点ですね。2006年頃だったでしょうか。
※参考リンク：
木田：私は2009年ですね。
山田：私は本格的に仕事として携わったのは2013～2014年頃です。それまでにもプライベートでブログを書いていたので、そういう意味では2007年頃から触っています。
Ray：私が本格的に触ったのは2018年の4月頃です。「グローバルサイトタグ」や「アプリ＋ウェブ プロパティ」が出る直前ですね。
大友：Google アナリティクスは2005年にリリースされましたが、出てきた頃はどんな印象でしたか。
木田：最初は画面が変わっているだけで、Urchin丸出しだなと思った記憶があります（笑）。「なんだかおもちゃのようなものが出てきたな」と思っていたのですが、あれよあれよという間に大人になっていった印象があります。
村山：Google アナリティクスももう15歳なのですね。
大友：当時のGoogle アナリティクスやUrchinは、業界の中ではどのような立ち位置だったのでしょうか。
木田：Google アナリティクス登場以前はVisionalistやSiteTrackerといった有償のものを入れる必要があったのですが、Google アナリティクスのおかげで民主化がおきた。当時は高機能ではありませんでしたが、「こんなにしっかりしたツールが無料で使えるんだ」と世に知らしめたのが、Google アナリティクスが業界にもたらしたビッグインパクトだったのではないでしょうか。
村山：そうですね。アナリティクスのツールが登場しはじめた時期はGoogle アナリティクス以外の無償版でもページビューしか分からないような簡易なものだったのが、徐々に現在のアナリティクスツールと同じぐらいのデータが見られるようになり、非常に高機能なものが出てきた印象がありました。その中でも他のアナリティクスツールと比べてGoogle アナリティクスは設定しやすく、ウェブサイトを作ってすぐに導入できるというメリットもあったと思います。
当時はまだ検索キーワードを見ることができたので、「こんな検索キーワードでコンバージョンしているのか」というのがわかり、非常に面白かった記憶があります。
Google アナリティクスでよく使っていたレポートは？
大友：まだまだ完全なものではないですが、今後、GA4 プロパティの導入が徐々に進んでいくと思います。それは後ほど伺うとして、まずは通常版のGoogle アナリティクスにおいて、皆さんにとって便利だった機能はありますか。
Ray：一番使っていたのは行動レポートや目標レポートだと思います。前職の某ECサイトでは設計や実装まわりを管轄していたので、サイト内コンテンツでどこが最もコンバージョンに貢献しているのか、であったり、実装に問題があるページがないかの調査によく利用しました。その他には、eコマースのレポートもとても便利だと思います。
GA4 プロパティになってからは試していないのですが、eコマース系サイトにおいてサイト内の行動を把握する分析を行う際に、企業が一番見たいデータは、購入までのどのファネルでカゴ落ちしているのかといったデータだと思うからです。そのためeコマースデータはトラッキングも含めてとても有用性が高いと思います。
※参考リンク：
逆に使い所が難しいという意味では、レポートではないのですが、メルマガの開封率を測る際などにMeasurement Protocolが良いのではないかという記事を見かけますが、メールを開くたびにビーコンが飛んでしまうことなどを考慮すると、制御が難しく扱いにくい機能だと思います。イベントレポート自体は便利であるものの、Measurement Protocol等、一部使いにくい機能はあったかなと思っています。
山田：レポート領域では、ユーザー系のレポートはあまり見ない気がします。ユーザーを飛ばして集客や行動ばかり見ることが多いですね。使い方次第で色々なことができると思うのは、アトリビューション系のレポートです。コンバージョンを設定しないとアトリビューションが見られないので、私のブログでは目標に「1ページ以上閲覧したらコンバージョンとする」を追加しています。これにより、資料請求や会員登録、購入などを行ったユーザーだけでなく、サイトに訪問したユーザー全体のアトリビューション・レポートを見ることができるようになります。
大友：実際にそれを実装し、データを取得していたということですか。
山田：はい、単純に目標を一つ追加して常にコンバージョンになるように設定しただけですが、それで見えるものが広がるのは面白いです。
村山：各レポートが使えるか否かは見る人によっても異なりますよね。私は主に大規模サイトを見てきたので、行動フローやナビゲーションサマリーなどサンプリングの閾値が低い機能は使っていなかったのですが、個人ブロガーさんなどはむしろそういった機能のほうが有用性が高いかもしれません。
一方で、私がよく使うのは、やはりセグメントでしょうか。現在の業務でカスタムレポートのフラットテーブルでよく使っています。セグメントを適用したカスタムレポートで非サンプリングレポートにてデータを抽出し、そのデータをTableauに読み込ませるといった用途でほぼ毎日使っています。
また、ユーザー系レポートでは、ディメンションの一つである(ユーザーの訪問回数を集計する)セッション数に関してもフラットテーブルで利用しています。ただ、色々な場面に応じて組み合わせて一番メリットが大きかったのはセグメントですね。
木田：村山さんにほぼ同意で、ユーザーカテゴリの中でセッション数はどうしても必要ですね。あとやはりセグメントは良いです。Google アナリティクスのデータをTableauで利用するときには、5つ以上のディメンションを適用したくなります。そのような場合、CSVファイルをダウンロードするのですが、Google アナリティクス側で作成したセグメントをGoogle データポータルに適用して、Google データポータルでフラットテーブルを作りCSVファイルを取得しています。すると、ディメンションも5つ以上使えますし、ダウンロードもカスタムレポートの「一度に5000行」という制限を逃れることができます。
よく使っている機能としては、カスタムディメンションは良かったですね。ただ、ざっくりと言うとGoogle アナリティクスで良いのはJavaScript側であって、レポートは段々どうでもよくなるというと大げさかもしれませんが、狙いたい指標はカスタムレポートなりGoogle データポータルなりで作れてしまうので、今後は脱UI、UI卒業に向かうのではないかと思います。その結果がGA4 プロパティなのではないかという気がします。
「アプリ＋ウェブ プロパティ」の登場、そして「Google アナリティクス 4 プロパティ」へ
大友：2018年頃までは機能のアップデートが頻繁にあったのですが、2019年に入り、ぱたっと機能アップデートが止まりました。そして2019年8月に「アプリ＋ウェブ プロパティ」が発表されました。この発表があった時、皆さんはどう思われましたか。
※参考リンク：
山田：今までならば、ある程度機能として使える状態でローンチしていたGoogleが、2019年8月時点で未完成とも言える状態で世に出したということに、当時少し驚きがありました。今は一気に機能が増えてきて、少し安心しています。
木田：私はFirebase、次いでアプリ＋ウェブ プロパティの登場あたりで「なんだこれは、日本の全Google アナリティクスユーザーに新しいUI、新しいディメンションをまた学び直させるのか…」と少し腰が引けてしまって、ちょうどその頃自身にTableauの波が来ていたこともあり、新たに学ぶことはしていませんでした。
2020年にベータが取れたGA4ですが、無料でGoogle BigQueryへのエクスポートができる仕様になっています。そうか、Google アナリティクスはデータ取得装置として割り切り、分析はGoogle BigQueryやTableauでやればよいのか。と妙な納得感がありましたね。
Google アナリティクスは、Urchinに始まり、ga.js、analytics.js、そしてgtag.jsといったようにタグベースで世代を管理しているのだと思います。「GA4 プロパティ」という名称からは、Googleが正式にこれを第4世代と認識したのだな、という印象を受けましたね。
村山：私が前職でサポートしていたGoogle アナリティクス 360を導入しているお客様ではユニバーサル アナリティクスにてウェブサイトとアプリを統合したデータを計測し、それをGoogle BigQueryに出力していました。ですので、同じことをわざわざ工数をかけてアプリ＋ウェブ プロパティに変える必要はない気がしていました。既にそのようなデータ集計を行っている企業で、Google BigQueryにてCRMデータなどとも連携させているデータ集計基盤をリプレイスするのはリソースを考えると難しいかなと思います。
Ray：アプリ＋ウェブ プロパティが出る少し前に、Google アナリティクス モバイルSDKのサービス終了のアナウンスもあったので、Google アナリティクス側での何らかのアップデートはあるだろうと予測はしていました。
ただ、Firebase AnalyticsのUIを利用したアプリ＋ウェブ プロパティが登場するのは予測していませんでした。というのも、Firebase AnalyticsはFirebaseプラットフォーム内にあるサービスの一つであって、基本の計測仕様も異なりますし、カスタムレポート機能もありません。カスタムレポートの替わりを作るとなったら、管理画面からGoogle BigQueryをリンクする必要があり、SQLを書く必要もあります。今まで、Google アナリティクスのウェブ計測に慣れていた人にとっては、あまりなじみのない状態でリリースしたことには非常に驚きました。
村山：世の中にアプリとウェブを運用している会社はそこまで多くないですし、そういうキャッチーなものがあると入りやすいのではないかとは思います。ユニバーサル アナリティクスを含め、以前までのGoogle アナリティクスでは、ページビューとイベントのようなヒットのタイプがさまざまあり、それに加えてカスタム ディメンションのようなデータが入ってきました。その辺りは山田さんが詳しいと思います。
このようなネスト化されたデータを集計しつづけるのも、それがビューごとに作成されるのも、Googleとしてはデータの集計コストがけっこう掛かると想像できます。そのような面を踏まえると大きく舵を切る選択肢は考えられると思います。GA4 プロパティではビューを複数つくることができないですし、ヒットのタイプもイベントだけとなり非常にシンプルなデータ構造なので、Googleとしてもコストや管理、保守という面でもやりやすいのではないでしょうか。
山田：その一方で、GA4 プロパティの仕様をきちんと理解するなど、Google側の考えていることをしっかり理解して実装する必要があります。Googleの考えを理解せずに「ビューがたくさん作れないものでプロパティを複数作ってタグを複数入れる」という実装が出てくる可能性が高く、怖いですね(笑)。おそらくGoogle側はビューをたくさん作って管理するような考えではなく、別の解決策を考えていると思われます。
進む機械学習、得られた示唆を運用者はどう活用していくのか
大友：Google BigQueryを前提とした思考でないと、山田さんが懸念されているようなことに陥ってしまいますね。
木田：今まではGoogle アナリティクス上でビューというデータベースを作っていましたが、今後はGoogle BigQueryの中の一つのテーブルとしてビューを作るイメージですよね。同じビューでも作る場所が違ってくる。
山田：一般ユーザーのほとんどが使えないGoogle BigQueryに持っていってしまうというのは危険な気がしますね。
木田：確かにそこは恐ろしい舵取りだと思います。あと、これまでのGoogle アナリティクスと違って、精緻な設計が必要だと思うのですよ。これまでのGoogle アナリティクスは目標設定も簡単なので、”ただ単に入れておく”という使い方ができましたが、GA4 プロパティはイベントから派生させる必要があるため、単に入れておくと利用価値が減る気がします。そのため、設計やデータ構造の理解が必要になってきます。
また、様々な指標もイベント単位に変わったので、ユーザー軸でもヒット単位でも、セッション単位でも取り出せるようになったため、データのユニバーサル化が起きたという気がします。
山田：機械学習に関しては今までよりもやりやすくなった感じがします。今までだと、コンバージョンといっても目標が20個あり、何がどのスロットに設定されているか分からないという状況だったのが、リード獲得ならリード獲得、サインアップならサインアップのイベントが決まっているという仕様に変わりました。今まで各利用者側に委ねられていた目標設計部分をある程度Google側が統一して提供することで、Google側が決めたデータを機械学習で処理してフィードバックするところがよりやりやすくなってくるのではないかと思いました。
木田：これまでスマートゴールでやろうとしていたことですよね。ユーザーごとにゴール設定が異なると機械学習が働きづらいのでしょう。
村山：ユニバーサル アナリティクスのときに使えていたスマートリストなども、コンバージョンは見ていないですね。
大友：トランザクションですよね。
村山：はい。トランザクション、イベントといった具体的なヒットが対象です。対象にコンバージョンを含めてしまうとデータ内の雑味が多過ぎて何も使えなくなってしまいます。GA4 プロパティのようなイベント計測で標準化したデータや似ているウェブサイトでデータの傾向を機械学習に食わせるというのは、非常に効率的だとは思います。
大友：村山さんや木田さんが仰るとおり、GA4 プロパティではイベント計測で機械学習がどんどん進んでいくと思います。
村山：セッションの品質やコンバージョン見込みはGoogle アナリティクス 360のプロパティでは結構使えたのですが、トランザクションが月に千件以上などの制限があったので、少し利用要件が厳しかったのです。プロパティ内でデータを使った機械学習を行おうとすると、やはりそれぐらいのデータが必要になってしまうのですよね。GA4 プロパティはイベント計測である程度似たようなデータを取得できるので、機械学習としては使いやすいと思います。
あとは、将来的にはGoogle 広告などにインポートする際にGA4 プロパティをつなげさえすれば、広告で最適化されるくらいのレベルを目指しているのではないかと思います。例えば、今まではユニバーサル アナリティクスで、例えばカゴ落ちした人のためのセグメントをわざわざユーザー側で作って、そのためにイベントを飛ばしてという形で、カスタマイズをするのにも知識や実装が必要だったのが、GA4 プロパティではそれらをすでに計測しているので、あとはよしなにやっておきますよというような未来をGoogleは描いているのではないかと考えています。
木田：そうですね。おそらくそのためにデータを正規化して取得しているのでしょう。ユーザーにセグメントを切らせると、そこまで意味のないセグメントをどんどん切って、そのオーディエンスリストがどんどんGoogle 広告にやってきて、結局コンバージョンしないといったことがよくあったと思います。
ワンタッチで連携できれば、セッション品質の高いユーザーや、その閾値だけを人間が設定できるといった運用ができます。
村山：セグメント作成は結構間違いが多いですし、検証するのも大変です。Google 広告にインポートしたセグメントの内容によって作成されたオーディエンスリストにも差が出てしまいますし、そういったミスを中心とした、運用者である人間によるデータの雑味を減らしたいのかもしれません。
※後編はこちら：
facebook
X (twitter)
LINE
