Google Ads kürzt granularen Datenzeitraum von 11 Jahren auf 37 Monate

Google kürzt den granularen Google Ads-Berichtszugang von 11 Jahren auf 37 Monate – eine Reduktion des nutzbaren historischen Zeitfensters für tägliche, stündliche und wöchentliche Performance-Daten um 72 Prozent. Die Kehrtwende kommt weniger als 18 Monate nach Einführung der 11-Jahres-Richtlinie und rund sieben Monate nachdem diese am 13. November 2024 in Kraft trat. Für Teams, die Attributionsmodelle, Jahresvergleichs-Benchmarks oder BigQuery-Pipelines auf der Grundlage eines langen Google Ads-Verlaufs aufgebaut haben, ist der 1. Juni 2026 nun eine harte Deadline.

Die Zahlen

Die Kernkürzung beträgt von 11 Jahren auf 37 Monate für granulare Daten, aber der tatsächliche Umfang der Änderung ist größer als eine einzelne Zahl vermuten lässt. Wie PPC Land berichtete, gilt die am 1. Mai 2026 im Google Ads Developer Blog veröffentlichte Ankündigung von Nadine Wang vom Advertising and Measurement APIs Team für die Google Ads API, Google Ads-Scripts, die Google Analytics Data API sowie den BigQuery Data Transfer Service. Eine parallele Hilfe-Center-Aktualisierung mit demselben Datum bestätigt, dass das Limit auch für die Google Ads-Oberfläche selbst gilt, nicht nur für Entwickler-Schnittstellen.

Die 37-Monats-Obergrenze gilt speziell für granulare Performance-Statistiken, die auf täglicher, stündlicher und wöchentlicher Ebene aufgeschlüsselt sind. Höhere Aggregationen auf monatlicher, quartalsweiser und jährlicher Granularitätsebene behalten weiterhin 11 Jahre. Die Richtlinie ist daher besser als gestaffeltes Aufbewahrungsmodell zu beschreiben denn als pauschale Kürzung: granular = 37 Monate, aggregiert = 11 Jahre. Diese Unterscheidung ist wichtig, weil sie die Art der Analyse einschränkt, die langfristig möglich ist – nicht aber die Existenz historischer Daten.

Eine Unterkategorie ist noch restriktiver. Reichweiten- und Frequenzmetriken – darunter eindeutige Nutzer, durchschnittliche Impressionsfrequenz pro Nutzer, die 7-Tage- und 30-Tage-Frequenzvarianten sowie Frequenzverteilungsschwellenwerte bei 1+, 2+, 3+, 4+, 5+ und 10+ – sind nur für drei Jahre zugänglich. Das ist rund einen Monat kürzer als das allgemeine 37-Monats-Fenster und kürzer als der 36-Monats-Kürzungspunkt der Google Analytics Data API.

Zum Vergleich: Facebook Ads bewahrt Daten für ungefähr 37 Monate auf, sodass Google faktisch auf eine Parität mit dem Niveau von Meta zusteuert. Die DV360 API und CM360 API hingegen sind unverändert bei einer Aufbewahrungsdauer von 24 Monaten. Innerhalb von Googles eigenem Ad-Stack gibt es nun drei unterschiedliche Aufbewahrungsmodelle: 24 Monate für DV360/CM360, 37 Monate granular plus 11 Jahre aggregiert für Google Ads sowie ein separates Drei-Jahres-Fenster für Reichweite und Frequenz. Die Quelle gibt nicht an, warum DV360 und CM360 ausgenommen wurden – was insofern relevant ist, als es darauf hindeutet, dass die Einschränkung spezifisch auf die Google Ads-Infrastruktur zurückzuführen ist und keine einheitliche Richtlinienentscheidung über Googles gesamtes Werbegeschäft darstellt.

Was wirklich neu ist

