{"id":9368,"date":"2026-08-12T10:35:00","date_gmt":"2026-08-12T08:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9368"},"modified":"2026-10-24T04:15:28","modified_gmt":"2026-10-24T02:15:28","slug":"google-ads-datenaufbewahrung-37-monate-leistungsdaten","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-marketing-de\/google-ads-datenaufbewahrung-37-monate-leistungsdaten\/","title":{"rendered":"Google-Ads-Datenaufbewahrung: Fristen verstehen und Backfills planen"},"content":{"rendered":"

F\u00fcr Google-Ads-Exporte entscheidet die zeitliche Aufl\u00f6sung \u00fcber die verf\u00fcgbare Historie. Seit dem 1. Juni 2026 gilt die dokumentierte Grenze von 37 Monaten f\u00fcr st\u00fcndliche, t\u00e4gliche und w\u00f6chentliche Berichte. Monatliche, viertelj\u00e4hrliche und j\u00e4hrliche Auswertungen reichen bis zu elf Jahre zur\u00fcck. Reichweite und H\u00e4ufigkeit haben eine eigene Grenze von drei Jahren. Ein Backfill \u2013 das nachtr\u00e4gliche Nachladen \u00e4lterer Daten \u2013 muss diese Unterschiede ber\u00fccksichtigen.<\/p>\n

Aufbewahrung ist nicht f\u00fcr jede Abfrage gleich<\/h2>\n

Die elf Jahre beziehen sich auf gr\u00f6ber zusammengefasste Berichtsdaten, nicht auf einen elfj\u00e4hrigen Abruf des \u00c4nderungsverlaufs. Die API-Ressource change_event<\/code> verlangt einen Zeitraum innerhalb der letzten 30 Tage und h\u00f6chstens 10.000 Ergebnisse. Daf\u00fcr ist ein eigener Export n\u00f6tig.<\/p>\n

\u00c4ltere Monatswerte sind kein Ersatz f\u00fcr verlorene Tageswerte: Die Verteilung innerhalb eines Monats l\u00e4sst sich daraus nicht wiederherstellen. Die Google-Ads-API erlaubt f\u00fcr die l\u00e4ngere Historie auch Berichte ohne Datumssegment, sofern der Datumsfilter vollst\u00e4ndige Monate umfasst. Grenzmonate und zul\u00e4ssige Felder m\u00fcssen zur Abfrage passen. Daten vor der Grenze sind daher nicht pauschal vollst\u00e4ndig verschwunden.<\/p>\n

GA4, BigQuery-Transfers, DV360 und CM360 haben eigene Regeln. Eine Zahl aus der Google-Ads-Richtlinie belegt keine Aufbewahrungsfrist eines anderen Produkts. Ebenso ist Reichweite nicht beliebig \u00fcber Tage addierbar: Dieselbe Person kann an mehreren Tagen vorkommen.<\/p>\n

\"Aufbewahrungsgrenzen
Aufbewahrungsgrenzen nach Zeitaufl\u00f6sung; Exportabdeckung separat nachweisen.<\/figcaption><\/figure>\n

Datumsgrenze und tats\u00e4chliche Exportabdeckung trennen<\/h2>\n

Als festes Rechenbeispiel dient der 10. August 2026: 37 Kalendermonate zur\u00fcck ergibt den 10. Juli 2023. F\u00fcr laufende Jobs z\u00e4hlt das Datum in der Zeitzone des Werbekontos, also customer.time_zone<\/code>, statt der zuf\u00e4lligen Serverzeitzone. Monatsenden und Schaltjahre verlangen Kalenderarithmetik.<\/p>\n

Ein fehlender Datensatz in einer Kennzahlentabelle beweist keine Exportl\u00fccke. Nach Datum segmentierte Google-Ads-Berichte liefern keine Zeile, wenn alle ausgew\u00e4hlten Kennzahlen null sind. Deshalb braucht jeder erfolgreich vollst\u00e4ndig abgefragte Tag einen Abdeckungsnachweis, auch bei null Ergebniszeilen. Der Nachweis gilt nur f\u00fcr das konkrete Konto und die konkrete Berichtsdefinition.<\/p>\n

Ein geeigneter Berichtsschl\u00fcssel identifiziert API-Ressource, Felder, Filter, Segmentierung und Schemafassung. Eine ge\u00e4nderte Abfrage ben\u00f6tigt eine neue Version oder einen kontrollierten Neuaufbau. Ein einzelnes MAX(window_end)<\/code> \u00fcbersieht \u00e4ltere L\u00fccken und vermischt bei fehlendem Berichtsschl\u00fcssel unterschiedliche Exporte.<\/p>\n

Ein begrenzter, ausf\u00fchrbarer Fensterplaner<\/h2>\n

Das folgende Python-Beispiel ben\u00f6tigt python-dateutil<\/code>. Es plant h\u00f6chstens sieben Tage ab der \u00e4ltesten unbest\u00e4tigten, noch erreichbaren Stelle. completed_days<\/code> enth\u00e4lt ausschlie\u00dflich best\u00e4tigte Tage desselben Kontos und Berichts. \u00c4ltere unbest\u00e4tigte Tage werden getrennt zur\u00fcckgegeben \u2013 bereits beim ersten Lauf. Die Funktion ruft keine API auf und schreibt keine Datenbank.<\/p>\n

from datetime import date, timedelta\nfrom dateutil.relativedelta import relativedelta\n\ndef plan_window(today, oldest_wanted, completed_days, chunk_days=7):\n    if chunk_days < 1:\n        raise ValueError("chunk_days must be positive")\n    floor = today - relativedelta(months=37)\n    yesterday = today - timedelta(days=1)\n    completed = set(completed_days)\n    expired_unconfirmed = []\n    current = oldest_wanted\n    while current < floor and current <= yesterday:\n        if current not in completed:\n            expired_unconfirmed.append(current)\n        current += timedelta(days=1)\n    current = max(oldest_wanted, floor)\n    while current <= yesterday and current in completed:\n        current += timedelta(days=1)\n    window = None if current > yesterday else (\n        current, min(current + timedelta(days=chunk_days - 1), yesterday)\n    )\n    return window, expired_unconfirmed\n\nif __name__ == "__main__":\n    example_day = date(2026, 8, 10)\n    window, expired = plan_window(\n        example_day, date(2023, 7, 8), {date(2023, 7, 8)}\n    )\n    print(window)   # (2023-07-10, 2023-07-16)\n    print(expired)  # [2023-07-09], not proof that every other copy is lost\n<\/code><\/pre>\n
Das Ergebnis expired_unconfirmed<\/code> bedeutet: Au\u00dferhalb der t\u00e4glichen Abrufgrenze fehlt in diesem Register ein erfolgreicher Exportnachweis. Andere Sicherungen oder \u00e4ltere Monatswerte k\u00f6nnen trotzdem existieren. Das ist kein Beweis f\u00fcr unwiederbringlichen Verlust aller Daten. Ein teilweise bereits best\u00e4tigtes Fenster darf erneut geladen werden, wenn die Speicherung den ganzen Bereich sicher ersetzt.<\/p>\n
Abruf und Speicherung m\u00fcssen zusammenpassen<\/h2>\n
    \n
  1. Vor der Fensterwahl eine Sperre f\u00fcr Konto und Bericht erwerben. In PostgreSQL kann daf\u00fcr eine vorab angelegte Zustandszeile innerhalb einer Transaktion mit SELECT \u2026 FOR UPDATE<\/code> gesperrt werden. Alle beteiligten L\u00e4ufe m\u00fcssen dieselbe Sperre beachten.<\/li>\n
  2. Die gesamte API-Antwort lesen: alle Seiten von Search<\/code> oder den vollst\u00e4ndigen SearchStream<\/code>. Fehler oder abgebrochene Streams d\u00fcrfen keinen erfolgreichen Abdeckungsnachweis erzeugen. Erwartete Felder, Datumsbereich und Kontozuordnung pr\u00fcfen.<\/li>\n
  3. Den betroffenen Berichtsbereich atomar ersetzen: alte Zeilen f\u00fcr genau dieses Konto, diesen Bericht und dieses Fenster l\u00f6schen, neue Zeilen einf\u00fcgen und jeden erfolgreich abgefragten Tag im Abdeckungsregister best\u00e4tigen. Das schlie\u00dft Tage mit null Zeilen ein.<\/li>\n
  4. Daten und Register gemeinsam committen. Bei Fehlern gemeinsam zur\u00fcckrollen. Staging und geeignete eindeutige Schl\u00fcssel verhindern Dubletten und erlauben kontrollierte Wiederholung.<\/li>\n
  5. Fehler, Stillstand und unbest\u00e4tigte abgelaufene Tage \u00fcberwachen. Ein Alarm auf den letzten erfolgreichen Lauf erkennt einen Stillstand bereits vor dem n\u00e4chsten gelungenen Export.<\/li>\n<\/ol>\n
    Dieses Verfahren beschreibt den Integrationsvertrag. API-Anmeldung, freigegebene GAQL-Felder, Tabellenschema und Sperrstrategie m\u00fcssen im konkreten Export implementiert werden. Ein beliebiger bestehender Wrapper garantiert weder vollst\u00e4ndige Antworten noch idempotente Speicherung. Lange Abrufe innerhalb einer Datenbanktransaktion erfordern passende Zeitlimits; gr\u00f6\u00dfere Systeme k\u00f6nnen mit Leasing und abgesichertem Abschluss arbeiten.<\/p>\n
    Aufholen und laufende Korrekturen<\/h2>\n
    Vom 10. Juli 2023 bis einschlie\u00dflich 9. August 2026 sind es 1.127 Tage und damit 161 Fenster mit h\u00f6chstens sieben Tagen. Ein erfolgreiches Fenster pro Stunde entspr\u00e4che unter idealen Bedingungen ungef\u00e4hr 6,7 Tagen. Das ist eine Kapazit\u00e4tsrechnung, keine Laufzeitgarantie: Datenmenge, Quoten, Ausf\u00e4lle und Wiederholungen bestimmen den Betrieb.<\/p>\n
    \u00c4lteste gef\u00e4hrdete Tage erhalten Vorrang. Gleichzeitig braucht der Export einen Nachladebereich f\u00fcr k\u00fcrzlich abgeschlossene Tage, weil Kennzahlen nachtr\u00e4glich angepasst werden k\u00f6nnen. Ein einmal best\u00e4tigter Tag ist nicht f\u00fcr immer unver\u00e4nderlich. Der hier gezeigte Planer erledigt nur den historischen L\u00fcckenschluss; aktuelle Korrekturen ben\u00f6tigen einen eigenen Lauf.<\/p>\n
    \n
    Fragen und Antworten<\/h2>\n
    Gen\u00fcgt ein st\u00fcndlicher Cron-Eintrag?<\/h3>\n
    Nur mit eingerichteter Authentifizierung, \u00dcberwachung, Sperre gegen Parallelstarts und gepr\u00fcfter Speicherung. Ein Fenster entspricht nicht automatisch genau einem HTTP-Aufruf; Seitenabrufe und Wiederholungen k\u00f6nnen hinzukommen.<\/p>\n
    Welche Daten haben zuerst Priorit\u00e4t?<\/h3>\n
    Je Datensatz gilt die eigene Grenze. Reichweite und H\u00e4ufigkeit d\u00fcrfen nicht mit dem 37-Monate-Fenster f\u00fcr t\u00e4gliche Leistungsdaten geplant werden. Das Exportregister muss diese Berichte getrennt f\u00fchren.<\/p>\n
    Kann ein Warehouse die urspr\u00fcngliche Attribution neu berechnen?<\/h3>\n
    Ein aggregierter Leistungsbericht bewahrt seine gelieferten Kennzahlen. F\u00fcr eine unabh\u00e4ngige Neuberechnung der Attribution reichen solche Summen allein nicht; daf\u00fcr w\u00e4ren zus\u00e4tzliche geeignete Ereignisdaten und Annahmen erforderlich.<\/p>\n<\/div>\n
    \n
    Quellen<\/h2>\n