ProductInput kontra Product. Dlaczego Google używa innej wersji produktu niż ta wysłana przez sklep?

Google używa innej wersji produktu niż ta wysłana przez sklep, ponieważ w Merchant API dane przesłane (ProductInput) i dane wyświetlane (Product) to dwa odrębne zasoby – między nimi Google stosuje reguły feedu, automatic improvements i łączenie z dodatkowymi źródłami. ProductInput to surowe dane przesłane do konkretnego data source, a Product to zasób tylko do odczytu, zbudowany z jednego primary i zero lub więcej supplemental ProductInput. Ten artykuł wyjaśnia, co się dzieje pomiędzy tymi dwoma zasobami i jak diagnozować rozbieżności.

Jak wygląda cykl życia danych produktowych w Merchant Center?

Kiedy sklep przesyła dane produktowe do Google – czy to przez plik feedu, API, czy autofeed – dane przechodzą przez kilka warstw transformacji, zanim trafią na powierzchnie Google (Shopping, Free Listings, AI Overview, AI Mode). To oznacza, że widoczność produktu w AI i pozycjonowanie AI zależy nie tylko od feedu. Każda warstwa może zmodyfikować, uzupełnić lub odrzucić poszczególne pola.

Dokumentacja Merchant API – Manage your products (weryfikacja: 17 sierpnia 2026) definiuje ten cykl jako rozdzielenie danych wejściowych od danych wyjściowych: „A key concept in Merchant API is the distinction between the data you submit and the final product that Google uses. This separation provides a clearer model of the product data lifecycle and gives you more precise control over your product information.”

Proces wygląda następująco: sklep przesyła dane do data source (plik, API lub autofeed), Merchant Center tworzy zasób ProductInput, następnie łączy go z ewentualnymi źródłami uzupełniającymi (supplemental data sources), stosuje reguły feedu (feed rules), przeprowadza automatyczne ulepszenia (automatic improvements) i walidację, a na końcu tworzy finalny zasób Product, który jest widoczny na powierzchniach Google.

Czym jest ProductInput?

ProductInput to zasób Merchant API reprezentujący surowe dane produktowe przesłane przez sklep do konkretnego data source. Dokumentacja Google opisuje go jako: „the raw product data you submit to a specific data source. Think of this as the row you upload in a feed file or the data you submit with an API call before any Merchant Center processing happens.”

Najważniejsze cechy ProductInput:

• To zasób do zapisu (write) – sklep używa go do operacji insert, patch i delete.
• Każdy ProductInput należy do konkretnego data source (identyfikowanego przez dataSource).
• Jeden produkt może mieć wiele ProductInput – jeden primary i zero lub więcej supplemental.
• Format i wymagania dla atrybutów definiuje Product data specification.
• Nazwa zasobu: accounts/{account}/productInputs/{productInput}.

Ważne: ProductInput przechowuje dokładnie to, co sklep przesłał. Jeśli sklep przesłał tytuł „Laptop Dell Inspiron 15 3520 i5/8GB/512SSD”, ten tekst zostaje zapisany w ProductInput bez modyfikacji. Zmiany następują dopiero na etapie przetwarzania.

Czym jest przetworzony Product?

Product to zasób Merchant API reprezentujący finalny, przetworzony produkt, który Google wyświetla na swoich powierzchniach. Dokumentacja opisuje go jako: „a read-only resource that represents the final, processed product as it appears in Merchant Center and on Google surfaces. It is built from one primary ProductInput and zero or more supplemental ProductInput resources after all feed rules and processing have been applied.”

Najważniejsze cechy Product:

• To zasób tylko do odczytu (read) – sklep używa go do operacji get i list.
• Zawiera finalny stan produktu po wszystkich transformacjach.
• Zawiera status produktu na poszczególnych powierzchniach (Shopping Ads, Free Listings) i ewentualne problemy z jakością danych.
• Nazwa zasobu: accounts/{account}/products/{product}.
• Sklep nie może bezpośrednio modyfikować Product – zmiany wprowadza się przez ProductInput.

