Google Analytics 4移行とBigQueryエクスポートでつまずかないための6つのポイント

Dentsu Digital Tech Blog

こんにちは、電通デジタル開発部エンジニアのリチャードです。

前回の記事ではGoogle Analytics 4プロパティの基礎知識について、GA4移行を技術的に正しく理解しながら進めるために、事前に抑えておくべきポイントを紹介しました。

前回の記事からの続きで後半にあたる本記事では、GA4移行ステップとそれに伴って私たちが行ったBigQueryエクスポートの設定をもとに、これらの作業でつまずかないための6つのポイントを紹介します。ビデオや公式ヘルプを見るだけでは設定を間違ってしまいそうな部分を中心に説明し、公式資料を見た方が早い部分についてはリンクを貼って、公式資料と重複する説明は避けています。

本記事の想定読者層

本記事は主にエンジニアに読まれることを想定して書いています。自分が担当するアプリケーションにすでにGoogle Analyticsが導入されていて、ビジネスサイドからの要求などによって、GA4への移行を担当することになったエンジニアの皆様に役立つかと思います。

想定する知識レベルとしては、HTMLやJavaScriptアプリケーションについては業務で使ったことがあるものの、Google Analyticsを頻繁には触ったことがなく、多少管理画面を触ったことはある、公式のスニペット通りにタグを埋め込んだことはある、といったレベルです。

ユニバーサル アナリティクスからGA4への移行ステップ

本記事で想定する移行シナリオは、すでにユニバーサル アナリティクス・プロパティを使ったGoogle Analyticsを導入済みのWebサイトにおけるGA4移行です。新規にGoogle Analyticsを導入するケースについては、この記事では対象としません。また弊社の移行例では使わなかったことから、この記事ではGoogle Tag Managerは使いません。Webサイトに埋め込むタグとしてgtag.jsの利用を前提とします。

まずは最低限必要な移行ステップの把握に、YouTubeのビデオをご覧いただくことをおすすめします。

移行ステップのうち最初に行うのはGoogle Analytics管理画面でのGA4プロパティの作成で、これは上記のビデオ、及びこちらの公式ドキュメントに従うだけです。

移行の際に「接続済みのプロパティ」と「接続済みのサイトタグ」という、名前はよく似ているものの中身は全く異なる2つの概念が関わってくるので、まずは移行のポイント1と2でそれらの違いを解説することから始めましょう。

ポイント1: 接続済みのプロパティ

既存のユニバーサル アナリティクス・プロパティからGA4プロパティへの移行手順を終えたら、両者は必ず接続済みのプロパティの関係になります。最後の画面の「既存のタグを使用してデータ取集を有効にします」はチェックをしてもしなくても、ユニバーサル アナリティクスとGA4は、接続済みになります。接続済みのプロパティは管理画面上「リンク済みプロパティ」とも表記されています。

ユニバーサル アナリティクス管理画面での表示画像1

GA4管理画面での表示画像3

ポイント2: 接続済みのサイトタグは、イベント・パラメータの計測漏れに注意して導入の是非を判断

GA4プロパティを作成する最後の画面で、以下のポップアップが現れ、その下部にチェックボックスがついています。ここをチェックすると接続済みのサイトタグが使えます。

画像2

ユニバーサル アナリティクスからGA4への移行では、両方のプロパティへデータを送る並行稼働期間を設ける場合が多いでしょう。まさにその用途のために接続済みのサイトタグは用意されました。

接続済みのサイトタグの利点は、Webサイトの埋め込みタグを書き換えることなく、ユニバーサル アナリティクスとGA4両方へデータを送れることです。下記の画像のように、ユニバーサル アナリティクスを計測していた時の埋め込みタグに一切手を加えることなく、GA4管理画面の変更だけを行えばよくなります。

画像4

もし接続済みのサイトタグを使わなかったとしたら、Webサイトへの埋め込みタグのなかで、以下のようにgtag('config')呼び出しをGA4のために1行追加する必要があります。

<script async src="https://www.googletagmanager.com/gtag/js?id=UA-XXXXXX"></script>
<script>
 window.dataLayer = window.dataLayer || [];
 function gtag(){dataLayer.push(arguments);}
 gtag('js', new Date());
 gtag('config', 'UA-XXXXXX');
 //接続済みのサイトタグを使わない場合、この1行を加える
 gtag('config', 'G-XXXXXXXX');
</script>
オプション 1: 新しい「config」ディレクティブに追加する 
ページに既存の gtag.js コードがある場合は、関連する Google アナリティクス 4 プロパティの測定 ID を新しい「config」ディレクティブに追加します - Google Analytics 公式ヘルプ:[GA4] gtag.js 実装ガイド

