Dwie czerwcowe zmiany w analityce bez komunikatu o błędzie

Dwie zmiany w stosie analitycznym Google weszły w życie w czerwcu 2026 roku. Obie są udokumentowane, obie obowiązują na dzień 10.08.2026 i żadna nie daje o sobie znać w trakcie działania pipeline’u. Pierwsza zawęża to, co BigQuery Data Transfer Service pobiera podczas backfillu. Druga zawęża to, czym w rzeczywistości steruje ustawienie Google Signals w panelu administracyjnym Analytics. Łączy je nie tematyka, lecz sposób pojawienia się: brak nieudanego zadania, brak wyjątku w logu, brak wpisu w dashboardzie monitoringu. Pierwsza ujawnia się w momencie uruchomienia backfillu. Druga wychodzi na jaw wtedy, gdy ktoś zauważy, że przełącznik nie wywołuje już efektu, który wywoływał wcześniej.

1. Dwie zmiany, które weszły w życie w czerwcu bez komunikatu o błędzie

Większość zmian w stosie danych daje o sobie znać. Zmienia się schemat i zapytanie kończy się błędem. Endpoint zostaje wycofany, a klient otrzymuje kod statusu. Limit zostaje zaostrzony i zadanie się zatrzymuje. Takie zmiany są głośne, a właśnie ta głośność sprawia, że ich obsługa jest tania: wychwytuje je monitoring, który już istnieje, i ktoś czyta komunikat.

Dwie czerwcowe zmiany należą do innej kategorii. W obu przypadkach system działa dalej. Zadania kończą się powodzeniem, ustawienia nadal można przełączać, dashboardy nadal się renderują. Zmiana ujawnia się wyłącznie w treści danych albo w znaczeniu wartości konfiguracyjnej, a żadne z tych dwojga nie jest objęte typowym alertowaniem.

• BigQuery Data Transfer Service: od 01.06.2026 konektory dla Google Ads, Search Ads 360 i Google Analytics 4 nie zasilają już przebiegów backfill danymi starszymi niż 37 miesięcy. Dokumentacja podaje, że takie przebiegi zwracają niekompletne lub puste wyniki i mogą nadpisać istniejącą kompletną historię.
• Google Signals: od 15.06.2026 ustawienie Google Signals w panelu administracyjnym Analytics oraz Google Signals API sterują wyłącznie powiązaniem danych Analytics z informacjami od zalogowanych użytkowników na potrzeby raportowania behawioralnego. Kontrola nad samymi danymi leży po stronie Consent Mode, konkretnie po stronie parametru ad_storage.

Dalsza część artykułu traktuje je jako dwa przypadki tego samego problemu operacyjnego: udokumentowanej zmiany, której skutek staje się widoczny dopiero po celowym sprawdzeniu. Rozdziały 2 do 4 dotyczą limitu transferu oraz zabezpieczenia, które można umieścić przed backfillem. Rozdziały 5 i 6 dotyczą zmiany w Signals oraz inwentaryzacji utrwalającej stan bieżący, zanim okaże się potrzebny.

2. Granica 37 miesięcy w BigQuery Data Transfer Service

Wpis pojawił się w notatkach o wydaniu BigQuery 06.05.2026 i wszedł w życie 01.06.2026. Dotyczy trzech konektorów BigQuery Data Transfer Service: Google Ads, Search Ads 360 oraz Google Analytics 4. Przebiegi backfill na tych konektorach nie są już zasilane danymi starszymi niż 37 miesięcy. Jako powód podano zmianę reguł retencji po stronie Google Ads.

Dla utrzymania hurtowni zbudowanej na tych transferach znaczenie mają dwie granice tej zmiany. Dane już przeniesione pozostają nietknięte — dopóki nie przejdzie po nich backfill. 37 miesięcy to okno przesuwne, a nie stała data graniczna, więc zakres, który w czerwcu mieścił się jeszcze w granicy, wraz z upływem miesięcy wychodzi poza nią. Definicja backfillu zapisana w runbooku rok temu i pozostawiona bez zmian w pewnym momencie przekroczy zatem granicę, choć w samej definicji nic się nie zmieni.

Kilku szczegółów dokumentacja nie obejmuje i nie należy ich zakładać. Nie jest udokumentowane, jaki kod błędu lub komunikat — o ile w ogóle jakiś — towarzyszy takiemu przebiegowi. Nie jest udokumentowane, czy konsola Cloud pokazuje ostrzeżenie przy wprowadzeniu zakresu wykraczającego poza granicę. Nie jest udokumentowane, czy operację da się później cofnąć. Zabezpieczenia nie da się więc oprzeć na sygnale z usługi; musi opierać się na zakresie, który wchodzi, i na wierszach, które wychodzą.

3. Dlaczego backfill może zastąpić kompletną historię

