Google Analytics 4(GA4)のレコード数の話

本ブログでも度々扱っているGoogle Analytics 4(以下、GA4)ネタですが、今回はエクスポートしたデータのレコード数に関する記事になります！

GA4には、Google CloudのBigQueryにデータを簡単にエクスポートできる機能がありますが、とあるデータを眺めているときに既に確定していると思っていたレコード数が増加することがありました。

今回はこの現象について少し詳しく見ていきたいと思います！

GA4→BigQueryへのデータのエクスポート

既に設定されている方も多いかとは思いますが、こちらのドキュメントに従って設定を行うだけで簡単にGA4→BigQueryにデータエクスポートすることができます。

ここで設定できる項目に「エクスポートタイプ」というものがあります。

ここではデータをエクスポートする頻度を設定することができ、「毎日(1日1回)」または「ストリーミング(継続的)」、あるいは両方を選択することができます。

ここで、両方設定するくらいなら「ストリーミング」だけで良いのでは？という疑問が生じますが、先ほどご紹介したドキュメントにも記載されているように、「ストリーミングエクスポートはベストエフォート型の処理であり、イベントの遅れやアップロードの失敗などにより、データに漏れが生じる場合もあります」と記述があります。

そのため、両方設定しておくことで、速報値としてストリーミングデータ、確定値として日次エクスポートのデータを使うといった使い分けができます。(もちろんその分追加の料金は発生します)

なお、こちらに記載されているように標準のGA4プロパティでは、日次でエクスポートできるイベント数の上限が100万件となっており、それを超えると場合によってはデータのエクスポートが一時停止されるため注意が必要です。(ストリーミングエクスポートは無制限)

ちなみに、有料版であるアナリティクス360のGA4プロパティでは日次エクスポートが数十億件のイベントに対応しており、実質無制限となっております。

エクスポート先のテーブルについて

GA4とBigQueryをリンクさせると通常24時間以内にデータのエクスポートが開始されます。

エクスポートが開始されると以下のようなデータセットとテーブルがBigQuery内に作成されます。スクリーンショット_2024-03-04_10.09.53

データセット名はanalytics_<property_id>となっており、２つあるテーブルはevents_YYYYMMDDとevents_intraday_YYYYMMDDという名前で作成されており、以前こちらの記事でも触れられていたシャーディングされたテーブルになっております。

このevents_YYYYMMDDが先程紹介した日次でエクスポートされたデータによって作成されたテーブルで、events_intraday_YYYYMMDDがストリーミングデータとなっております。

また、テーブルの数を見てみるとevents_YYYYMMDDはかなりのテーブル数があるのに対して、events_intraday_YYYYMMDDは1日分のテーブルしか存在していません。

これは、events_intraday_YYYYMMDDはevents_YYYYMMDD の作成が完了すると1日の終わりに削除されるという仕様になっていることによるものです。

エクスポートしたデータの遅延

前置きが長くなってしまいましたが、ここから本題になります。

冒頭にも書かせていただいたように、とあるデータについて分析を進めていると、events_YYYYMMDD テーブルにおいて、テーブル作成後の2, 3日間でレコード数が増加することがありました。

また、テーブル情報を確認すると以下のように作成タイミング以降も更新されていることが分かります。スクリーンショット_2024-03-04_10.11.52

調べてみると、公式のドキュメントに記述がありました。

セッション数が低くなるもうひとつの要因として、「レイトヒット」（発生後すぐに送信されないヒット）があります。ユニバーサルアナリティクスでは、前日の終了から 4 時間以内に届いたヒットが処理されます。Google アナリティクス 4 では、最大 72 時間遅れて届いたイベントも処理されます。Google アナリティクス 4 のイベントの場合、より長い期間が処理の対象となります。そのため、Google アナリティクス 4 プロパティでのセッション数が多くなったり、処理対象期間である 72 時間で報告される数値が変動したりすることがあります。

GA4では本来のイベントから遅れて72時間後以内に届いたイベントも処理されることがあるとのことで、これを「 レイトヒット 」と呼びます。

例えば、ユーザーが、あるセッション中にサービスにアクセスできなくなり、その48時間後に再び利用できるようになった場合は、GA4ではレイトヒットとして処理され、データが遅れて連携されます。

ちなみに、Google Analytics 4の前のバージョンであるユニバーサルアナリティクス(UA)では、この仕様が「前日の終了から4時間以内に届いたヒット」となっていたため、GA4になって大幅に処理の対象期間が増えています。

レイトヒットに対する考え方

今回のようなデータの到着に遅延がある場合に気をつけないといけないのが、その後のデータ加工です。

例えば、日次処理で前日分のevents_YYYYMMDD テーブルを加工して、新たなテーブルにインサートしている場合、その後にレイトヒットとして届いたデータは処理されなくなってしまいます。

そのため、より高精度なデータを求めるのであれば、72時間以上経過して確定したデータを利用して、テーブルを作成する。

もしくは、いったんテーブルは作成しておいて、データが確定次第、対象の期間のデータを洗い替える必要があります。

もしくは、viewを利用して、常に最新のテーブルを参照するというのも一つの手段かと思われます。

このように、対応としては様々な方法が考えられるため、実際のデータ規模やどこまでの精度を求めているのか、採用しているアーキテクチャなどの要件によってやり方を変えるのが良いかと思います。

実際、このレイトヒット自体が致命的になるほどのデータ量ではないので、要件によっては無視してしまうというのも一つの選択肢かと思います。

ただ、仕様として知っておいて損はないかと思います。

まとめ

GA4→BigQueryへのエクスポートの仕様について簡単に触れた後に、GA4の仕様であるレイトヒットとその考え方についてまとめてみました。

GA4は非常に便利ですし、データのエクスポートも簡単に設定ができるため細かい仕様まで目を通さずに使ってしまいがちですが、意外な落とし穴や隠れた仕様があるので、細かいドキュメントの確認はやはり大事ですね！