Zwroty na poziomie produktu w Merchant Center: returns czy return_policy_label?

Zwroty na poziomie produktu w Merchant Center: kiedy użyć returns, a kiedy return_policy_label?

W danych produktowych Google są dwa mechanizmy, które mogą służyć do obsługi wyjątków od standardowych zasad zwrotu, ale działają inaczej.

return_policy_label nie zawiera zasad zwrotu. Przypisuje produkt do polityki utworzonej wcześniej na poziomie konta Merchant Center. returns przekazuje natomiast parametry zwrotu bezpośrednio z danymi oferty i może zastąpić politykę skonfigurowaną na poziomie konta.

Wybór między nimi wpływa więc na sposób modelowania danych. Przy return_policy_label definicja zasad pozostaje w Merchant Center, a dane produktu zawierają przypisanie. Przy returns część konfiguracji jest przenoszona na poziom konkretnej oferty.

return_policy_label wskazuje politykę utworzoną na koncie

Pierwsza polityka zwrotów utworzona dla produktów sprzedawanych przez Google staje się polityką domyślną. Oprócz niej można tworzyć dodatkowe polityki dla określonych grup produktów. Atrybut return_policy_label służy do przypisania produktu lub grupy produktów do jednej z takich niestandardowych polityk.

Dane produktu zawierają wtedy wyłącznie etykietę, na przykład:

return_policy_label = electronics

Szczegóły polityki electronics, takie jak okres zwrotu, metody czy opłaty, są utrzymywane na poziomie konta Merchant Center.

Jeżeli return_policy_label nie zostanie podany, obowiązuje skonfigurowana polityka domyślna. Google stosuje ją również wtedy, gdy przesłana etykieta nie odpowiada żadnej polityce istniejącej na koncie.

Taki model wymaga zgodności między dwoma elementami. System generujący dane produktowe musi przypisać ofertę do właściwej etykiety, a konto Merchant Center musi zawierać politykę z odpowiadającą jej wartością. Zaletą jest centralna aktualizacja. Zmiana jednej polityki może objąć wszystkie oferty, które już do niej wskazują.

returns przekazuje reguły na poziomie oferty

Google dodał pole returns do ProductAttributes Merchant API w tygodniu rozpoczynającym się 20 lipca 2026 r. Release notes opisują je wprost jako mechanizm umożliwiający offer-level return policy overrides.

W Merchant API returns jest powtarzalnym polem zawierającym obiekty Returns. Mogą one określać m.in. kraje, akceptowany stan produktu, metody zwrotu, możliwe rezultaty zwrotu, długość i typ okresu, koszt przesyłki zwrotnej, sposób rozliczenia tego kosztu, opłatę restockingową oraz URL polityki.

Dedykowana dokumentacja danych produktowych pokazuje również użycie returns w pliku tekstowym, np.:

returns(country:window_days:item_condition:method:outcome)

PL:30:NEW:BY_MAIL:REFUND

Jeżeli window_type ma wartość FINITE_RETURN_WINDOW, trzeba podać window_days. Domyślną wartością window_type, gdy pole nie zostanie przesłane, jest FINITE_RETURN_WINDOW.

Merchant Center obsługuje do 100 offer-level return policy overrides na ofertę. Dla ofert posiadających własne dane returns nie trzeba konfigurować polityki zwrotów na poziomie konta. Google jednocześnie zaleca oszczędne stosowanie override'ów na poziomie oferty i wskazuje, że polityki konta są łatwiejsze do zarządzania dla dużych części katalogu.

returns nie jest pełnym odpowiednikiem polityki konta

Nie należy traktować returns jako sposobu na przeniesienie dowolnej polityki Merchant Center jeden do jednego do danych produktu.

Zakres obiektu Returns w ProductAttributes różni się od account-level OnlineReturnPolicy. Polityka na poziomie konta ma pola niewystępujące w offer-level Returns, m.in. seasonalOverrides, processRefundDays i returnLabelSource.

Różnica między mechanizmami nie dotyczy więc wyłącznie miejsca przechowywania tych samych informacji. Account-level policy i offer-level Returns mają również inny model danych.

Kilka powtarzalnych polityk przemawia za return_policy_label

Jeżeli katalog korzysta z kilku stabilnych zestawów zasad zwrotu, return_policy_label ogranicza duplikowanie konfiguracji.

Przykładowo 10 000 produktów może podlegać trzem politykom: domyślnej, polityce dla produktów ponadgabarytowych i polityce dla wybranej kategorii. Feed musi wtedy określić właściwe przypisanie, ale definicja zasad pozostaje wspólna.

Zmiana okresu zwrotu dla całej grupy nie wymaga aktualizacji danych każdej oferty. Wystarczy zmienić politykę, do której wskazują produkty.

Ten model jest zgodny z zaleceniem Google, aby polityki konta wykorzystywać do zarządzania dużymi częściami katalogu, a offer-level overrides stosować oszczędnie.

Sama liczba produktów nie rozstrzyga jednak wyboru. Znaczenie mają przede wszystkim liczba różnych zestawów zasad, sposób ich utrzymywania i to, czy zmiany dotyczą zwykle całych grup, czy pojedynczych ofert.

returns ma sens, gdy reguły powstają na poziomie oferty

Inny model występuje wtedy, gdy zasady zwrotu są już częścią danych konkretnej oferty i mogą różnić się między produktami.

Jeżeli system e-commerce, PIM lub ERP przechowuje dla oferty parametry potrzebne do wygenerowania Returns, tworzenie kolejnych polityk w Merchant Center wyłącznie po to, aby następnie przypisywać je przez etykiety, dodaje osobną warstwę mapowania.