Różnica między ProductInput a Product to nie kwestia konwencji nazewnictwa. To dwa różne zasoby z różnymi endpointami, różnymi dozwolonymi operacjami i potencjalnie różnymi wartościami tych samych pól.

Czym różni się ProductInput od Product?

Cecha	ProductInput	Product
Rola	Dane wejściowe (surowe)	Dane wyjściowe (przetworzone)
Operacje API	insert, patch, delete (write)	get, list (read-only)
Źródło danych	Konkretny data source	Wynik przetwarzania wszystkich źródeł
Liczba na produkt	1 primary + 0..N supplemental	1 (finalny)
Reguły feedu	Nie zastosowane	Zastosowane
Automatic improvements	Nie zastosowane	Zastosowane (jeśli włączone)
Status i issues	Brak	Zawiera status per powierzchnia + data quality issues
Modyfikowalny	Tak (przez sklep)	Nie (read-only)
Nazwa zasobu	accounts/{id}/productInputs/{id}	accounts/{id}/products/{id}

Skąd bierze się finalny produkt – primary i supplemental data source?

Finalny Product nie musi pochodzić z jednego źródła. Merchant API rozróżnia dwa typy data sources dla produktów:

Primary data source – główne źródło danych produktowych. Zawiera podstawowe atrybuty: tytuł, opis, cenę, dostępność, link, obraz (relację tych pól z kartą produktu i danymi strukturalnymi omawiamy osobno). Każdy produkt musi mieć dokładnie jeden primary ProductInput. Primary data source może być typu API (produkty przesyłane przez Merchant API), file (plik feedu pobierany z URL lub przesyłany przez SFTP) lub autofeed (Google automatycznie skanuje stronę sklepu).

Supplemental data source – źródło uzupełniające, które dostarcza dodatkowe lub nadpisujące atrybuty dla produktów już istniejących w primary source. Supplemental data source musi być powiązany (linked) z primary data source. Wartości z supplemental source mogą nadpisywać wartości z primary source dla wybranych pól.

Praktyczny przykład: sklep przesyła feed z tytułami, cenami i opisami jako primary source. Osobne supplemental source dostarcza dane o promocjach, dodatkowe atrybuty custom label lub lokalne ceny regionalne – każdy z tych elementów to część strategii content marketingu produktowego. Finalny Product łączy dane z obu źródeł.

Kiedy dane z primary i supplemental source kolidują, Merchant Center stosuje reguły priorytetu. Supplemental source może nadpisać pole z primary source, ale nie może dodać produktu, którego nie ma w primary source. Dokumentacja Manage API data sources opisuje proces linkowania supplemental do primary: „linking supplemental sources to primary ones, which is required after supplemental data sources creation.”

Jak reguły feedu i konflikty źródeł wpływają na dane produktowe?

Między ProductInput a finalnym Product Merchant Center stosuje feed rules – reguły, które mogą transformować wartości pól. Typowe transformacje obejmują:

• Modyfikacja tytułu – dodanie lub usunięcie fragmentów, standaryzacja formatu.
• Mapowanie kategorii – przypisanie google_product_category na podstawie product_type lub treści strony.
• Ekstrakcja atrybutów – wyciągnięcie koloru, rozmiaru lub materiału z tytułu lub opisu.
• Uzupełnienie brakujących pól – automatyczne dodanie GTIN na podstawie innych identyfikatorów (a to właśnie GTIN decyduje o selekcji sprzedawcy w ChatGPT).
• Normalizacja formatów – standaryzacja zapisu ceny, waluty, dostępności.

Reguły feedu konfiguruje się w Merchant Center (zakładka Feed rules w ustawieniach data source). Mogą działać na poziomie pola (zmiana wartości konkretnego atrybutu) lub na poziomie produktu (filtrowanie, wykluczanie). Rezultat reguł jest widoczny dopiero w finalnym Product, nie w ProductInput.

