Kontrola zmian analitycznych z sierpnia 2026: rozliczenia BigQuery, API Adobe i pomiar Shopify

W sierpniu 2026 r. trzy zmiany analityczne nastąpiły w krótkim odstępie: etykieta rozliczeniowa BigQuery 11 sierpnia, termin nowych stron podziękowania i statusu zamówienia Shopify dla planów bez Plus 26 sierpnia oraz wycofanie Adobe Analytics API 1.4 31 sierpnia. Terminy już minęły. Teraz istotne są działające raporty, zmigrowane integracje i potwierdzony pomiar. Historyczne dane rozliczeniowe nie znikają tylko dlatego, że zmieniła się etykieta.

1. BigQuery: wartość etykiety to nie nazwa SKU

Informacja o wydaniu BigQuery z 8 maja podaje wartości wprost: dla klucza goog-bq-feature-type wartość DATA_TRANSFER_SERVICE zmienia się na data_transfer_service. Od 11 sierpnia etykieta obejmuje także orkiestrację, ładowanie i scalanie w Data Transfer Service. Etykieta jest metadanymi pozycji rozliczeniowej, a SKU identyfikuje rozliczaną usługę. Komunikat nie potwierdza ogólnej zmiany nazwy SKU ani podwyżki cen.

Filtr dopasowujący wyłącznie dawną wartość wielkimi literami może pomijać nowe pozycje. Znaczenie ma również szerszy zakres etykiety: wzrost może wynikać z dodatkowo uwzględnianych operacji. Zamiana liter na małe nie zapewnia porównywalności wykonywanej pracy.

2. Historia rozliczeń nadal nadaje się do analizy

Wcześniej wyeksportowane i zachowane dane można odpytywać po terminie. Zapisany wcześniej wynik ułatwia odtworzenie kontroli, ale nie jest warunkiem każdego późniejszego porównania. Przy braku historii zakres pierwszego uzupełnienia zależy od zasad Cloud Billing i lokalizacji datasetu. Nie ma gwarancji dowolnie długiego eksportu wstecz; usuwanie i wygasanie tabel również mogą ograniczyć zachowaną historię.

Przykład korzysta ze schematu standardowego eksportu Cloud Billing. Nazwa tabeli jest symbolem zastępczym. Dwa równe okna UTC obejmują po 14 dni. EXISTS sprawdza etykiety i etykiety systemowe bez powielania pozycji rozliczeniowych przy wielu dopasowaniach. Waluty i SKU pozostają osobno; kredyty rozliczeniowe są pokazane obok kosztów.

-- Standard Cloud Billing export; table identifier is a placeholder.
-- Two 14-day UTC windows: [2026-07-28, 2026-08-11) and [2026-08-11, 2026-08-25).
WITH selected AS (
  SELECT DATE(b.usage_start_time, 'UTC') AS usage_day,
         b.currency, b.sku.id AS sku_id, b.sku.description AS sku_description,
         b.cost,
         COALESCE((SELECT SUM(c.amount) FROM UNNEST(b.credits) AS c), 0) AS credits
  FROM `PROJECT.DATASET.gcp_billing_export_v1_ACCOUNT` AS b
  WHERE b.usage_start_time >= TIMESTAMP('2026-07-28', 'UTC')
    AND b.usage_start_time < TIMESTAMP('2026-08-25', 'UTC')
    AND EXISTS (
      SELECT 1 FROM UNNEST(ARRAY_CONCAT(b.labels, b.system_labels)) AS label
      WHERE label.key = 'goog-bq-feature-type'
        AND LOWER(label.value) = 'data_transfer_service'
    )
)
SELECT IF(usage_day < DATE '2026-08-11', 'before', 'after') AS phase,
       currency, sku_id, sku_description,
       ROUND(SUM(cost), 2) AS cost_before_credits,
       ROUND(SUM(credits), 2) AS credits,
       ROUND(SUM(cost + credits), 2) AS cost_after_credits,
       COUNT(*) AS line_items,
       COUNT(DISTINCT usage_day) AS observed_usage_days
FROM selected
GROUP BY phase, currency, sku_id, sku_description
ORDER BY currency, sku_id, phase;

Rzeczywisty eksport musi zawierać ten klucz. Pozycje bez etykiety nie trafiają do wyboru, dlatego pusty wynik nie musi oznaczać zerowego kosztu. Także observed_usage_days nie potwierdza kompletności dostawy. Data użycia może różnić się od miesiąca faktury, a opóźnione pozycje lub korekty mogą zmienić późniejszy wynik. Zapis porównania wymaga zapytania i czasu pobrania danych.

Analiza przyczyn nadal wymaga tych samych transferów, porównywalnych wolumenów danych i częstotliwości uruchomień. Zapytanie pokazuje pozycje rozliczeniowe, ale nie mierzy zmiany ceny ani nie odtwarza pełnego wcześniejszego zakresu nowo oznaczanych operacji. Rzetelne porównanie wymaga dopasowania tych samych transferów i operacji w obu okresach. Dopiero wtedy można porównać ilość danych i liczbę uruchomień.

