Retencja Google Ads: okresy przechowywania i planowanie backfillu

Dostępna historia raportu Google Ads zależy od rozdzielczości czasu. Od 1 czerwca 2026 r. udokumentowany limit 37 miesięcy dotyczy raportów godzinowych, dziennych i tygodniowych. Raporty miesięczne, kwartalne i roczne mogą sięgać do jedenastu lat wstecz. Zasięg i częstotliwość mają osobny limit trzech lat. Backfill, czyli pobranie starszych danych, wymaga rozróżnienia tych przypadków.

Retencja zależy od zapytania

Jedenaście lat dotyczy zagregowanych danych raportowych, a nie jedenastoletniego eksportu historii zmian przez API. Zasób change_event wymaga zakresu z ostatnich 30 dni i limitu najwyżej 10 000 wyników. Taki zbiór wymaga osobnego eksportu.

Starsze sumy miesięczne nie odtwarzają utraconego podziału dziennego. Dłuższa historia w Google Ads API jest dostępna także bez segmentu daty, jeżeli filtr obejmuje pełne miesiące. Znaczenie mają miesiące graniczne i zgodność pól. Dane sprzed granicy dziennej nie muszą więc zniknąć w każdej postaci.

GA4, transfery BigQuery, DV360 i CM360 mają własne zasady. Liczba z polityki Google Ads nie dowodzi okresu retencji innego produktu. Zasięgu nie należy również bezpośrednio sumować między dniami: ta sama osoba może pojawić się wielokrotnie.

Granica daty a potwierdzony zakres eksportu

Stały przykład wykorzystuje 10 sierpnia 2026 r.: odjęcie 37 miesięcy kalendarzowych daje 10 lipca 2023 r. Działające zadanie potrzebuje daty w strefie konta reklamowego, czyli customer.time_zone, zamiast przypadkowej strefy serwera. Końce miesięcy i lata przestępne wymagają arytmetyki kalendarzowej.

Brak wiersza z metrykami nie dowodzi luki eksportu. Raport Google Ads segmentowany według daty pomija wiersz, jeśli wszystkie wybrane metryki mają wartość zero. Dlatego każdy dzień, dla którego zapytanie zakończyło się w całości poprawnie, potrzebuje potwierdzenia zakresu, także przy zerowej liczbie wierszy. Potwierdzenie dotyczy konkretnego konta i definicji raportu.

Klucz raportu powinien identyfikować zasób API, pola, filtry, segmentację i wersję schematu. Zmienione zapytanie wymaga nowej wersji lub kontrolowanego odtworzenia. Samo MAX(window_end) pomija starsze luki, a bez klucza raportu miesza różne eksporty.

Ograniczony, uruchamialny planer okien

Poniższy przykład Pythona wymaga python-dateutil. Planuje najwyżej siedem dni od najstarszego niepotwierdzonego dnia dostępnego w oknie dziennym. completed_days zawiera wyłącznie potwierdzone dni tego samego konta i raportu. Starsze niepotwierdzone dni są zwracane osobno, również przy pierwszym uruchomieniu. Funkcja nie wywołuje API i nie zapisuje bazy danych.

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

expired_unconfirmed oznacza brak potwierdzenia udanego eksportu w tym rejestrze dla dnia poza granicą pobierania dziennego. Nadal mogą istnieć inne kopie lub starsze sumy miesięczne. To nie jest dowód trwałej utraty każdej kopii. Ponowne pobranie częściowo potwierdzonego okna jest poprawne, jeśli zapis bezpiecznie zastępuje cały zakres.

Spójny proces pobierania i zapisu

1. Przed wyborem okna uzyskać blokadę dla konta i raportu. W PostgreSQL można zablokować wcześniej utworzony wiersz stanu przez SELECT … FOR UPDATE w transakcji. Wszystkie uczestniczące procesy muszą respektować tę samą blokadę.
2. Odczytać całą odpowiedź API: wszystkie strony Search albo kompletny SearchStream. Błędy i przerwane strumienie nie mogą tworzyć potwierdzenia poprawnego zakresu. Sprawdzić pola, daty i przypisanie konta.
3. Atomowo zastąpić odpowiedni zakres raportu: usunąć stare wiersze wyłącznie tego konta, raportu i okna, wstawić nowe oraz potwierdzić każdy poprawnie odpytany dzień w rejestrze. Dotyczy to także dni bez wierszy.
4. Zatwierdzić dane i rejestr razem albo wycofać oba zapisy. Staging i właściwe klucze unikalne zapobiegają duplikatom i umożliwiają kontrolowane ponowienia.
5. Monitorować błędy, zatrzymanie postępu i przeterminowane niepotwierdzone dni. Alarm oparty na ostatnim udanym uruchomieniu wykrywa przestój jeszcze przed kolejnym poprawnym eksportem.

To kontrakt integracji. Uwierzytelnianie API, zgodne pola GAQL, schemat tabel i blokady wymagają implementacji w konkretnym eksporcie. Istniejący wrapper nie gwarantuje automatycznie kompletnej odpowiedzi ani idempotentnego zapisu. Długie pobieranie wewnątrz transakcji bazy wymaga odpowiednich limitów czasu; większe systemy mogą stosować dzierżawy z zabezpieczonym zatwierdzeniem.

Nadrabianie historii i późniejsze korekty

Zakres od 10 lipca 2023 r. do 9 sierpnia 2026 r. włącznie obejmuje 1127 dni, czyli 161 okien po najwyżej siedem dni. Jedno udane okno na godzinę dawałoby w idealnych warunkach około 6,7 dnia. To oszacowanie przepustowości, nie gwarancja czasu. Znaczenie mają rozmiar danych, limity, awarie i ponowienia.

Najstarsze zagrożone dni mają pierwszeństwo. Niedawno zakończone dni również wymagają ponownego pobierania, ponieważ metryki mogą ulec korekcie. Potwierdzony eksport nie oznacza niezmienności wartości. Pokazany planer uzupełnia tylko historyczne luki; aktualne korekty wymagają osobnego przebiegu.