Google Ads Daten retten: 5 Wege vor dem 1. Juni 2026 Cutoff

Am 1. Mai 2026 hat Google still und leise eine neue Data-Retention-Policy auf dem Google Ads Developer Blog angekündigt. Ab 1. Juni 2026 werden granulare Reporting-Daten gecappt. Reach- und Frequency-Metriken nach 3 Jahren, Hourly/Daily/Weekly-Daten nach 37 Monaten. Wer Year-over-Year-Vergleiche auf Tagesebene fährt oder Brand-Lift-Studien über mehrere Jahre archiviert, verliert ab diesem Datum schrittweise jeden Tag Daten.

Was die Policy bedeutet und wer betroffen ist, habe ich im Awareness-Beitrag zur 37-Monate-Regel im Detail aufgeschlüsselt. Dieser Beitrag liefert die andere Hälfte: fünf konkrete Lösungswege im Vergleich, eine Entscheidungs-Heuristik nach Account-Anzahl und ein praktischer Aufbau-Bauplan für ein eigenes Export-Skript. Wer parallel zum Daten-Export auch das eigene Tracking-Setup auf den Prüfstand stellen will, findet im Beitrag zu typischen Google-Ads-Tracking-Fehlern die häufigsten Schwachstellen, die in Audits regelmäßig auftauchen.

Was am 1. Juni 2026 wirklich passiert

Die offizielle Policy ist klar gestaffelt:

Datentyp	Retention ab 1.6.2026
Reach und Frequency (unique_users, frequency_distribution, average_impression_frequency_per_user)	3 Jahre
Sub-monthly: hourly, daily, weekly	37 Monate
Monthly, Quarterly, Annual	11 Jahre

Wichtig: Die Daten werden gelöscht, nicht archiviert. Wer nach dem Cutoff via Google Ads API einen Query auf einen Zeitraum stellt, der außerhalb des Fensters liegt, bekommt einen DateRangeError.INVALID_DATE als Antwort. Im Web-UI verschwinden Reports älter als das jeweilige Fenster aus der Auswahl.

Die Policy betrifft fünf Kanäle parallel:

• Google Ads Web-UI
• Google Ads API
• Google Ads Scripts
• Google Analytics Data API (mit zusätzlicher Eigenheit: dort wird stillschweigend auf 36 Monate gekürzt, ohne Error)
• BigQuery Data Transfer Service

Nicht betroffen sind die DV360- und CM360-APIs, die bei ihren eigenen 24-Monats-Fenstern bleiben.

Welche Daten konkret weg sind

Reach- und Frequency-Reports treffen es am härtesten:

• unique_users pro Kampagne, Asset Group, Anzeigengruppe
• frequency_distribution Buckets bei 1+, 2+, 3+, 4+, 5+ und 10+
• average_impression_frequency_per_user über 7-Day und 30-Day Variants

Auf Sub-monthly-Ebene:

• Tages-Performance pro Kampagne und Ad Group
• Wochen-Search-Term-Reports
• Stunden-Granularität pro Tag (sofern verfügbar)

Was bleibt:

• Monthly-Aggregate pro Kampagne (Impressions, Klicks, Cost, Conversions, Conversion Value)
• Quarterly und Annual Roll-ups
• Year-over-Year-Vergleiche auf Monatsbasis

Die Implikation für Werbetreibende: ab 1. Juni 2026 sind Drill-Downs in einzelne Wochen oder Tage für Daten älter als 37 Monate nicht mehr möglich.

Die fünf Lösungswege im Vergleich

Aus der Analyse für die eigenen Accounts haben sich fünf Wege herauskristallisiert. Jeder hat seinen Sweet-Spot, abhängig von Account-Anzahl, technischer Kapazität und Budget.

Lösung 1: Python-Skript via Google Ads API

