Google-Ads-Datenaufbewahrung: Fristen verstehen und Backfills planen

Für Google-Ads-Exporte entscheidet die zeitliche Auflösung über die verfügbare Historie. Seit dem 1. Juni 2026 gilt die dokumentierte Grenze von 37 Monaten für stündliche, tägliche und wöchentliche Berichte. Monatliche, vierteljährliche und jährliche Auswertungen reichen bis zu elf Jahre zurück. Reichweite und Häufigkeit haben eine eigene Grenze von drei Jahren. Ein Backfill – das nachträgliche Nachladen älterer Daten – muss diese Unterschiede berücksichtigen.

Aufbewahrung ist nicht für jede Abfrage gleich

Die elf Jahre beziehen sich auf gröber zusammengefasste Berichtsdaten, nicht auf einen elfjährigen Abruf des Änderungsverlaufs. Die API-Ressource change_event verlangt einen Zeitraum innerhalb der letzten 30 Tage und höchstens 10.000 Ergebnisse. Dafür ist ein eigener Export nötig.

Ältere Monatswerte sind kein Ersatz für verlorene Tageswerte: Die Verteilung innerhalb eines Monats lässt sich daraus nicht wiederherstellen. Die Google-Ads-API erlaubt für die längere Historie auch Berichte ohne Datumssegment, sofern der Datumsfilter vollständige Monate umfasst. Grenzmonate und zulässige Felder müssen zur Abfrage passen. Daten vor der Grenze sind daher nicht pauschal vollständig verschwunden.

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 über Tage addierbar: Dieselbe Person kann an mehreren Tagen vorkommen.

Datumsgrenze und tatsächliche Exportabdeckung trennen

Als festes Rechenbeispiel dient der 10. August 2026: 37 Kalendermonate zurück ergibt den 10. Juli 2023. Für laufende Jobs zählt das Datum in der Zeitzone des Werbekontos, also customer.time_zone, statt der zufälligen Serverzeitzone. Monatsenden und Schaltjahre verlangen Kalenderarithmetik.

Ein fehlender Datensatz in einer Kennzahlentabelle beweist keine Exportlücke. Nach Datum segmentierte Google-Ads-Berichte liefern keine Zeile, wenn alle ausgewählten Kennzahlen null sind. Deshalb braucht jeder erfolgreich vollständig abgefragte Tag einen Abdeckungsnachweis, auch bei null Ergebniszeilen. Der Nachweis gilt nur für das konkrete Konto und die konkrete Berichtsdefinition.

Ein geeigneter Berichtsschlüssel identifiziert API-Ressource, Felder, Filter, Segmentierung und Schemafassung. Eine geänderte Abfrage benötigt eine neue Version oder einen kontrollierten Neuaufbau. Ein einzelnes MAX(window_end) übersieht ältere Lücken und vermischt bei fehlendem Berichtsschlüssel unterschiedliche Exporte.

Ein begrenzter, ausführbarer Fensterplaner

Das folgende Python-Beispiel benötigt python-dateutil. Es plant höchstens sieben Tage ab der ältesten unbestätigten, noch erreichbaren Stelle. completed_days enthält ausschließlich bestätigte Tage desselben Kontos und Berichts. Ältere unbestätigte Tage werden getrennt zurückgegeben – bereits beim ersten Lauf. Die Funktion ruft keine API auf und schreibt keine Datenbank.

from datetime import date, timedelta
from dateutil.relativedelta import relativedelta

def plan_window(today, oldest_wanted, completed_days, chunk_days=7):
    if chunk_days < 1:
        raise ValueError("chunk_days must be positive")
    floor = today - relativedelta(months=37)
    yesterday = today - timedelta(days=1)
    completed = set(completed_days)
    expired_unconfirmed = []
    current = oldest_wanted
    while current < floor and current <= yesterday:
        if current not in completed:
            expired_unconfirmed.append(current)
        current += timedelta(days=1)
    current = max(oldest_wanted, floor)
    while current <= yesterday and current in completed:
        current += timedelta(days=1)
    window = None if current > yesterday else (
        current, min(current + timedelta(days=chunk_days - 1), yesterday)
    )
    return window, expired_unconfirmed