3. Adobe: migracja wywołań API i uwierzytelniania

Adobe potwierdza wycofanie Analytics API 1.4 i uwierzytelniania WSSE 31 sierpnia 2026 r. Zmiana obejmuje API raportowe i administracyjne. Data Insertion API do zbierania danych jest wyłączone z tej migracji; nie jest to ogólne wyłączenie zbierania danych Analytics.

Inwentaryzacja obejmuje zadania cykliczne, wersje SDK, endpointy i uwierzytelnianie. Poniższe wyszukiwanie wypisuje wyłącznie nazwy plików, ograniczając zbędne ujawnianie w logu terminala linii z możliwymi poświadczeniami. Trzy katalogi są symbolami zastępczymi. Błąd wyszukiwania pozostaje odróżnialny od ukończonego wyszukiwania bez trafień.

#!/usr/bin/env bash
# Source directories are placeholders; filenames only, no credential contents.
grep -rIilE 'wsse|/1\.4/|api[-_ ]?1\.4|api\.omniture\.com' ./src ./jobs ./config
status=$?
case "$status" in
  0) printf '%s\n' 'Potential legacy references found; manual review required.' ;;
  1) printf '%s\n' 'No textual matches; this is not migration proof.' ;;
  *) printf '%s\n' 'Search failed or was incomplete.' >&2; exit "$status" ;;
esac

Trafienie jest wskazówką, a nie dowodem aktywnego wywołania. Z kolei biblioteki pomocnicze pośrednio wywołujące API, automatycznie tworzone konfiguracje lub usługi zewnętrzne mogą ukrywać szukane ciągi. Migracja wymaga zatem również sprawdzenia rzeczywistych klientów i poprawnego porównania merytorycznego nowych raportów. Endpoint to adres, na który trafia żądanie API. API 2.0 zmienia te adresy, strukturę zapytań i dostępne funkcje administracyjne; sama podmiana numeru wersji nie wystarcza.

OAuth Server-to-Server jest udokumentowaną drogą dla integracji serwerowych bez udziału użytkownika. Przypisane profile produktu określają dostęp do danych; ważny token nie gwarantuje uprawnień do report suite. Awarie zadań nadal wymagają sprawdzenia konkretnych odpowiedzi HTTP, uprawnień i endpointów zamiast przypisywania każdego błędu dacie wycofania.

Legacy Report Builder ma osobny harmonogram. Dokumentacja podaje koniec cyklu życia w czerwcu 2026 r., brak kolejnych zaplanowanych dostaw skoroszytów od 1 lipca i termin migracji do 12 sierpnia. Po tej dacie Adobe odsyła po oryginalne skoroszyty do wsparcia.

4. Shopify: kontrola rzeczywistych stron i pikseli

Termin 26 sierpnia dla planów bez Plus dotyczy istniejących stron podziękowania i statusu zamówienia, a nie całego checkoutu. checkout.liquid był sposobem dostosowania dostępnym w Plus; dodatkowe skrypty i aplikacje ze starszymi integracjami wymagają osobnej inwentaryzacji. Sam upływ terminu nie dowodzi udanej migracji konkretnego sklepu.

Sekcja konfiguracji w Ustawienia → Checkout pokazuje rzeczywisty stan. Według Shopify pozostały komunikat o aktualizacji oznacza nadal przestarzałe strony. Spersonalizowany przewodnik migracji wskazuje istniejące dostosowania, zgodne i niezgodne aplikacje oraz tracking. Od 28 sierpnia 2025 r. sekcja dodatkowych skryptów jest tylko do odczytu; to wcześniejsza zmiana, odrębna od terminu stron w 2026 r.

Eksport motywu nie jest kompletną inwentaryzacją. Dodatkowe skrypty w ustawieniach checkoutu, piksele aplikacji i osobno zarządzany kontener tag managera wymagają własnej kontroli. Kontener tag managera grupuje skrypty pomiarowe i reguły ich uruchamiania. Pomaga tylko wtedy, gdy rzeczywiście ładuje się na nowej stronie potwierdzenia lub statusu zamówienia. Shopify przewiduje odpowiednie bloki, web pixels i app pixels do poszczególnych zadań; istniejący kod przeglądarkowy nie zawsze nadaje się do przeniesienia bez zmian.

Zakończenie prac wymaga kontrolowanego zakupu testowego z zapisem sytuacji zgód. Identyfikator zamówienia, waluta, wartość i zdarzenie zakupu muszą być widoczne w docelowym systemie; ponowne otwarcie statusu zamówienia nie powinno tworzyć niepożądanej drugiej konwersji. Zamówienie w Shopify i zmierzony zakup w platformie reklamowej są odrębnymi dowodami.