{"id":9403,"date":"2026-08-12T20:00:00","date_gmt":"2026-08-12T18:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9403"},"modified":"2026-10-24T04:16:24","modified_gmt":"2026-10-24T02:16:24","slug":"limit-backfill-w-bigquery-data-transfer-i-zakres-google-signals-dwie-zmiany","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/limit-backfill-w-bigquery-data-transfer-i-zakres-google-signals-dwie-zmiany\/","title":{"rendered":"Limit backfill w BigQuery Data Transfer i zakres Google Signals: dwie zmiany w GA4 z czerwca 2026"},"content":{"rendered":"

Limit backfill w BigQuery Data Transfer i zakres Google Signals: dwie zmiany w GA4 z czerwca 2026<\/h2>\n

Dwie zmiany z czerwca 2026 r. wymagaj\u0105 osobnych kontroli. BigQuery Data Transfer Service ogranicza historyczne ponowne pobieranie danych kilku konektor\u00f3w raportowych do 37 miesi\u0119cy. Google Signals steruje obecnie w\u0119\u017cszym powi\u0105zaniem danych Analytics, natomiast Ads Consent Mode reguluje odpowiednie zbieranie i u\u017cycie danych reklamowych. Zielony status dashboardu nie wystarcza do oceny tych zmian.<\/p>\n

1. Limit backfill dotyczy konektor\u00f3w raportowych<\/h2>\n

Backfill ponownie \u0142aduje okres historyczny. Informacja o wydaniu BigQuery z 6 maja 2026 r. zapowiedzia\u0142a, \u017ce od 1 czerwca 2026 r. konektory Data Transfer Service dla Google Ads, Search Ads 360 i Google Analytics 4 przestaj\u0105 uzupe\u0142nia\u0107 backfill starszy ni\u017c 37 miesi\u0119cy. Dotyczy to tych konektor\u00f3w, w tym konektora raportowych danych GA4. Nie jest to nowy limit retencji natywnego eksportu GA4 events_* ani automatyczne usuwanie istniej\u0105cej historii BigQuery.<\/p>\n

Aktualny rejestr zmian rozr\u00f3\u017cnia wyniki: Google Ads i Search Ads 360 odrzucaj\u0105 dzienne uzupe\u0142nienia starsze ni\u017c 37 miesi\u0119cy b\u0142\u0119dem. Konektor Analytics ostrzega natomiast przed nadpisaniem historycznych partycji cz\u0119\u015bciowymi lub pustymi wynikami. <\/p>\n

Ograniczenie dziennych transfer\u00f3w nie dotyczy jednak wszystkich raport\u00f3w Google Ads. Dane miesi\u0119czne, kwartalne i roczne pozostaj\u0105 dost\u0119pne do 11 lat; wska\u017aniki zasi\u0119gu i cz\u0119stotliwo\u015bci maj\u0105 limit trzech lat. <\/p>\n

Bezpo\u015brednie zapytania do Google Ads API obejmuj\u0105ce okres sprzed ponad 37 miesi\u0119cy wymagaj\u0105 co najmniej miesi\u0119cznej segmentacji dat lub braku segmentacji oraz zakresu obejmuj\u0105cego pe\u0142ne miesi\u0105ce. Agregaty nie pozwalaj\u0105 odtworzy\u0107 szczeg\u00f3\u0142\u00f3w dziennych. Zakresy API odnosz\u0105 si\u0119 do customer.time_zone<\/code> konta emituj\u0105cego reklamy. Poni\u017cszy przyk\u0142ad UTC przedstawia obliczenia kalendarzowe i wymaga dostosowania do konkretnego konektora oraz zasad harmonogramu; nie stanowi kompletnego walidatora dowolnych zapyta\u0144 Google Ads API.<\/p>\n

\"Przed
Przed backfillem: kontrola zakresu i zachowanie migawki. Po zako\u0144czeniu: por\u00f3wnanie liczb i tre\u015bci. Nowy limit nie usuwa automatycznie istniej\u0105cej historii.<\/figcaption><\/figure>\n

2. Kontrola dat kalendarzowych przed zaplanowaniem<\/h2>\n

Granica przesuwa si\u0119 wraz z dat\u0105 planowania. Zapisany zakres wymaga ponownej kontroli bezpo\u015brednio przed wykonaniem, szczeg\u00f3lnie po op\u00f3\u017anieniu lub ponowieniu zadania. Poni\u017csza bramka w Pythonie u\u017cywa UTC i ogranicza ko\u0144ce miesi\u0119cy do ostatniego prawid\u0142owego dnia, podobnie jak BigQuery DATE_SUB z MONTH. Na przyk\u0142ad 31 marca 2026 r. minus 37 miesi\u0119cy daje 28 lutego 2023 r. GNU date mo\u017ce zamiast tego przenie\u015b\u0107 nieistniej\u0105c\u0105 dat\u0119 lutow\u0105 do marca; poprzednie obliczenie pow\u0142oki nie jest r\u00f3wnowa\u017cne.<\/p>\n

#!\/usr\/bin\/env python3\nimport calendar\nfrom datetime import date, datetime, timezone\nimport json\nimport re\nimport sys\n\ndef parse_day(value):\n    if not re.fullmatch(r"[0-9]{4}-[0-9]{2}-[0-9]{2}", value):\n        raise ValueError('Expected YYYY-MM-DD')\n    return date.fromisoformat(value)\n\ndef months_before(day, months):\n    month_index = day.year * 12 + day.month - 1 - months\n    year, zero_month = divmod(month_index, 12)\n    month = zero_month + 1\n    return date(year, month, min(day.day, calendar.monthrange(year, month)[1]))\n\ndef validate(start_text, end_text, as_of):\n    start, end = parse_day(start_text), parse_day(end_text)\n    boundary = months_before(as_of, 37)\n    if start > end:\n        raise ValueError('Start is after end')\n    if end > as_of:\n        raise ValueError('End is in the future')\n    if start < boundary:\n        raise ValueError(f'Start precedes 37-month boundary {boundary}')\n    return {'start': str(start), 'end': str(end),\n            'as_of_utc': str(as_of), 'boundary': str(boundary)}\n\ndef main():\n    if len(sys.argv) != 3:\n        print('Usage: guard.py START END', file=sys.stderr)\n        return 2\n    try:\n        result = validate(sys.argv[1], sys.argv[2], datetime.now(timezone.utc).date())\n    except ValueError as exc:\n        print(f'BLOCKED: {exc}', file=sys.stderr)\n        return 1\n    print(json.dumps(result))\n    return 0\n\nif __name__ == '__main__':\n    sys.exit(main())\n<\/code><\/pre>\n
Przyk\u0142ad sprawdza pe\u0142ne daty YYYY-MM-DD, pocz\u0105tek niep\u00f3\u017aniejszy od ko\u0144ca, brak przysz\u0142ego ko\u0144ca i granic\u0119 37 miesi\u0119cy. Wypisuje dozwolony zakres, ale nie uruchamia transferu. Harmonogram musi przerwa\u0107 dzia\u0142anie przy niezerowym kodzie i przekaza\u0107 do w\u0142a\u015bciwego polecenia dok\u0142adnie sprawdzone daty. Za\u0142o\u017cenie UTC i regu\u0142y planowania konkretnego konta wymagaj\u0105 weryfikacji blisko granicy; dodatkowy bufor mo\u017ce wykluczy\u0107 przypadki graniczne. Bramka dotyczy wskazanych konektor\u00f3w, a nie wszystkich rodzaj\u00f3w backfillu.<\/p>\n
3. Osobny punkt odtworzenia dla ka\u017cdego przebiegu<\/h2>\n
Przed ponownym \u0142adowaniem nadpisuj\u0105cym dane potrzebne s\u0105 jednoznacznie okre\u015blone cel i kopia. Poni\u017csze polecenie tworzy migawk\u0119 tabeli tylko do odczytu. CREATE TABLE AS SELECT tworzy\u0142oby natomiast materializowan\u0105 kopi\u0119. PROJECT, DATASET, TARGET_TABLE i RUN_ID s\u0105 symbolami zast\u0119pczymi; ka\u017cdy przebieg wymaga nowego RUN_ID. Migawka i \u017ar\u00f3d\u0142o musz\u0105 znajdowa\u0107 si\u0119 w tej samej lokalizacji. Udane zako\u0144czenie zadania kopii jest warunkiem rozpocz\u0119cia transferu.<\/p>\n
-- Replace identifiers; use a fresh RUN_ID for every backfill.\n-- Keep snapshot and source in the same location.\nCREATE SNAPSHOT TABLE `PROJECT.audit.TARGET__RUN_ID`\nCLONE `PROJECT.DATASET.TARGET_TABLE`;\n<\/code><\/pre>\n
Migawka obejmuje tabel\u0119 \u017ar\u00f3d\u0142ow\u0105, a nie zakres wybrany przez WHERE. Dane w buforze strumieniowym i pozosta\u0142e ograniczenia migawek wymagaj\u0105 kontroli dla konkretnej tabeli. Inne zapisy do badanego zakresu musz\u0105 zosta\u0107 wstrzymane lub uwzgl\u0119dnione podczas por\u00f3wnania. Istniej\u0105cych nazw migawek nie nale\u017cy nadpisywa\u0107. Odtworzenie do osobnej tabeli powinno zosta\u0107 prze\u0107wiczone przed rzeczywist\u0105 awari\u0105.<\/p>\n
4. Por\u00f3wnanie wszystkich dni i kontrola tre\u015bci<\/h2>\n
Po zako\u0144czeniu transferu zapytanie por\u00f3wnuje konkretn\u0105 migawk\u0119 z obecn\u0105 tabel\u0105. Pe\u0142na lista dat obejmuje r\u00f3wnie\u017c puste dni. Brak tabeli powoduje b\u0142\u0105d zapytania zamiast zera wierszy; brak grupy dla dnia w istniej\u0105cej tabeli rzeczywi\u015bcie oznacza zero w tym zapytaniu. Przyk\u0142ad zak\u0142ada kolumn\u0119 PARTITION_DATE typu DATE. Partycjonowanie wed\u0142ug czasu przyj\u0119cia lub znacznika czasu wymaga jawnie dopasowanego wyra\u017cenia daty.<\/p>\n
-- Run only after the transfer has completed successfully.\n-- @start_day and @end_day are DATE parameters from the validated range.\n-- PARTITION_DATE is a DATE column in this example.\nWITH days AS (\n  SELECT day FROM UNNEST(GENERATE_DATE_ARRAY(@start_day, @end_day)) AS day\n), before_counts AS (\n  SELECT PARTITION_DATE AS day, COUNT(*) AS n\n  FROM `PROJECT.audit.TARGET__RUN_ID`\n  WHERE PARTITION_DATE BETWEEN @start_day AND @end_day\n  GROUP BY day\n), after_counts AS (\n  SELECT PARTITION_DATE AS day, COUNT(*) AS n\n  FROM `PROJECT.DATASET.TARGET_TABLE`\n  WHERE PARTITION_DATE BETWEEN @start_day AND @end_day\n  GROUP BY day\n)\nSELECT d.day,\n       COALESCE(b.n, 0) AS rows_before,\n       COALESCE(a.n, 0) AS rows_after,\n       COALESCE(a.n, 0) - COALESCE(b.n, 0) AS delta,\n       CASE\n         WHEN COALESCE(b.n, 0) = 0 AND COALESCE(a.n, 0) = 0 THEN 'BOTH_EMPTY'\n         WHEN COALESCE(a.n, 0) < COALESCE(b.n, 0) THEN 'FEWER_ROWS'\n         WHEN COALESCE(a.n, 0) > COALESCE(b.n, 0) THEN 'MORE_ROWS'\n         ELSE 'SAME_COUNT_REQUIRES_CONTENT_CHECK'\n       END AS check_result\nFROM days d\nLEFT JOIN before_counts b USING (day)\nLEFT JOIN after_counts a USING (day)\nORDER BY d.day;\n<\/code><\/pre>\n
Mniejsza liczba wierszy wymaga wyja\u015bnienia; wi\u0119ksza liczba r\u00f3wnie\u017c jest zmian\u0105, a nie automatycznym sukcesem. R\u00f3wne liczby nie dowodz\u0105 identycznej tre\u015bci: usuni\u0119te rekordy i nowe duplikaty mog\u0105 wzajemnie wyr\u00f3wna\u0107 wynik. Nadal potrzebne s\u0105 kontrole kluczy biznesowych, istotnych metryk i wybranych pojedynczych rekord\u00f3w. Migawka powinna pozosta\u0107 do zako\u0144czenia walidacji i przewidzianego okna odtworzenia, zamiast znika\u0107 tylko dlatego, \u017ce liczba wierszy nie spad\u0142a.<\/p>\n
5. Google Signals i Consent Mode steruj\u0105 r\u00f3\u017cnymi elementami<\/h2>\n
Zgodnie z komunikatem Google o kontrolach danych od 15 czerwca 2026 r. ustawienie Signals w administracji Analytics i odpowiednie API steruj\u0105 wy\u0142\u0105cznie powi\u0105zaniem danych Analytics z informacjami o zalogowanych u\u017cytkownikach na potrzeby raportowania zachowa\u0144. Powi\u0105zana zmiana przenosi kontrol\u0119 cookies i identyfikator\u00f3w Google Ads zbieranych przez tag lub SDK Analytics do Ads Consent Mode. Dotyczy to tego zakresu danych reklamowych, a nie wszystkich danych Analytics.<\/p>\n
Typy zg\u00f3d pozostaj\u0105 osobne: ad_storage dotyczy reklamowych cookies lub identyfikator\u00f3w urz\u0105dze\u0144; analytics_storage dotyczy przechowywania analitycznego; ad_user_data dotyczy wysy\u0142ania danych u\u017cytkownik\u00f3w do reklamy internetowej; ad_personalization steruje reklam\u0105 spersonalizowan\u0105. Ustawienie Signals nie zast\u0119puje tych sygna\u0142\u00f3w. W zale\u017cno\u015bci od wdro\u017cenia podstawowego lub zaawansowanego odmowa przechowywania mo\u017ce nadal wsp\u00f3\u0142istnie\u0107 z pingami pomiarowymi bez cookies. Warto\u015b\u0107 denied nie oznacza uniwersalnie braku wszystkich \u017c\u0105da\u0144 sieciowych.<\/p>\n
6. Osobny zapis ustawie\u0144 i dowod\u00f3w pomiarowych<\/h2>\n
Inwentaryzacja dla us\u0142ugi mo\u017ce zapisywa\u0107 czas pobrania, identyfikator us\u0142ugi, stan Signals i \u017ar\u00f3d\u0142o obserwacji. Udokumentowane \u017c\u0105danie Admin API tylko do odczytu wymaga wa\u017cnego access tokena, zakresu analytics.readonly i dost\u0119pu do us\u0142ugi. PROPERTY_ID oraz ACCESS_TOKEN s\u0105 symbolami zast\u0119pczymi; \u017c\u0105danie GET nie zmienia ustawienia.<\/p>\n
GET \/v1alpha\/properties\/PROPERTY_ID\/googleSignalsSettings HTTP\/1.1\nHost: analyticsadmin.googleapis.com\nAuthorization: Bearer ACCESS_TOKEN\nAccept: application\/json\n<\/code><\/pre>\n
Odpowied\u017a ilustracyjna, a nie odczyt rzeczywistej us\u0142ugi:<\/p>\n
{\n  "name": "properties\/123456789\/googleSignalsSettings",\n  "state": "GOOGLE_SIGNALS_ENABLED",\n  "consent": "GOOGLE_SIGNALS_CONSENT_CONSENTED"\n}\n<\/code><\/pre>\n
Pole consent tego zasobu oznacza akceptacj\u0119 warunk\u00f3w Google Signals, a nie zgod\u0119 odwiedzaj\u0105cego witryn\u0119. Brak stanu lub warto\u015b\u0107 unspecified nie potwierdzaj\u0105 w\u0142\u0105czenia Signals. Nieudane \u017c\u0105dania musz\u0105 pozosta\u0107 widoczne jako b\u0142\u0119dy; zaplanowana inwentaryzacja nie powinna jedynie dopisa\u0107 b\u0142\u0119du i zg\u0142osi\u0107 sukcesu. Por\u00f3wnanie wymaga dw\u00f3ch udanych, datowanych obserwacji tej samej us\u0142ugi. Ten szablon \u017c\u0105dania nie implementuje automatycznej inwentaryzacji ani por\u00f3wnywania zmian.<\/p>\n
Wska\u017aniki zg\u00f3d wymagaj\u0105 osobnej definicji jednostki: zdarzenia, sesje i pojedyncze decyzje o zgodzie daj\u0105 r\u00f3\u017cne wyniki. W natywnym eksporcie GA4 pole privacy_info.ads_storage u\u017cywa Yes, No i Unset, a nie granted\/denied. Nieznane warto\u015bci nale\u017c\u0105 do osobnej kategorii. Zmiana wska\u017anika mo\u017ce wynika\u0107 ze struktury ruchu, zmian bannera lub wdro\u017ce\u0144; sam zwi\u0105zek czasowy z czerwcem nie dowodzi wp\u0142ywu Signals.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Czy time travel mo\u017ce zast\u0105pi\u0107 kopi\u0119?<\/h3>\n
Time travel w BigQuery mo\u017ce umo\u017cliwi\u0107 odtworzenie w skonfigurowanym oknie: domy\u015blnie siedem dni, z mo\u017cliwo\u015bci\u0105 ustawienia od dw\u00f3ch do siedmiu dni. Migawka mo\u017ce zachowa\u0107 punkt odtworzenia d\u0142u\u017cej. Koszty przechowywania migawki mog\u0105 wzrosn\u0105\u0107 po zmianie lub usuni\u0119ciu blok\u00f3w \u017ar\u00f3d\u0142owych; ma\u0142a zmiana logiczna mo\u017ce dotyczy\u0107 wi\u0119kszych blok\u00f3w fizycznych. Nie nale\u017cy zak\u0142ada\u0107 ani stale niskiego kosztu, ani nieograniczonego odtwarzania wstecz.<\/p>\n
Czy niezmieniony czas modyfikacji partycji dowodzi braku zmian danych?<\/h3>\n
Nie. Metadane INFORMATION_SCHEMA.PARTITIONS zapewniaj\u0105 przydatny kontekst, ale cz\u0119\u015b\u0107 zmian, w tym usuwanie rekord\u00f3w, mo\u017ce nie zosta\u0107 odzwierciedlona w last_modified_time. Zliczenia, kontrole tre\u015bci i rzeczywisty punkt odtworzenia s\u0142u\u017c\u0105 r\u00f3\u017cnym celom. Pojedyncze pole metadanych nie dowodzi kompletno\u015bci.<\/p>\n<\/div>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n