Optymalizacja feedu: tytuły produktów pod Shopping i PMax

Tytuł jest jednym z najbardziej widocznych i użytecznych pól danych produktowych w reklamach Shopping, Performance Max oraz bezpłatnych informacjach o produktach. Pomaga systemowi rozpoznać ofertę, a klientowi szybko zrozumieć, co widzi. Nie działa jednak samodzielnie. Trafność i możliwość emisji zależą również od identyfikatorów, wariantów, kategorii, obrazu, ceny, dostępności oraz zgodności ze stroną docelową.

Optymalizacja feedu nie polega więc na dopisywaniu jak największej liczby fraz do nazwy. Polega na stworzeniu dokładnego, kompletnego i spójnego modelu produktu, w którym tytuł eksponuje cechy najważniejsze dla decyzji w danej kategorii.

W skrócie

• Tytuł powinien jednoznacznie identyfikować sprzedawany wariant i odpowiadać temu, co znajduje się na stronie produktu.
• Oficjalny limit Google dla title wynosi 150 znaków, ale pełna treść nie zawsze jest widoczna; najważniejsze informacje powinny znaleźć się wcześniej.
• Nie istnieje jeden szablon dla całego katalogu. Kolejność marki, typu, modelu, zastosowania, rozmiaru i koloru zależy od kategorii oraz intencji klienta.
• Tytuł nie zastępuje atrybutów. Kolor, rozmiar, GTIN, marka, MPN, item_group_id, kategoria i typ produktu należy przesyłać w przeznaczonych do tego polach.
• Nie wolno wymyślać GTIN ani używać wewnętrznego SKU jako numeru producenta. Brak prawdziwego identyfikatora obsługuje się zgodnie ze specyfikacją.
• Nazwa, cena, dostępność i wariant w feedzie muszą zgadzać się z landing page’em i checkoutem.
• Tytuły wygenerowane przez AI wymagają użycia structured_title z właściwym oznaczeniem źródła.
• Zmiany należy wdrażać na kontrolowanej grupie, z rejestrem wersji i oceną wpływu na widoczność, trafność, sprzedaż oraz marżę.

Co tytuł robi — i czego nie robi

Google opisuje tytuł jako jeden z najbardziej widocznych elementów reklamy lub bezpłatnej informacji produktowej. Konkretna i zgodna z rzeczywistością nazwa pomaga pokazać produkt właściwym osobom. Nie oznacza to, że tytuł jest tajnym „najsilniejszym czynnikiem” o stałej wadze ani że wystarczy skopiować zapytania z raportu wyszukiwania.

Tytuł pełni trzy funkcje:

1. Identyfikuje ofertę. Określa, jaki produkt i wariant jest sprzedawany.
2. Dostarcza kontekstu. Pokazuje cechy, które odróżniają go od podobnych pozycji.
3. Wspiera decyzję o kliknięciu. Pozwala ocenić zgodność z potrzebą bez otwierania strony.

Pozostałe pola dostarczają danych, których nie należy upychać w nazwie. GTIN i MPN pomagają rozpoznać konkretny produkt. google_product_category oraz product_type porządkują klasyfikację. Atrybuty wariantu mówią o rozmiarze, kolorze czy materiale. Cena, dostępność, wysyłka i obraz budują pełną prezentację oferty.

Najlepszy tytuł nie uratuje produktu z błędnym GTIN, niezgodną ceną albo zdjęciem innego wariantu.

Dlaczego nazwa z ERP lub magazynu często wymaga przekształcenia

System wewnętrzny optymalizuje nazwy pod pracę zespołu, a nie pod decyzję konsumenta. Typowe problemy to:

• sam kod, np. BT-4412-CZ;
• nazwa kolekcji bez typu produktu, np. „Aurora Comfort”;
• skróty techniczne zrozumiałe wyłącznie dla organizacji;
• brak marki lub modelu używanych przez klientów;
• wspólna nazwa dla wszystkich wariantów;
• dopisek magazynowy, status lub symbol dostawcy;
• kolejność informacji wynikająca z bazy, nie z kategorii.

Rozwiązaniem nie jest przepisanie nazwy na „frazę kluczową”. Tytuł powinien brzmieć naturalnie, identyfikować produkt i zawierać cechy, które rzeczywiście pomagają odróżnić wariant. Zapytania użytkowników są materiałem badawczym: pokazują język, kolejność i ważne atrybuty, ale nie powinny być kopiowane mechanicznie.

Aktualne wymagania Google dla tytułu

Zgodnie z aktualną specyfikacją danych produktów dla każdej pozycji wymagany jest title albo structured_title.

Najważniejsze zasady:

• limit treści wynosi 150 znaków;
• nazwa ma dokładnie opisywać produkt i odpowiadać tytułowi na stronie docelowej;
• nie może zawierać tekstów promocyjnych, takich jak „darmowa dostawa”;
• nie należy stosować nadmiaru wersalików ani sztucznych znaków;
• warianty powinny zawierać cechy rozróżniające, np. kolor lub rozmiar;
• tytuł nie jest miejscem na cenę, informację o dostawie, nazwę konkurenta ani listę zapytań.

Limit 150 znaków nie jest celem. W wielu miejscach użytkownik zobaczy krótszy fragment. Początek powinien więc pozwolić rozpoznać ofertę bez polegania na końcówce, ale kolejność musi pozostać naturalna. Marka nie zawsze musi być pierwsza: przy produktach nieznanej marki ważniejszy może być typ i zastosowanie, natomiast przy produktach markowych klient często szuka właśnie producenta oraz modelu.

title a structured_title przy treściach AI

Jeżeli tytuł powstał z wykorzystaniem generatywnej AI, Google wymaga użycia structured_title i oznaczenia digital_source_type wartością trained_algorithmic_media. Tytuł niewygenerowany przez AI może korzystać ze zwykłego title albo odpowiednio skonfigurowanego structured_title.

Samo oznaczenie nie zwalnia z kontroli. Automatycznie wygenerowana nazwa może:

• dopisać cechę nieobecną w danych źródłowych;
• pomylić warianty;
• użyć nieprawidłowej marki lub kompatybilności;
• przekroczyć wymogi kategorii;
• rozminąć się z nazwą na stronie;
• stworzyć nienaturalny, przeładowany tekst.

Proces AI powinien działać na zatwierdzonej strukturze i wiarygodnych atrybutach, a wynik przechodzić walidację. Szczególnie ryzykowne są kategorie regulowane, kompatybilność części, skład produktu, parametry techniczne i deklaracje zdrowotne.

Jak projektować strukturę tytułu według kategorii

Nie istnieje szablon gwarantujący wynik. Poniższe wzorce są punktem startowym do dopasowania na podstawie katalogu, zapytań, strony i zachowania klientów.

Przykładowo tytuł Kurtka 4412 nie identyfikuje wystarczająco wariantu. Lepsza wersja może brzmieć Marka X kurtka przeciwdeszczowa damska granatowa, rozmiar M, o ile wszystkie informacje są prawdziwe, widoczne na stronie i przekazane również w odpowiednich atrybutach.

Przy części zamiennej fraza „do BMW” może opisywać kompatybilność, ale brand musi wskazywać faktycznego producenta części. Specyfikacja Google wyraźnie zabrania podawania marki producenta oryginalnego urządzenia jako marki produktu kompatybilnego, jeśli go nie wytworzył.

Warianty: osobny produkt, wspólna rodzina

Jednym z najczęstszych błędów jest wysłanie wielu wariantów z identycznym tytułem, obrazem i identyfikatorem. Tymczasem każdy wariant powinien odzwierciedlać realną ofertę możliwą do zakupu.

Dla wariantów potrzebne są:

• stabilne i unikalne id;
• wspólne item_group_id dla rodziny;
• wspólny item_group_title, jeśli jest przesyłany;
• cechy rozróżniające w odpowiednich polach, np. color, size, material, pattern;
• variant_option, gdy jest używany w aktualnej konfiguracji;
• właściwy GTIN przypisany przez producenta do konkretnego wariantu;
• link prowadzący do strony, na której ten wariant jest wybrany lub łatwo identyfikowalny;
• obraz zgodny z przesłanym kolorem i modelem;
• aktualna cena oraz dostępność właśnie tego wariantu.

Nie należy zmieniać id przy każdej aktualizacji tytułu. Historia produktu i możliwość porównania wyników zależą od stabilności identyfikatora. Raz używany identyfikator nie powinien być później przypisywany innemu produktowi.

GTIN, marka, MPN i identifier_exists

Unikalne identyfikatory pomagają Google rozpoznawać i łączyć produkty. Dla pozycji, którym producent przypisał GTIN, należy przesyłać właściwy numer. Oficjalna dokumentacja About unique product identifiers ostrzega przed zgadywaniem, używaniem numeru podobnego produktu i wpisywaniem wewnętrznego SKU w polu GTIN albo MPN.

Podstawowe scenariusze:

