Tworzenie i optymalizacja pliku XML z ofertą dla sklepów wielobranżowych.

Jeden plik, kilkanaście różnych branż

Baner wejsciowyParallax

Tworzenie i optymalizacja pliku XML z ofertą dla sklepów wielobranżowych.

Jeden plik, kilkanaście różnych branż

Autor nie posiada zdjęcia
Tomasz Piasecki
31 stycznia 2022

Sklep, który sprzedaje wyłącznie obuwie, ma z plikiem produktowym problem prosty: jeden zestaw atrybutów, jedna logika tytułów, jedno drzewo kategorii. Sklep, który obok obuwia sprzedaje elektronikę, książki, artykuły dla dzieci i chemię gospodarczą, ma problem innego rodzaju — bo każda z tych grup ma inne wymagania, a plik jest jeden.

Widzę to na większości kont wielobranżowych, które przejmuję. Plik generuje wtyczka sklepu w domyślnej konfiguracji, tytuły powstają według jednego szablonu dla całego asortymentu, kategorie Google są przypisane jednym wpisem do wszystkiego, a w Merchant Center świeci się kilkaset odrzuceń, których nikt nie przeglądał od miesięcy. Kampanie działają, bo działają na tym, co przeszło walidację.

Ten tekst jest o pracy, którą trzeba wykonać, żeby taki plik dawał się utrzymać: o architekturze generowania, o poprawności technicznej, o mapowaniu kategorii i o atrybutach, które w jednej grupie produktów są wymagane, a w innej bez znaczenia.

Jeden plik czy kilka plików

Pierwsza decyzja i najbardziej strategiczna. Merchant Center przyjmuje wiele plików podstawowych w jednym koncie, więc pytanie nie jest techniczne, a organizacyjne.

Za jednym plikiem mówi prostota: jedno miejsce generowania, jeden harmonogram, jeden raport. Sprawdza się, gdy asortyment jest liczny, ale wewnętrznie spójny.

Za podziałem mówią trzy rzeczy. Różne tempo zmian — asortyment rotujący warto odświeżać częściej niż katalog stały. Odpowiedzialność — jeśli za elektronikę i za odzież odpowiadają w firmie inne osoby, osobne pliki oznaczają, że każda widzi tylko swoje błędy. Diagnostyka — przy jednym pliku z całym sklepem lista problemów w Merchant Center jest tak długa, że nikt jej nie przechodzi do końca.

Pliki dzielę więc według grup asortymentu wymagających innego zestawu atrybutów, a nie według kategorii marketingowych. Odzież osobno, bo ma własne wymagania. Książki i multimedia osobno, bo mają identyfikatory wydawnicze. Reszta razem, dopóki nie zacznie przeszkadzać.

Jak generować plik, żeby dało się nim zarządzać

Są trzy drogi i każda ma inny koszt utrzymania.

  • Wtyczka lub wbudowany eksport platformy sklepowej — najszybciej i najtaniej. Wada: zakres atrybutów jest ograniczony do tego, co przewidział autor, a warunkowa logika dla różnych grup produktów zwykle nie jest przewidziana wcale.
  • Zewnętrzne narzędzie do plików danych — pobiera surowy eksport ze sklepu i buduje z niego plik wyjściowy według reguł, które sami ustawiamy. Największa elastyczność bez pracy programisty, koszt abonamentowy i kolejny element w łańcuchu, który może zawieść.
  • Własny eksport po stronie sklepu — pełna kontrola i możliwość korzystania z danych, których nie ma w interfejsie. Wymaga programisty i dokumentacji, bo za dwa lata nikt nie będzie pamiętał, skąd bierze się dana wartość.

Niezależnie od drogi trzymam się jednej zasady: reguły muszą być zapisane poza plikiem. Prosty arkusz z opisem, skąd bierze się każdy atrybut i jakie wyjątki obowiązują dla których kategorii. Bez tego każda zmiana w sklepie oznacza odgadywanie własnych decyzji z przeszłości.

Osobna droga to interfejs programistyczny. Content API for Shopping pozwala aktualizować oferty bez czekania na pobranie pliku i przy dużych, szybko zmieniających się katalogach bywa jedynym sensownym rozwiązaniem — zwłaszcza gdy problemem są ceny i stany magazynowe, nie dane produktowe.

Poprawność techniczna pliku

Zanim zajmę się treścią atrybutów, sprawdzam, czy plik jest w ogóle poprawny. To brzmi banalnie, a w praktyce jest źródłem awarii, których nie widać w raportach kampanii, dopóki nie zniknie połowa ofert.

Rzeczy, które kontroluję zawsze: kodowanie znaków ustawione na UTF-8 i faktycznie takie w pliku, poprawne znaki specjalne w opisach — ampersandy, cudzysłowy i znaki mniejszości muszą być zapisane w formie dopuszczonej przez XML albo zamknięte w sekcji znaków niekontrolowanych. Jeden nieuciekniony znak potrafi unieważnić plik od tego miejsca w dół.

Dalej: przestrzeń nazw atrybutów Google zadeklarowana w nagłówku, spójna struktura wpisów, brak duplikatów identyfikatorów. Duplikat identyfikatora to najczęstszy błąd w sklepach wielobranżowych, bo ten sam numer katalogowy pojawia się u dwóch dostawców.

Warto też pilnować rozmiaru i czasu odpowiedzi. Pobieranie dużych plików potrafi się zwyczajnie przerwać — kompresja gzip rozwiązuje to w większości przypadków. Sprawdzam również, czy plik nie jest generowany „na żądanie” przy każdym pobraniu, bo przy dużym katalogu skończy się to przekroczeniem czasu.