if __name__ == "__main__":
    example_day = date(2026, 8, 10)
    window, expired = plan_window(
        example_day, date(2023, 7, 8), {date(2023, 7, 8)}
    )
    print(window)   # (2023-07-10, 2023-07-16)
    print(expired)  # [2023-07-09], not proof that every other copy is lost

Das Ergebnis expired_unconfirmed bedeutet: Außerhalb der täglichen Abrufgrenze fehlt in diesem Register ein erfolgreicher Exportnachweis. Andere Sicherungen oder ältere Monatswerte können trotzdem existieren. Das ist kein Beweis für unwiederbringlichen Verlust aller Daten. Ein teilweise bereits bestätigtes Fenster darf erneut geladen werden, wenn die Speicherung den ganzen Bereich sicher ersetzt.

Abruf und Speicherung müssen zusammenpassen

1. Vor der Fensterwahl eine Sperre für Konto und Bericht erwerben. In PostgreSQL kann dafür eine vorab angelegte Zustandszeile innerhalb einer Transaktion mit SELECT … FOR UPDATE gesperrt werden. Alle beteiligten Läufe müssen dieselbe Sperre beachten.
2. Die gesamte API-Antwort lesen: alle Seiten von Search oder den vollständigen SearchStream. Fehler oder abgebrochene Streams dürfen keinen erfolgreichen Abdeckungsnachweis erzeugen. Erwartete Felder, Datumsbereich und Kontozuordnung prüfen.
3. Den betroffenen Berichtsbereich atomar ersetzen: alte Zeilen für genau dieses Konto, diesen Bericht und dieses Fenster löschen, neue Zeilen einfügen und jeden erfolgreich abgefragten Tag im Abdeckungsregister bestätigen. Das schließt Tage mit null Zeilen ein.
4. Daten und Register gemeinsam committen. Bei Fehlern gemeinsam zurückrollen. Staging und geeignete eindeutige Schlüssel verhindern Dubletten und erlauben kontrollierte Wiederholung.
5. Fehler, Stillstand und unbestätigte abgelaufene Tage überwachen. Ein Alarm auf den letzten erfolgreichen Lauf erkennt einen Stillstand bereits vor dem nächsten gelungenen Export.

Dieses Verfahren beschreibt den Integrationsvertrag. API-Anmeldung, freigegebene GAQL-Felder, Tabellenschema und Sperrstrategie müssen im konkreten Export implementiert werden. Ein beliebiger bestehender Wrapper garantiert weder vollständige Antworten noch idempotente Speicherung. Lange Abrufe innerhalb einer Datenbanktransaktion erfordern passende Zeitlimits; größere Systeme können mit Leasing und abgesichertem Abschluss arbeiten.

Aufholen und laufende Korrekturen

Vom 10. Juli 2023 bis einschließlich 9. August 2026 sind es 1.127 Tage und damit 161 Fenster mit höchstens sieben Tagen. Ein erfolgreiches Fenster pro Stunde entspräche unter idealen Bedingungen ungefähr 6,7 Tagen. Das ist eine Kapazitätsrechnung, keine Laufzeitgarantie: Datenmenge, Quoten, Ausfälle und Wiederholungen bestimmen den Betrieb.

Älteste gefährdete Tage erhalten Vorrang. Gleichzeitig braucht der Export einen Nachladebereich für kürzlich abgeschlossene Tage, weil Kennzahlen nachträglich angepasst werden können. Ein einmal bestätigter Tag ist nicht für immer unveränderlich. Der hier gezeigte Planer erledigt nur den historischen Lückenschluss; aktuelle Korrekturen benötigen einen eigenen Lauf.