Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
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.
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ć.
Są trzy drogi i każda ma inny koszt utrzymania.
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.
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.
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.
Tu leży różnica między sklepem jednobranżowym a wielobranżowym: nie ma jednego zestawu atrybutów dla wszystkiego.
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.
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.
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ść.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |