Co Google robi z ceną promocyjną w pliku

W pliku produktowym są dwa atrybuty, które opisują to, ile klient zapłaci. Atrybut price to cena bazowa — regularna, „normalna” cena produktu. Atrybut sale_price to cena promocyjna, ta faktycznie do zapłaty w trakcie obniżki.

Najczęstszy błąd, jaki widzę przy przejmowaniu konta, jest banalny: sklep w ogóle nie wysyła sale_price, tylko podmienia wartość w price na obniżoną. Z punktu widzenia zgodności danych wszystko jest w porządku — cena w pliku zgadza się z ceną na stronie, produkt się zatwierdza, reklama działa. Tylko Google nie ma pojęcia, że to promocja, bo nie dostał informacji o cenie odniesienia. Efekt: reklama wygląda dokładnie tak jak przez pozostałe jedenaście miesięcy roku.

Dopiero para price plus sale_price daje Merchant Center materiał do adnotacji o wyprzedaży — czyli tego układu, w którym cena regularna jest przekreślona, a obok stoi niższa. To adnotacja generowana przez Google, nie element, który wstawiasz sam. Ty dostarczasz dane i spełniasz warunki, decyzja o wyświetleniu należy do systemu.

Warto tu rozdzielić dwie rzeczy, które mylą się nawet doświadczonym osobom. Adnotacja o wyprzedaży bierze się z Twoich danych. Osobno istnieje oznaczenie spadku ceny, które Google wylicza z własnej historii cen produktu — na to nie masz wpływu przez plik i nie da się go „włączyć”. Jeśli ktoś obiecuje, że skonfiguruje Wam spadek ceny w feedzie, nie wie, o czym mówi.

Kiedy Google pokaże przekreśloną cenę

Same atrybuty nie wystarczą. Wymagania są opisane w polityce Merchant Center i sprowadzają się do kilku warunków, które sprawdzam po kolei.

• Cena bazowa musi być realna. Wartość z price musi obowiązywać przez co najmniej 30 dni z ostatnich 200 — niekoniecznie pod rząd. To zabezpieczenie przed podbiciem ceny na tydzień przed wyprzedażą, żeby rabat wyglądał lepiej.

• Obniżka musi mieścić się w widełkach. Rabat poniżej pięciu procent jest dla systemu zbyt drobny, żeby go komunikować, a bardzo głębokie obniżki — powyżej dziewięćdziesięciu procent — są odrzucane jako podejrzane.

• Promocja nie może trwać wiecznie. Adnotacja pokazuje się przez ograniczony czas, rzędu miesiąca. Cena „promocyjna” utrzymywana przez pół roku przestaje być promocją i staje się po prostu ceną.

• Strona produktu musi to potwierdzać. Obie kwoty — regularna i promocyjna — powinny być widoczne na stronie docelowej. Jeśli w pliku jest obniżka, a na stronie widać tylko jedną liczbę, Google nie ma czego zweryfikować.

Ten ostatni punkt jest w praktyce najbardziej kłopotliwy, bo wymaga zgody między marketingiem i zespołem sklepu. Widzę to na większości kont, które przejmuję: plik jest przygotowany poprawnie, a szablon produktu pokazuje tylko cenę końcową, bo tak kiedyś zdecydował ktoś od UX. Zanim zacznę grzebać w feedzie, sprawdzam więc, co faktycznie renderuje się na karcie produktu.

Harmonogram promocji, czyli sale_price_effective_date

Drugi atrybut, który w polskich sklepach bywa pomijany, to sale_price_effective_date. Podaje się w nim okres obowiązywania ceny promocyjnej jako dwie daty rozdzielone ukośnikiem, w formacie ISO 8601 razem ze strefą czasową — na przykład od piątego maja o dziewiątej rano do dwunastego maja o dwudziestej trzeciej pięćdziesiąt dziewięć.

Bez tego atrybutu sale_price obowiązuje tak długo, jak długo siedzi w pliku. To działa, dopóki ktoś pamięta o wycofaniu wiersza po zakończeniu wyprzedaży. Przy kilku tysiącach SKU i promocji rotującej co tydzień na pamięć nie ma co liczyć — a rozjazd między ceną w reklamie a ceną w koszyku to nie tylko odrzucenie produktu, ale też realny koszt kliknięć, które nie mogły się skonwertować.

Podanie zakresu dat ma jeszcze jedną zaletę: pozwala przygotować promocję zawczasu. Jeśli plik pobierany jest raz na dobę, a wyprzedaż startuje w środku dnia, nie musisz czekać na kolejne pobranie ani ręcznie wymuszać aktualizacji. Cena promocyjna wchodzi w życie w podanej godzinie po stronie Google.

Uwaga na strefę czasową. Pominięcie jej oznacza interpretację według strefy przypisanej do konta, a nie według czasu w Polsce, więc promocja potrafi wystartować z przesunięciem. Przy jednodniowych akcjach to różnica między działającą kampanią a straconym dniem.

Omnibus a struktura ceny w pliku

Od pierwszego stycznia tego roku każda informacja o obniżce w polskim sklepie musi być opatrzona najniższą ceną z 30 dni przed obniżką. To wymóg prawny, wynikający z wdrożenia dyrektywy Omnibus, i dotyczy strony sklepu — Google nie ma osobnego atrybutu, w którym można tę liczbę przekazać.

