Rok z Google Ads API: dwa twarde terminy, reszta to okazja

W styczniu Google wydał v23 Ads API i ogłosił, że od tej pory nowa wersja będzie wychodzić co miesiąc. Przeczytałem to dwa razy. Od dwunastu lat piszę kod przeciwko temu API i przez większość tego czasu była to powolna powierzchnia, którą odwiedzałeś raz w roku, podbijałeś numer wersji i zapominałeś.

Potem zrobiłem to, czego nauczyły mnie te lata. Otworzyłem nasz kod w Lyncie i wyszukałem shoppingcontent.googleapis.com. Każde trafienie to skrypt, który umiera 18 sierpnia 2026, w dniu wyłączenia Content API for Shopping. Zaraz za nim czai się druga data. We wrześniu 2026 każda pozostała kampania dynamicznych reklam w wyszukiwarce automatycznie przechodzi na AI Max, czy tego chcesz, czy nie.

Te dwa zegary to obowiązki roku API Google. Cała reszta, którą wydała platforma, to okazja. Usługi AI dla kreacji, raportowanie sprzedaży na poziomie produktu, Merchant API wewnątrz Google Ads Scripts. Przejdę więc przez rok według priorytetów, najtwardszy termin najpierw. Przy każdej zmianie: co to jest, dlaczego dotyczy twojego konta i jaki dokładnie call, payload albo migrację uruchomić.

Niczego nie zostawię na etapie „powinieneś zmigrować”. Termin bez konkretnego artefaktu to tylko niepokój. Na każdym kroku dostajesz endpoint zastępujący stary, payload eksperymentu albo zapytanie GAQL, więc dokładnie widzisz, co zbudować, zanim data nadejdzie.

Termin numer jeden: Content API for Shopping umiera 18 sierpnia 2026

To najtwardsza data roku, więc idzie pierwsza.

Co się zmieniło. Content API for Shopping v2.1 gaśnie 18 sierpnia 2026. Jego następca, Merchant API v1, jest w GA od lipca 2025, a pośrednia v1beta już zgasła 28 lutego 2026. Stary monolit zastępują wyspecjalizowane pod-API. datasources, products, inventories, reports, notifications.

Dlaczego dotyczy twojego konta. Wszystko, co dotyka twojego feedu przez stare API, przestaje tego dnia działać. Przesyłanie feedów, feedy uzupełniające, etykiety niestandardowe, aktualizacje cen i stanów, odczyt odrzuceń. To nie jest „fajnie byłoby zmigrować”, to twarde cięcie. Jeśli dzienny skrypt synchronizuje ci ceny, 18 sierpnia zamilknie, a feed powoli odjedzie od rzeczywistości, aż ktoś zauważy utracony przychód. Widziałem ten scenariusz na prawdziwych kontach i kosztowna nigdy nie jest sama awaria, kosztowne są tygodnie, w których nikt jej nie zauważa.

Co zrobić. Przebuduj pod strukturę pod-API. Migracja jest mechaniczna. Zmienia się host, ścieżka i model zasobów, intencja zostaje. Oto przed i po dla najczęstszego calla ze wszystkich, upsertu produktu:

# OLD: Content API for Shopping v2.1 (off on 2026-08-18)
curl -X POST \
  "https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "title": "...", "price": {"value":"19.90","currency":"EUR"} }'

# NEW: Merchant API v1 (productInputs sub-API)
curl -X POST \
  "https://merchantapi.googleapis.com/products/v1/accounts/{account}/productInputs:insert?dataSource=accounts/{account}/dataSources/{ds}" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "productAttributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Hosty endpointów i podział na pod-API pochodzą z dokumentacji Google. Dokładne body żądania dla swojego zasobu sprawdź przed wdrożeniem w referencji Merchant API, bo zmieniły się nazwy pól, nie tylko URL.)

Cel jest szczerze lepszy od tego, co zastępuje, i właśnie tego nikt ci nie mówi. Trzy ulepszenia, które dziedziczysz za darmo dzięki migracji:

Jeśli od dawna zbierałeś się do utwardzenia narzędzi feedowych, wyłączenie jest tym wymuszonym impulsem. Przebuduj raz i wyjdź z czystszą obsługą błędów i mniejszą liczbą round-tripów, niż v2.1 kiedykolwiek pozwalało.

Termin numer dwa: dynamiczne reklamy we wrześniu 2026 stają się AI Max

Druga zmiana z datą i ta, która przetasowuje, ile kontroli trzymasz w rękach.

