GA4の過去データは勝手に消える｜保持期間と退避の備え

「先月まで見えていた数字が、今日は出ない」。GA4の探索レポートで前年の同じ月を指定したら、表が空のまま返ってきた——この種の相談は、たいてい年次の振り返りや期の締めの直前に届きます。原因はほとんどの場合ひとつで、データの保持期間の設定です。GA4が探索で使えるイベントデータを持つ期間には上限があり、既定は2か月。14か月まで延ばせますが、変更する前に消えた分は戻りません。しかも、この保持期間が効くのは探索とファネルのレポートだけで、標準の集計レポートには影響しないとされています。つまり日々の運用で標準レポートだけを見ている人は、異変にまったく気づきません。データが消えていることに気づくのは、消えてから何か月も後——この構造そのものが事故の原因になっています。本記事では、保持期間の仕様、最初に変えるべき設定、しきい値やサンプリングで数字が動く話、そしてBigQueryやスプレッドシートへの退避運用までを順に整理します。

「去年の数字が出ない」日は突然来る

気づき方はいつも似ています。年次のレポートを作ろうとして、探索で期間に前年の同じ月を指定する。表が空のまま返ってくる。日付の指定を間違えたかと思って何度か入れ直し、ようやく「そもそもデータがない」と分かる。焦って設定を確認すると、データの保持が2か月のままになっている——という流れです。

厄介なのは、この状態が何か月も前から続いていることです。標準レポートを開けば期間を長く取っても数字は出るので、日々の運用では異変が見えません。異変が表面化するのは、探索で長い期間を指定した瞬間だけ。つまり四半期や年度の振り返りを担当する人が、いつも最初の発見者になります。日次のダッシュボードを見ている担当者は、最後まで気づけません。

BtoBではこの遅れが特に痛みます。検討期間が数か月に及ぶため、施策の効果は翌月ではなく半年後や1年後に現れる。展示会の反響、ホワイトペーパー経由の流入、年度予算に紐づく季節性——いずれも前年と比べないと良し悪しを判断できない指標です。比較する相手のデータが消えていれば、判断そのものが成立しません。

データ保持期間とは何の期間か

まず用語の整理です。データの保持期間は、GA4のサーバーにデータが保存される期間を指します。設定は「ユーザーデータ」と「イベントデータ」の2つに分かれ、それぞれ別の値を選べます。

公式の説明では、ユーザーデータは2か月または14か月、イベントデータは2か月・14か月に加えて、アナリティクス360のプロパティのみ26か月・38か月・50か月が選べるとされています。無料版で選べるのは2か月と14か月の2択で、それ以上に延ばす設定は用意されていません。

設定項目	選べる期間	影響が出る場所
ユーザーデータの保持	2か月／14か月	探索のユーザー軸の分析（コホートなど）
イベントデータの保持	2か月／14か月（360は26・38・50か月も）	探索とファネルのレポート全般
新しいアクティビティでのリセット	オン／オフ（既定はオン）	ユーザーデータの起算点

ここで押さえておきたいのが、「保存されている」ことと「レポートに表示できる」ことが同じではないという点です。標準レポートは集計済みの数字を返す仕組みのため、元のイベントデータが消えた後も表示が続きます。見えているのに、元データはもうないという状態が起こり得ます。

影響するのは探索、標準レポートは残る

公式のヘルプは、この点をはっきり書いています。データ保持の設定は、プライマリとセカンダリのディメンションを含む標準の集計レポートには影響せず、データ探索とファネルのレポートにのみ影響する、という記述です。レポートで比較を作成した場合も同様とされています。

なぜ差が出るのか。標準レポートは、あらかじめ決まった切り口で集計された値を返します。一方の探索は、個々のイベントを条件で絞り直し、任意のディメンションと指標を組み合わせて計算します。後者は元のイベントが手元にあることが前提なので、保持期間を過ぎて削除された分は再計算できません。消えるのは探索の材料、残るのは標準レポートの結論という関係です。

この非対称が、社内での認識のずれを生みます。レポートを受け取る側は「GA4に去年のデータがある」と思っている。実際に探索を触る担当者だけが、ない期間があると知っている。両者の会話が噛み合わないまま、年次の分析の依頼が来るという展開になります。設定を確認したら、その結果を関係者に共有しておくところまでを一続きの作業にしてください。