Istotą tej zmiany nie jest sama granica. Limit zasięgu wstecz konektora byłby niedogodnością z oczywistym obejściem: zachowaniem archiwum, które już istnieje. Istotą jest druga połowa udokumentowanego zachowania — przebieg zwracający niekompletne lub puste wyniki może nadpisać historię, która była kompletna.

Prowadząca do tego sekwencja jest całkiem zwyczajna. Hurtownia przechowuje cztery lata danych z transferu. Późna korekta, zmiana schematu albo podejrzenie luki skłaniają do ponownego uruchomienia dla starszego okna. Backfill zostaje zaplanowany z zakresem dat sięgającym — w całości lub częściowo — poza 37 miesięcy. Przebieg kończy się powodzeniem. Partycje w obrębie okna zostają nadpisane tym, co dostarczył konektor, a to, co konektor dostarczył dla części wykraczającej poza granicę, jest niekompletne lub puste. Nic w tym łańcuchu nie wymaga błędu w samym żądaniu; to samo żądanie zadziałałoby jeszcze w maju.

To właśnie odróżnia ponowne uruchomienie od pierwszego ładowania. Pierwsze ładowanie do pustego zakresu może wyłącznie dodawać. Ponowne uruchomienie na istniejącym zakresie zastępuje, a zastąpienie jest bezpieczne tylko wtedy, gdy źródło jest co najmniej tak kompletne jak cel. Od 1 czerwca to założenie nie obowiązuje już dla objętych zmianą konektorów poza granicą 37 miesięcy, co zmienia rutynową operację w taką, do której trzeba dopiąć warunek wstępny.

Ponieważ dokumentacja nie opisuje ścieżki cofnięcia, praktyczna konsekwencja jest taka, że sprawdzenie musi nastąpić przed przebiegiem, a kopia musi istnieć przed przebiegiem. Odzyskanie danych po fakcie zależy wyłącznie od tego, co zachowała sama hurtownia.

4. Zabezpieczenie przed przebiegiem: sprawdzenie granicy, spis wierszy, kopia

Zabezpieczenie składa się z trzech części, a każda jest na tyle drobna, że mieści się przed istniejącym krokiem backfillu. Wszystkie zapisane poniżej wielkimi literami identyfikatory są symbolami zastępczymi dla projektu, zbioru danych, tabeli i kolumny daty w hurtowni, której dotyczy przebieg; nazwy kolumn nie są narzucone przez usługę i odpowiadają temu, czego już używa tabela docelowa.

Pierwsza część porównuje żądany zakres z granicą przesuwną. Odpowiada na jedno pytanie — czy jakakolwiek część tego okna wykracza poza 37 miesięcy — i odpowiada na nie na podstawie kalendarza, a nie odpowiedzi, którą usługa może przesłać albo nie.

-- PROJECT, DATASET, TARGET_TABLE i PARTITION_DATE to symbole zastepcze.
DECLARE backfill_start DATE DEFAULT DATE '2022-01-01';
DECLARE backfill_end   DATE DEFAULT DATE '2022-06-30';
DECLARE earliest_supported DATE DEFAULT DATE_SUB(CURRENT_DATE(), INTERVAL 37 MONTH);

SELECT
  backfill_start,
  backfill_end,
  earliest_supported,
  backfill_start < earliest_supported AS starts_before_boundary,
  backfill_end   < earliest_supported AS ends_before_boundary,
  DATE_DIFF(earliest_supported, backfill_start, DAY) AS days_outside;

To samo porównanie należy umieścić w warstwie wyzwalającej przebieg, tak aby okno spoza zakresu zatrzymywało zadanie, zamiast jedynie wytwarzać wiersz w zbiorze wyników. Bramka w shellu utrzymuje decyzję przy schedulerze, a nie wewnątrz hurtowni.

#!/usr/bin/env bash
set -euo pipefail

START="2022-01-01"
END="2022-06-30"
BOUNDARY="$(date -u -d '37 months ago' +%F)"

if [[ "$START" < "$BOUNDARY" ]]; then
  echo "range starts $START, boundary is $BOUNDARY - backfill not started" >&2
  exit 1
fi

# osiagane tylko wtedy, gdy cale okno miesci sie w granicy
# ./run_backfill.sh "$START" "$END"

Druga część to spis wierszy w podziale na dni, wykonany przed przebiegiem i ponownie po nim. Nie zależy od żadnego komunikatu z usługi i uwidacznia zastąpienie pustymi wynikami jako liczbę, a nie jako przypuszczenie. Zapisanie obu faz w tej samej tabeli audytowej ogranicza porównanie do jednego zapytania.

CREATE TABLE IF NOT EXISTS `PROJECT.audit.transfer_row_census` (
  captured_at TIMESTAMP,
  phase STRING,
  day DATE,
  row_count INT64
);