コードスニペット上は1行の違いですが、以下のような場合には接続済みのサイトタグの利用は魅力的に見えます。

- Google Analytics管理者(例: 広告代理店)とWebサイト管理者(例: 広告主)が異なり、Google Analytics管理者は直接Webサイトのgtag.js埋め込みタグを書き換えられない
- 膨大な数のgtag.js埋め込みタグがあって、全て書き換えるのが一苦労

ところが接続済みのサイトタグをよくわからないまま利用するとイベント パラメータの計測漏れを引き起こす可能性があり注意が必要です。その原因は、接続済みのサイトタグでは、埋め込みタグで明示したイベントのパラメータはユニバーサル アナリティクス側にしか送られないからです。

画像5

接続済みサイトタグでGA4に送信されないのは、埋め込みタグで明示的に指定したパラメータのみで、暗黙的に自動で送信されるパラメータ、例えば[GA4] 拡張計測機能で計測されるpage_viewイベントのpage_location、page_referrerパラメータなどはGA4でも計測されます。

GA4は豊富なイベントタイプに自由に定義したパラメータを組み合わせて、イベント単位で柔軟に集計できることが強みです。それは後述のBigQueryエクスポートと組み合わせると顕著になります。一方接続済みのサイトタグを使えるのは、自分でパラメータを定義することがなく、GA4が暗黙に自動で送るパラメータのみを使う場合でのみです。私の考え得る限りではこの過程が当てはまるケースは少ないと思っています。

接続済みサイトタグを利用していて、独自イベント パラメータやカスタム ディメンションを後から利用したくなった場合は接続済みサイトタグを解除してください。ユニバーサル アナリティクス管理画面の管理 > プロパティ > トラッキング情報 > トラッキングコードから、以下のように「接続済みのサイトタグ」が「1個が接続済み」となっているのを見つけたら、それを削除するだけです。

画像6

注意点として接続済みのプロパティは削除しないでください。先ほど紹介したように接続済みのプロパティと接続済みのサイトタグは別物です。混同しないでください。

ポイント3: GA4でのイベント パラメータとカスタム ディメンションの送信

gtag.jsでイベント パラメータを明示的に送信する時は以下のような書き方をします。

//login_methodという名前のイベント パラメータを送信
gtag('event', 'login_event', {
 'login_method': 'Google'
});

GA4ではカスタム ディメンションも同じ方法でイベント パラメータとして送信します。ただのイベント パラメータとして扱われるか、カスタム ディメンションとして扱われるかは管理画面で当該パラメータをカスタム ディメンションとして登録するかどうかで決まります。

画像7

カスタム ディメンションの編集画面はこちら

画像8

カスタム ディメンションとカスタム指標の値は、ログに記録されたイベント パラメータとユーザー プロパティから提供されます。- Google Analytics 公式ヘルプ: [GA4] カスタム ディメンションとカスタム指標

上記のようにGA4ではイベント パラメータもカスタム ディメンションも単純な仕組みで送信できますが、ユニバーサル アナリティクスからの移行を考えるときは、両方のプロパティでカスタム ディメンションのディメンション名を揃えなくてはならないため、注意が必要です。

比較のためにユニバーサル アナリティクスでのカスタム ディメンション送信をおさらいすると、以下のような書き方をするのでした。一度 'custom_map' というものを先に定義する形になります。

// 'custom_map'を使う、dimension2は管理画面で設定したカスタム・ディメンションの連番インデックスに対応
gtag('config', 'UA-XXXXXX'', {
 'custom_map': {'dimension2': 'age'}
});

// age計測イベントを送信する際、dimension2に対応するageという名前のパラメータで送信
gtag('event', 'age_measurement_event', {'age': 55});

ユニバーサル アナリティクスでは、管理画面でのカスタム ディメンション登録時に連番のインデックスが付けられるので、それを上記のdimension2のようにgtag.js側でも指定する必要がありました。

画像9

GA4移行ではこうなります。

// 'custom_map'を使う、dimension2は管理画面で設定したカスタム・ディメンションの連番インデックスに対応
gtag('config', 'UA-XXXXXX'', {
 'custom_map': {'dimension2': 'age'}
});

//GA4用'G-XXXXXX'に対し、もう一度gtag(‘config’)呼び出しが必要。接続済みサイトタグを利用していないため。
gtag('config', 'G-XXXXXX');

// 上記2種類のgtag('config')呼び出しがすめば、あとは一回のgtag(‘event’)呼び出しで
// ユニバーサル アナリティクスとGA4両方にカスタム ディメンションが送信できます。
// age計測イベントを送信する際、dimension2に対応するageという名前のパラメータで送信。
gtag('event', 'age_measurement_event', {'age': 55});