Wie es funktioniert: Ein Skript iteriert über alle Customer-IDs (aus Account-Konfig), führt pro Konto GAQL-Queries auf Campaign-Daily, AdGroup-Daily, Keyword-Daily und Reach-Frequency aus, schreibt die Resultate als CSV pro Konto.

Wann sinnvoll:

• Mehrere Accounts (etwa ab fünf)
• Bestehende Google Ads API Auth mit Refresh-Token und Developer-Token (Basic Access genügt)
• Wiederkehrender Export gewünscht (monatlich nachladen)

Vorteile:

• Skaliert über beliebig viele Accounts
• Manifest mit Schema und Spalten-Bedeutung als Audit-Trail
• BigQuery-Snapshot als Native-Table möglich (statt Transfer-Service)
• Versionierbar in Git

Trade-offs:

• Initialer Setup-Aufwand etwa ein Vormittag bis ein Arbeitstag
• API-Quota: bei Basic Access 15.000 Operations pro Tag, reicht für die meisten KMU-Setups
• Pro-Account-Customer-ID muss ohne Dashes übergeben werden, sonst läuft die Library in Fehler

Kosten: keine API-Gebühr seitens Google. Bei BigQuery-Storage als Native-Table fallen geringe Storage-Kosten an, typisch im niedrigen einstelligen Euro-Bereich pro Monat für mittlere Datenmengen.

Lösung 2: Manueller CSV-Export aus dem Web-UI

Wie es funktioniert: Pro Konto im Google Ads Web-Interface den Bericht-Editor öffnen, gewünschte Granularität und Zeitraum einstellen, als CSV herunterladen, lokal oder in Drive ablegen.

Schritt-für-Schritt für die drei prioritären Reports:

Reach- und Frequency-Report (engster Cutoff):

1. Berichte > Vordefinierte Berichte > Reichweite und Häufigkeit
2. Granularität: Tag oder Woche, je nach Bedarf
3. Zeitraum: Maximum, so weit zurück wie verfügbar
4. CSV herunterladen

Daily Performance pro Kampagne:

1. Berichte > Vordefinierte Berichte > Leistung > Kampagne
2. Datumssegmentierung: Tag
3. Zeitraum: Maximum
4. CSV herunterladen

Weekly Search Terms:

1. Berichte > Vordefinierte Berichte > Suchbegriffe
2. Datumssegmentierung: Woche
3. Zeitraum: Maximum verfügbar (variiert je nach Konto)
4. CSV herunterladen

Wann sinnvoll:

• 1 bis 2 Accounts
• Keine Programmier-Affinität
• Akuter Zeitdruck vor Cutoff

Trade-offs:

• Zeitaufwand: etwa 30 Minuten pro Konto und Bericht-Sammlung
• Reach-Frequency im UI eingeschränkt verfügbar, oft nur für aktive Display- und Video-Kampagnen
• Manuelle Pflege: pro Konto eigener Ordner, Versionierung von Hand
• Kein automatisierter Re-Run

Kosten: 0 Euro plus reine Arbeitszeit.

Lösung 3: BigQuery Data Transfer Service (disqualifiziert als Backup)

Diese Option wird in vielen Diskussionen erwähnt, ist aber bei näherer Betrachtung kein Backup gegen die neue Policy. Der BigQuery Data Transfer Service ist explizit auf der Liste der betroffenen Schnittstellen. Ab 1. Juni 2026 wird er selbst keine Daten älter als 37 Monate mehr backfillen.

Zusätzlich gibt es eine kritische Falle: Wer einen manuellen GA4-Backfill für ältere Daten anstößt, kann bestehende historische BigQuery-Tabellen mit leeren Werten überschreiben. Das ist im offiziellen Help Center dokumentiert und ein realer Datenverlust-Risiko.

Wann der Transfer Service trotzdem Sinn macht:

• Laufendes Monitoring nach dem Cutoff (rolling 37-Monate-Fenster)
• Wenn Daten ohnehin nicht älter als 37 Monate gebraucht werden
• Als Ergänzung zu einem nativen Snapshot, nicht als Ersatz

