Google wygasza Content API for Shopping i wprowadza Merchant API – co to oznacza i jak się przygotować?

Google ogłosił ogólną dostępność Merchant API i jednocześnie rozpoczął proces wygaszania Content API for Shopping. W praktyce oznacza to, że dotychczasowy interfejs pozostanie aktywny do 18 sierpnia 2026 roku, po czym zostanie wyłączony. Zmiana ma charakter systemowy: Merchant API staje się domyślnym sposobem programistycznego zarządzania danymi w Merchant Center, obejmując produkty, stany magazynowe, ceny, konfigurację kont i diagnostykę. Dla sklepów, integratorów i agencji to sygnał, aby z odpowiednim wyprzedzeniem zaplanować migrację, potraktować ją jako okazję do audytu jakości danych oraz uporządkowania procesów publikacji i synchronizacji asortymentu.

Co się zmienia i dlaczego Google to robi?

Merchant API ma uprościć architekturę integracji i przyspieszyć wdrażanie nowych funkcji. Jedno, spójne API oznacza mniej wyjątków, bardziej przewidywalne wersjonowanie, klarowniejszą diagnostykę błędów i krótszą ścieżkę od zmiany w katalogu do odzwierciedlenia jej w usługach Google. W porównaniu z Content API for Shopping nacisk położono na standaryzację operacji, czytelne komunikaty o niezgodnościach oraz lepsze narzędzia do nadzoru i raportowania.

W codziennej pracy zespołów marketingowo-technicznych przekłada się to na mniej trudnych do wykrycia awarii, szybsze reagowanie na odrzucenia spowodowane politykami i możliwość sprawniejszego eksperymentowania z automatyzacją publikacji.

Kogo dotyczą zmiany?

Zmiany obejmują wszystkich, którzy programistycznie zasilają Merchant Center danymi: duże sklepy z własnym PIM lub ERP, mniejsze e-commerce’y korzystające ze wtyczek i konektorów do platform sklepowych, integratorów łączących wiele źródeł danych, a także agencje performance obsługujące kampanie produktowe na wielu rynkach.

Jeśli w kodzie, zadaniach CRON, integracjach SaaS czy skryptach pomocniczych występują wywołania Content API for Shopping, konieczne jest zaplanowanie przejścia na Merchant API. Warto uwzględnić partnerów zewnętrznych, takich jak dostawcy feedów, agregatory marketplace’ów czy software house’y, aby skoordynować harmonogram i uniknąć przestojów.

Oś czasu i konsekwencje dla operacji

Choć horyzont czasowy wydaje się komfortowy, duże projekty rzadko przebiegają idealnie. Im bliżej daty wyłączenia starego API, tym większe ryzyko, że drobne różnice i niezgodności ujawnią się dopiero w ruchu produkcyjnym. Rozsądna strategia zakłada jak najszybsze przygotowanie pilotażu w Merchant API, równoległe testowanie krytycznych przepływów i stopniowe przełączanie segmentów asortymentu.

Taki plan daje czas na wykrywanie błędów, dostrojenie mapowania atrybutów, weryfikację uprawnień oraz aktualizację dokumentacji operacyjnej, harmonogramów i SLA dla aktualizacji cen, stanów oraz materiałów graficznych.

Plan migracji krok po kroku

Pierwszym krokiem jest inwentaryzacja wszystkich miejsc, ważnych dla danych produktowych: dodawanie i aktualizacje, warianty, dostępności, ceny promocyjne, atrybuty logistyczne, zestawy i zdjęcia. Następnie należy zidentyfikować mechanizmy autoryzacji i zarządzania kluczami (OAuth, konta serwisowe, zakresy uprawnień), a także biblioteki klienckie wykorzystywane przez aplikacje.

Kolejny etap to przygotowanie mapowania funkcji pomiędzy starym a nowym API wraz z listą operacji krytycznych dla biznesu, które muszą działać bezbłędnie w dniu przełączenia.