Co się zmieniło. AI Max for Search osiągnął GA 15 kwietnia 2026 po starcie bety w maju 2025. Od września 2026 Google automatycznie przenosi na AI Max wszystkie pozostałe DSA, automatycznie tworzone zasoby i przybliżone dopasowanie na poziomie kampanii. Potem nowej kampanii DSA już nie utworzysz. Ani w interfejsie, ani w Editorze, ani przez API.

Dlaczego dotyczy twojego konta. Układ brzmi: kontrola za wzrost. Z pełnym zestawem funkcji (dopasowanie haseł plus personalizacja tekstu plus ekspansja finalnych URL-i) Google raportuje około +7 % konwersji lub wartości konwersji względem samego dopasowania. W zamian oddajesz modelowi dopasowanie, teksty zasobów i wybór strony docelowej. Jeśli masz reguły brandowe albo compliance ręcznie wszyte w setup DSA, cicha wrześniowa zmiana może zacząć wysyłać ruch na URL-e i teksty, których nigdy nie zatwierdziłeś. Automatyzacja, której nie zmierzyłeś, to automatyzacja, której nie kontrolujesz.

Co zrobić. Nie czekaj, aż się okaże, co zmiana zrobi z twoimi liczbami. Zmierz to teraz. Google wydał barierki i haczyki pomiarowe w API równolegle z funkcją, więc możesz przełączenie przetestować A/B na własnych danych, zanim stanie się obowiązkowe:

Praktyczny ruch to ten ostatni. Utwórz eksperyment ADOPT_AI_MAX na swoich kontach i pozwól mu pochodzić. Deltę CPA i ROAS odczytasz, porównując kampanie z ramienia eksperymentu z kontrolą. Zwykłe zapytanie GAQL pokaże ci potem, co ekspansja bez słów kluczowych naprawdę dopasowała i zarobiła:

-- After ADOPT_AI_MAX runs: inspect automated expansion performance.
-- Calculate trial/control delta separately from the experiment arm campaigns.
SELECT campaign.name,
       metrics.conversions,
       metrics.conversions_value,
       metrics.cost_micros
FROM targeting_expansion_view
WHERE segments.date DURING LAST_30_DAYS

(ADOPT_AI_MAX to jeden z nowych typów eksperymentów z v24.1; targeting_expansion_view to zasób raportowy z v22. Dostępność pól sprawdź w release notes wersji, którą wołasz.)

Termin kroczący: wydanie co miesiąc

Nie pojedyncza data, tylko zegar, który tyka już bez przerwy.

Co się zmieniło. Od v23 (28 stycznia 2026) Google Ads API przeszło na miesięczny rytm wydań. Cztery wersje major rocznie plus miesięczne wersje minor, z rokiem wsparcia na każdą wersję major.

Dlaczego dotyczy twojego konta. Szybszy dostęp do funkcji i szybsze starzenie się. Wersje wygasają według opublikowanego kalendarza. v20 dobiega końca życia w czerwcu 2026, v21 w sierpniu, v22 w październiku. Miesięczny bump minor niczego nie psuje. Przegapiony sunset wersji major oznacza, że skrypty zaczynają zwracać błędy bez innego ostrzeżenia niż data w kalendarzu, którego nie obserwowałeś.

Co zrobić. Przypnij swoją wersję i pilnuj kalendarza sunsetów. Najtańszym ubezpieczeniem jest cykliczna kontrola, która wie, jaką wersję wołasz, i odzywa się około 60 dni przed wygaśnięciem. Całość to kilka linijek:

# Recurring guardrail: alert ~60 days before your pinned version sunsets.
from datetime import date

PINNED = "v22"                 # the version your client is pinned to
SUNSET = {"v20": "2026-06-01", "v21": "2026-08-01", "v22": "2026-10-01"}  # sunset-dates page
sunset = SUNSET.get(PINNED)    # None until your version reaches the published calendar
if sunset and (date.fromisoformat(sunset) - date.today()).days < 60:
    alert(f"{PINNED} sunsets {sunset}; schedule the version bump")  # major bump needs a re-test

404 z wygaszonej wersji to awaria, którą zafundowałeś sobie sam. Traktuj zarządzanie wersjami jak stałe cykliczne zadanie, nie jak alarm pożarowy.

A teraz bonus: AI wprowadza się do kreacji i feedu

Z terminami pod kontrolą reszta roku to dźwignia, którą wdrażasz według własnego kalendarza. Dwie usługi zamieniły pracę nad zasobami i feedem w coś, co oskryptujesz na tysiącach SKU.

