Google は2026年5月1日、Google Ads のデータ保持ポリシーを大幅に縮小する変更を発表した。時間別・日別・週別の granular データ保持期間が、これまでの11年から37ヶ月へ短縮(月別・四半期・年別の集計は11年維持)、施行は2026年6月1日。本記事公開時点で施行まで残り20日弱の緊急変更だ(出典:Google Ads Help Center / Developer Blog)。
本質は「11年→37ヶ月」という数字ではなく、11年保持宣言からわずか18ヶ月で方針が反転した事実だ。プラットフォーム約束の予測不能性が露呈し、広告データを「Google が長期保持している前提」で組まれた分析設計は、今その前提自体が崩れ得ることに直面している。
本記事は Google 電話専用広告終了・LINEヤフー広告統合・Meta Advantage+ Leads B2B に続く「媒体方針変更で揺らがない運用設計」シリーズ第4作。前3作の「機能依存」「媒体分断」「プラットフォーム委任」に対し、本記事は「データ保持の前提崩壊」を扱う。6月1日までの緊急アクションは本文末で整理する。
何がどう変わるのか(公式整理)
データ粒度ごとに保持期間が3層に分かれる。保持期間を過ぎたデータは、Google Ads UI / API のどちらからもアクセスできなくなる。
- 37ヶ月保持(縮小):時間別・日別・週別の granular reporting データ。従来は11年
- 3年保持:reach & frequency 系メトリクス(unique users / 頻度分布など)
- 11年保持(維持):月別・四半期・年別の集計データ
11年から37ヶ月へ — 18ヶ月で反転した方針
Google は 2024年11月13日 に「11年データ保持」を拡張方向で導入していた。その方針が、わずか18ヶ月後に「37ヶ月へ縮小」と反転している。
11年宣言時に「これで長期分析を Google 依存で組める」と判断した組織は、18ヶ月後に裏切られたことになる。Google の公式約束ですら、18ヶ月単位で反転し得る——これが本変更最大の教訓であり、データ保管をプラットフォームに委ねるリスクは机上の議論ではなくなった。
3層の技術的影響と、最も危険な BigQuery 落とし穴
影響は Google Ads API / GA4 Data API / BigQuery Data Transfer Service の3層で異なる挙動になる(技術詳細の出典:PPC.land)。
第1層:Google Ads API は明示エラーで落ちる
37ヶ月より古い日付に segments.date / segments.week を含むクエリを投げると、6月1日から DateRangeError.INVALID_DATE が返る(将来は REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED に置き換え予定)。明示エラーで落ちるため影響箇所の特定は容易だ。
第2層:GA4 Data API は黙って切り詰める
GA4 Data API の挙動はずっと厄介だ。date dimension を含むレポートで Advertiser Ad Cost / Clicks / Impressions を取得すると、直近36ヶ月のウィンドウに silent truncation される。エラーが出ないため、複数プラットフォーム横断のダッシュボードで「数字が静かに減る」事故が起きうる。
第3層:BigQuery 手動 backfill が過去データを破壊する
最も危険なのが BigQuery Data Transfer Service の挙動だ。2026年6月1日以降に37ヶ月より古い日付に対して手動 backfill を実行すると、BigQuery 側の該当日付テーブルが空の値で上書きされる(出典:PPC.land)。これは「データ取得失敗」ではなく、能動的なデータ破壊だ。この挙動を知らずに backfill を走らせると、せっかく BigQuery に取り込んでいた granular データが永久に失われる。本変更で最も警戒すべき落とし穴であり、すべての ETL 担当者が施行前に把握しておく必要がある。
ただし——プラットフォーム約束に依存した分析設計は、構造的に脆い
本変更は「Google が悪い」という個別事象ではなく構造問題だ。広告データを「プラットフォームが11年保持してくれる」前提で長期分析を組む発想自体が、媒体側のビジネス都合・法規制・コスト構造でいつでも反転し得る(現に18ヶ月で反転した)。これは Google 固有ではなく、Meta でも Yahoo でも LINE でも原理的に起こり得る話だ。
媒体方針変更シリーズで一貫して論じてきたのは、媒体側の機能・約束・データに依存する運用設計は、媒体方針が変わった瞬間に崩れるという構造だった。article-22 で Meta Advantage+ Leads について「使うが主導権は渡さない」と書いたのと同じ構造で、結論は変わらない。広告データは、自社の資産として自社の倉庫に持つ。
2026年6月1日までにやるべきこと(緊急アクションリスト)
施行まで残り20日弱。すべての Google Ads 利用組織が施行前に実施すべきアクションを優先順位順に整理する。
- 1. 自社 DWH に過去 granular データを退避:Data Transfer Service / Looker Studio / API 経由で、37ヶ月以上前を含む granular データを自社管理ウェアハウスへ完全エクスポート。施行後は復元不可
- 2. 手動 backfill の凍結(最重要):6月1日以降、37ヶ月より古い日付への BigQuery DTS 手動 backfill は絶対に走らせない。既存テーブルが NULL で上書きされ永久消失する
- 3. API クエリの監査と移行:Google Ads API / Scripts で segments.date / segments.week を37ヶ月以上前に投げているクエリを特定、施行後は segments.month / quarter / year へ移行
- 4. GA4 silent truncation 対策:date dimension 付きで Ad Cost / Clicks / Impressions を取る GA4 レポートは事前にスナップショット取得、自社 DWH へ保管
- 5. ETL パイプラインの監査:複数 Google API を組み合わせる処理は、各層の挙動差(エラー / silent truncation / NULL 上書き)を踏まえて退避手順とエラーハンドリングを再設計
まとめ:データ保持の主導権を媒体から自社へ
本変更は、媒体方針変更シリーズで論じてきた構造の最も尖った事例だ。プラットフォームが11年と約束した翌々年に37ヶ月へ反転する世界では、長期分析を媒体側に委ねる設計は持続できない。今すぐの打ち手は前節の5項目、中長期で問われるのは プラットフォーム委任ではなく自社配信設計 と同じ構造をデータ層にも適用する判断だ。「運用ではなく設計」の核心はデータ運用層でも変わらず、マーケティング DX の出発点であるデータ統合論は本変更を機に「Google が持っている前提」から「自社が持つ前提」へアップデートする必要がある。