W takim przypadku returns pozwala przekazać dane bezpośrednio z systemu źródłowego do oferty w Merchant Center.

Nie wynika z tego, że każda różnica między produktami powinna prowadzić do zastosowania returns. Jeżeli wiele ofert korzysta z tych samych kilku polityk, centralne zarządzanie przez polityki konta zwykle ogranicza liczbę miejsc, które trzeba aktualizować.

Źródło prawdy powinno wynikać z architektury sklepu

To już rekomendacja architektoniczna, a nie wymaganie Google: zasady zwrotów powinny mieć jedno kontrolowane źródło, z którego powstają dane publikowane w sklepie i przekazywane do kanałów zewnętrznych.

Google wymaga natomiast, aby wartości przesyłane przez returns odpowiadały zasadom widocznym w witrynie. Niespełnienie minimalnych wymagań może prowadzić do odrzucenia produktu.

Przy return_policy_label system źródłowy może przechowywać informację o tym, do której klasy polityki należy oferta, podczas gdy odpowiadające jej zasady są skonfigurowane w Merchant Center.

Przy returns system źródłowy musi dostarczyć parametry potrzebne do zbudowania reguł na poziomie oferty.

Decyzja powinna więc uwzględniać cztery kwestie: gdzie powstają dane o zwrotach, ile różnych polityk rzeczywiście występuje w katalogu, jak często są zmieniane oraz czy sklep potrzebuje funkcji dostępnych w OnlineReturnPolicy, których nie ma w offer-level Returns.

policy_url musi odpowiadać konkretnej ofercie

Jeżeli w returns przekazywany jest policy_url, Google wymaga adresu prowadzącego do właściwej polityki dla produktu. URL musi być dostępny z poziomu strony opisu powiązanego produktu, zaczynać się od http:// lub https:// i prowadzić do działającej strony polityki. Google zgłasza również problem, gdy domena policy_url nie odpowiada domenie produktów.

W praktyce nie wystarczy więc przekazać dowolnej ogólnej strony o zwrotach, jeżeli nie opisuje ona zasad obowiązujących dla danej oferty.

Dokumentacja Google jest obecnie niespójna w nazwie atrybutu feedowego

Przy wdrożeniu opartym na pliku danych trzeba zwrócić uwagę na aktualną niespójność w oficjalnej dokumentacji Google.

Dedykowana strona atrybutu używa nazwy zwroty [returns] i pokazuje nagłówki takie jak:

returns(country:window_days:method:outcome)

Merchant API również używa pola returns.

Jednocześnie ogólna specyfikacja danych produktów Google, w wersji angielskiej i polskiej dostępnej 28 września 2026 r., nadal opisuje ten mechanizm jako zwrot [return].

Dokumentacja nie wyjaśnia obecnie tej rozbieżności ani nie stwierdza, że [return] i [returns] są oficjalnymi aliasami. Dlatego nie należy tego zakładać. Przy implementacji feedu trzeba sprawdzić aktualną dokumentację właściwą dla używanej metody przesyłania danych. W Merchant API nazwa pola jest jednoznaczna: returns.

Pojawienie się returns nie wymaga migracji z return_policy_label

returns nie zastąpiło return_policy_label.

Merchant API nadal zawiera returnPolicyLabel, które grupuje produkty według polityk zwrotu na poziomie konta. Pole returns funkcjonuje obok niego jako osobny mechanizm offer-level.

Release notes Merchant API pokazują również, że oba pola zostały dodane do Products Service osobno: return_policy_label w tygodniu rozpoczynającym się 16 marca 2026 r., a returns w tygodniu rozpoczynającym się 20 lipca 2026 r.

Migracja istniejącej konfiguracji ma więc sens wtedy, gdy obecny model nie odpowiada sposobowi przechowywania danych albo wymaga utrzymywania zbędnej warstwy polityk i mapowań. Sama dostępność nowszego pola nie jest argumentem za zmianą.

Migracja do Merchant API to osobna decyzja

Content API for Shopping oficjalnie osiągnęło sunset 18 sierpnia 2026 r. Nie oznacza to jednak, że wszystkie endpointy zostały tego dnia jednocześnie wyłączone.

Od 1 września 2026 r. Google prowadzi stopniową degradację usługi. Żądania klientów bez aktywnego przedłużenia mogą okresowo kończyć się błędem HTTP 410 Gone. Pełne wyłączenie wszystkich endpointów jest planowane na początek 2027 r., przy czym Google zastrzega możliwość zmiany tego terminu. Istniejące integracje mają zostać przeniesione do Merchant API.

Migracja API i wybór modelu zwrotów są jednak niezależnymi decyzjami. Przejście z Content API do Merchant API nie wymaga automatycznej zamiany return_policy_label na returns.

Kiedy wybrać który mechanizm

return_policy_label jest właściwym modelem, gdy kilka wspólnych polityk obejmuje większe grupy ofert, a sklep chce zarządzać ich definicjami centralnie na poziomie konta Merchant Center.

returns odpowiada sytuacji, w której reguły zwrotu są związane z konkretną ofertą i dane potrzebne do ich opisania są dostępne w systemie źródłowym.

Przed wyborem returns trzeba dodatkowo sprawdzić, czy zakres obiektu Returns wystarcza do odwzorowania rzeczywistych zasad. Nie wszystkie możliwości OnlineReturnPolicy są dostępne na poziomie oferty.

Możliwość technicznego przesłania określonych zasad do Merchant Center nie rozstrzyga ich zgodności z prawem. Specyfikacja Google określa format i zakres danych obsługiwanych przez platformę, nie zastępuje oceny przepisów mających zastosowanie do sprzedaży i zwrotów.