Google Merchant Center rozszerza możliwości prezentowania ofert o sześć opcjonalnych atrybutów konwersacyjnych, dzięki którym funkcje AI, w tym AI Mode, mogą trafniej interpretować dane produktowe. Pozwalają one uporządkować informacje dotyczące m.in. pytań klientów, dokumentacji technicznej, wariantów i powiązań między produktami. Choć nie gwarantują wyższych pozycji ani większej sprzedaży, mogą poprawić widoczność i zrozumienie oferty przez AI. Jak wykorzystać ich potencjał i na co zwrócić uwagę podczas wdrożenia?
Najważniejsze informacje w skrócie
-
Google udostępnia sześć atrybutów konwersacyjnych: question_and_answer, document_link, related_product, item_group_title, variant_option oraz popularity_rank.
-
Wszystkie są opcjonalne. Google wskazuje, że ich dodanie nie zmienia statusu zatwierdzenia istniejących produktów.
-
Nie trzeba wypełniać każdego pola dla całego katalogu. Warto zacząć tam, gdzie klienci rzeczywiście potrzebują dodatkowych informacji.
-
Najbezpieczniej przeprowadzić pilotaż za pomocą dodatkowego źródła danych, nazywanego też feedem suplementarnym. Google rekomenduje tę drogę, ponieważ pozwala uzupełnić dane bez przebudowy źródła podstawowego.
-
Informacji nie należy bez potrzeby powielać między opisem, product_highlight, product_detail, question_and_answer i dokumentacją PDF.
-
Sama obecność atrybutów nie gwarantuje, że informacje z nich zostaną wykorzystane w każdej odpowiedzi AI ani że wpłyną na wyniki kampanii.
Czym są atrybuty konwersacyjne w Merchant Center?
Standardowy feed produktowy dobrze odpowiada na podstawowe pytania: co to za produkt, ile kosztuje, czy jest dostępny i gdzie można go kupić. Gorzej radzi sobie z informacjami, które wynikają z kontekstu. Czy urządzenie współpracuje z konkretnym akcesorium? Która część jest niezbędna do uruchomienia produktu? Czym dwa warianty różnią się poza kolorem? Czy instrukcja przewiduje samodzielny montaż?
Atrybuty konwersacyjne uzupełniają tę lukę. Nie zastępują pól takich jak title, description, price czy availability. Tworzą dodatkową warstwę danych, dzięki której relacje i szczegóły ważne dla kupującego mogą zostać przekazane w czytelnym formacie.
Obecnie specyfikacja obejmuje sześć pól:
- Pytania i odpowiedzi [question_and_answer]
- Link do dokumentu [document_link]
- Produkt powiązany [related_product]
- Tytuł grupy produktów [item_group_title]
- Opcja wariantu [variant_option]
- Poziom popularności [popularity_rank]
Każdy z atrybutów pełni inną funkcję. question_and_answer porządkuje odpowiedzi na pytania klientów, document_link prowadzi do instrukcji i kart technicznych, a related_product wskazuje kompatybilne lub powiązane produkty. Atrybuty item_group_title i variant_option ułatwiają rozpoznawanie wariantów, natomiast popularity_rank określa popularność produktu w ofercie sprzedawcy.
Dlaczego Google rozwija rozwiązania wspierające wyszukiwanie konwersacyjne?
Sposób szukania produktów stopniowo się zmienia. Klient coraz częściej nie wpisuje już krótkiej frazy, na przykład „ekspres automatyczny 15 barów”, lecz zadaje kilka powiązanych pytań: czy w urządzeniu można używać kawy mielonej, czy blok zaparzający jest wyjmowany, jaki filtr do niego pasuje i czym droższy wariant różni się od podstawowego.
Aby odpowiedzieć sensownie, system potrzebuje danych, które są nie tylko obszerne, ale też jednoznaczne. Długi opis produktu może zawierać wszystkie potrzebne informacje, jednak wymaga ich rozpoznania i interpretacji. Ustrukturyzowane atrybuty wskazujące konkretne pytanie i odpowiedź albo rodzaj relacji między dwoma SKU ograniczają ryzyko nieporozumień.
Ma to znaczenie również dla samego sklepu. Dobrze przygotowane dane mogą uporządkować wiedzę rozproszoną w karcie produktu, instrukcji, systemie PIM i skrzynce działu obsługi klienta. Wdrożenie nie powinno więc zaczynać się od „napisania treści pod AI”, ale od zebrania prawdziwych informacji o produkcie i ustalenia, które z nich pomagają klientowi podjąć decyzję.
Który atrybut warto wdrożyć w konkretnym sklepie?
Nie jest to zamknięta lista. W sklepie z częściami motoryzacyjnymi największą wartość może przynieść related_product, podczas gdy producent sprzętu technicznego skorzysta przede wszystkim z document_link. W branży modowej szczególne znaczenie będzie miało spójne opisanie wariantów. Dobór pól powinien wynikać z formy katalogu i pytań klientów, a nie z potrzeby wypełnienia wszystkich dostępnych kolumn.
Sześć atrybutów konwersacyjnych w praktyce
Question and answer [question_and_answer]: odpowiedzi na realne pytania kupujących
question_and_answer służy do przekazywania par składających się z pytania i odpowiedzi. Na jeden produkt można dodać maksymalnie 30 takich par. Pytanie i odpowiedź mogą mieć po 1000 znaków, a łączna długość wszystkich wartości dla jednego produktu nie może przekroczyć 10 000 znaków.
Przykład dla ekspresu do kawy:
"Czy blok zaparzający można wyjąć?":"Tak. Blok zaparzający jest wyjmowany i można go płukać pod bieżącą wodą.","Czy urządzenie obsługuje kawę mieloną?":"Tak. Ma osobny otwór przeznaczony na jedną porcję kawy mielonej."
Najbardziej przydatnych pytań zwykle nie trzeba wymyślać. Znajdują się w wiadomościach do obsługi klienta, zapytaniach wpisywanych w wewnętrznej wyszukiwarce sklepu, recenzjach, materiałach producenta i rozmowach przedsprzedażowych. Rola zespołu nie polega na tworzeniu trzydziestu pytań za wszelką cenę. Lepiej dodać pięć par zawierających potwierdzone odpowiedzi, które rozwiązują realne wątpliwości, niż rozbudowaną sekcję pełną oczywistości.
Odpowiedź powinna być konkretna i samodzielnie zrozumiała. Nie warto umieszczać w niej słów kluczowych dla samego SEO, języka promocyjnego ani informacji szybko tracących aktualność. Google odradza dodawanie w tym polu cen, terminów promocji, danych o wysyłce i dostawie, nazw firmy oraz innych treści, dla których istnieją osobne atrybuty.
Trzeba też uważać na składnię. question_and_answer jest powtarzalnym atrybutem grupowym, a przecinki, dwukropki i cudzysłowy mają w nim znaczenie techniczne. Google rekomenduje w przypadku plików tekstowych format TSV, ponieważ jest mniej podatny na błędy niż CSV. Jeżeli treść zawiera znaki specjalne, należy zastosować zasady ujmowania wartości w cudzysłów i zabezpieczania znaków specjalnych, właściwe dla używanego źródła danych.
Jeśli te same informacje znajdują się już w podlinkowanym dokumencie PDF, nie należy ich mechanicznie kopiować do question_and_answer. Google wskazuje, że może pozyskać odpowiedzi z dokumentacji przekazanej przez document_link. Warto natomiast sprawdzić, czy PDF rzeczywiście zawiera aktualne i jednoznaczne dane.
Document link [document_link]: dokumentacja jako źródło wiedzy o produkcie
document_link pozwala podać adres oficjalnego dokumentu PDF, na przykład instrukcji obsługi, karty technicznej, schematu montażu, materiału szkoleniowego albo ulotki dołączanej do opakowania. Jest to szczególnie przydatne w przypadku elektroniki, AGD, narzędzi, produktów wymagających montażu oraz części o rozbudowanej specyfikacji.
Na jeden produkt można przesłać maksymalnie pięć adresów. Każdy URL może mieć do 2000 znaków, a plik PDF nie może przekraczać 50 MB. Dokument musi być publicznie dostępny bez logowania, możliwy do odczytania przez Googlebota i nieblokowany w robots.txt. Adres powinien być stabilny i nie powinien wygasać.
Przykład:
https://example.com/instrukcja-ekspresu.pdf,https://example.com/karta-techniczna-ekspresu.pdf
Wdrożenie wymaga czegoś więcej niż wklejenia linku. Sprzedawca musi mieć prawa do udostępnienia dokumentu w celach marketingowych. URL powinien zaczynać się od http:// lub https://, być zgodny z RFC 3986 i zawierać wyłącznie znaki ASCII; znaki specjalne trzeba odpowiednio zakodować.
Dobry PDF ma czytelną strukturę, odnosi się do właściwego modelu i nie łączy kilku generacji urządzenia bez wyraźnego rozróżnienia. Jeżeli instrukcja została zastąpiona nowszą wersją, lepiej zaktualizować plik pod tym samym stabilnym adresem niż tworzyć kolejne, szybko wygasające linki.
Related product [related_product]: relacje i kompatybilność w katalogu
related_product służy do określania relacji między opisywaną ofertą a innym produktem z katalogu. Może to być część konieczna do działania, opcjonalne akcesorium, zamiennik albo produkt często kupowany razem.
Każda relacja składa się z trzech wymaganych elementów:
|
Podatrybut |
Znaczenie |
|
relationship_type |
rodzaj relacji między produktami |
|
identifier_type |
typ identyfikatora: id albo gtin |
|
identifier |
identyfikator drugiego produktu zgodny z wybranym typem |
Google obsługuje sześć rodzajów relacji:
|
Wartość |
Kiedy jej użyć |
Przykład |
|
part_of_set |
produkt jest elementem zestawu lub pasującej kolekcji |
krzesło należące do tego samego zestawu co stół |
|
required_part |
drugi produkt jest niezbędny do działania |
dedykowany akumulator do urządzenia |
|
often_bought_with |
produkty są często kupowane razem |
etui i telefon |
|
substitute |
drugi produkt może zastąpić aktualną ofertę |
model o porównywalnym zastosowaniu |
|
different_brand |
identyczny produkt jest sprzedawany pod inną marką |
ten sam wyrób oferowany jako marka własna |
|
accessory |
drugi produkt jest opcjonalnym dodatkiem |
dodatkowy pojemnik na mleko do ekspresu |
Przykładowy zapis:
required_part:id:FILTR-A4,accessory:id:POJEMNIK-MLEKO-02
Na jeden produkt można podać maksymalnie 30 relacji. Jeżeli ten sam typ dotyczy kilku ofert, każdą trzeba przekazać jako osobną, kompletną wartość atrybutu. Nie należy łączyć kilku identyfikatorów w jednym polu identifier. W przypadku identifier_type=id identyfikator może zawierać litery, cyfry, podkreślenia i łączniki, ale nie powinien zawierać znaków używanych do budowania składni grupowej, takich jak przecinki czy dwukropki. Jeśli wybrano identifier_type=gtin, wartość musi być prawidłowym numerem GTIN.
W praktyce najtrudniejszy nie jest format, lecz jakość powiązań. „Często kupowane razem” powinno wynikać z danych o zamówieniach, a „zamiennik” z potwierdzonej zgodności funkcjonalnej. Błędnie wskazana część lub błędnie dobrane akcesorium mogą być dla kupującego większym problemem niż brak relacji.
Item group title [item_group_title]: wspólna nazwa rodziny wariantów
item_group_title nadaje wspólny tytuł wszystkim wariantom połączonym tym samym item_group_id. Nie zastępuje indywidualnego title na poziomie SKU. Pomaga natomiast wyraźnie oddzielić nazwę modelu od cech konkretnej wersji.
Przykład:
item_group_id: KURTKA-NP-01
item_group_title: Kurtka trekkingowa NorthPeak
title konkretnego SKU: Kurtka trekkingowa NorthPeak granatowa, rozmiar M
Wartość może mieć od 1 do 150 znaków. Musi być taka sama dla wszystkich produktów z tym samym item_group_id, a jednocześnie różnić się od tytułów poszczególnych wariantów. Najlepiej, aby była krótsza i bardziej ogólna niż pełne tytuły SKU: powinna opisywać rodzinę produktu, nie konkretny kolor, rozmiar czy pojemność.
Variant option [variant_option]: precyzyjne różnice między wariantami
variant_option opisuje cechy, które odróżniają dany wariant od pozostałych produktów w tej samej grupie. W przypadku kurtki mogą to być kolor i rozmiar, a w przypadku laptopa – pamięć, przekątna ekranu, procesor i układ graficzny.
Przykład:
color:navy,size:M
Atrybut składa się z par name i value. Każdy z tych elementów może mieć do 250 znaków. Dla jednego produktu można przekazać maksymalnie 30 par, a ich łączna długość nie może przekroczyć 5000 znaków.
Najważniejsza jest spójność w obrębie grupy. Jeśli jeden wariant z item_group_id KURTKA-NP-01 ma nazwy color i size, wszystkie pozostałe warianty w tej grupie powinny korzystać z takiego samego zestawu nazw. Zmieniają się wartości, nie struktura. Mieszanie nazw color, colour i kolor w ramach jednej rodziny utrudni prawidłowe odczytanie danych.
variant_option nie zastępuje standardowych pól wariantowych. Jeżeli warianty różnią się kolorem, rozmiarem, wzorem, materiałem, grupą wiekową lub płcią, Google zaleca przesłanie zarówno variant_option, jak i odpowiedniego atrybutu standardowego, na przykład color, size albo material.
Popularity rank [popularity_rank]: popularność według danych sprzedawcy
popularity_rank to liczba z zakresu od 0.0 do 100.0, za pomocą której sprzedawca określa popularność produktu na tle całego swojego asortymentu. Im wyższa wartość, tym wyżej produkt wypada w wewnętrznej ocenie popularności. Nie jest to średnia ocen klientów ani wskaźnik obliczany przez Google.
Poprawny zapis wygląda tak:
95.5
Nie należy dodawać znaku procentu, a separatorem dziesiętnym musi być kropka, również w polskojęzycznym feedzie. Zapis 95,5 byłby nieprawidłowy.
Dokumentacja Google nie podaje szczegółowego wzoru obliczeń. Sklep może oprzeć ranking na liczbie sprzedanych sztuk albo zamówień w ustalonym okresie, na przykład ostatnich 30 lub 90 dni. Ważne, aby tę samą metodę stosować w całym katalogu, konsekwentnie uwzględniać zwroty i udokumentować sposób obliczeń. Wartości należy aktualizować po istotnej zmianie popularności, zamiast ustawiać je raz i pozostawiać bez kontroli.
Jak dodać atrybuty konwersacyjne do Merchant Center?
Google przewiduje trzy drogi: podstawowe źródło danych, dodatkowe źródło danych oraz Merchant API. Wybór zależy od sposobu zarządzania katalogiem.
1. Dodatkowe źródło danych – najlepsze do pilotażu
Dodatkowe źródło danych, często nazywane feedem suplementarnym, uzupełnia informacje już przesłane w źródle podstawowym. Łączenie odbywa się na podstawie identyfikatora produktu [id], dzięki czemu nie trzeba kopiować ceny, dostępności, tytułu ani pozostałych pól.
To wygodne rozwiązanie na początek. W razie błędu można odłączyć dodatkowe źródło bez ingerowania w główny proces zasilania katalogu. Aby zakładka źródeł uzupełniających była dostępna, dodatek Advanced data source management musi być aktywny w Merchant Center. Identyfikator produktu musi odpowiadać wartości w źródle podstawowym, a etykieta i język – jego ustawieniom.
2. Podstawowe źródło danych – dobre przy dojrzałej integracji
Jeżeli PIM, platforma sklepowa lub generator feedu obsługuje nowe pola i ma sprawdzony proces kontroli jakości, atrybuty można dodać bezpośrednio do głównego źródła. Upraszcza to utrzymanie danych, ale wymaga większej ostrożności przy zmianach składni i mapowaniu wariantów.
3. Merchant API – rozwiązanie dla dużych i dynamicznych katalogów
Merchant API sprawdzi się tam, gdzie pytania, relacje i popularność są aktualizowane automatycznie. Nazwy pól w zasobie API różnią się od tagów używanych w plikach. Przykładowo występują tam questionsAndAnswers, documentLinks, variantOptions, relatedProducts, popularityRank i itemGroupTitle. Nie należy więc kopiować nazw z feedu tekstowego bezpośrednio do obiektu API. Warto też sprawdzić wersję używanej biblioteki klienckiej, ponieważ nowe pola mogą pojawić się w niej później niż w samym interfejsie REST.
Przykład dodatkowego źródła danych
Poniższa tabela pokazuje logikę pliku. W produkcyjnym TSV kolumny muszą być oddzielone tabulatorami, a wartości atrybutów grupowych zapisane zgodnie z regułami składni.
|
id |
item_group_title |
variant_option |
popularity_rank |
question_and_answer |
|
KURTKA-NP-NV-M |
Kurtka trekkingowa NorthPeak |
color:navy,size:M |
78.4 |
„Czy kurtka ma odpinany kaptur?”:”Tak. Kaptur można całkowicie odpiąć.” |
|
KURTKA-NP-BK-L |
Kurtka trekkingowa NorthPeak |
color:black,size:L |
64.2 |
„Czy kurtka ma odpinany kaptur?”:”Tak. Kaptur można całkowicie odpiąć.” |
Każdy wiersz zawiera wyłącznie id oraz pola, które mają uzupełnić dane podstawowe. W rzeczywistym pliku warto również przekazać standardowe atrybuty color i size, jeśli nie są już prawidłowo przekazywane w źródle głównym.
Pierwszy z tych produktów w formacie XML może wyglądać następująco:
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
<channel>
<title>Przykładowy katalog produktów</title>
<link>https://example.com</link>
<description>Przykładowe źródło danych produktowych</description>
<item>
<g:id>KURTKA-NP-NV-M</g:id>
<g:item_group_id>KURTKA-NP-01</g:item_group_id>
<g:item_group_title>Kurtka trekkingowa NorthPeak</g:item_group_title>
<g:color>navy</g:color>
<g:size>M</g:size>
<g:popularity_rank>78.4</g:popularity_rank>
<g:variant_option>
<g:name>color</g:name>
<g:value>navy</g:value>
</g:variant_option>
<g:variant_option>
<g:name>size</g:name>
<g:value>M</g:value>
</g:variant_option>
<g:question_and_answer>
<g:question>Czy kurtka ma odpinany kaptur?</g:question>
<g:answer>Tak. Kaptur można całkowicie odpiąć.</g:answer>
</g:question_and_answer>
</item>
</channel>
</rss>
Jak przygotować wdrożenie, które da się utrzymać?
Największym ryzykiem nie jest brak wszystkich sześciu atrybutów. Jest nim wdrożenie danych bez wskazania, kto odpowiada za ich prawdziwość i aktualizację. Zestaw pytań kierowanych do BOK szybko się zmienia, instrukcje otrzymują nowe wersje, akcesoria wypadają z oferty, a popularność produktów zmienia się wraz z sezonem.
1. Zrób audyt danych, które już istnieją
Przejrzyj FAQ, opisy, product_highlight, product_detail, tabele techniczne, instrukcje PDF, dane wariantowe oraz historię pytań do obsługi klienta. Celem nie jest natychmiastowe przepisywanie treści do nowych kolumn. Najpierw trzeba ustalić, które informacje są potwierdzone, aktualne i nie zostały już przesłane w innym polu.
2. Ustal źródło prawdy dla każdego typu informacji
Źródłem specyfikacji technicznej może być PIM, kompatybilności – zatwierdzona baza produktowa, a popularity_rank – hurtownia danych sprzedażowych. Dział obsługi klienta może wskazać pytania, ale odpowiedź powinien potwierdzić właściciel produktu lub producent. Specjalista od feedów odpowiada za format, nie za domyślanie się właściwości urządzenia.
3. Zmapuj relacje i warianty
Sprawdź, czy item_group_id rzeczywiście łączy warianty jednego produktu, a nie podobne modele. Następnie ujednolić nazwy cech w variant_option. Przy related_product rozdziel kompatybilność techniczną od rekomendacji sprzedażowych: required_part powinno wynikać ze specyfikacji, natomiast often_bought_with – z zachowań klientów.
4. Wybierz rozsądny pilotaż
Nie trzeba zaczynać od całego katalogu ani wyłącznie od bestsellerów. Lepszą grupą testową będą produkty, które:
- mają wystarczający ruch, aby obserwować zmianę;
- generują wiele pytań przed zakupem;
- mają złożone warianty, akcesoria lub dokumentację;
- sprzedają się, ale ich wyniki można jeszcze poprawić;
- należą do jednej lub kilku porównywalnych kategorii.
Nie istnieje uniwersalny próg kliknięć zapewniający wiarygodny test. Dwadzieścia wejść w miesiącu może wystarczyć do znalezienia błędu technicznego, ale zwykle nie wystarczy do oceny zmiany współczynnika konwersji. Zakres pilotażu powinien odpowiadać skali konta, długości cyklu zakupowego i sezonowości.
5. Zaplanuj kontrolę i aktualizacje
Warto stworzyć prostą matrycę odpowiedzialności. Obsługa klienta zbiera pytania, właściciel produktu zatwierdza treść, osoba zarządzająca feedem kontroluje składnię, a analityk dba o spójność metody obliczania popularity_rank. Po każdej zmianie dotyczącej produktu wskazana osoba powinna potwierdzić, że odpowiedzi, dokumenty i relacje nadal są aktualne.
Kontrola jakości przed publikacją
Przed uruchomieniem źródła warto sprawdzić:
- czy każde id dokładnie odpowiada identyfikatorowi w źródle podstawowym;
- czy język i etykieta źródła są zgodne;
- czy atrybuty grupowe są prawidłowo zapisane, również w przypadku występowania znaków specjalnych;
- czy w popularity_rank separatorem dziesiętnym jest kropka zamiast przecinka i czy wartość nie zawiera znaku procentu;
- czy wszystkie warianty z jednym item_group_id mają ten sam item_group_title i zestaw nazw w variant_option;
- czy standardowe pola, takie jak color, size i material, są nadal przekazywane tam, gdzie są wymagane;
- czy linki PDF działają bez logowania, nie wygasają i nie są blokowane dla Googlebota;
- czy sklep ma prawa do udostępnienia dokumentów;
- czy related_product wskazuje istniejące SKU lub prawidłowe GTIN-y;
- czy odpowiedzi nie zawierają cen, terminów promocji, obietnic dostawy ani niepotwierdzonych informacji;
- czy treść feedu nie przeczy stronie produktowej i dokumentacji producenta.
Jak ocenić rezultat wdrożenia?
Najpierw należy rozdzielić jakość techniczną od efektu biznesowego. Na pierwszym etapie liczy się to, czy źródło zostało poprawnie przetworzone, ile produktów otrzymało komplet planowanych danych, czy dokumenty są dostępne i czy nie pojawiły się błędy mapowania wariantów.
Dopiero później można obserwować wyniki: widoczność produktów, kliknięcia, konwersje, przychód oraz liczbę powtarzających się pytań do obsługi. Dobrym rozwiązaniem jest porównanie dwóch grup podobnych produktów – jednej z wdrożonymi atrybutami i drugiej stanowiącej grupę kontrolną – w tym samym okresie. Jeśli ruch na to pozwala, pilotaż powinien trwać kilka tygodni i nie nakładać się na większe zmiany cen, kampanii lub dostępności.
Trzeba zachować ostrożność przy wnioskach. Wzrost sprzedaży po wdrożeniu nie dowodzi jeszcze, że spowodowały go same atrybuty konwersacyjne. Na wynik wpływają również sezon, działania reklamowe, konkurencja, cena i stan magazynowy. Celem testu jest sprawdzenie, czy dane są wykorzystywane poprawnie i czy pojawia się spójny sygnał poprawy, a nie przypisanie całego efektu jednej zmianie w feedzie.
Najczęstsze błędy przy atrybutach konwersacyjnych
🔴 Pisanie pytań pod słowa kluczowe zamiast na podstawie potrzeb klientów
Nienaturalne pytania i odpowiedzi nie zwiększają wartości danych. Dobry materiał brzmi jak odpowiedź kompetentnego doradcy: jest krótki, konkretny i możliwy do potwierdzenia.
🔴 Dublowanie tych samych informacji w kilku polach
Powtarzanie identycznej treści w description, product_highlight, question_and_answer i PDF-ie nie sprawia, że staje się ona ważniejsza. Zwiększa za to ryzyko, że po aktualizacji produktu treść w jednym z tych miejsc nie zostanie zaktualizowana.
🔴 Traktowanie podobnych modeli jako wariantów
Wspólny item_group_id powinien łączyć rzeczywiste warianty jednego produktu. Inny model z podobnej serii nie staje się wariantem tylko dlatego, że ma zbliżoną nazwę.
🔴 Ręczne ustawianie popularity_rank bez określonej metodologii
Przypisanie wysokich wartości produktom, które sklep chce wypromować, nie jest rzetelnym rankingiem popularności. Pole powinno wynikać z aktualnych danych sprzedażowych i być liczone tak samo dla całego asortymentu.
🔴 Niepotwierdzone relacje między produktami
Akcesorium pasujące wizualnie nie zawsze jest kompatybilne technicznie. Każdą relację required_part, substitute czy accessory warto zatwierdzić na podstawie specyfikacji.
🔴 Brak procesu aktualizacji
Nawet najlepiej przygotowany zestaw Q&A przestaje pomagać, jeśli producent zmieni funkcję urządzenia, dokument wygaśnie albo wskazany zamiennik zostanie wycofany. Atrybuty konwersacyjne są częścią danych produktowych, a nie jednorazowym projektem contentowym.
Najczęściej zadawane pytania (FAQ)
Co dalej z feedem produktowym?
Atrybuty konwersacyjne pokazują, że feed przestaje być wyłącznie techniczną listą ofert. Coraz częściej staje się uporządkowanym źródłem wiedzy o produkcie: jego zastosowaniu, wariantach, dokumentacji i relacjach z resztą katalogu.
Nie oznacza to jednak, że należy od razu uzupełnić sześć atrybutów dla każdego SKU. Rozsądniejsze podejście zaczyna się od audytu i dobrze zaplanowanego pilotażu obejmującego wybraną grupę produktów. W wielu sklepach największy sens będzie miało uporządkowanie pytań klientów i kompatybilności produktów. W innych – naprawienie grup wariantów albo udostępnienie dokumentacji, która do tej pory była trudna do odnalezienia.
Warto równolegle zadbać o fundamenty: poprawne GTIN-y, logiczną kategoryzację, spójne tytuły, aktualne ceny, dostępność i zgodność strony z feedem. Atrybuty konwersacyjne nie naprawią zaniedbanych danych podstawowych. Mogą je natomiast dobrze uzupełnić i przygotować katalog na sytuację, w której kupujący nie wpisuje już pojedynczego hasła, lecz prowadzi z wyszukiwarką całą rozmowę.
Źródła:
- Google Merchant Center Help, How to use conversational attributes
- Google Merchant Center Help, Question and answer [question_and_answer]
- Google Merchant Center Help, Document link [document_link]
- Google Merchant Center Help, Related product [related_product]
- Google Merchant Center Help, Variant option [variant_option]
Zastanawiasz się, czy to realnie przełoży się na sprzedaż?
Sprawdzimy Twój feed, pokażemy, gdzie jest największy potencjał, i przygotujemy plan wdrożenia z jasnymi priorytetami, zanim ruszymy do pracy. Zamów bezpłatną konsultację.