Konflikty między źródłami mogą prowadzić do sytuacji, w której sklep widzi poprawne dane w pliku feedu, ale Merchant Center pokazuje inną wersję. Najczęstsze przyczyny to: supplemental source nadpisuje pole z primary source, reguła feedu modyfikuje wartość, automatic improvement zmienia cenę lub dostępność na podstawie strony produktu.

Kiedy Google sam zmienia dane produktowe przez automatic improvements?

Automatic improvements to zestaw funkcji Merchant Center, które pozwalają Google automatycznie aktualizować dane produktowe na podstawie strony docelowej (landing page) sklepu. Dokumentacja opisuje trzy kategorie ulepszeń:

Kategoria	Co zmienia	Skąd bierze dane	Domyślny stan
Item Updates	Cenę, dostępność, condition	Structured data (schema.org) na stronie produktu – spójność danych między DOM, schema i feedem to osobny temat	Zależy od konta (może być dziedziczony z konta nadrzędnego)
Image Improvements	Obrazy produktowe	Strona produktu	Może być dziedziczony z konta nadrzędnego
Shipping Improvements	Szacunkowy czas dostawy	Dane przewoźnika	Konfigurowalny tylko przez API (nie przez UI MC)

Centralny mechanizm: jeśli Merchant Center wykryje, że cena na stronie produktu różni się od ceny w feedzie, może automatycznie zaktualizować cenę w finalnym Product do wartości ze strony. Sklep przesłał 199 zł w feedzie, ale na stronie jest 179 zł po promocji – Merchant Center może użyć 179 zł w Product, mimo że ProductInput nadal zawiera 199 zł.

Warunek: automatyczne aktualizacje ceny i dostępności wymagają, aby strona produktu miała wdrożone structured data (schema.org Product z polami price i availability – problem rekomendacji niedostępnych produktów dotyczy też tego kontekstu). Bez structured data Merchant Center nie ma skąd pobrać zaktualizowanych wartości.

Automatic improvements działają w jedną stronę: Google może zmienić wartość w Product na podstawie strony, ale zmiana w Product nie zmienia ProductInput. Jeśli chcesz trwale zmienić dane, musisz zaktualizować źródło (feed lub API). Źródło: Merchant API – Automatic Improvements, weryfikacja 17.08.2026.

Jakie ryzyko niesie błędne łączenie identyfikatorów produktu?

W Merchant API identyfikator produktu to kombinacja kilku pól:

• offerId – identyfikator nadany przez sklep (odpowiada polu id w specyfikacji Product data).
• contentLanguage – język treści produktu (np. pl).
• feedLabel – etykieta feedu (zastępuje targetCountry w nowszych wersjach API).
• channel – kanał sprzedaży (ONLINE lub LOCAL).

Kombinacja tych pól tworzy unikalny identyfikator finalnego Product. Jeśli dwa ProductInput z różnych data sources mają ten sam offerId, contentLanguage, feedLabel i channel, Merchant Center traktuje je jako dane dotyczące tego samego produktu i łączy je (primary + supplemental).

Ryzyko błędnego łączenia pojawia się, gdy sklep używa tego samego offerId w różnych kontekstach. Na przykład: offerId = "12345" w primary source to laptop, ale offerId = "12345" w supplemental source (np. z innego systemu PIM) to etui do telefonu. Merchant Center połączy te dane w jeden Product, nadpisując atrybuty z supplemental source.

Diagnoza: jeśli produkt ma niespodziewane wartości atrybutów, pierwszym krokiem jest sprawdzenie, czy offerId nie występuje w więcej niż jednym data source z różnymi danymi.

Jak porównać źródło z wynikiem i zdiagnozować rozbieżności?

Rozbieżność między tym, co sklep przesłał, a tym, co Google wyświetla, wymaga porównania kilku warstw danych. Ten proces jest elementem każdego audytu SEO dla e-commerce:

Warstwa	Co sprawdzić	Jak sprawdzić
1. Plik feedu / eksport z PIM	Wartości pól w pliku źródłowym	Bezpośredni odczyt pliku CSV/XML/TSV
2. ProductInput (primary)	Wartości po imporcie do MC	Merchant API: GET accounts/{id}/productInputs/{id}
3. ProductInput (supplemental)	Wartości z źródeł uzupełniających	Merchant API: list productInputs z filtrem po dataSource
4. Feed rules	Reguły transformacji	Merchant Center UI: Data sources → Feed rules
5. Automatic improvements	Nadpisania z landing page	Merchant Center UI: Products → Product issues; API: AutomaticImprovements resource
6. Product (finalny)	Wartości po przetworzeniu	Merchant API: GET accounts/{id}/products/{id}
7. Strona produktu	Dane na landing page	Bezpośredni odczyt strony + schema.org
8. Powierzchnia Google	Co widzi użytkownik	Shopping tab, Free Listings, AI Overview (z personalizowaną rekomendacją)

Najczęstsze scenariusze rozbieżności:

Tytuł w feedzie jest inny niż na Shopping

Przyczyna: reguła feedu modyfikuje tytuł (np. dodaje markę na początku) lub automatic improvement wyciąga tytuł ze structured data na stronie. Diagnostyka: porównaj title w ProductInput z title w Product. Jeśli się różnią, sprawdź feed rules.

Cena w Merchant Center jest inna niż w pliku

Przyczyna: automatic item update zmienia cenę na podstawie strony produktu, lub supplemental source nadpisuje cenę z primary source. Diagnostyka: sprawdź, czy automatic improvements są włączone (allowPriceUpdates: true). Porównaj cenę w ProductInput z ceną w Product i ceną na stronie.

Produkt odrzucony mimo poprawnego wiersza w feedzie

Przyczyna: ProductInput jest poprawny, ale po zastosowaniu reguł feedu lub połączeniu ze supplemental source finalny Product narusza politykę. Diagnostyka: odczytaj Product przez API i sprawdź pole productStatuses – zawiera listę problemów z jakością danych per powierzchnia.

Atrybut został nadpisany przez Google

Przyczyna: Google wyciąga wartość ze structured data na stronie i traktuje ją jako bardziej aktualną niż feed. Diagnostyka: porównaj structured data na stronie z wartościami w feedzie. Jeśli się różnią i automatic improvements są włączone, Merchant Center może nadpisać feed.

Jak ustalać źródło prawdy w organizacji?

Rozdzielenie ProductInput od Product tworzy praktyczny problem organizacyjny: który system w firmie jest „źródłem prawdy” dla danych produktowych? Odpowiedź zależy od tego, jakie dane sprawdzamy.

Dla danych, które sklep kontroluje (tytuł, opis, cena, obraz, dostępność) – źródłem prawdy powinien być system PIM lub platforma e-commerce lub marketplace (sprawdź checklistę agentic commerce readiness), z której generowany jest feed. To tam powinny być wprowadzane zmiany, a feed powinien odzwierciedlać aktualny stan danych w PIM.

Dla danych, które Google przetwarza (kategoria Google, automatic improvements, status na powierzchniach) – źródłem prawdy jest finalny Product w Merchant API. To on pokazuje, jak Google widzi produkt po wszystkich transformacjach, a spójność tych danych przekłada się na ocenę wiarygodności sprzedawcy.

Dla diagnostyki – trzeba porównać obie warstwy. Jeśli sklep widzi problem na powierzchni Google (np. zła cena), musi ustalić, na której warstwie doszło do rozbieżności: feed → ProductInput → feed rules → automatic improvements → Product → powierzchnia. Ten proces diagnostyczny jest fundamentem pozycjonowania sklepu internetowego w erze przetwarzanych danych produktowych.

Co sprawdzić, gdy produkt wygląda inaczej niż w feedzie?

Poniższa checklista stanowi uzupełnienie audytu treści produktowych w kontekście Merchant API:

• 1. Sprawdź ProductInput przez API. Czy wartości w ProductInput zgadzają się z plikiem feedu? Jeśli nie, problem jest na etapie importu (format pliku, kodowanie, separator).
• 2. Sprawdź, czy istnieją supplemental data sources. Czy inny data source dostarcza dane dla tego samego offerId? Jeśli tak, wartości z supplemental mogą nadpisywać primary.
• 3. Sprawdź feed rules. Czy w ustawieniach data source zdefiniowane są reguły transformacji? Feed rules mogą zmieniać tytuł, opis, kategorię i atrybuty konwersacyjne i inne pola.
• 4. Sprawdź automatic improvements. Czy allowPriceUpdates, allowAvailabilityUpdates lub allowConditionUpdates są ustawione na true? Jeśli tak, Google może nadpisywać te pola danymi ze strony.
• 5. Porównaj structured data na stronie z feedem. Jeśli schema.org na stronie ma inną cenę niż feed i automatic improvements są włączone, Merchant Center użyje wartości ze strony.
• 6. Odczytaj finalny Product przez API. Porównaj wartości pól z ProductInput. Różnice wskazują, na której warstwie doszło do transformacji.
• 7. Sprawdź productStatuses. Finalny Product zawiera status per powierzchnia (Shopping Ads, Free Listings) i listę data quality issues. Problem może dotyczyć tylko jednej powierzchni.

Co oznacza sunset Content API for Shopping?

Google ogłosił wycofanie Content API for Shopping na rzecz Merchant API. Termin zakończenia wsparcia to 18 sierpnia 2026. Sklepy korzystające ze starego API (endpoint content/v2.1) muszą zmigrować do Merchant API (endpoint merchantapi.googleapis.com).

W kontekście ProductInput vs Product migracja jest istotna: stare Content API nie rozdzielało tak wyraźnie danych wejściowych od przetworzonych. Merchant API wprowadza to rozdzielenie jako fundamentalny element architektury. Sklepy migrujące z Content API powinny zaktualizować swoje procesy diagnostyczne – w tym audyt widoczności w AI – aby uwzględniać nowy model dwóch zasobów.

Dokumentacja migracji: Migrate products management.

Ile pól zmienia się między feedem a finalnym produktem?

Cel: zmierzyć, ile pól zmienia się między ProductInput (dane przesłane przez sklep) a finalnym Product (dane po przetworzeniu Merchant Center).

Próba: 5 kont Merchant Center z różnych branż (artykuły papiernicze, narzędzia ogrodnicze, zabawki, sprzęt kuchenny, akcesoria rowerowe), 100-500 produktów na konto, osobne segmenty: produkty aktywne, odrzucone, z ostrzeżeniami i z promocją.

[WYMAGA DANYCH SEMGENCE] Procedura: 1) pobranie ProductInput przez Merchant API dla każdego produktu, 2) pobranie finalnego Product przez Merchant API, 3) porównanie wartości pól pole-po-polu, 4) klasyfikacja różnic: zachowane (identical), transformowane (modified), utracone (missing in Product), dodane (present only in Product).

[WYMAGA DANYCH SEMGENCE] Pola priorytetowe do porównania:

Pole	Typ porównania	Oczekiwany wynik
title	Exact match	Różnice z feed rules lub automatic improvements
description	Exact match	Obcięcie do limitu znaków, usunięcie HTML
price / sale_price	Wartość numeryczna	Rozbieżność z automatic item updates
availability	Enum match	Zmiana przez automatic item updates
image_link	URL match	Zmiana przez image improvements
brand	Exact match	Zwykle zachowane
gtin / mpn	Exact match	Zwykle zachowane
google_product_category	ID match	Nadpisanie przez Google auto-categorization
product_type	Exact match	Zachowane (nie transformowane)
condition	Enum match	Zmiana przez automatic item updates
shipping	Struktura	Zmiana przez shipping improvements
item_group_id	Exact match	Zachowane

[WYMAGA DANYCH SEMGENCE] Metryki do raportu:

• Field preservation rate (% pól identycznych w ProductInput i Product)
• Field transformation rate (% pól zmienionych przez reguły lub improvements)
• Field loss rate (% pól obecnych w ProductInput, ale nieobecnych w Product)
• Conflict rate między primary i supplemental data sources
• Liczba produktów z różnicą ceny między feedem a Product
• Liczba produktów z różnicą dostępności
• Udział automatic improvements w transformacjach vs feed rules

Patenty jako kontekst mechanizmu

Patent US11249993B2 opisuje generowanie odpowiedzi wyszukiwania na podstawie faktów wyekstrahowanych z treści strukturalnych. Klasa związku: Supporting. Patent wskazuje na mechanizm ekstrakcji faktów ze strukturalnych źródeł danych, co jest kontekstem dla sposobu, w jaki Google wyciąga i przetwarza atrybuty produktowe z feedów i stron docelowych.

Patent US12222995B2 opisuje ekstrakcję pól i kontekstowe reprezentacje DOM. Klasa związku: Supporting. Patent wskazuje na mechanizm, w którym system automatycznie wyciąga dane produktowe ze strony (landing page), co odpowiada funkcji automatic improvements w Merchant Center.

Patent US10943241B2 opisuje przetwarzanie katalogów produktowych z wielu źródeł handlowych – normalizację kategorii, wzbogacanie atrybutów przez product attribute resolver i tworzenie zunifikowanego katalogu produktowego. Klasa związku: Supporting. Patent dokumentuje pipeline analogiczny do modelu ProductInput → Product: surowe dane od sprzedawcy przechodzą normalizację, wzbogacenie z dodatkowych źródeł i walidację, zanim trafią do finalnego katalogu.

Patent US20250103640A1 opisuje generowanie odpowiedzi z cytatami wskazującymi dokumenty źródłowe. Klasa związku: Context only. Patent dotyczy śledzenia pochodzenia treści w generatywnych odpowiedziach AI (powiązane z tematem atrybucji w agentic commerce), co stanowi kontekst dla problemu identyfikacji, z którego źródła danych pochodzi konkretny atrybut w finalnym produkcie.

Czego nie twierdzić o ProductInput i Product?

• Nie twierdzić, że automatic improvements zawsze nadpisują dane z feedu. Działają tylko wtedy, gdy są włączone na koncie i gdy structured data na stronie zawiera odpowiednie pola.
• Nie twierdzić, że supplemental data source zawsze ma priorytet nad primary. Reguły priorytetu zależą od konfiguracji i mogą się zmieniać.
• Nie twierdzić, że różnica między ProductInput a Product oznacza błąd. Transformacja jest zamierzonym elementem systemu.
• Nie twierdzić, że feed rules w Merchant Center odpowiadają dokładnie feed rules opisanym w patentach. Patent opisuje mechanizm ogólny, nie konkretną implementację.
• Nie twierdzić, że model ProductInput/Product jest ostateczny. Google wersjonuje API (v1, v1beta, v1alpha) i może zmieniać strukturę zasobów.
• Nie twierdzić, że ten sam problem diagnostyczny dotyczy Content API i Merchant API tak samo. Migracja zmienia nazwy zasobów, endpointy i dostępne operacje.

Jakie są ograniczenia tego artykułu?

• Artykuł bazuje na dokumentacji publicznej Google Merchant API zweryfikowanej 17 sierpnia 2026.
• Nie mamy dostępu do wewnętrznych reguł przetwarzania Merchant Center. Opisujemy, co dokumentacja ujawnia, nie jak dokładnie działa system.
• Case study opisuje procedurę porównania warstw, nie gotowe wyniki.
• Feed rules konfiguruje się w Merchant Center UI – ich dokładne działanie może zależeć od konta i regionu.
• Automatic improvements mogą być dziedziczone z konta nadrzędnego (MCA), co komplikuje diagnostykę.

Jeśli potrzebujesz indywidualnej analizy feedu i diagnostyki rozbieżności ProductInput vs Product, skorzystaj z konsultacji SEO.

ProductInput vs Product – pytania z perspektywy feedu