既定の2か月が引き起こす事故

既定の2か月のままだと、具体的に何ができなくなるのか。最も痛いのが前年同月比です。前年の同じ月を探索で指定しても、そこにデータはありません。前月比までは取れても、季節性を排除した比較ができなくなります。

困る場面はほかにもあります。去年うまくいったキャンペーンを再実行するとき、当時の流入経路の内訳を確認できない。期初に目標を置くとき、前年度の月別の推移を細かく見られない。サイトを改修した後で、改修前のユーザー行動と比べられない。去年の数字がない状態では、今年が良いのか悪いのかを言えないという事態になります。

さらに見落とされやすいのが、後から思いついたセグメントを過去に適用できないという制約です。探索の強みは、分析の途中で「この条件で絞ったらどう見えるか」を試せることにあります。その試行の対象になる期間が2か月しかないのでは、探索を導入した意味が半減します。

まず変えるべきはイベントデータの保持

対処の第一歩は設定変更です。作業自体は1分で終わります。管理画面から、データの収集と修正に関する項目の中にあるデータの保持を開き、イベントデータの保持を14か月に変更して保存します。

1. 管理画面を開き、データの収集と修正に関する項目からデータの保持を選ぶ
2. イベントデータの保持を2か月から14か月に変更する
3. ユーザーデータの保持と、リセットのオプションも確認する
4. 保存し、24時間後に反映されることを前提に予定を組む

公式には、保持期間を変更すると適用までに24時間かかるとあります。この期間内であれば変更を取り消せるとも記載されています。保存した直後に探索を開いても、まだ挙動は変わりません。設定したつもりで数字を確認して「変わっていない」と慌てないでください。画面上のメニュー名は改定されることがあるため、見つからない場合は管理画面内の検索で「データの保持」を探すのが早道です。

そして重要なのが、この作業をプロパティごとに行う必要がある点です。新しくプロパティを作ったとき、設定は自動では引き継がれません。テスト用のプロパティ、サブブランドのプロパティ、事業部ごとに分けたプロパティ——設定を1か所変えるだけで、来年の自分が救われるのに、その1か所が漏れているケースが少なくありません。プロパティの一覧を出して、全件を確認してください。

ユーザーデータとリセットの扱い

イベントデータと並んで設定できるのがユーザーデータの保持です。こちらも2か月または14か月から選びます。あわせて「新しいアクティビティのユーザーデータのリセット」というオプションがあり、既定ではオンになっているとされています。

このオプションがオンの場合、対象のユーザーから新しいイベントが発生するたびに、そのユーザーのデータ保持期間が起算し直されます。たとえば保持が2か月でも、2か月以内に再訪があれば、その時点から改めて2か月保持されるという挙動です。オフにすると、初回のアクティビティから一定期間で削除され、再訪によるリセットは起きません。

実務での影響は、ユーザー軸の分析に出ます。コホート探索、初回接触からリピートまでの期間、長期の再訪パターン。ユーザー軸の分析は、イベント軸より先に見えなくなる傾向があるため、リピートを重視するサイトでは、ユーザーデータの保持も14か月にしておくのが素直な選択です。片方だけ延ばして満足してしまうのが、よくある取りこぼしです。

設定に関係なく決まっているデータもある

14か月に延ばせば全部が14か月残る——とは限りません。設定値とは別の規則で保持期間が決まるデータがあります。

年齢・性別・インタレストといったユーザー属性のデータは、プロパティの設定に関係なく常に2か月の保持期間が適用されるとされています。またGoogleシグナルに関するデータは常に26か月とされる一方、プロパティの設定値がそれより短い場合は短いほうが優先される、という整理です。属性でセグメントを切る分析は、長い期間では再現できないと考えておくのが安全です。

この点を知らないと、原因の切り分けで迷います。イベント数は14か月分出るのに、性別で分けた表だけが直近しか出ない。設定が壊れているように見えますが、仕様どおりの挙動です。属性を含む分析は、必要になった時点でその都度書き出して残すという運用に切り替えてください。後から遡る前提を捨てるのが現実的です。

変更しても消えたデータは戻らない