INSERT INTO `PROJECT.audit.transfer_row_census`
SELECT CURRENT_TIMESTAMP(), 'before', PARTITION_DATE, COUNT(*)
FROM `PROJECT.DATASET.TARGET_TABLE`
WHERE PARTITION_DATE BETWEEN DATE '2022-01-01' AND DATE '2022-06-30'
GROUP BY PARTITION_DATE;

-- po przebiegu to samo polecenie z phase = 'after', a nastepnie:
SELECT
  b.day,
  b.row_count AS rows_before,
  IFNULL(a.row_count, 0) AS rows_after,
  IFNULL(a.row_count, 0) - b.row_count AS delta
FROM `PROJECT.audit.transfer_row_census` b
LEFT JOIN `PROJECT.audit.transfer_row_census` a
  ON a.day = b.day AND a.phase = 'after'
WHERE b.phase = 'before'
  AND IFNULL(a.row_count, 0) < b.row_count
ORDER BY delta;

Trzecia część to kopia. Skoro dokumentacja nic nie mówi o cofnięciu takiego przebiegu, jedyną pewną drogą powrotu jest kopia objętego zakresu wykonana wtedy, gdy był jeszcze kompletny. Wystarczy tabela migawkowa nazwana od przebiegu i jego daty; można ją usunąć, gdy spis nie wykaże ujemnej delty.

CREATE TABLE `PROJECT.DATASET.TARGET_TABLE__pre_backfill_20260810` AS
SELECT *
FROM `PROJECT.DATASET.TARGET_TABLE`
WHERE PARTITION_DATE BETWEEN DATE '2022-01-01' AND DATE '2022-06-30';

Trzy kroki, wszystkie po stronie hurtowni, żaden nie zależy od sygnału, którego wysyłanie przez usługę nie jest udokumentowane. Wartość niesie kolejność: sprawdzenie granicy, spis, kopia, a potem przebieg.

5. Od 15 czerwca Google Signals steruje mniejszym zakresem

Druga zmiana jest mniejsza w kodzie, a większa w interpretacji. Od 15.06.2026 ustawienie Google Signals w panelu administracyjnym Analytics oraz Google Signals API regulują tylko jedno: czy dane Analytics są powiązywane z informacjami od zalogowanych użytkowników na potrzeby raportowania behawioralnego. Kontrola nad samymi danymi leży teraz po stronie Consent Mode, konkretnie po stronie parametru ad_storage. Opis znajduje się na stronie pomocy Google Analytics 17016975, pobranej 10.08.2026.

Konsekwencją operacyjną jest przesunięcie tego, która powierzchnia odpowiada na dane pytanie. Na pytanie o powiązanie z zalogowaniem w raportowaniu behawioralnym odpowiada ustawienie Signals. Na pytanie o dane źródłowe odpowiada konfiguracja zgód po stronie zbierania. Dokument konfiguracyjny, wewnętrzna strona wiki albo opis przygotowany dla klienta przed 15 czerwca może nadal przedstawiać przełącznik Signals jako regulujący drugie z tych pytań, a nic w interfejsie nie oznacza takiego opisu jako nieaktualnego.

Kilka kwestii dotyczących tej zmiany nie jest udokumentowanych i warto nazwać je otwartymi, zamiast je szacować. Strona pomocy nie zawiera daty publikacji, więc dokładnego momentu, w którym opis został zmieniony, nie da się z niej odczytać. Nie wymienia efektów wolumenowych, więc żadne twierdzenie o tym, jak przesuwają się liczby w raportach, nie znajduje oparcia w źródle. Nie mówi też nic o istniejących listach odbiorców, więc status list zbudowanych w czasie, gdy ustawienie miało szerszy zakres, również nie został tam poruszony. Każda z tych kwestii jest pytaniem do konkretnych usług, a nie pytaniem, na które odpowiada dokumentacja.

6. Inwentaryzacja dla każdej usługi i to, co pozostaje otwarte

Bez opuszczania udokumentowanego gruntu można wykonać inwentaryzację: zapisać bieżący stan Signals dla każdej usługi, zachować ten zapis i osobno sprawdzać w raportowaniu wskaźniki zgód ad_storage. Powstaje w ten sposób opatrzona datą linia bazowa, czyli to, czego wymagać będzie każde późniejsze pytanie o różnicę.

Google Signals API jest wymienione w dokumentacji jako jedna z dwóch powierzchni sterujących, ale nazwy endpointów, pola żądań ani schematy odpowiedzi nie są tu ustalone. Poniższy skrypt pozostawia więc samo wywołanie API za funkcją-zaślepką, do uzupełnienia zgodnie z dokumentacją API dla używanej biblioteki klienckiej; rozpisana jest ta część, która odpowiada za utrwalanie i porównanie, bo to w niej tkwi wartość inwentaryzacji.