• produkt ma GTIN: przekazywany jest prawidłowy GTIN, marka i dostępny MPN;
• produkt nie ma GTIN, ale ma markę i MPN: przekazywane są prawdziwe wartości producenta;
• produkt rzeczywiście nie ma przypisanych identyfikatorów: pola pozostają zgodne ze stanem faktycznym, a identifier_exists może przyjąć no według wymagań;
• marka własna lub produkt wykonywany na zamówienie: stosuje się zasady właściwe dla producenta i produktu, nie generuje fikcyjnego EAN-u.

Ustawienie identifier_exists=no nie jest sposobem na ukrycie brakujących danych. Jeśli Google ma dowód, że identyfikator istnieje, produkt może otrzymać ostrzeżenie lub ograniczenie.

Kategorie i typ produktu

google_product_category opiera się na taksonomii Google i pomaga właściwie sklasyfikować ofertę. product_type jest własną hierarchią sprzedawcy. Oba pola pełnią inne funkcje i warto je utrzymywać równolegle.

Dobra hierarchia product_type może wyglądać tak:

Dom i ogród > Meble > Krzesła > Krzesła biurowe

Pozwala później analizować wyniki oraz tworzyć podziały i etykiety odpowiadające biznesowi. Nie należy wpychać do product_type listy luźnych fraz. Z kolei błędna kategoria Google może wpływać na wymagane atrybuty, sposób prezentacji i kwalifikację produktu.

Kategoryzację warto sprawdzać po zmianach w taksonomii i przy dodaniu nowego asortymentu. Automatyczne przypisanie nie powinno pozostać bez kontroli w katalogach, gdzie nazwy są niejednoznaczne.

Opis, szczegóły i najważniejsze cechy

description może mieć do 5000 znaków i powinien dokładnie opisywać produkt oraz odpowiadać stronie docelowej. Nie jest miejscem na linki, promocje, informacje o konkurencji ani mechaniczne listy fraz. Najważniejsze cechy warto umieścić wcześnie i pisać językiem pomocnym w decyzji.

Dodatkowe pola pozwalają rozdzielić informacje:

• product_highlight dla kluczowych korzyści lub cech;
• product_detail dla uporządkowanej specyfikacji;
• wymiary produktu w dedykowanych atrybutach;
• unit_pricing_measure i unit_pricing_base_measure, gdy potrzebna jest cena jednostkowa;
• pola energii i certyfikacji zgodne z wymaganiami rynku;
• cost_of_goods_sold, jeśli sklep wykorzystuje analizę marży i ma prawidłowe dane kosztowe.

Rozdzielanie danych zwiększa ich użyteczność. Ta sama informacja nie musi być powtarzana w tytule, opisie i kilku polach tylko po to, aby „wzmocnić SEO”.

Obrazy są częścią jakości danych produktowych

Nie należy sprowadzać obrazu do wpływu na CTR. Zdjęcie jest wymaganym elementem prezentacji produktu i podlega szczegółowym zasadom. Główny obraz powinien dokładnie pokazywać sprzedawany wariant, być dostępny dla Googlebota, nie zawierać tekstu promocyjnego, znaków wodnych, ramek ani zastępczej grafiki.

Google ogłosił również podniesienie minimalnego wymagania głównych obrazów do 500 × 500 px od 31 stycznia 2027 r. Ponieważ publikacja tego wpisu poprzedza termin egzekwowania, katalog warto przygotować wcześniej, bez sztucznego powiększania miniaturek.

Do additional_image_link można przesłać dodatkowe ujęcia, w tym zastosowanie produktu. Dobra sekwencja pokazuje skalę, detal, tył, opakowanie i kontekst, o ile pozostaje zgodna z ofertą.

Obrazy utworzone lub istotnie przetworzone przez generatywną AI wymagają zachowania odpowiednich metadanych IPTC, m.in. DigitalSourceType. Nie wolno usuwać oznaczeń zapisanych przez narzędzia takie jak Product Studio. Syntetyczne tło nie może wprowadzać w błąd co do cech produktu, zestawu ani rozmiaru.

Spójność feedu, strony i checkoutu

Google porównuje dane z feedu z informacjami na stronie. Tytuł powinien odpowiadać produktowi, a cena i dostępność muszą zgadzać się na landing page’u, w danych strukturalnych oraz w koszyku. Rozbieżności mogą prowadzić do ostrzeżeń, odrzuceń i złego doświadczenia użytkownika.

Najczęstsze rozjazdy to:

• feed pokazuje cenę najtańszego wariantu, ale link otwiera droższy;
• produkt oznaczony jako dostępny nie może zostać dodany do koszyka;
• obraz przedstawia inny kolor niż wybrany wariant;
• tytuł zawiera zestaw, a strona sprzedaje jedną sztukę;
• cena promocyjna nie ma prawidłowego okresu albo warunków;
• aktualizacja w ERP nie dociera wystarczająco szybko do Merchant Center.