ここが最も重要な原則です。保持期間を過ぎたデータは月単位で自動的に削除され、削除されたデータは復元できません。設定を14か月に変えても、それまでに削除された分が戻ることはありません。

逆方向の操作はさらに危険です。公式には、保持期間を短縮した場合、影響を受けるデータは翌月の処理で削除されるとあります。つまり14か月から2か月に戻す操作は、12か月分のデータを捨てる操作になります。プロパティの整理中に軽い気持ちで触ってよい設定ではありません。

• 保持期間の設定は未来のデータにしか効かない。過去は遡って復元されない
• 保持期間を過ぎたデータは月単位で自動削除される
• 短縮すると、対象のデータは翌月の処理で削除される（実質的に取り返しがつかない）
• 変更の反映には24時間かかり、その間なら取り消せる
• プロパティを新設したら、そのたびに保持の設定を確認する

したがって、この記事を読んで最初にやるべきことは分析ではなく設定変更です。保持期間の設定は、未来のデータにしか効かない。今日変えれば来年の今日には14か月分がそろいますが、来月に延ばせば1か月分の損失が確定します。判断を保留している期間そのものが、そのまま失われるデータ量になります。

しきい値とサンプリングで数字は動く

保持期間の話と並べて理解しておきたいのが、GA4の数字が状況によって変わる2つの仕組みです。しきい値とサンプリングで、どちらも「間違い」ではなく仕様です。

しきい値は、プライバシー保護のために一部のデータを非表示またはマスクする仕組みです。年齢・性別・インタレスト・地域といった属性や、個人の行動が反映されやすいサイト内検索の語句などをレポートに含めたとき、対象のユーザー数が少ないと適用されることがあるとされています。行そのものが消えるため、合計と内訳が合わなくなるのが特徴です。

サンプリングは、処理量を抑えるために一部を抽出して計算する仕組みです。標準レポートではサンプリングは行われず、探索でイベントの割り当て上限を超えた場合に適用されるとされています。期間を長く取り、条件を複雑に重ねた探索ほど発生しやすくなります。

• 合計と内訳が合わない：しきい値で行が隠れている可能性を先に疑う
• 同じ条件で数字が微妙に変わる：探索のサンプリングを確認する
• 古い期間だけ空になる：データ保持期間を超えている
• 標準レポートと探索で数字が違う：集計の仕組みが違うため、そろわないのが正常

退避を考えるうえで、この2つは無視できません。書き出した数字は、そのときのしきい値とサンプリングを通った後の値です。退避で残せるのは数字であって、数字の意味ではないため、書き出したファイルには期間・条件・適用状況を必ず併記してください。1年後に見返したときの解釈が変わります。

長期保存の選択肢を並べる

14か月より長く見たい場合、選択肢は大きく4つに分かれます。それぞれ残るものが違うので、目的から逆算して選びます。

手段	残るもの	費用の目安	手間
保持期間を14か月にする	探索で14か月分のイベント	無料	設定1回のみ
BigQueryへのエクスポート	未加工のイベントを期限なく	連携は無料・クエリ量で課金	初期設定と権限の設計
レポートの書き出し	そのとき見た集計値	無料	毎月の手作業（自動化可）
Looker Studioでの保存	ダッシュボードで定義した指標	無料（参照先の課金に注意）	画面の設計が必要

この表で判断が分かれるのは、生データが必要かどうかです。後から新しい切り口で問い直したいならBigQueryしかありません。逆に「毎月このKPIを追う」と決まっているなら、書き出しやLooker Studioで足ります。無期限に残したいなら、退避先を別に持つしかないという点はどの手段でも共通です。

現実的な組み合わせは、保持期間を14か月にしたうえで、BigQueryエクスポートを設定し、加えて月次の主要指標だけをスプレッドシートに残す形です。手段は排他ではなく、粒度の違う保険を重ねると考えてください。BigQueryが使えない事情があるなら、書き出しの自動化に寄せます。

BigQueryエクスポートを使うときの実務

長期保存の本命はBigQueryへのエクスポートです。公式の説明では、無料版のGA4でも利用でき、日次エクスポートでは1日1回、前日に取得した未加工でサンプリングされていないイベントが送られるとされています。当日のデータをほぼリアルタイムで送るストリーミングも選べます。

