Google Ads Data Retention 37 Monate: Was du bis 1.6.2026 sichern musst

Am 1. Mai 2026 hat Nadine Wang vom Advertising and Measurement APIs Team eine neue Data-Retention-Policy im Google Ads Developer Blog angekündigt: Ab 1. Juni 2026 verkürzt Google die Aufbewahrungsfrist für granulare Reporting-Daten auf 37 Monate. Was nach einer technischen Notiz klingt, ist für Werbetreibende mit langer Account-Historie ein konkretes Problem: Wer Year-over-Year-Vergleiche auf Wochen- oder Tagesebene fahren will, hat ab Juni 2026 nur noch ein gleitendes 37-Monats-Fenster.

Der Hintergrund ist absurd: Google hatte die Retention erst im November 2024 von vorher kürzeren Fristen auf 11 Jahre verlängert. Diese 11-Jahre-Policy war damals als Hebel für Long-Term-Analysen vermarktet worden. Jetzt, weniger als 18 Monate später, kommt der Rückzieher. Für Werbetreibende heißt das: vorbeugend exportieren, statt sich auf Google’s API-Versprechen zu verlassen.

Was sich ab 1. Juni 2026 ändert

Die neue Policy ist gestaffelt nach Datentyp und Aggregationsstufe. Drei verschiedene Retentions-Fenster gelten parallel:

Datentyp	Retention ab 1.6.2026	Beispiele
Hourly, Daily, Weekly (granulare Reports)	37 Monate	Tagesperformance pro Kampagne, wöchentliche Search-Term-Reports
Monthly, Quarterly, Annual (Aggregate)	11 Jahre	Monats-Spend, jährliche Kampagnen-Roll-ups
Reach & Frequency	3 Jahre	Unique Users, Average Impression Frequency, 7-Day/30-Day Frequency, Distribution 1+, 2+, 3+, 4+, 5+, 10+

Der engste Cutoff trifft Reach- und Frequency-Daten: nur drei Jahre. Das ist für Display-, YouTube- und Demand-Gen-Werbung relevant, weniger für Search-only-Accounts.

Wer im Google Ads UI auf einen Bericht klickt, der älter als das jeweilige Fenster ist, sieht ab Juni 2026 keine Daten mehr. Dasselbe gilt für die programmatische Abfrage über die Google Ads API und Scripts.

Welche APIs und Tools betroffen sind

Die Policy gilt nicht nur für das Google Ads Web-Interface, sondern für alle Schnittstellen, die Google Ads Daten ausliefern:

• Google Ads UI: Reports älter als 37 Monate verschwinden aus der Oberfläche
• Google Ads API: GAQL-Queries mit segments.date oder segments.week für Daten älter als 37 Monate liefern DateRangeError.INVALID_DATE. Künftig (Version-Update) soll der präzisere Fehler DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED zurückkommen.
• Google Ads Scripts: gleicher Cutoff wie API
• Google Analytics Data API: Metriken wie Advertiser Ad Cost, Clicks und Impressions werden stillschweigend auf die letzten 36 Monate gekürzt, ohne Fehlermeldung. Das ist gefährlicher als ein Error, weil das Skript scheinbar weiter funktioniert
• BigQuery Data Transfer Service: Stoppt das Backfilling für Daten älter als 37 Monate

Nicht betroffen sind die DV360- und CM360-APIs. Beide haben weiterhin ihre eigenen 24-Monats-Retentions, die unverändert bleiben.

Die BigQuery-Falle, die wirklich gefährlich ist

Ein Detail, das in den meisten Diskussionen untergeht: Wer den BigQuery Data Transfer Service nutzt, um Google Ads Daten in BigQuery zu spiegeln, hat einen blind spot. Manuell ausgelöste GA4-Backfills für Daten älter als der 37-Monate-Cutoff können bestehende historische BigQuery-Tabellen mit leeren Werten überschreiben. Wer bisher BigQuery als Backup für Google Ads Daten nutzt, sollte vor Juni 2026 prüfen, ob die Transfer-Konfiguration sicher ist.