Po stronie technicznej warto zbudować prototyp w Merchant API obejmujący odczyt i aktualizację podstawowych zasobów, a następnie uruchomić testy równoległe, w których te same zmiany są wysyłane oboma kanałami i porównywane pod kątem czasów propagacji, statusów i komunikatów diagnostycznych.

Jakość danych i zarządzanie informacją produktową

Migracja to dobry moment, aby poprawić jakość danych, ponieważ nawet najlepsze API nie skompensuje braków w kluczowych atrybutach. W praktyce oznacza to ujednolicenie identyfikatorów produktów i wariantów, weryfikację GTIN, uzupełnienie opisów i parametrów technicznych, dopracowanie zdjęć oraz jasno zdefiniowaną logikę wyliczania dostępności i cen, zwłaszcza w okresach promocji.

Warto zbudować proste reguły walidacji po stronie PIM lub ERP, przygotować scenariusze testów dla nowych kategorii i zapewnić szybkie ścieżki publikacji poprawek w szczytach sprzedażowych. Lepsza jakość danych przekłada się na mniejszą liczbę odrzuceń, krótszą diagnostykę i stabilniejszą widoczność produktów.

Bezpieczeństwo, uprawnienia i zgodność

Zmiany w przepływach autoryzacyjnych i zakresach dostępu to dobra okazja, aby wdrożyć zasadę najmniejszych uprawnień, uporządkować rotację kluczy, a także przejrzeć, które systemy mają prawo modyfikować asortyment. W większych organizacjach sprawdza się dwustopniowy proces zatwierdzania zmian konfiguracyjnych i wyraźne rozdzielenie ról pomiędzy zespołami technicznymi oraz marketingowymi.

Warto również zaplanować monitoring nadużyć, politykę przechowywania w menedżerach haseł i audyty dostępu, aby uniknąć przypadkowych lub nieautoryzowanych modyfikacji danych produktowych.

Ryzyka zwlekania z migracją

Odkładanie decyzji do ostatniej chwili zwiększa ryzyko przestojów i rozjechania się danych o cenach oraz stanach, co uderzy w widoczność, jakość kampanii i przychody. Nawet kilkugodzinne opóźnienia w aktualizacjach w gorącym okresie mogą skutkować utratą budżetów mediowych i wzrostem obciążenia działu obsługi. Z perspektywy zarządzania ryzykiem lepiej zakończyć przełączenie z odpowiednim buforem czasowym i mieć przygotowaną ścieżkę szybkiego powrotu do poprzedniej konfiguracji, gdyby w środowisku produkcyjnym ujawniła się nieprzewidziana niezgodność.

Korzyści z dobrze przeprowadzonej migracji

Przejście na Merchant API, poza spełnieniem wymogów Google, pozwala uprościć ekosystem integracji, ograniczyć dług techniczny, zwiększyć obserwowalność procesów oraz przyspieszyć eksperymenty z automatyzacją publikacji. W połączeniu z regularnym przeglądem diagnostyki w Merchant Center i jasnym podziałem odpowiedzialności między działami technicznymi i marketingowymi daje to stabilniejszą widoczność produktów, lepszą odporność na wahania sezonowe i większą przewidywalność wyników sprzedażowych.

Migracja z Content API for Shopping na Merchant API jest obowiązkowa w wyznaczonym horyzoncie i nie warto jej odkładać. Najlepsze rezultaty przynosi podejście etapowe: rzetelna inwentaryzacja, prototyp w nowym API, testy równoległe na realistycznych danych, twarde metryki jakości informacji produktowych, kontrolowane przełączenie oraz gotowość do szybkich poprawek w odpowiedzi na incydenty. Traktując migrację jako impuls do modernizacji, można podnieść jakość danych, uprościć integracje i zyskać większą kontrolę nad publikacją oferty w usługach Google.

Bibliografia

1. SERoundtable, Google Merchant API Replaces Content API for Shopping; Dostęp: 22.08.2025.
   https://www.seroundtable.com/google-merchant-api-content-api-for-shopping-39958.html