上限と費用は把握しておく必要があります。標準のプロパティでは1日あたり最大100万件のイベントがエクスポートの上限とされ、アナリティクス360では1日あたり最大200億件とされています。ストリーミングを使う場合はデータ1GBあたり0.05ドルの追加費用が発生し、1GBはイベント約60万件に相当するという記述もあります。まずは日次エクスポートだけで始めるのが無難です。

エクスポートされたデータは、日付ごとのテーブルとして並びます。テーブル名の形が分かっていると、クエリを書くときの見通しがよくなります。

-- 日次エクスポート（前日分までが日付別テーブルで並ぶ）
analytics_123456789.events_20260701
analytics_123456789.events_20260702

-- ストリーミングを有効にした場合の当日分
analytics_123456789.events_intraday_20260728

落とし穴は3つあります。第一に、連携を設定する前のデータは遡って入らないこと。連携した日から先しか残らないので、迷っている期間そのものが損失になります。第二に、BigQueryのサンドボックスではテーブルの有効期限が既定で60日に設定されており、無期限にするには変更が必要とされている点。第三に、Looker StudioからBigQueryを直接参照する設計にすると、閲覧のたびにクエリが走って課金が跳ねることがある点です。参照用のテーブルを集計済みで用意するか、抽出の仕組みを使ってクエリ量を抑えてください。

スプレッドシートとLooker Studioへの退避

BigQueryをすぐに立てられない事情もあります。権限がない、クラウドの利用申請が通らない、SQLを書ける人がいない。その場合の現実解が、レポート画面からの書き出しを定期作業にすることです。

退避で決め手になるのは「何を残すか」です。すべてを残そうとすると続きません。後から必ず見る軸を3つか4つに絞り、毎月同じ形で1シートに追記します。具体的には、チャネル別のセッションとキーイベント数、ランディングページ別の流入、デバイス別の内訳、そして主要なキーイベントの発生数あたりが定番です。

あわせて、シートには数字以外の情報も書き残してください。取得日、対象期間、適用した条件、しきい値が出ていたかどうか。毎月5分の書き出しが、1年後の比較を可能にするのは事実ですが、条件の記録がない数字は1年後に比較できません。列を4つ足すだけの話です。

Looker Studioを使うなら、レポートの画面自体を退避先とみなす設計もあります。月ごとのスナップショットをPDFで保存する、あるいは集計結果を別の表に書き出して固定する。ダッシュボードは接続元のデータが消えると空になるため、表示できることと保存されていることを混同しないでください。

退避運用を設計する4手順

ここまでの内容を、着手できる手順に落とします。設定変更から始め、退避の型を決めるところまでを一続きで進めます。

この4手順のうち、成否を分けるのは3つ目です。退避は、見たい軸を先に決めた人だけが成功する。軸を決めずに始めると、書き出す対象が毎月変わり、1年後に並べても比較できないファイルの山が残ります。形式をそろえることが、退避の目的そのものです。

4つ目については、担当者が交代しても続く形にしてください。手順書を1枚作り、どの画面からどの条件で書き出すかを画面名まで書いておく。属人的な作業として残すと、担当が変わった月に途切れます。実際、退避が止まる原因の多くは意欲ではなく引き継ぎの不備です。

退避でつまずく型

退避を始めた組織で実際に起きやすい問題を整理します。いずれも運用の設計で防げるものです。

• 保持期間を14か月にしたことで安心し、退避の仕組みを作らないまま15か月目を迎える
• 書き出す軸が毎月変わり、1年分を並べても比較できない
• 取得日・期間・条件を記録していないため、後から数字の意味が分からない
• BigQueryの連携を「使う予定が決まってから」と後回しにし、その間のデータを失う
• サンドボックスのテーブル有効期限を変更せず、60日で消えていることに気づかない
• Looker Studioの画面が表示できることを、データが保存されている証拠だと誤解する

1つ目が最も多い型です。14か月という数字には安心感があり、当面は困りません。しかし14か月は「2年分の比較には足りない期間」です。前年同月比は取れても、前々年との比較や2年越しの施策評価はできません。設定変更は退避の代わりにはなりません。