Für reine Backup-Zwecke gegen den 1.6.2026-Cutoff ist die Option ausgeschlossen.

Lösung 4: Google Ads Scripts mit Sheet-Output

Wie es funktioniert: JavaScript-Skript im Google Ads Konto, das einen AdsApp.report() Query ausführt und das Ergebnis in ein Google Sheet exportiert.

Beispiel-Skelett:

function main() {
  var report = AdsApp.report(
    "SELECT campaign.name, segments.date, " +
    "metrics.impressions, metrics.clicks, metrics.cost_micros " +
    "FROM campaign " +
    "WHERE segments.date >= '2023-01-01' AND segments.date < '2024-01-01'"
  );
  report.exportToSheet('https://docs.google.com/spreadsheets/d/SHEET_ID/');
}

Wann sinnvoll:

• MCC-Inhaber mit moderater Account-Anzahl
• Sheets-Affinität im Team
• Wunsch nach Lösung ohne API-Setup

Trade-offs:

• Google Ads Scripts haben ein 30-Minuten-Execution-Cap pro Run. Bei vielen Accounts oder großen Datenmengen reicht das nicht aus. Das hat Arjan Schoorl von Flowboost in einem LinkedIn-Beitrag am 2. April 2026 dokumentiert.
• Spreadsheet-Output erschwert Audit-Trail-Sauberkeit (Zell-Limits, manuelle Versionierung)
• Pro Account einzeln installieren
• Reach-Frequency-Daten via Scripts eingeschränkt zugänglich

Kosten: 0 Euro, läuft auf Google-Infrastruktur.

Lösung 5: Drittanbieter-Tools (Supermetrics, Funnelio, Adverity)

Wie es funktioniert: Multi-Source-Reporting-Plattformen, die Google Ads Daten regelmäßig syncen und in eigene Datenbanken oder Connectoren ablegen.

Wann sinnvoll:

• 30 oder mehr Accounts
• Multi-Source-Reporting (Google Ads plus Meta plus Microsoft Ads plus weitere)
• Team-Setup mit Self-Service-Reports

Trade-offs:

• Laufende Kosten zwischen 70 und 300 Euro pro Monat, je nach Anbieter und Datenmenge
• Datenkontrolle wird teilweise an den Anbieter abgegeben
• Setup-Aufwand niedriger als Eigenbau, dafür Vendor-Lock-in
• Backup-Qualität abhängig vom Anbieter (manche cachen, manche pullen on-demand)

Kosten-Beispiele (Stand Mai 2026, ohne Anspruch auf Vollständigkeit): Supermetrics Essential ab etwa 70 Euro pro Monat, Funnelio ab etwa 200 Euro pro Monat, Adverity individuell verhandelt.

Welche Lösung passt zu deinem Setup

Die Entscheidung hängt primär an drei Faktoren: Account-Anzahl, technische Kapazität und Zeit bis zum Cutoff.

Wenn…	Dann…	Aufwand
Maximal 2 Accounts, Cutoff in unter 1 Woche	Manueller UI-Export	etwa 30 Minuten pro Konto
Mehrere Accounts, bestehende API-Auth	Python-Skript via Google Ads API	etwa ein Setup-Tag, dann skalierbar
Sehr viele Accounts, Multi-Source nötig	Drittanbieter mit ROI-Check	Tool-Kosten plus Onboarding
Plan langfristige YoY-Queries nach Cutoff	API-Skript plus BigQuery Native als Storage	wie Skript plus Storage-Setup
MCC-internes Reporting, kein externer Stack gewünscht	Google Ads Scripts	pro Account einzeln einrichten

Empfohlener Aufbau für eine eigene Skript-Lösung

Wer den Python-Weg geht, kommt mit einem überschaubaren Setup ans Ziel:

Technischer Stack:

• Python 3.11 oder neuer mit der offiziellen google-ads Library (aktuelle stabile Version, derzeit v23)
• Google Ads API mit Basic Access (Developer Token + Refresh Token pro MCC)
• Customer-IDs aus einer zentralen Konfigurationsdatei (etwa accounts.json)
• Output: CSV pro Konto in einem Reports-Ordner plus Manifest-Datei für den Audit-Trail

Sinnvolle Datenstruktur pro Konto:

• campaign-daily.csv: Date × Campaign × KPIs inklusive Search Impression Share
• adgroup-daily.csv: Date × Ad Group × KPIs
• keyword-daily.csv: Date × Keyword × Match Type × KPIs
• reach-frequency.csv: nur Display, Video, Performance Max und Demand Gen Campaigns
• manifest.json: Schema-Dokumentation plus Source-Policy-URL

Bug-Note für Eigenbauer: Das DISCOVERY-Enum in Google Ads API v23 wurde deprecated und durch DEMAND_GEN ersetzt. Wer Skripte schreibt, die alte Enum-Werte nutzen, läuft in einen API-Error. Tipp: vor dem Cutoff einmal komplett neu laufen lassen, damit die letzten Tage vor dem 1. Juni mit der aktuellen Enum erfasst sind.

Re-Run-Strategie:

• Monatlicher Refresh-Lauf, der die letzten 30 Tage in die bestehenden CSVs einspeist
• Kurz vor dem 1. Juni 2026 ein finaler Komplett-Lauf, damit die letzten 24 Stunden vor Cutoff erfasst sind
• Nach dem Cutoff: rolling 37-Monate-Fenster, das jeden Monat um einen Monat weiterwandert

Storage: wohin mit den Daten

Drei realistische Optionen, je nach Use-Case:

Option A: CSV in Git-Repo

• Pro: versioniert, diff-bar, leicht überprüfbar bei Audits, kostenlos
• Con: bei großen Datenmengen wird das Repo schwer (10+ GB möglich)
• Best für: KMU mit moderaten Datenmengen, Backup-Fokus

Option B: BigQuery Native Table als Snapshot

• Pro: SQL-Queries direkt möglich, gute Skalierung bei großen Datenmengen, kompatibel zu existing BigQuery-Setups
• Con: laufende Storage-Kosten (typisch unter 5 Euro pro Monat bei mittleren Mengen)
• Best für: analytische Nutzung, YoY-Queries, Reporting-Dashboards

Option C: Cloud Storage (S3, GCS, Dropbox) als Off-Site Backup

• Pro: unabhängig von Git oder Google Cloud, gut für Disaster Recovery
• Con: keine analytische Nutzung ohne Re-Import
• Best für: Compliance-Backups, Versions-Archiv

Hybrid-Empfehlung: CSV in Git als Working-Copy plus BigQuery Native als Analytics-Layer plus Cloud Storage als Off-Site-Backup. Klingt aufwendig, ist aber bei einem einmaligen Setup pro Konto in wenigen Stunden fertig.

Häufige Fallstricke

• BigQuery Data Transfer Service ist nicht das Backup. Das ist die Falle, in die die meisten tappen, weil der Service-Name nahelegt, er würde dauerhaft Daten archivieren.
• Manuelle GA4-Backfills überschreiben historische Tabellen mit leeren Werten. Wer den Transfer Service nutzt, sollte das vor dem Cutoff prüfen.
• Search-Term-Reports älter als 37 Monate sind bei vielen Konten teilweise schon vor 1.6.2026 ausgedünnt, weil Google bestimmte Suchanfragen aus Datenschutzgründen entfernt. Was du heute siehst, ist nicht garantiert das Maximum.
• Reach-Frequency nur für die richtigen Kampagnen. Search-only-Accounts brauchen den Report nicht, weil keine Reach-Frequency-Daten generiert werden. Für Display, Video, Performance Max und Demand Gen ist er zentral.
• Customer-IDs mit Dashes im Python-Skript: die offizielle Google-Ads-Library erwartet IDs ohne Dashes (also 1234567890 statt 123-456-7890).
• API-Quota bei Basic Access bei 15.000 Operations pro Tag. Bei vielen Accounts und tiefem Drill-Down kann das knapp werden, dann zwei Tage einplanen oder Standard Access beantragen.