Konsekwencja dla pliku produktowego jest jedna i trzeba ją zrozumieć: najniższa cena z 30 dni nie jest ceną bazową. Do price nadal idzie cena regularna, do sale_price cena do zapłaty, a wartość wymagana przepisami żyje wyłącznie w treści strony jako informacja dla konsumenta. Widziałem już wdrożenia, w których deweloper podłączył feed do tego samego pola, z którego szablon bierze najniższą cenę z 30 dni — i cała wyprzedaż przestała pokazywać jakikolwiek rabat, bo obie liczby były niemal równe.

Druga pułapka jest wizualna. Na karcie produktu stoją teraz trzy kwoty i nie zawsze da się na pierwszy rzut oka poznać, która jest ceną do zapłaty. Jeśli szablon przekreśla najniższą cenę z 30 dni albo wyróżnia ją wizualnie mocniej niż cenę końcową, rośnie ryzyko, że automat czytający stronę odczyta ją błędnie. Warto tu zadbać o dane strukturalne produktu i wskazać w nich jednoznacznie cenę faktycznie płaconą.

Niezgodność ceny i automatyczne aktualizacje

Najczęstszy komunikat, jaki zbierają sklepy w trakcie wyprzedaży, dotyczy niezgodności ceny podanej w pliku z ceną znalezioną na stronie. Google porównuje jedno z drugim i przy rozbieżności odrzuca produkt — bo z perspektywy użytkownika obietnica z reklamy nie została dowieziona.

Źródła są zwykle prozaiczne. Plik pobierany raz na dobę, a ceny zmieniane w systemie kilka razy dziennie. Cache na warstwie frontu, przez który robot widzi starszą wersję strony niż klient. Ceny zależne od zalogowania albo od kuponu, którego robot nie ma. Albo po prostu zakończona promocja, której nikt nie wyjął z pliku.

Dwie rzeczy, które w takiej sytuacji ustawiam. Po pierwsze, automatyczne aktualizacje produktów — funkcja, która pozwala Google poprawiać cenę i dostępność na podstawie danych strukturalnych ze strony, zanim dojdzie do odrzucenia. Wymaga poprawnych mikrodanych, więc nie jest to przełącznik do kliknięcia w oderwaniu od pracy nad sklepem. Po drugie, częstsze zasilanie danych: harmonogram pobierania ustawiony na godzinę, w której ceny są już świeże, a przy dużych i zmiennych asortymentach aktualizacja przez interfejs programistyczny zamiast jednego pliku raz na dobę.

Czego w Polsce nie ma i czego nie kontrolujesz

Trzeba jasno powiedzieć jedną rzecz, bo oszczędza tygodnie szukania. Dodatek promocji w Merchant Center — ten, który pozwala podpiąć kod rabatowy albo darmową dostawę i wyświetlić przy produkcie link „specjalna oferta” — nie jest dostępny dla ofert z Polski. Lista krajów jest zamknięta i nie obejmuje naszego rynku. Poradniki opisujące atrybut z identyfikatorem promocji dotyczą kont z innych krajów.

Dla polskiego sklepu oznacza to, że narzędziem do komunikowania obniżki w reklamie produktowej pozostaje para cena regularna plus cena promocyjna wraz z datami obowiązywania. Kody rabatowe komunikujesz w innych miejscach — w tekstach reklam w wyszukiwarce, w bannerze na stronie, w mailingu.

Nie kontrolujesz też samego faktu wyświetlenia adnotacji. Spełnienie warunków polityki to warunek konieczny, nie gwarancja: sposób prezentacji zależy od formatu, urządzenia i miejsca, w którym pokazuje się oferta. Dlatego przy raportowaniu skutków wyprzedaży nie obiecuję klientowi, że przekreślona cena pojawi się w każdym wyświetleniu.

Jak układam plik przed sezonem wyprzedaży

Kolejność, którą stosuję, jest zawsze taka sama i zaczyna się co najmniej miesiąc przed akcją — bo warunek trzydziestu dni dla ceny bazowej trzeba spełnić z wyprzedzeniem.

Najpierw sprawdzam, czy ceny bazowe w pliku są stabilne i zgodne z tym, co pokazuje sklep. Potem weryfikuję, że szablon produktu pokazuje obie kwoty w trakcie promocji i że dane strukturalne wskazują cenę do zapłaty. Następnie przygotowuję zasilanie promocji — u mniejszych sklepów jako dodatkowy plik danych z kolumnami ceny promocyjnej i zakresu dat, dopisywany do głównego pliku, bez ruszania eksportu z systemu sklepowego. Na końcu ustawiam harmonogram pobierania pod godzinę startu i planuję kontrolę statusów w pierwszych godzinach akcji.

Po zakończeniu wyprzedaży robię jeszcze jedno: sprawdzam, czy ceny promocyjne faktycznie wygasły i czy w pliku nie został żaden wiersz z zakończonym zakresem dat. To pięć minut pracy, które ratują przed najgłupszym scenariuszem — reklamą obiecującą rabat, którego w koszyku już nie ma.

Cała ta konfiguracja nie sprawi, że wyprzedaż sprzeda się sama. Sprawia natomiast, że komunikat o obniżce dociera do użytkownika w miejscu, w którym podejmuje decyzję, i że nie płacisz za kliknięcia w ofertę, która przestała być aktualna. Przy sezonie sprzedażowym to różnica między kampanią, która pracuje, a kampanią, która tłumaczy się z rozbieżności.