Najpierw ustal, co dokładnie zostało odrzucone

Słowo „wszystko” w opisie awarii bywa nieprecyzyjne i ta nieprecyzyjność kosztuje godziny.

Sprawdzam trzy liczby: ile ofert jest aktywnych, ile odrzuconych i ile ma stan ostrzeżenia. Potem patrzę na rozbicie po typie problemu — czy dominuje jeden komunikat, czy jest ich kilka. Jeden komunikat dotyczący całego katalogu wskazuje na przyczynę systemową, na przykład zmianę w szablonie strony. Kilka różnych sugeruje, że problem narastał od dawna i dziś tylko przekroczył próg widoczności.

Sprawdzam też, czy odrzucenie dotyczy wszystkich krajów i wszystkich źródeł danych, czy tylko jednego. Sklep z kilkoma rynkami ma zwykle kilka źródeł i awaria potrafi dotyczyć tylko jednego z nich.

Na koniec ustalam moment. W panelu widać datę zmiany stanu i to jest najcenniejsza informacja w całej diagnostyce, bo pozwala zapytać zespół techniczny, co zostało wdrożone w tym dniu. Odpowiedź zwykle rozwiązuje sprawę szybciej niż analiza danych.

Skąd Google bierze dane ze strony i po co

Warto rozumieć mechanizm, bo bez tego naprawa jest zgadywaniem.

Merchant Center nie ufa wyłącznie plikowi. Regularnie odwiedza strony produktów i odczytuje z nich cenę oraz dostępność, korzystając z danych strukturalnych, a gdy ich nie ma — z zawartości strony. Celem jest ochrona użytkownika przed sytuacją, w której klika ofertę za sto złotych i trafia na produkt za dwieście.

Jeśli wartości się różnią, dzieją się dwie rzeczy. Przy włączonych automatycznych aktualizacjach produktów Google może samodzielnie poprawić dane w ofercie na te ze strony. Przy wyłączonych — oznacza ofertę jako niezgodną i wstrzymuje ją.

Ma to ważną konsekwencję praktyczną. Włączone automatyczne aktualizacje maskują problem: oferty żyją, ale dane w koncie zaczynają się rozjeżdżać z systemem sklepowym. Wyłączone ujawniają problem natychmiast i boleśnie. Wolę drugie ustawienie u klientów z porządnym eksportem, a pierwsze tam, gdzie plik jest odświeżany rzadko.

Dodam, że odczyt ze strony wymaga dostępu. Strona produktu zablokowana w pliku robots, chroniona przed botami albo wymagająca skryptu do wyrenderowania ceny bywa odczytana jako oferta bez ceny — z takim samym skutkiem jak cena błędna.

Typowe rozjazdy między stroną a plikiem

Lista przypadków, które w praktyce odpowiadają za większość takich awarii.

• Cena brutto w pliku, netto w znaczniku na stronie — klasyk w sklepach obsługujących klientów biznesowych. Wystarczy jedna zmiana w szablonie, żeby dotknęło to całego katalogu.

• Cena promocyjna widoczna na stronie i cena podstawowa w pliku — albo odwrotnie, gdy promocja się skończyła, a plik nie został odświeżony.

• Dostępność liczona inaczej po obu stronach — strona pokazuje „na zamówienie”, plik podaje stan magazynowy jako dostępny.

• Cena renderowana skryptem po wczytaniu strony — dla użytkownika niewidoczna różnica, dla robota brak ceny w treści.

• Znacznik z ceną w innej walucie albo bez waluty, po wdrożeniu wielojęzyczności.

• Dwa różne znaczniki produktu na jednej stronie — jeden z wtyczki sklepu, drugi z motywu, i Google odczytuje ten, którego nie mieliśmy w planach.

• Cena za inną jednostkę — strona pokazuje cenę za metr, plik za opakowanie.

Ostatni przypadek na liście jest najbardziej podstępny, bo formalnie oba miejsca podają prawdę. Rozbieżność w jednostce trzeba rozwiązać decyzją, a nie poprawką techniczną.

Kiedy to kończy się zawieszeniem konta

Trzeba powiedzieć wprost, że masowa niezgodność ceny bywa traktowana poważniej niż jako błąd danych.

Google ma zasadę dotyczącą wprowadzania w błąd i konsekwentna rozbieżność między ceną reklamowaną a ceną w koszyku mieści się w niej. Przy dużej skali i braku reakcji może się to skończyć zawieszeniem całego konta, a nie tylko wstrzymaniem ofert. To zupełnie inny poziom problemu, bo odzyskanie konta zajmuje tygodnie.

Sygnałów ostrzegawczych zwykle nie brakuje: powiadomienia o niezgodnościach pojawiają się przed zawieszeniem. Problem polega na tym, że w wielu firmach powiadomienia z Merchant Center idą na skrzynkę, do której nikt nie zagląda, i pierwszym objawem jest zatrzymanie kampanii.

