GA4 レポートにデータが表示されるまでにどれくらい時間がかかりますか？

　GA4のイベントサマリーレポートにおいて、レポート期間を1日前に指定しレポートを参照すると、(other)というイベントが多く確認できます。この事象はアプリ（Webサイトの計測ではなく）で起きることが多いです。
　UA（Universal Analytics）においても、悩まされてきたレポート上の(not set) や (other) について部分的な情報となりますがまとめていきたいと思います。今回は (other)について。

②アプリデータを含むすべてのプロパティでは前日のレポートに(other) が多く出てくる

1. GA4のレポートに(other)が表示される理由
2. データ送信は1時間毎のバッチ処理になっている
3. GA4のデータの更新頻度
4.まとめ

1. GA4のレポートに(other)が表示される理由

仕様①：
　GA4 ではレポートの行数上限があり、そのレポート専用に設計された表毎に上限が5万行となっています。
また、データの比較（期間やオーディエンスなど）をしたり、セカンダリーディメンジョンを追加したような場合は、上限が200万行に切り替わることがあります。
　レポート表示するときに、この上限行を超えた場合、超過分のデータ行は(other)行にまとめられます。超過分の行が(other)にまとめられるため、ディメンジョン情報は表示されませんが、取得された全データの指標の合計は正しい値になります。

GA4 行数の上限

仕様②：
GA4 ではヒットデータを処理するまでに最大で 72 時間必要になる場合があり、処理・集計が完了していないデータ行が (other) として表示される

セッションのカウント

前者の「仕様①」はUAでも同じ仕様がありました。
後者の「仕様②」はUAとGA4の違いになります。GA4ではデータ送信のレイテンシを考慮した集計タームになっており、1日毎にセッションを切って集計するUAとGA4では此処が異なります。

2. データ送信は1時間毎のバッチ処理になっている

　前項の後者の「仕様②」はアプリを含むマルチデバイスの集計プラットフォームであるGA4には、必要な仕様だと思います。アプリは、以下の2つのことに注意しないといけません。

１．アプリは、オフラインで操作が出来るケースがあり、リアルタイムにデータ送信できないケースが存在する

２．絶え間ないリアルタイムに送信されるデータ処理はデバイスの熱問題や深刻なバッテリーの消耗に影響を及ぼしことが考えられる

　細かいデータ送信処理については、触れませんが、どのような処理をしているかというと、アプリのGA4データはクライアントライブラリが1時間毎にローカルデータの有無を確認して、まとめてデータ送信（バッチ処理）されています。
　※iOSデバイス（およびGoogle PlayサービスのないAndroidデバイス）では、この1時間タイマーはアプリ毎ですが、Google Playサービスを搭載したAndroidデバイスでは、この1時間毎のデータ送信タイマー処理をGA4を使用するすべてのアプリを対象にGoogle Playサービスが纏めて行っております。

　しかし、以下の特別な場合は、GA4は即座にデータ送信をします。

１．ユーザーがコンバージョンイベント（アプリ内購入など）をトリガーした場合に、クライアントからすべてのデータを送信します

２．iOSデバイスで、アプリがバックグラウンドに移行するたびにデータを送信します
※Androidアプリは、アプリ自身がアナリティクスデータを送信しているわけではなく、Google Play サービスがデータ送信を行っているので、アプリがバッググランドに移行しようが、気にせずデータ送信プロセスを管理出来ています。

３．また、デバッグモードになっている場合はデータ送信は即座に行われます

3. GA4のデータの更新頻度

　データの更新頻度とは、GA4がデバイスからのイベントの取集と処理に要する時間のことを指します。

データの更新間隔は以下のように定義されているようです。
※GA4は有料版のプロパティと標準版のプロパティでデータの更新間隔を、おおよそ以下の通りとしております。

レポート > Thresholds and limits > [GA4] データの更新頻度

　利用しているサービスレベルと見るレポートによって表示されるレポートの処理時間は変わってくるようです。多くの一般的なサイズ（すべてのプロパティサイズ）であれば、12時間位という事でしょうか。また、1分未満に処理されるリアルタイムレポートもUAとは変わってきています。

GA4のリアルタイムレポート：
以下の情報がカード形式で表示され、ユーザーがコンバージョンプロセスに入るルートや、プロセスに入った後の行動を把握できるようになっています。

・過去 30 分間のユーザー数（分単位）
・参照元、メディア、キャンペーンごとのユーザー数の内訳: ユーザーはどこから流入しているか
・オーディエンスごとのユーザー数または新規ユーザー数: ユーザーはどんな人たちなのか
・ページタイトルまたはスクリーン名ごとのユーザー数: どんなコンテンツを利用しているか
・イベント名ごとのイベント発生数: どんなイベントを発生させているか
・イベント名ごとのコンバージョン数: どんなコンバージョンを達成しているか

[GA4] リアルタイムレポート

※GA4の非標準のデータ処理を伴う機能
以下のGA4の機能は、一般的なデータ処理サービスレベルの対象外とのことです。

正直複雑です。
当日の速報をレポートしてほしいといわれた際に、どのように対応すべきか検討がついていません。。

4.まとめ

GA4レポートに(other)というレコードが表示される、理由は大きく以下の2つになります。

　・行数上限
　・レポート表示のレイテンシ

　そして、2つ目のレポート表示のレイテンシ（遅延）には、以下の要素が関係してきます。

・クライアントアプリから分析データがGA4サーバーに送信されるまでにかかる時間

・サーバーでデータを受信してからGA4がデータをレポートに表示されるまでにかかる時間

The Firebase Blog > how long dose it take fo my firebase analytics data to show up?

GA4から一部のレポートでは残っているがセッションという概念を排除したため、UAはアクティブなユーザ（セッションが維持されている）というリアルタイムレポートになっているが、GA4では、過去1分毎のユーザー数と30分間のユーザーの行動合計レポートがいくつか準備されている。GA4のリアルタイムレポートに慣れていないだけかもしれませんが、30分間の合計値ランキングのため、徐々にどのように何が増えていっているのか視覚的に情報を捉えることが出来ないため、なかなかリアルタイムレポートを活用できていません。

　もし、GA4のレポート表示のためにデータ処理にかかる数時間を待っていることが出来ない場合、BigQueryに蓄積されている、events_intradayテーブルを直接参照しに行く必要があるかもしれません。
Webサイトのデータは数10秒前のデータを確認することが出来ます。お気に入りのリアルタイムレポートや当日、前日用のレポートを独自に準備をしないといけないかもしれません。GA4のリアルタイムレポートに世の中が慣れるまでは。

events_intradayテーブルの参照クエリー例です。
user_pseudo_id（もしくは取得しているのであればuser_idで）ユーザーを一意に特定して、直近のトラフィックを確認することができます。

SELECT 
    event_timestamp,
    CAST(FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', TIMESTAMP_MILLIS(CAST(event_timestamp/1000 AS INT64)), 'Asia/Tokyo') as DATETIME) AS jst,
    event_name,
    platform,
    (SELECT value.string_value FROM UNNEST(event_params) AS params WHERE params.key = 'page_location') AS string_value_page_location
FROM
    `******.analytics_*****.events_intraday_2022****` 
    WHERE user_pseudo_id='XXXXXXXXXXXX'
--    WHERE user_id='YYYYYYYYYYY'
ORDER BY event_timestamp DESC
LIMIT 10

※event_server_timestamp_offsetは無視しています。Firebase BigQuery server offset timeを参照