import csv
import datetime

# Zaslepka: implementacja w oparciu o Google Signals API i uzywana
# biblioteke kliencka. Zwraca pole stanu udostepniane przez to API.
def fetch_signals_state(property_id: str):
    raise NotImplementedError("fill in against the API reference")

PROPERTIES = ["PROPERTY_ID_1", "PROPERTY_ID_2"]   # symbole zastepcze
OUT = "signals_inventory.csv"

captured_at = datetime.datetime.now(datetime.timezone.utc).isoformat()

with open(OUT, "a", newline="", encoding="utf-8") as fh:
    writer = csv.writer(fh)
    for property_id in PROPERTIES:
        try:
            state = fetch_signals_state(property_id)
            writer.writerow([captured_at, property_id, state, ""])
        except Exception as exc:                  # zapisywane, nie pomijane
            writer.writerow([captured_at, property_id, "", repr(exc)])

Drugą połowę inwentaryzacji stanowi strona zgód. Sposób przechowywania stanu ad_storage różni się w zależności od wdrożenia — może znajdować się w tabeli eksportu, w logu po stronie zbierania albo w tabeli utrzymywanej przez platformę zgód — więc nazwy tabeli i kolumn poniżej są symbolami zastępczymi dla tego, co hurtownia już zawiera. Zapytanie zwraca wskaźnik dzienny, czyli formę, w której przesunięcie na przełomie czerwca w ogóle byłoby czytelne.

-- CONSENT_TABLE, DAY_COLUMN i AD_STORAGE_COLUMN to symbole zastepcze
-- dla kolumn, w ktorych hurtownia zapisuje stan zgody.
SELECT
  DAY_COLUMN AS day,
  COUNTIF(AD_STORAGE_COLUMN = 'granted') AS granted,
  COUNT(*) AS total,
  SAFE_DIVIDE(COUNTIF(AD_STORAGE_COLUMN = 'granted'), COUNT(*)) AS granted_rate
FROM `PROJECT.DATASET.CONSENT_TABLE`
WHERE DAY_COLUMN BETWEEN DATE '2026-05-01' AND CURRENT_DATE()
GROUP BY day
ORDER BY day;

Czego inwentaryzacja nie dostarcza, to wyjaśnienie. Wskaźnik, który przesuwa się na przełomie czerwca, może odzwierciedlać konfigurację zgód, sezonowość, strukturę ruchu albo wdrożenie na stronie. Dokumentacja nie wymienia efektów wolumenowych, więc przypisanie takiego ruchu zmianie w Signals wykraczałoby poza źródło. Cel zapisu jest węższy i trwalszy: utrwala opatrzony datą stan dla każdej usługi i oddziela pytanie o to, czym steruje ustawienie, od pytania o to, co pokazują dane.

Podsumowanie

• Granica transferu: od 01.06.2026 konektory BigQuery Data Transfer Service dla Google Ads, Search Ads 360 i Google Analytics 4 nie zasilają już przebiegów backfill danymi starszymi niż 37 miesięcy. Jako powód podano zmianę reguł retencji w Google Ads.
• Część o największych skutkach: dokumentacja podaje, że takie przebiegi zwracają niekompletne lub puste wyniki i mogą nadpisać istniejącą kompletną historię. Dane już przeniesione pozostają nietknięte, dopóki nie przejdzie po nich backfill.
• Nieudokumentowane: jaki kod błędu lub komunikat się pojawia, czy interfejs ostrzega i czy operację da się cofnąć. Zabezpieczenie opiera się więc na żądanym zakresie, spisie wierszy przed i po oraz na kopii wykonanej wcześniej.
• Zakres Signals: od 15.06.2026 ustawienie Signals i Google Signals API sterują wyłącznie powiązaniem danych Analytics z informacjami o zalogowanych użytkownikach na potrzeby raportowania behawioralnego; kontrola nad samymi danymi leży po stronie Consent Mode i ad_storage.
• Otwarte po tej stronie: strona pomocy nie zawiera daty publikacji, nie wymienia efektów wolumenowych i nie mówi nic o istniejących listach odbiorców. Opatrzona datą inwentaryzacja dla każdej usługi utrwala stan; nie wyjaśnia ruchów w liczbach.

Obie zmiany zostały udokumentowane przed wejściem w życie i obie pozostają niewidoczne w codziennej pracy do chwili, w której konkretne działanie lub konkretne pytanie wydobędzie je na wierzch. Praktyczna różnica między nimi polega na tym, kiedy sprawdzenie się opłaca: przy granicy transferu jest to moment przed rozpoczęciem backfillu, przy Google Signals — moment, w którym opis konfiguracji zostaje zapisany i opatrzony datą.