Empfehlung aus der Praxis: Statt sich auf Transfer-Service zu verlassen, einen eigenen Export als native BigQuery-Tabelle schreiben (kein Transfer-Service-Sync, sondern echter Snapshot). Das ist Mehraufwand einmalig, schützt aber vor stillem Daten-Verlust.

Warum das ein 180-Grad-Schwenk ist

Im Oktober 2024 hatte Google die Retention auf 11 Jahre verlängert (effective 13. November 2024). Damals wurde das als Vorteil für Werbetreibende vermarktet: lange historische Analysen, YoY auf granularer Ebene, Markt-Trend-Beobachtungen über Jahre.

Weniger als 18 Monate später kommt der Rückzieher auf 37 Monate. Google hat keine offizielle Begründung kommuniziert. Plausible Erklärungen aus der PPC-Community: Storage-Kosten, Daten-Schutz-Anpassungen, oder Vorbereitung auf strengere DSGVO-Auslegungen, die Aufbewahrung-Mininum-Prinzipien folgen. Was auch immer der Grund ist, das Signal an Werbetreibende ist klar: Verlass dich nicht auf Google’s Aufbewahrungs-Versprechen, sondern halte deine eigenen Daten selber.

Diese Lehre ist 2026 nicht neu, sie war schon im Server-Side-Tracking-Beitrag als Argument für 1st-Party-Datenbanken angeführt. Data-Retention ist die Auftrags-Seite davon: nicht nur was gesammelt wird, sondern wie lange es zugänglich bleibt.

Wer wirklich Probleme bekommt

Nicht jedes Konto ist gleich betroffen. Drei Szenarien aus der Praxis:

Konto unter 3 Jahre alt: Niedrige Priorität. Das Konto hat noch keine 37 Monate Historie, der Cutoff wird erst in der Zukunft relevant. Es lohnt sich, einen regelmäßigen Export-Workflow einzurichten, der monatlich die granularen Daten sichert. Akuter Handlungsbedarf besteht nicht.

Konto 3 bis 5 Jahre alt: Mittlere Priorität. Granulare Daten, die heute älter als 37 Monate sind, gehen ab Juni 2026 verloren. Wer YoY-Vergleiche auf Tagesebene oder Search-Term-Historien über mehrere Jahre braucht, sollte vorbeugend exportieren.

Konto über 5 Jahre alt, mit komplexer Historie: Hohe Priorität. Hier liegt der größte Daten-Schatz: jahrelange Tagesdaten, Search-Term-Reports, Reach-Frequency aus YouTube-Kampagnen. Wer das nicht sichert, verliert mit dem Cutoff im Juni eine schwer rekonstruierbare Daten-Grundlage für Bid-Modelle, Saisonalitäts-Analysen und Audits.

Branchenspezifisch besonders betroffen: Saisonale Geschäfte (Reisen, Mode, Geschenke) mit klaren YoY-Mustern, die auf granularen Daten beruhen. Bei Konten mit kurzen Konversionspfaden (Lead-Gen für lokale Dienstleister) ist der Verlust überschaubar, weil weniger lange historische Vergleiche nötig sind.

Was du bis 1. Juni 2026 sichern solltest

Drei Datensätze sind aus meiner Sicht prioritär:

1. Reach- und Frequency-Reports (akut, weil 3-Jahre-Cutoff der engste ist):

• Pro Kampagne und Asset Group: Unique Users, Average Frequency, 7-Day und 30-Day Frequency, Frequency-Distribution-Buckets (1+, 2+, 3+, 4+, 5+, 10+)
• Auf maximal verfügbarem Zeitraum exportieren
• Relevant primär für Display und YouTube (beide gibt es lange genug, dass mehrjährige Reach-Daten existieren). Performance Max ist erst Ende 2021 GA gegangen, Demand Gen Ende 2023; bei diesen Kampagnen-Typen gibt es schlicht noch keine relevant alten Daten, die durch den 3-Jahre-Cutoff verloren gehen