FAQ

Reicht ein einmaliger Export, oder muss ich regelmäßig laufen lassen?

Ein einmaliger Export am 31. Mai 2026 sichert dir die vollständige Historie. Wer aber nach dem Cutoff weiterhin granulare Daten in der eigenen Datenbank haben will (z. B. für YoY-Vergleiche), braucht einen monatlichen Refresh-Lauf, der neue Daten in das bestehende Archiv schreibt. Das ist das Rolling-Window-Pattern.

Was kostet BigQuery für Storage von Google Ads Daten?

Für mittlere Datenmengen unter 50 GB liegen die Storage-Kosten typisch unter 5 Euro pro Monat. Compute-Kosten fallen erst bei Queries an, bei normaler Nutzung ebenfalls überschaubar. Google bietet ein Free-Tier mit 10 GB Storage und 1 TB Query-Verarbeitung pro Monat.

Gibt es eine fertige Lösung statt Eigenbau?

Drittanbieter wie Supermetrics oder Funnelio bieten den Export als Service. Wer bereits mit solchen Tools arbeitet, kann den Export-Workflow als Konfiguration einrichten. Wer noch nicht: für reine Backup-Zwecke ist das ein teurer Weg im Vergleich zum einmaligen Eigenbau-Skript.

Was wenn ich keine API-Zugänge habe?

Dann bleibt der manuelle UI-Export (Lösung 2) oder ein Google Ads Script (Lösung 4). Beide brauchen keine externe API-Auth, sondern laufen mit den bestehenden Konto-Berechtigungen. Bei mehreren Konten ist der manuelle Weg schmerzhaft, bei einem Konto akzeptabel.

Was ist mit Smart-Bidding-Lern-Daten oder Audience-Insights?

Die hier diskutierte Policy bezieht sich auf Reporting-Daten. Smart Bidding lernt intern auf rolling-windows-basierten Daten, dort ändert sich nichts. Audience Insights und Demografie-Daten haben separate Retention-Logiken, die nicht direkt von der Reporting-Policy berührt werden.

Quellen

• Google Ads Developer Blog: New Data Retention Policy for Google Ads starting June 1, 2026 (Nadine Wang, Advertising and Measurement APIs Team, 1. Mai 2026)
• Google Ads Data Retention Policy, Google Ads Help Center
• Data deletion and retention controls, Google Ads Help Center
• PPC.land: Google Ads cuts granular data access to 37 months starting June 2026
• Arjan Schoorl (Flowboost) zum 30-Minuten-Execution-Limit bei Google Ads Scripts (LinkedIn, 2. April 2026)
• Rob Sanders: Google Ads Data Retention Policy Analysis

Deine nächsten Schritte

Drei mögliche Pfade, je nach Situation:

1. Schneller Selbst-Export: Inline-Anleitungen aus diesem Beitrag direkt umsetzen. Für 1 bis 2 Konten reicht der manuelle UI-Weg in 60 Minuten.
2. Multi-Account-Setup: Wer mehrere Konten betreut, baut sich ein Python-Skript nach dem oben beschriebenen Pattern. Das Manifest-Format aus dem eigenen Setup kann als Vorlage dienen.
3. Audit plus Export im Paket: Wer parallel sauberes Tracking oder eine strategische Klärung braucht, fährt mit einem Audit besser, in dem die historischen Daten als Audit-Basis dienen. Erstgespräch unverbindlich. Wer noch Grundsatz-Themen klären will, findet im Beitrag Negative Keywords in Google Ads einen typischen Hygiene-Workflow, der ohnehin zu jedem sauberen Konto gehört.

→ Erstgespräch vereinbaren