Kategorie: własne drzewo, taksonomia Google i typ produktu

W sklepie wielobranżowym to najbardziej pracochłonny obszar, bo mamy do czynienia z trzema różnymi klasyfikacjami naraz.

Kategoria Google pochodzi z gotowej taksonomii wyszukiwarki. Google potrafi przypisać ją sam na podstawie danych produktu, ale w części grup asortymentu atrybut jest wymagany i tam trzeba go podać ręcznie. Nawet gdzie nie jest wymagany, wolę mieć go wypełniony — automatyczne przypisanie w asortymencie mieszanym myli się częściej niż w sklepie jednobranżowym.

Typ produktu to nasza własna ścieżka kategorii, w dowolnym kształcie. To pole jest podstawą podziału asortymentu w kampaniach, więc powinno odwzorowywać drzewo, którym faktycznie chcemy zarządzać, a nie nawigację sklepu przygotowaną pod użytkownika. Jeżeli w kampaniach dzielę asortyment po marce w obrębie kategorii, ta informacja musi znaleźć się w ścieżce.

Mapowanie utrzymuję jako osobny arkusz przypisań. Nowa kategoria w sklepie oznacza wpis w tym arkuszu — jeśli tego nie ma w procesie, po roku duża część asortymentu wisi w kategorii domyślnej.

Atrybuty wymagane w różnych grupach asortymentu

Tu leży różnica między sklepem jednobranżowym a wielobranżowym: nie ma jednego zestawu atrybutów dla wszystkiego.

  • Odzież i obuwie — rozmiar, kolor, płeć i grupa wiekowa. W części krajów są to atrybuty wymagane, a wszędzie tam, gdzie nie są, i tak decydują o dopasowaniu do zapytań z rozmiarem albo kolorem.
  • Książki i multimedia — identyfikator wydawniczy jako numer produktu. To grupa, w której identyfikatory są dostępne praktycznie zawsze, więc ich brak natychmiast obniża widoczność ofert.
  • Elektronika — numer katalogowy producenta obok kodu kreskowego, stan produktu i informacja o zgodności, jeśli dotyczy akcesoriów.
  • Produkty wykonywane na zamówienie i rękodzieło — brak kodu kreskowego jest tu normalny, ale trzeba go zadeklarować odpowiednim atrybutem, zamiast zostawiać puste pole.
  • Produkty z ograniczeniami — alkohol, suplementy, produkty dla dorosłych podlegają osobnym zasadom i wymagają dodatkowych oznaczeń. Warto to sprawdzić przed dodaniem takiej kategorii do sklepu, nie po odrzuceniu ofert.

Do tego dochodzą pola obowiązujące wszystkich: tytuł w limicie stu pięćdziesięciu znaków, opis, adres oferty, obraz, cena, dostępność i marka. W asortymencie mieszanym pilnuję zwłaszcza tytułów — szablon dobry dla elektroniki daje bezsensowne wyniki w książkach, więc musi zależeć od kategorii.

Warianty, zestawy i wielopaki

Trzy sytuacje, które w plikach wielobranżowych sklepów są najczęściej opisane błędnie.

Warianty tego samego produktu — rozmiary, kolory, pojemności — powinny być osobnymi ofertami z własnymi identyfikatorami, powiązanymi wspólnym identyfikatorem grupy. Wtedy Google rozumie, że to jedna rodzina produktów. Wysłanie ich jako niezależnych ofert bez powiązania daje duplikaty w wynikach.

Zestawy wymagają oznaczenia, że oferta jest zestawem różnych produktów. To istotne w sklepach z artykułami dla domu i kosmetykami, gdzie zestawy są normalnym elementem asortymentu.

Wielopaki to ta sama rzecz w większej liczbie sztuk i mają własny atrybut na liczbę jednostek. Bez niego porównanie cen wypada dla nas absurdalnie — nasza cena za sześciopak stoi obok ceny konkurencji za jedną sztukę.

Warto przejść te trzy przypadki kategoria po kategorii, bo każda platforma sklepowa modeluje je inaczej i domyślny eksport rzadko trafia we wszystkie trzy.

Reguły, pliki uzupełniające i kontrola jakości

Nie wszystko trzeba naprawiać w źródle i to jest wiadomość, która oszczędza dużo czasu.

Merchant Center pozwala nakładać na dane reguły: podstawiać wartości domyślne, przenosić dane z jednego atrybutu do drugiego, podmieniać teksty, ustawiać kategorię dla wybranego zakresu ofert. To dobre miejsce na poprawki, których platforma sklepowa nie potrafi wykonać, i na testy, zanim zamówimy zmianę u programisty.

Pliki uzupełniające służą do dokładania danych do istniejących ofert bez ruszania pliku podstawowego. Używam ich do etykiet niestandardowych opartych na marży i rotacji, bo te informacje pochodzą z systemu magazynowego, a nie ze sklepu.

Na koniec rzecz, bez której cała reszta się rozjeżdża: harmonogram i przegląd. Ustalam częstotliwość pobierania adekwatną do tempa zmian cen, włączam automatyczne aktualizacje na podstawie danych ze strony produktu i raz w tygodniu przeglądam diagnostykę, sortując problemy po liczbie dotkniętych ofert. Pilnuję też, żeby liczba aktywnych ofert dawała się uzgodnić z liczbą produktów dostępnych w sklepie — rozjazd między tymi liczbami jest najprostszym sygnałem, że plik przestał opisywać rzeczywistość.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.