2. Daily Performance Reports rückwirkend bis Account-Start (37-Monate-Cutoff):

• Pro Kampagne und Ad Group: Impressionen, Klicks, Cost, Conversions, Conversion Value, CTR, CPC, CPA
• Search Terms mit Tages-Granularität, sofern verfügbar
• Pro Geräte-Typ, Geo-Segment, Tageszeit (sofern für Audits gebraucht)

3. Weekly Search Terms Reports (37-Monate-Cutoff):

• Pro Kampagne: alle gematchten Suchanfragen mit Impressionen, Klicks, Conversions
• Wichtig für Negative-Keyword-Workflows und Keyword-Erweiterungen, siehe Negative Keywords in Google Ads

Monatliche und jährliche Aggregate brauchst du nicht zu exportieren. Die behalten ihre 11-Jahre-Frist und decken Trend-Vergleiche auf Monatsbasis automatisch ab.

Wie du das technisch löst

Drei realistische Optionen, sortiert nach Aufwand:

Option A: Manueller CSV-Export aus dem Google Ads UI

• Pro Konto und pro Bericht in der UI auf “Herunterladen” klicken
• Vorteil: kein technisches Setup, klappt sofort
• Nachteil: bei mehreren Konten und vielen Berichten enormer Zeitaufwand. Ist mehr für Einzelkonten geeignet, nicht für Agenturen oder Multi-Account-Setups

Option B: Google Ads Scripts mit Sheet-Export

• Ein Skript auf Account- oder MCC-Ebene zieht die Daten in Google Sheets
• Vorteil: läuft automatisiert, pro Konto einzeln konfigurierbar
• Nachteil: Sheet-Zellen-Limit bei großen Konten, Skripte müssen pro Account installiert werden, Scope-Limit für Reach-Frequency

Option C: Python-Skript mit Google Ads API direkt

• Skript mit Customer-IDs der zu sichernden Konten plus GAQL-Queries für die drei prioritären Datensätze. Schreibt nach CSV oder direkt in eine native BigQuery-Tabelle als Snapshot (nicht über Transfer-Service)
• Vorteil: skaliert über alle Konten gleichzeitig, einmaliges Setup, läuft unbeobachtet, BigQuery-Falle umgangen
• Nachteil: erfordert Google-Ads-API-Refresh-Token und einen Developer-Token mit Basic-Access

Bei mehreren betreuten Konten skaliert Option C deutlich besser, weil sich das einmalige Setup über alle Konten verteilt. Wer nur ein einzelnes Konto sichern muss und keine Programmier-Affinität hat, fährt mit Option A am schnellsten.

Empfehlung für die nächsten Wochen

Sinnvolle Reihenfolge unabhängig davon, ob ein einzelnes Konto oder ein Multi-Account-Setup gesichert wird:

1. Mai 2026: Reach- und Frequency-Reports zuerst, weil der 3-Jahre-Cutoff am akutesten ist. Maximaler verfügbarer Zeitraum.
2. Mai bis Mitte Juni 2026: Daily Performance Reports rückwirkend bis Account-Start, pro Kampagne und Ad Group.
3. Mitte Juni 2026: Weekly Search Term Reports, ebenfalls bis zum Account-Start.
4. Ab Juni 2026: Monatlicher Refresh-Job, der neue Daten in die Snapshot-Tabelle nachlädt, damit der Backup-Datenbestand mit dem 37-Monats-Fenster mitwandert.

Die Exporte sollten in einem klar dokumentierten Format abgelegt werden (Spalten-Schema, Zeitraum, Export-Datum), sodass auch in 5 Jahren noch nachvollziehbar ist, woher die Daten kommen.

FAQ

Muss ich als kleines KMU mit einem Konto wirklich exportieren?

Wenn dein Konto unter drei Jahre alt ist, hat es nichts zu verlieren. Wer ein bis zwei Jahre Historie hat, ist ebenfalls außer Reichweite des Cutoffs. Kritisch wird es ab einem Konto-Alter von etwa drei bis fünf Jahren mit aktiver Werbung. Wer YoY-Vergleiche auf Tagesebene macht oder Search-Term-Historien für Negative-Keyword-Pflege nutzt, sollte exportieren.

