Dlaczego plik produktowy jest dobrym źródłem

To brzmi nieintuicyjnie, bo plik powstał do zupełnie innego celu. A jednak ma trzy cechy, których zwykle brakuje bazie sklepowej.

Po pierwsze, jest znormalizowany. Wymagania Merchant Center wymuszają jednolite jednostki, waluty, format dostępności i spójne identyfikatory. Baza sklepowa bywa pod tym względem archeologicznym stanowiskiem z kilkoma warstwami konwencji.

Po drugie, jest kompletny w zakresie tego, co da się sprzedawać. Produkty bez ceny, bez zdjęcia albo bez opisu z pliku po prostu wypadają, więc to, co w nim zostaje, ma minimum wymaganych informacji.

Po trzecie, jest weryfikowany z zewnątrz. Merchant Center codziennie sprawdza dane i zgłasza rozbieżności, co jest formą darmowego audytu, którego nikt inny sklepowi nie zrobi.

Nie twierdzę, że plik powinien być głównym magazynem danych sklepu. Twierdzę, że jego struktura jest dobrym wzorcem dla tego, jak dane o produktach powinny wyglądać w każdym systemie, który je konsumuje — w tym w silniku rekomendacji.

Które atrybuty faktycznie przydają się rekomendacjom

Silniki rekomendacji różnią się algorytmem, ale wszystkie potrzebują tego samego rodzaju metadanych o produkcie.

• Identyfikator i kod towaru — podstawa łączenia zdarzeń z katalogiem. Jeśli rekomendacje pracują na identyfikatorach wewnętrznych, a plik używa innych, wszelkie porównania między systemami wymagają mapowania i to mapowanie zawsze się w końcu rozjeżdża.

• Kategoria produktu i typ własny — kategoria Google daje wspólny język, typ własny odzwierciedla logikę sklepu. Rekomendacje potrzebują obu, bo pierwsza pozwala na podobieństwo ogólne, druga na sensowne uzupełnienia.

• Cena, cena promocyjna i waluta — konieczne, żeby nie polecać produktu droższego o rząd wielkości ani nie pokazywać ceny nieaktualnej.

• Dostępność — atrybut, którego brak psuje rekomendacje najbardziej widocznie, bo prowadzi klienta do towaru, którego nie kupi.

• Identyfikator grupy wariantów wraz z rozmiarem i kolorem — bez tego karuzela pokazuje sześć razy ten sam model w różnych rozmiarach, co widzę zaskakująco często.

• Marka i grupa docelowa — proste, ale skuteczne wymiary podobieństwa, zwłaszcza w odzieży i kosmetykach.

Zwracam uwagę, że to dokładnie te same pola, których wymaga poprawny plik produktowy. Nie trzeba więc budować osobnego katalogu — trzeba udostępnić ten, który już istnieje.

Kierunek przepływu i kto komu co daje

Integrację można poprowadzić w dwie strony i najlepsze efekty daje połączenie obu.

W kierunku od pliku do rekomendacji przekazuję katalog: pełną listę produktów z atrybutami, w tym samym rytmie, w jakim plik jest odświeżany. Silnik rekomendacji dostaje wtedy dokładnie ten sam obraz asortymentu, jaki ma Google, i przestaje polecać rzeczy, których nie reklamujemy.

W kierunku odwrotnym przekazuję do warstwy reklamowej wnioski z zachowań na stronie: które produkty są razem oglądane, które razem kupowane, co jest końcem ścieżki, a co jej początkiem. Z tego buduję niestandardowe etykiety w pliku produktowym, a etykiety wykorzystuję do podziału kampanii i priorytetów budżetowych.

Ten drugi kierunek jest rzadziej wdrażany i uważam go za bardziej wartościowy. Sklep zwykle wie, co się dobrze sprzedaje, ale rzadko przenosi tę wiedzę do struktury kampanii produktowych.

Warto ustalić jeden szczegół organizacyjny: który system jest źródłem prawdy dla ceny i dostępności. Odpowiedź powinna brzmieć: system sklepowy, a plik i rekomendacje są jego konsumentami. Każdy inny układ prowadzi do sytuacji, w której dwa systemy poprawiają się wzajemnie i żaden nie ma racji.

Spójność ceny i dostępności

To najbardziej praktyczna korzyść z połączenia tych światów i jednocześnie najczęstsze źródło problemów.

Merchant Center porównuje dane z pliku z tym, co widzi na stronie produktu, i przy rozbieżności potrafi wstrzymać ofertę. Jeżeli równolegle na stronie działa moduł rekomendacji z własnym cache’em cen, powstaje trzecia wersja prawdy — i bardzo łatwo o sytuację, w której widżet pokazuje starą cenę promocyjną, choć promocja się skończyła.