Das technische Verhalten ist der Punkt, an dem die Ankündigung konkret wird und auf den sich Engineering-Teams konzentrieren müssen. Die Google Ads API und Google Ads-Scripts geben ab dem 1. Juni 2026 einen harten DateRangeError.INVALID_DATE-Fehler zurück, wenn eine Abfrage granulare Segmente wie segments.date oder segments.week für Datumsbereiche anfordert, die älter als 37 Monate sind. Zukünftige API-Versionen sollen einen spezifischeren DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED-Fehler zurückgeben. Um ältere Daten abzurufen, müssen Abfragen segments.month, segments.quarter oder segments.year verwenden, und unsegmentierte historische Abfragen müssen exakt an Kalendermonatsgrenzen ausgerichtet sein, um zu funktionieren.

Die Google Analytics Data API verfolgt einen anderen Ansatz: stilles Abschneiden statt eines Fehlers. Wenn die Dimension date (oder datumsäquivalente Dimensionen wie day oder Day of week) in einem Bericht vorhanden ist, werden betroffene Metriken auf das aktuelle 36-Monats-Fenster gekürzt. Die betroffenen Metriken sind Advertiser Ad Cost, Clicks und Impressions. Berichte werden nur gekürzt, wenn sie alle drei betroffenen Metriken enthalten, einen Datumsbereich von 37 Monaten oder älter abdecken und die Datumsdimension einschließen.

Diese Divergenz ist das eigentlich neue operative Risiko. Eine API wirft einen Fehler; die andere schneidet stillschweigend ab. Eine Reporting-Pipeline, die Google Ads API-Daten mit Google Analytics Data API-Daten zusammenführt, könnte am Ende nicht übereinstimmende Zeilenzahlen aufweisen – ohne eine ausgelöste Exception, die auf die Diskrepanz hinweist. Alle, die einheitliche Dashboards auf Basis beider Oberflächen betreiben, sollten dies vor Juni 2026 prüfen.

Der BigQuery Data Transfer Service hat seine eigene Asymmetrie. Bei Google Ads- und Search Ads 360-Konnektoren hören Backfill-Läufe mit Daten, die älter als 37 Monate sind, auf, neue Daten zu befüllen – aber bereits in BigQuery-Tabellen übertragene Daten bleiben erhalten. Für GA4 hingegen überschreibt ein manuell ausgelöster Transfer für ein Berichtsdatum, das 37 Monate oder älter ist, vorhandene Daten in der BigQuery-Tabelle mit einem leeren Wert. Das ist ein destruktiver Vorgang, der durch eine Bedieneraktion ausgelöst wird, die zuvor das Gegenteil bewirkte. Die hier offene Frage – die die Quelle nicht beantwortet – ist, ob geplante (nicht manuelle) GA4-Transfers dasselbe Überschreibungsrisiko tragen oder ob das destruktive Verhalten auf manuelle Auslöser beschränkt ist. Der Schadensumfang hängt vollständig von dieser Unterscheidung ab.

Was im Performance Marketing bereits eingepreist ist

Performance-Marketing-Teams beobachten seit über einem Jahr, wie Google Aufbewahrungsfenster komprimiert, sodass die Richtung keine Überraschung ist. Im Februar 2025 setzte Google eine 540-Tage-Grenze für die Aufbewahrung von Customer Match-Daten in Google Ads und Display & Video 360, die ab dem 7. April 2025 gültig war. Im Juni 2025 kürzte Google AdMob die Daten im Ads Activity-Bericht auf sieben Jahre und reduzierte die Daten im User Activity-Bericht auf nur 90 Tage. Die 37-Monats-Obergrenze für Google Ads fügt sich in dieses Muster ein.

Was meines Erachtens noch nicht eingepreist ist, ist die Geschwindigkeit und die Kehrtwende. Google kündigte die 11-Jahres-Aufbewahrungsrichtlinie im Oktober 2024 an und setzte sie am 13. November 2024 in Kraft. Die 37-Monats-Obergrenze wurde weniger als sieben Monate nach dem Inkrafttreten dieser Richtlinie veröffentlicht. Teams, die das 11-Jahres-Versprechen für bare Münze genommen und auf Basis des dokumentierten Aufbewahrungsfensters langfristige Attributionsmodelle, Inputs für Marketing-Mix-Modellierungen oder Jahresvergleichs-Benchmarks aufgebaut haben, müssen diese Systeme nun in einem Zeitrahmen von rund 13 Monaten neu gestalten. Das ist eine ungewöhnlich kurze Halbwertszeit für eine kommunizierte Aufbewahrungsrichtlinie eines Anbieters von Googles Größe.