Reicht der BigQuery Data Transfer Service als Backup?

Nein, jedenfalls nicht ohne zusätzliche Absicherung. Der Transfer Service hört ab 1. Juni 2026 selbst auf, Daten älter als 37 Monate zu liefern. Plus die GA4-Backfill-Falle, die bestehende historische Tabellen überschreiben kann. Wer auf Transfer-Service-Sync angewiesen ist, sollte vor Juni 2026 entweder einen einmaligen Snapshot ziehen oder die Transfer-Konfiguration absichern.

Was passiert mit Audits oder Reports, die ältere Daten brauchen?

Nach dem Cutoff sind ältere Daten weder im UI noch über die API erreichbar. Audits, die zwingend granular auf Daten älter als 37 Monate zugreifen, sind nach Juni 2026 nicht mehr möglich, ohne dass die Daten vorher exportiert wurden. Saubere Audit-Vorbereitung gehört deshalb zur Pre-Cutoff-Aufgabenliste, siehe auch der Beitrag zu typischen Tracking-Fehlern, in dem historische Daten oft zur Diagnose herangezogen werden.

Werden Google Analytics 4 Daten in BigQuery auch gelöscht?

Eigene GA4-Properties unterliegen separaten Retention-Einstellungen in der GA4-Property selbst (typisch 2 oder 14 Monate für Event-Daten). Die hier diskutierte 37-Monats-Policy betrifft die API-Schnittstellen, die Google Ads Daten ausliefern. Wer eine eigene GA4-Property hat und in BigQuery exportiert, ist von den GA4-eigenen Retentionsregeln betroffen, nicht von der Google Ads Policy. Beide Themen sind verwandt aber unabhängig zu prüfen.

Was bedeutet das für meine Smart-Bidding-Daten?

Smart Bidding lernt auf aktuellen Daten, das Modell selbst greift nicht auf 37-Monats-Historie zurück. Aus Optimierungs-Sicht ändert sich nichts. Was sich ändert: deine eigene Möglichkeit, im Nachhinein zu prüfen, wie Smart Bidding über Jahre hinweg performt hat. Wer Bid-Strategie-Wechsel über mehrere Jahre dokumentiert, braucht den Export.

Sind Microsoft Ads und Meta auch betroffen?

Nein, jedenfalls nicht direkt. Microsoft Advertising hat eine eigene Retention-Policy (typisch 36 Monate für detailed reports), Meta ähnliche Werte. Die hier diskutierte Änderung ist Google-Ads-spezifisch und betrifft die Tochter-Produkte DV360 und CM360 ausdrücklich nicht. Für eine Multi-Plattform-Architektur sollte jede Plattform separat geprüft 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
• PPC.land: Google Ads cuts granular data access to 37 months starting June 2026
• Surfside PPC: Google Ads reduces data retention to 37 months starting June 2026
• Search Engine Roundtable: Google Ads Updates Data Retention Policy

Deine nächsten Schritte

Wer mehrere Konten betreut oder eines mit langer Historie hat, sollte die Export-Frist im Mai 2026 als Deadline behandeln. Drei konkrete Schritte für die nächsten Wochen:

1. Account-Inventur: Welche Konten sind älter als drei Jahre? Welche fahren YoY-Analysen auf granularer Ebene?
2. Prio-Datensätze identifizieren: Reach-Frequency zuerst (engster Cutoff), Daily Performance dann, Weekly Search Terms zum Abschluss
3. Export-Architektur wählen: CSV-Manuell für Einzelkonten, Skript-Lösung für mehrere Konten mit BigQuery-Snapshot als Backup

Wer bei der technischen Umsetzung Unterstützung braucht oder einen sauberen Audit vor dem Cutoff durchführen will, kann ein Erstgespräch buchen. Im Audit ist die Datenvorbereitung Teil der Standard-Routine.

→ Kostenloses Erstgespräch buchen