GA4ではカスタム ディメンションに連番のインデックスはつきません。管理画面でもパラメータ名favorite_game, ageなどを直接登録します。

画像10

page_viewの場合は明示的に毎回gtag('event')を呼び出すのではなく、1度gtag('config')呼び出しを行えばあとは画面遷移と同時に自動的にpage_viewイベントが送信されます。よってpage_viewに対するカスタム ディメンションはこのように指定します。

gtag('config', 'G-XXXXXX', {
 'favorite_game': 'オセロ' 
});

ポイント3で紹介した内容は、以下の公式ヘルプにより詳しく載っています。かなり読み解くのが難しいヘルプページだと思いますが、ここまでの記事の内容が理解の助けになるように書いたつもりです。

ポイント4: 移行作業中のデバッグにはGA4管理画面のDebugViewを使う

初めて行うGA4移行作業は、当然知らないことが多いため、細かな設定ミスや、ドキュメントを誤解してgtag.jsの呼び出し方を間違うことが起きがちです。正しくイベントを送信できているかを確認するのに、GA4管理画面のDebugViewは強い味方になってくれます。

DebugViewを使うためにはgtag.jsの呼び出しで以下のように、debug_modeパラメータにtrueを設定します。

gtag('config', 'G-XXXXXX', {
 'debug_mode': true 
});

後はGA4管理画面から、DebugViewを開いて送信されたイベントを確認するだけです。ほとんどリアルタイムで、送信されたイベントのパラメータも含めて確認できるDebugViewは、GA4移行を素早く終わらせるために必須の存在と言っていいでしょう。これがあれば、イベント送信とパラメータ設定がうまくいっていたかを確認するのに、日時レポートの作成まで待つ必要がありません。

画像11

もしDebugView側でイベントが表示されなかったら、Webサイト側から正しく送られているかどうか、ブラウザの開発者ツールで確認しましょう。https://www.google-analytics.com かそれに類似するドメインのcollectで始まるパスに対してPOSTメソッドの呼び出しを行なっているはずです。URLのクエリストリングの一部はgtag関数呼び出しで指定したイベント・パラメータになっています。

画像12

ちなみに、GA4以前はGoogle Analytics DebuggerというGoogle Analytics公式ツールでリアルタイムなイベント送信のデバッグが可能でしたが、動作の安定性があまりよくなく、私も使ってみたところ何も変えていないのに突然イベント補足ができなくなることがありました。GA4のDebugView登場で、Google Analyticsのデバッグは格段に楽になりました。

BigQuery自動エクスポート設定

最後にGA4からBigQueryへの自動エクスポートについて紹介しましょう。BigQuery自動エクスポートはGA4における目玉機能の1つといえます。それまでは有償版であるGoogle Analytics 360の機能でしたが、GA4からは無償版Google Analyticsでも利用できます。特にBigQueryにデータ基盤を構築済みの会社にとっては、既存のデータセットと統合して自由自在に分析できることは大きな魅力でしょう。

GAからBigQueryへ自動エクスポートする設定方法はこちらの公式ヘルプを見てください。

GA4移行ステップの項と同じように、本記事では公式ヘルプを見ただけではわかりづらい部分に絞って説明していきます。

難しいのはユーザー権限の設定です。BigQueryが属するGCP側と、GA4側で適切なユーザーと権限が設定されなくては移行ステップの途中でつまずくか、もしくは完了したと思ったBigQuery自動エクスポートが正しく動きません。Google Analyticsのユーザー権限と、GCPのユーザー権限両方に詳しい人は少ないと思いますが、特に難しいのはGCP側の権限です。

正しい設定を行うために、GCPにおける以下の基礎的な部分は理解している必要があります。

基礎的な部分を把握した上で、もしGCPプロジェクト設定及びGA4設定の手順に自信が持てなかったら、さらにドキュメントを読み込むよりも実際に試してみるのが早いでしょう。本番環境とは別の練習用のGCPアカウントで試してみるのが良いかと思います。GA4のセットアップからBigQuery自動エクスポートまで行っても、早ければ2日で終わってしまいます。1日で終わらないのは、BigQuery自動エクスポートは翌日にデータが反映されるからです。

ところで、公式ヘルプページには24時間以内にデータが反映されると書いてあり、私が試した限りでは本当に24時間近くかかります。

データのエクスポートが開始されるタイミング
リンク完了後 24 時間以内に、データが BigQuery プロジェクトにエクスポートされるようになります。- [GA4] BigQuery Export のセットアップ