Dlatego w każdym koncie, które przejmuję, sprawdzam adresy powiadomień i ustawiam je na osobę, która realnie coś z tym zrobi. To zajmuje pięć minut i jest jedną z najbardziej opłacalnych czynności w tym całym obszarze.

Jeśli zawieszenie już nastąpiło, kolejność jest odwrotna do intuicyjnej: najpierw naprawiam wszystkie rozbieżności i sprawdzam je ręcznie na kilkudziesięciu produktach, a dopiero potem składam wniosek o ponowne rozpatrzenie. Wniosek złożony przed naprawą zużywa jedną z ograniczonej liczby prób.

Procedura naprawcza krok po kroku

Kolejność, która sprawdza się w awarii, gdy ważny jest czas.

Krok pierwszy: weź listę odrzuconych ofert z panelu, wybierz kilka z różnych kategorii i sprawdź ręcznie każdą z nich. Otwórz stronę produktu, zobacz cenę widoczną dla użytkownika, sprawdź znacznik danych strukturalnych i porównaj z wartością z pliku. Trzy takie porównania zwykle wystarczą, żeby rozpoznać wzorzec.

Krok drugi: ustal, która strona ma rację. To decyzja handlowa: która cena jest tą, którą chcemy sprzedawać. Bez tej decyzji nie da się poprawnie zaprogramować niczego.

Krok trzeci: napraw źródło, nie objaw. Jeśli błąd jest w znaczniku, poprawia go zespół techniczny w szablonie. Jeśli w eksporcie, poprawiamy eksport. Regułę w panelu traktuję tu jako rozwiązanie tymczasowe na czas wdrożenia poprawki.

Krok czwarty: sprawdź poprawkę narzędziem do testowania danych strukturalnych i podglądem oferty w panelu, na kilku produktach z różnych kategorii, w tym takich z promocją i z wariantami.

Krok piąty: dopiero teraz wyślij plik i uruchom ponowne przetwarzanie. Wcześniejsze wysyłki niczego nie zmieniają, a zaciemniają obraz w historii konta.

Jak przyspieszyć powrót do normy

Kilka rzeczy, które faktycznie skracają czas oczekiwania, i kilka, które go nie skracają, choć wszyscy je robią.

Skraca: poprawne mapy witryny i dostępność stron produktów dla robota, bo od tego zależy tempo ponownego odwiedzenia. Skraca też ograniczenie liczby zmian — jedna poprawka wdrożona i sprawdzona jest przetwarzana szybciej niż pięć wprowadzanych na przemian.

Nie skraca: wielokrotne ręczne wysyłanie tego samego pliku, zmiana harmonogramu pobierania na częstszy, usuwanie i ponowne dodawanie źródła danych. Ta ostatnia czynność potrafi wręcz wydłużyć proces, bo traci się historię oferty.

W trakcie oczekiwania warto zająć się czymś pożytecznym: przeglądem ofert z ostrzeżeniami, które nie zostały odrzucone. Zwykle wskazują na te same przyczyny i naprawa ich teraz oszczędza następnej awarii.

I rzecz organizacyjna. Klientowi mówię wprost, ile to potrwa, i nie obiecuję powrotu na następny dzień. Przy poprawnie naprawionym problemie liczy się to zwykle w dniach, nie w godzinach, a obietnica z powietrza kończy się rozmową gorszą niż sama awaria.

Jak nie wrócić do tego samego punktu

Ta awaria niemal zawsze jest powtarzalna, bo jej przyczyną jest brak połączenia między dwoma zespołami.

Ustalam więc trzy rzeczy. Pierwsza: dane strukturalne produktu są traktowane jako element funkcjonalny sklepu, a nie ozdoba SEO — a to znaczy, że wchodzą do listy sprawdzeń przed każdym wdrożeniem szablonu karty produktu.

Druga: monitoring. Prosty skrypt porównujący cenę z pliku z ceną odczytaną ze strony na losowej próbce produktów, uruchamiany codziennie, z powiadomieniem przy rozbieżności powyżej progu. Dzień pracy, a wyłapuje problem, zanim zrobi się z niego awaria.

Trzecia: kontrola po każdej promocji. Zakończenie akcji rabatowej jest w moim doświadczeniu najczęstszym momentem powstawania takich rozjazdów, bo ceny wracają w różnych systemach w różnym tempie.

Na koniec zdanie, które powtarzam przy każdym takim wdrożeniu: Merchant Center nie jest narzędziem marketingu, tylko interfejsem między systemem sprzedażowym a Google. Jeśli traktuje się go jak kanał reklamowy, w którym da się coś podkręcić ustawieniami, awarie tego typu będą wracać.