Automatyczne aktualizacje mogą ograniczać część rozbieżności, ale nie powinny zastępować poprawnego źródła. Feed, API, dane strukturalne i checkout muszą opierać się na tej samej logice produktu.

Reguły atrybutów, źródła dodatkowe i poprawa u źródła

Reguły atrybutów w Merchant Center mogą łączyć kolumny, dodawać wartości i warunkowo przekształcać dane. Przykładowo tytuł może powstać z marki, typu, modelu, koloru i rozmiaru. Dokumentacja Set up your attribute rules opisuje m.in. operacje Set to, Extract i Take latest.

Reguły są dobre do:

• szybkiej korekty spójnych błędów;
• testu struktury na ograniczonej grupie;
• wzbogacenia danych ze źródła dodatkowego;
• mapowania własnych nazw kolumn na atrybuty Google;
• tymczasowego obejścia ograniczenia systemu sklepu.

Nie powinny tworzyć drugiego, nieudokumentowanego systemu zarządzania produktem. Jeżeli kolor, GTIN lub marka są błędne w ERP, sklepie i marketplace’ach, najlepiej naprawić dane u źródła. Złożone reguły bez właściciela potrafią po miesiącach nadpisywać poprawne wartości i trudno je diagnozować.

Każda reguła powinna mieć opis celu, zakres, datę, właściciela i sposób wycofania. Zmiany wymagają ponownego przetworzenia danych, więc efekt nie zawsze pojawia się natychmiast.

Etykiety własne pomagają zarządzać biznesem

custom_label_0–4 nie są widocznym opisem produktu i nie służą do dopasowania zapytań. Pomagają dzielić katalog według logiki, której nie ma w standardowych atrybutach, np.:

• poziom marży;
• sezon;
• bestseller lub long tail;
• ryzyko braku zapasu;
• etap cyklu życia;
• grupa testowa tytułów;
• priorytet biznesowy.

Wartości powinny być stabilne, wzajemnie zrozumiałe i możliwe do automatycznego odświeżania. Etykieta „wysoka marża” bez definicji szybko traci znaczenie.

Jak testować tytuły bez fałszywej pewności

W aukcji produktowej trudno przeprowadzić idealny test A/B, ponieważ popyt, ceny, zapas, konkurencja i uczenie kampanii zmieniają się równocześnie. Nie należy także duplikować tej samej oferty tylko po to, aby wysłać dwa tytuły.

Praktyczny proces:

1. Diagnoza jakości danych. Najpierw odrzucenia, identyfikatory, warianty i zgodność strony; później copy.
2. Hipoteza. Np. przesunięcie modelu przed nazwę kolekcji poprawi trafność zapytań o konkretny wariant.
3. Grupa produktów. Podobna kategoria, wystarczający ruch i brak planowanej zmiany cenowej.
4. Grupa porównawcza. Produkty o zbliżonym popycie pozostają bez zmiany, jeśli katalog na to pozwala.
5. Rejestr wersji. Poprzedni tytuł, nowy tytuł, data, reguła i zakres ID.
6. Okres obserwacji. Obejmuje przetworzenie feedu i reprezentatywny cykl sprzedaży, bez arbitralnego „trzy dni wystarczą”.
7. Ocena wielowymiarowa. Diagnostyka, wyświetlenia, typ zapytań, CTR, współczynnik konwersji, przychód, marża i udział w dostępnych wyświetleniach.
8. Decyzja per kategoria. Wyniku z elektroniki nie przenosi się automatycznie na odzież.

Zmiana może zwiększyć wyświetlenia i jednocześnie obniżyć jakość ruchu. Może też zmniejszyć CTR, ale poprawić konwersję dzięki większej precyzji. Dlatego sukcesu nie należy definiować pojedynczym wskaźnikiem.

Priorytetyzacja katalogu

Nie każdy produkt zasługuje na ten sam nakład pracy. Kolejność można ustalić według:

• udziału w przychodzie lub marży;
• dostępnego zapasu i ciągłości dostaw;
• potencjału popytu przy niskiej obecnej widoczności;
• liczby odrzuceń lub brakujących atrybutów;
• strategicznej roli kategorii;
• możliwości zbudowania powtarzalnej reguły;
• sezonu i czasu potrzebnego na przetworzenie zmian.

Najpierw naprawia się problemy blokujące emisję i dane kluczowe dla rozpoznania produktu. Dopiero później optymalizuje kolejność słów. W katalogu z błędnymi cenami, wariantami i GTIN praca nad stylistyką tytułów jest złym priorytetem.