「日中データが数分遅れで反映される、ストリーミング エクスポートを選べば、24時間待たずに反映されるんでしょ？」と思うかもしれませんが、それでも初回データは最大24時間待ちます。当日には反映されるはずもないデータを待ち続けてムダに調査しないために、ここは覚えておいてください。

BigQueryにデータがエクスポートされたのを確認できたら、設定作業としては全て終わりです。しかしエクスポート機能によって自動作成されるテーブルには特徴があって、その扱いを把握していないと使いづらいテーブルになっていますので、ポイント5で説明します。

ポイント5: BigQueryからエクスポートされるテーブルのREPEATEDになっている列の集計

BigQueryエクスポートで自動作成されるテーブルの特徴の1つは、REPEATEDモードになっている列です。BigQueryコンソールでスキーマを確認すると、下記のようなevent_params列はこのようになっています。

画像13

event_paramsの中身がどうなっているかは、実際のテーブルを見る方が早いと思うので、こちらのスクリーンショットをご覧ください。

画像14

1つの行の中に、さらに複数の行に分かれたevent_params.keyやevent_params.value.string_valueなどの列が確認できます。SQLを知っている方でも、これには面食らった方も多いのではないでしょうか？この奇妙な入れ子構造はBigQuery独自機能ではなく、標準SQLであるSQL 2011に含まれています。入れ子になったままだとテーブルとして扱いづらいため、下のスクリーンショットにあるテーブルのように「列への展開」をすると集計がやりやすくなります。

画像15

SELECT
 event_date,
 event_timestamp,
 event_name,
 (SELECT value.string_value FROM UNNEST(event_params) AS params WHERE params.key = 'page_location') AS page_location,
 (SELECT value.string_value FROM UNNEST(event_params) AS params WHERE params.key = 'page_title') AS page_title,
 (SELECT value.string_value FROM UNNEST(event_params) AS params WHERE params.key = 'ga_session_number') AS ga_session_number,
 (SELECT value.string_value FROM UNNEST(event_params) AS params WHERE params.key = 'ga_session_id') AS ga_session_id
FROM
 `richard-ga4-bq.analytics_262777750.events_20210329`

SELECT文の列名を書く部分に、(SELECT ... FROM UNNEST…) が入る特徴的な書き方になっていますが、この書き方についてはこちらのブログを参考にしました。

とにかく早く「動くクエリだけ欲しい」という人は上記のブログをもとにクエリを調整すれば良いのですが、もっと詳しく背景から理解したい方は、以下のGoogle公式の動画が参考になります。「列への展開」までは話が進まないのですが、その一歩手前の段階であるUNNESTの使い方までは説明してくれます。

またUNNESTについてはこちらの記事も参考にしました。

ポイント6: BigQueryからエクスポートされるテーブルは日付ごとに別テーブルになっている

BigQueryへのエクスポートによって自動作成されるテーブルのもう一つの特徴は、日付ごとに別テーブルになっていることです。下のBigQueryコンソールのスクリーンショットで、events_テーブルが2021-03-30から2021-03-26と複数のテーブルに分かれていることがわかるでしょうか。

画像16

これらのテーブルに対しクエリを走らせる場合には、全てのテーブルを一度に走査する場合と、日付を指定して単一のテーブルのみ走査する場合があります。前者は以下のようなワイルドカード * をFROM句の中で書くだけなので単純です。

FROM
 `richard-ga4-bq.analytics_262777750.events_*`

後者は日付部分をパラメータ化したクエリを使うことが多いでしょう。

残念なことにGCPのWebコンソールからはパラメータ化されたクエリを作成できないので、bqコマンドラインツールや各種プログラミング言語で提供されるBigQueryクライアントライブラリを使ってクエリを走らせなくてはなりません。

クエリのスケジューリング機能を使って日付部分をパラメータ化するにはこちらのドキュメントを見てください。

クエリをスケジュールする前に @run_time パラメータと @run_date パラメータを使用してクエリ文字列を手動でテストするには、bq コマンドライン ツールを使用します。- BigQuery公式ドキュメント: クエリのスケジューリング

どうしてもパラメータ化されたクエリを使わずに日付によってクエリを変更したい場合は、ユーザー定義関数を使う方法もあります。

まとめ

前半の基礎知識部分と合わせて、私たちがGA4移行でつまずいた部分や、技術的に理解するのが難しかった部分を説明してきました。エンジニアとして移行作業を行う以上、ただ移行作業を終わらせるのでなく、技術的にしっかりと理解して、移行後の運用までスムーズに行いたいものです。本記事が読者の皆さんの理解とスムーズなGA4移行の助けになれば幸いです。

みんなにも読んでほしいですか？

オススメした記事はフォロワーのタイムラインに表示されます！