Ustalam więc zasadę: moduł rekomendacji nigdy nie wyświetla ceny z własnej pamięci, tylko pobiera ją z tego samego miejsca, z którego bierze ją karta produktu. Jeśli technicznie nie jest to możliwe, wolę, żeby w karuzeli nie było ceny w ogóle.

Analogicznie z dostępnością. Produkt oznaczony w pliku jako niedostępny powinien wypadać z rekomendacji automatycznie, a nie po nocnym przeliczeniu. Przy sklepach z krótkimi seriami różnica kilku godzin oznacza dziesiątki bezsensownych kliknięć.

Częstotliwość odświeżania warto ujednolicić. Jeśli plik idzie do Google co godzinę, a katalog rekomendacji raz na dobę, w praktyce mamy dwa różne sklepy.

Co jeszcze wyciągnąć z panelu

Merchant Center udostępnia dane, które w warstwie rekomendacji nadają się do czegoś więcej niż raportowanie.

Zestawienie popularności produktów w danym kraju pokazuje, czego szukają ludzie, a nie tylko co kupili u nas. To dobry materiał do decyzji, które produkty warto promować na stronie głównej, i do wykrywania sytuacji, w której mamy popularny towar schowany trzy poziomy w nawigacji.

Dane o konkurencyjności ceny mówią, jak nasza cena wygląda na tle innych ofert tego samego produktu. W rekomendacjach można to wykorzystać wprost: chętniej polecać to, w czym jesteśmy tani, ostrożniej to, gdzie odstajemy.

Do tego dochodzą informacje o odrzuconych ofertach. Produkt, który w Google jest wstrzymany z powodu błędu danych, zwykle ma też problem widoczny w sklepie — brak zdjęcia w dobrej rozdzielczości albo opis skopiowany od producenta. Traktuję listę odrzuceń jako kolejkę zadań dla działu contentu.

Warianty techniczne wdrożenia

Kolejność, w której zwykle rozważam rozwiązania, od najprostszego do najbardziej pracochłonnego.

Najprostszy: ten sam wygenerowany plik, który jedzie do Merchant Center, jest jednocześnie źródłem dla silnika rekomendacji. Zero dodatkowej logiki, jedno miejsce do poprawiania. Ograniczeniem jest częstotliwość i to, że plik zawiera tylko produkty przeznaczone do reklamowania.

Średni: eksport z systemu sklepowego w dwóch wariantach z jednej wspólnej warstwy danych — jeden dla Google, drugi dla rekomendacji, z tego samego zbioru pól. Rozwiązanie, które polecam najczęściej, bo pozwala oba pliki różnicować bez rozjeżdżania się danych.

Najbardziej pracochłonny: pobieranie danych programistycznie przez interfejs Merchant Center i budowanie na tej podstawie własnej warstwy synchronizacji. Ma sens tam, gdzie sklep ma wiele kont, kilka krajów i zmienne asortymenty, ale wymaga utrzymania.

Niezależnie od wariantu pilnuję jednego: rekomendacje nie mogą stać się kolejnym systemem, w którym ktoś ręcznie poprawia dane produktowe. Poprawki wracają zawsze do źródła.

Błędy, które ta integracja potrafi rozlać na cały sklep

Połączenie systemów ma tę nieprzyjemną cechę, że błąd w jednym miejscu widać teraz w kilku.

Najczęstszy: filtr wykluczający produkty z pliku, na przykład z powodu niskiej marży, zostaje przypadkiem zastosowany także do katalogu rekomendacji. Sklep przestaje polecać część asortymentu i nikt nie wie dlaczego, bo filtr żyje w skrypcie eksportu.

Drugi: mapowanie kategorii Google na wewnętrzne, wykonane raz i nieaktualizowane. Po dodaniu nowej grupy produktów rekomendacje traktują ją jako niepodobną do niczego i po prostu jej nie pokazują.

Trzeci: brak identyfikatora grupy wariantów, o którym pisałem wyżej, przenoszony teraz z pliku do rekomendacji razem ze wszystkimi konsekwencjami.

Czwarty, najbardziej bolesny: rozjazd walut albo cen brutto i netto między systemami. Sklep, który w pliku podaje ceny brutto, a w rekomendacjach netto, będzie miał klientów przekonanych, że został oszukany.

Dlatego po każdym takim wdrożeniu robię jedną nudną rzecz: biorę dziesięć losowych produktów i sprawdzam ręcznie, czy cena, dostępność, wariant i kategoria zgadzają się w sklepie, w pliku i w karuzeli. Pół godziny, a wyłapuje więcej niż jakikolwiek raport.