• AssetGenerationService (Ads API, v22, zamknięta beta). Generowanie tekstów i obrazów przez AI, z ulepszaniem i ekstrakcją obrazów dla PMax; v23.2 dodała VideoEnhancement dla wideo generowanego przez Google. Tworzenie kreacji wychodzi z interfejsu do programowalnej warstwy.
• Product Studio (Merchant API, alpha od kwietnia 2025). Generowane przez AI tytuły i opisy produktów plus AutomatedDiscounts do cen w czasie rzeczywistym. Przepisywanie tytułów na poziomie API oznacza masowe ulepszanie tysięcy SKU bez pracy ręcznej.

Połowę feedową biorę osobiście. W Lyncie przez dwa lata budowaliśmy Boosterę, warstwę AI wzbogacającą feedy Merchant Center, bo jakość feedu to sufit wyników Shopping i PMax. Lepsze tytuły przesuwają więcej przychodu niż większość zmian stawek. Product Studio wnosi kawałek tej zdolności prosto do platformy.

Pipeline, który to odblokowuje, czyta SKU z feedu, generuje zgodny tytuł, opis i zasoby graficzne i wypycha je prosto do grupy zasobów, bez ręcznego kroku w Canvie po środku. Obie usługi są pre-GA. Traktuj je jak pilotaż na wycinku katalogu, nie jak rollout na cały katalog, dopóki nie dojrzeją.

Hydraulika: Ads i Merchant wreszcie razem

Najbardziej niedoceniana zmiana roku jest zupełnie nieefektowna. Dwie połowy konta e-commerce lądują w jednym miejscu.

Co się zmieniło. Od 22 kwietnia 2026 Merchant API jest osiągalne z Google Ads Scripts. W połączeniu z product_filters (warunkowe udostępnianie feedu Google Ads, wydane w listopadzie 2025) i CartDataSalesView (v24) pętla między zdrowiem feedu a wydatkami reklamowymi domyka się w jednym środowisku.

Dlaczego dotyczy twojego konta. Stary podział, kampanie w Scripts i feed zarządzany gdzie indziej, oznaczał, że odrzucony produkt palił budżet, dopóki człowiek tego nie zauważył. Teraz jeden skrypt może zareagować na odrzucenie w feedzie pauzą kampanii albo wyjęciem SKU z grupy informacji o produktach w PMax. A CartDataSalesView wnosi do API przychód per sprzedane SKU z danych koszyka. Niesie przychód, nie wydatki, więc prawdziwy ROAS per SKU wymaga dwóch zapytań. Zacznij od strony przychodowej:

-- Revenue per sold SKU from cart data (v24+)
SELECT segments.product_item_id,
       metrics.revenue_micros,
       metrics.all_revenue_micros
FROM cart_data_sales_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.revenue_micros DESC

Potem pobierz stronę kosztową ze shopping_performance_view i połącz oba wyniki po product_item_id:

-- Cost per advertised SKU; join to the revenue query on product_item_id
SELECT segments.product_item_id,
       metrics.cost_micros,
       metrics.conversions_value
FROM shopping_performance_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.cost_micros DESC

Te połączone wiersze są wejściem do tieringu rentowności, który wcześniej co miesiąc składałeś ręcznie. Dla klientów prowadzimy raportowanie biznesowe na poziomie klienta w BigQuery i połową pracy zawsze było zszywanie danych reklamowych z produktowymi. Szew żyje teraz w dwóch wywołaniach API zamiast w eksporcie feedu i możesz go zwalidować. Sprawdź, czy item ID zgadzają się po obu stronach, zanim zaufasz wskaźnikowi. (Zasób to cart_data_sales_view z v24; dostępność segmentów sprawdź w release notes swojej wersji.)

Rok na jednej osi czasu

Każda wersja major poniżej pochodzi z oficjalnych release notes; kamienie milowe Merchant z Merchant API latest updates. Prawa kolumna jest jedyną, która powinna sterować twoim kalendarzem. Wszystko oznaczone TWARDY jest nienegocjowalne.

Pierwsza godzina pracy

Nie cała migracja. Grep. Przeszukaj swój kod pod kątem shoppingcontent.googleapis.com i zapisz każdy job, który wyskoczy. Ta lista to twoja ekspozycja na 18 sierpnia, a zajęła ci dziesięć minut.

Resztę godziny poświęć na utworzenie jednego eksperymentu ADOPT_AI_MAX na koncie, gdzie DSA znaczy najwięcej, żeby wrzesień przyszedł jako zmierzona zmiana, a nie niespodzianka. Terminy należą do Google. To, czy uderzą w ciebie jako awarie, czy jako ulepszenia, wciąż zależy od ciebie.

FAQ