Der weitere unterschätzte Aspekt ist die Kostenverschiebung hin zu den Werbetreibenden. Wenn granulare Verlaufsdaten, die älter als 37 Monate sind, für Trendmodellierungen, MMM-Training oder Saisonalitätszerlegungen benötigt werden, geht die Speicherlast auf den Kunden über. Teams, die ihre Google Ads-Daten noch nicht in eigene Data Warehouses exportiert haben, haben nun ein 13-monatiges Fenster, um eine Export-Pipeline aufzubauen, bevor der lange Verlauf unwiederbringlich verloren geht.

Die Gegenperspektive

Die gängige Lesart ist, dass Google etwas wegnimmt. Die Gegenperspektive: Die meisten Werbetreibenden nutzen granulare Google Ads-Daten, die älter als 37 Monate sind, gar nicht, und die 11-Jahres-Richtlinie war stets eher eine Marketing-Geste als eine operative Realität. Tagesaktuelle Kampagnendaten aus dem Jahr 2022 haben im Jahr 2026 begrenzten analytischen Wert, weil sich Auktionsdynamiken, Zielgruppendefinitionen und sogar Kampagnentypen so stark verändert haben, dass Zeitpunktvergleiche bestenfalls rauschbehaftet sind.

Wenn das stimmt, ist die bedeutsamere Einschränkung nicht die 37-Monats-Obergrenze, sondern das Drei-Jahres-Fenster für Reichweite und Frequenz sowie das spezifische GA4 BigQuery-Überschreibungsrisiko. Diese betreffen aktive Workflows. Die granulare Obergrenze betrifft größtenteils Berichte, die niemand ausführt.

Ich würde das mit einem Vorbehalt einschränken: Die Quelle liefert keine Nutzungsstatistiken darüber, wie oft granulare Abfragen jenseits von 37 Monaten tatsächlich gestellt werden, sodass die Einschätzung hier qualitativer Natur ist. Hätte Google Zahlen, die ein bedeutsames langfristiges Abfragevolumen belegen, hätte man sie vermutlich genutzt, um die 11-Jahres-Richtlinie zu verteidigen, statt sie zurückzunehmen.

Wichtigste Erkenntnisse

• Granulares Google Ads-Reporting sinkt am 1. Juni 2026 von 11 Jahren auf 37 Monate, wobei Reichweiten- und Frequenzmetriken auf drei Jahre begrenzt sind und aggregierte monatliche/quartalsweise/jährliche Daten weiterhin für 11 Jahre aufbewahrt werden.
• Die Google Ads API wirft DateRangeError.INVALID_DATE, die Google Analytics Data API schneidet stillschweigend auf 36 Monate ab, und der GA4 BigQuery Data Transfer Service kann bei manuellen Backfill-Auslösern vorhandene historische Daten mit leeren Werten überschreiben. Drei verschiedene Fehlermodi auf drei Oberflächen.
• Das 37-Monats-Fenster bringt Google Ads in etwa auf Augenhöhe mit der Facebook Ads-Aufbewahrung, während DV360 und CM360 unter der unveränderten Google Ads API-Dokumentation bei 24 Monaten bleiben.
• Teams sollten alle Google Ads API-Abfragen, Google Ads-Scripts oder BigQuery Data Transfer-Pipelines prüfen, die Daten auf Tages- oder Wochenebene anfordern, die älter als 37 Monate sind, und vor dem 1. Juni 2026 auf segments.month, segments.quarter oder segments.year mit kalenderausgerichteten Bereichen migrieren.
• Testbare Prognose: Sollte diese Richtlinie bestehen bleiben, ist in Q4 2025 und Q1 2026 ein messbarer Anstieg bei benutzerdefinierten Google Ads-zu-BigQuery-Exportvolumen zu erwarten, da Werbetreibende versuchen, historische granulare Daten vor der Deadline zu sichern. Bleibt dieser Anstieg aus, bestätigt das die Gegenperspektive, dass niemand den langen Verlauf tatsächlich genutzt hat.