Profesjonalny proces optymalizacji feedu

1. Audyt źródeł. ERP/PIM, platforma sklepu, integrator, Merchant Center, dane strukturalne i checkout.
2. Diagnostyka zgodności. Odrzucenia, ostrzeżenia, rozjazdy cen i dostępności.
3. Ocena kompletności. GTIN, marka, MPN, kategorie, warianty, obrazy i wysyłka.
4. Badanie języka kategorii. Zapytania, filtry sklepu, wyszukiwarka wewnętrzna i dane sprzedażowe.
5. Szablony per kategoria. Hierarchia cech z wyjątkami dla konkretnych typów produktów.
6. Kontrolowany test. Mała grupa, stabilne ID, wersjonowanie i grupa porównawcza.
7. Wdrożenie i monitoring. Przetworzenie, diagnostyka, jakość ruchu i wynik biznesowy.
8. Utrzymanie. Właściciel danych, alerty, dokumentacja reguł i cykliczna kontrola taksonomii.

Najczęstsze błędy

Najczęstsze pytania

Ile znaków może mieć tytuł produktu w Merchant Center?

Aktualny limit title i treści w structured_title wynosi 150 znaków. Nie oznacza to, że cały tytuł będzie widoczny w każdym formacie. Najważniejsze informacje powinny pojawić się wcześnie, bez poświęcania naturalności i zgodności ze stroną.

Czy tytuł w feedzie może różnić się od tytułu w sklepie?

Może być uporządkowany pod prezentację w Shopping, ale musi dokładnie opisywać ten sam produkt i odpowiadać nazwie na stronie docelowej. Istotna rozbieżność, dodatkowy wariant lub cecha nieobecna na stronie może prowadzić do problemów i wprowadzać klienta w błąd.

Czy warto dodawać markę na początku?

Zależy od sposobu zakupu. Dla rozpoznawalnego produktu markowego marka i model często są najważniejsze. Dla towaru bez znanej marki wcześniej może pojawić się typ i zastosowanie. Decyzja powinna wynikać z kategorii, zapytań i czytelności.

Jak oznaczać tytuły stworzone przez AI?

Google wymaga structured_title z digital_source_type=trained_algorithmic_media dla tytułów wygenerowanych przez generatywną AI. Treść nadal musi spełniać wszystkie wymagania, być prawdziwa i zgodna ze stroną.

Czy reguły Merchant Center wystarczą do poprawy feedu?

Są przydatne do mapowania, wzbogacania i szybkich testów. Nie zastąpią poprawnych danych źródłowych, jeśli błędy dotyczą wielu kanałów lub wymagają wiedzy produktowej. Złożone reguły trzeba dokumentować i monitorować.

Jak ocenić efekt zmiany tytułów?

Potrzebna jest zapisana hipoteza, kontrolowana grupa produktów, wersjonowanie i odpowiednio długi okres. Ocenia się diagnostykę, wyświetlenia, trafność zapytań, CTR, konwersję, sprzedaż i marżę. Nie należy duplikować produktu tylko po to, by wysłać dwa tytuły.

Najważniejsze wnioski

• Tytuł jest ważnym elementem danych produktowych, ale działa razem z identyfikatorami, kategorią, wariantami, obrazem, ceną i stroną.
• Limit 150 znaków nie jest zaproszeniem do ich wypełnienia; priorytetem są dokładność, czytelność i ważne cechy.
• Warianty wymagają własnych danych i stabilnych ID oraz prawidłowego grupowania.
• GTIN, marka i MPN muszą pochodzić z wiarygodnego źródła — nie wolno ich zgadywać.
• AI-generated titles i obrazy mają osobne wymagania dotyczące oznaczeń oraz metadanych.
• Najpierw usuwa się problemy z kwalifikacją i spójnością, później testuje copy tytułów.
• Wynik ocenia się po wartości dla biznesu, nie samym wzroście kliknięć.

Podstawy architektury danych rozwija artykuł Czym jest i jak wykorzystać feed produktowy. Integrację sprzedaży online i lokalnej opisuje przewodnik Local Inventory Ads i omnichannel.

Źródła i dalsza lektura

• Google Merchant Center: specyfikacja danych produktów
• Google Merchant Center: title i structured_title
• Google Merchant Center: unikalne identyfikatory produktów
• Google Merchant Center: konfiguracja reguł atrybutów
• Google Merchant Center: identifier_exists
• Czym jest i jak wykorzystać feed produktowy
• Do czego służy Google Merchant Center i jak nim zarządzać