応答受信やスクリプト完了だけでは全行の取得を証明できません。制限や遅延はAPIごとに異なります。
抽出結果を確認する
期間、タイムゾーン、フィルタ、項目、ページ分割、メタデータを確認します。GA4 Data APIのrowCountは一つのページだけでなくクエリ結果全体の行数です。実際の全行動の網羅を保証するものではありません。割り当てを守り部分取得を明示します。
四つの時刻を分ける
同日・同一タイムゾーンの架空の例です。観測08:00、利用可能08:10、抽出08:15、表示08:20。抽出から5分でも観測からは20分経過しています。Data Studioなどでも元データの遅延やキャッシュは残ります。
| 項目 | 時刻 |
|---|---|
| 観測 | 08:00 |
| 利用可能 | 08:10 |
| 抽出 | 08:15 |
| 表示 | 08:20 |
出典と確認
完全性を示す証拠に基づいて抽出を自動化してください。
技術的なエラーなしで生成されたレポートでも、結果ページが欠落したり、異なるフィルタが使用されたりする可能性があります。時間ウィンドウ、スキーマ、ページネーションルールを保持し、合計と重複を確認してください。変更履歴をサイレントに失うことなく、期間のリプレイを準備してください。
- フィルタ、ディメンション、単位、タイムゾーン、ページネーションをバージョン管理してください。
- 抽出したサンプルを同じ期間のソースと比較してください。
- 中断された抽出をリプレイし、損失と重複を確認してください。
一次資料：Google SRE — Data Processing Pipelines. 関連する方法：実践ガイドを読む.
タイムゾーンと遅延イベント
報告期間はイベント時刻と締め規則に依存します。
- イベント時刻、受信時刻、業務のタイムゾーンを別々に記録します。架空例では23:30 UTCは固定オフセットUTC+02:00で翌日の01:30です。PostgreSQLのタイムゾーン付きタイムスタンプは元のゾーン名を保持しません。
- 開始を含め、終了を含めない区間を使います。業務ゾーンで境界を決めてからUTCに変換します。夏時間の変更、月の切替、時刻のない日付を試します。現地の一日を常に24時間として扱うことはできません。
- 許容遅延と集計の締切を決めます。同じ識別子を再処理し、新規イベントと重複を区別します。公開版を残して訂正の影響を記録します。ウォーターマークは到着の見積もりであり、完全性の保証ではありません。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}期待される判断
指定の時間帯では10月9日のイベントです。UTCの時点も保持します。
検証手順
- 報告の時間帯と基準時点を定めます。
- 深夜付近のイベントを再現します。
- UTC、現地日付、締切規則を残します。 時刻変更時の曖昧な現地時刻も含め、時点を推測せずオフセットとタイムゾーンを保存します。
受信日をイベント日として使えますか？
レポートの定義がそう求める場合に限ります。両方の時刻を保存し、遅着イベントの扱いを説明します。
一次資料：PostgreSQL — Date/time types. 関連する方法：実践ガイドを読む.