4つ目については、判断の順序を変えるだけで解決します。BigQueryの連携そのものは無料で、課金が発生するのはクエリを実行したときです。使うかどうかを決める前に、データを溜め始めてよいという性質があります。溜めておいて使わなかった場合の損失はほぼありませんが、溜めずに後から必要になった場合の損失は取り返せません。

生成AIで退避データを読み解く

退避したデータは、溜めるだけでは意味がありません。読む工程に生成AIを使うと、月次の作業が現実的な時間に収まります。ただし使いどころは限られていて、任せてよい作業とそうでない作業があります。

向いているのは、書き出したCSVを渡して増減の大きい行を抜き出させ、変化の説明候補を並べさせる作業です。チャネル別の12か月分を渡し、前年同月比で伸びた行と落ちた行を分けさせる。このとき、施策の実施履歴を同じプロンプトに含めておくと、変化と施策の対応づけまで踏み込んだ整理が返ってきます。

SQLの下書きにも使えます。BigQueryのGA4エクスポートは入れ子になった構造を持つため、慣れないと書き出しに時間がかかります。テーブル名と欲しい集計軸を伝えて雛形を作らせ、実行前に自分で条件を確認する。生成されたクエリをそのまま実行しないことだけは守ってください。課金はクエリの処理量で決まります。

向いていないのは、数字の正しさの判断です。AIが答えられるのは、渡した表の中にあることだけで、しきい値で行が隠れていたか、サンプリングが効いていたか、保持期間を超えて空になっていたかは分かりません。前提の記録は人間が添える必要があります。だからこそ、退避のシートに条件を書く列が要るわけです。

よくある質問

保持期間を14か月にすれば、過去のデータも見られますか

見られません。設定は未来のデータに対して効くもので、すでに削除された分は復元されません。変更した日から数えて14か月分がそろうまで待つことになります。だからこそ、気づいた日に変更する意味があります。

標準レポートのデータも消えますか

公式には、データ保持の設定は標準の集計レポートには影響せず、データ探索とファネルのレポートにのみ影響するとされています。プライマリとセカンダリのディメンションを含む場合も同様です。ただし探索で自由に切り直すことはできなくなります。

無料版で14か月より長く保存する方法はありますか

設定で選べる上限は14か月です。それより長く残したい場合は、BigQueryへのエクスポートか、レポートの定期的な書き出しで自分の側に保存します。BigQueryの連携自体は無料版でも利用できるとされています。

設定を変えたのに探索の表示が変わりません

公式には、変更の適用まで24時間かかると記載されています。保存直後は挙動が変わらないため、翌日に再確認してください。なお、すでに削除された期間は24時間待っても表示されません。

プロパティを新しく作ったとき、設定は引き継がれますか

引き継がれません。プロパティごとに個別の設定です。事業部別やテスト用にプロパティを分けている場合は、作成のたびに保持期間の変更が必要になります。プロパティ新設の手順書に1行加えておくのが確実です。

まとめ

GA4の過去データは、放っておくと静かに消えます。探索で使えるイベントデータの保持期間は既定で2か月、無料版では14か月まで延ばせ、アナリティクス360なら最長50か月まで選べるとされています。この設定が影響するのは探索とファネルのレポートだけで、標準の集計レポートには影響しないため、日々のレポートを見ている限り異変には気づけません。気づくのは年次の振り返りで前年同月を指定した瞬間で、そのときにはもう戻せません。保持期間を過ぎたデータは月単位で自動削除され、復元できないからです。変更の反映には24時間かかり、短縮した場合は対象データが翌月の処理で削除されます。あわせて、ユーザー属性のデータは設定に関係なく2か月、Googleシグナルのデータは26か月とされるなど、設定値とは別の規則で動くデータもあります。しきい値で行が隠れ、探索ではサンプリングで数字が動くことも前提に入れてください。長期で見たいなら退避先が必要です。無料版でも使えるBigQueryへの日次エクスポートは、未加工でサンプリングされていないイベントを期限なく積める一方、連携した日から先しか残らないので、迷っている期間そのものが損失になります。BigQueryが難しければ、毎月同じ軸で書き出して条件を併記する運用で足ります。気づいた日が、いちばん早い日です。まず管理画面のデータの保持を開いて、イベントデータが2か月のままになっていないかを確認してください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。