Gdzie dokładnie powstaje rozjazd

Między liczbą sztuk w magazynie a informacją, którą widzi kupujący w reklamie, jest zwykle kilka ogniw: system magazynowy, baza sklepu, warstwa cache, generator pliku, transfer do Google i przetworzenie po stronie Merchant Center. Każde z nich dodaje własne opóźnienie.

Z mojego doświadczenia najczęściej winne są dwa. Pierwsze to cache po stronie sklepu — plik jest generowany co godzinę, ale generator odczytuje dane z pamięci podręcznej odświeżanej rzadziej. Wygląda to jak problem z feedem, a jest problemem z konfiguracją sklepu. Drugie to kolejka zadań: generowanie pliku dla dużego katalogu trwa i przy obciążonym serwerze potrafi się rozciągnąć albo przerwać w połowie.

Osobna kategoria to rezerwacja stanu. W wielu sklepach produkt schodzi z magazynu w chwili opłacenia zamówienia, a nie w chwili dodania do koszyka. W szczycie oznacza to, że kilkadziesiąt sztuk jest jednocześnie „w drodze” i nie wiadomo, czy je masz.

Atrybuty, które faktycznie sterują wyświetlaniem

O dostępności decyduje przede wszystkim jedno pole i warto rozumieć jego zachowanie, zanim zaczniemy kombinować.

• availability — wartość dostępny, niedostępny albo w przedsprzedaży. Produkt oznaczony jako niedostępny przestaje się wyświetlać w reklamach produktowych. To jedyny sygnał, który działa natychmiast i bezwarunkowo.

• availability_date — data, od której produkt w przedsprzedaży albo na zamówienie ma być dostępny. Wymagana przy tych statusach i traktowana poważnie: podanie daty z przeszłości potrafi wywołać ostrzeżenie.

• price i sale_price wraz z okresem obowiązywania obniżki. Wymieniam je tutaj, bo w praktyce cena i dostępność rozjeżdżają się razem — jeśli feed spóźnia się z jednym, spóźnia się i z drugim.

Czego w tym polu nie ma: liczby sztuk. Google nie oczekuje w standardowym pliku informacji o tym, że masz trzy egzemplarze. To ważne, bo część zespołów próbuje sterować widocznością przez liczbę stanów magazynowych i dziwi się, że nic z tego nie wynika. Widoczność sterujesz statusem, ewentualnie regułą, która ten status wylicza.

Harmonogram pobierania i jego granica

Pierwsza rzecz, którą robi większość osób, to skrócenie odstępu między pobraniami pliku. Warto to zrobić, ale trzeba wiedzieć, gdzie ta droga się kończy.

Standardowe pobranie pliku z adresu URL można ustawić na raz dziennie o wybranej godzinie. Przy wyprzedaży samo przesunięcie tej godziny na moment przed startem obniżek jest już poprawą — feed pobrany o czwartej nad ranem opisuje stan sprzed doby.

Częstsze odświeżanie wymaga innego mechanizmu niż zwykły plik. I tu zaczyna się prawdziwa decyzja: albo wysyłasz zmiany do Merchant Center aktywnie, albo pozwalasz Google czytać stronę produktu. Sam harmonogram, choćby najgęstszy, ma tę wadę, że przesyła cały katalog — a przy dużym asortymencie generowanie i transfer pełnego pliku kilka razy na godzinę to obciążenie, którego serwer w szczycie sprzedaży nie potrzebuje.

Feedy dodatkowe i aktualizacje przez API

Dwa narzędzia, które w szczycie robią najwięcej różnicy, są oba oparte na tej samej idei: przesyłać tylko to, co się zmieniło.

Feed dodatkowy to lekki plik zawierający identyfikator produktu i wyłącznie te pola, które chcesz nadpisać. Może zawierać kilkaset wierszy zamiast kilkudziesięciu tysięcy, więc generuje się i przesyła szybko. Używam go do dwóch rzeczy: do wyłączania z reklam wąskiej grupy produktów, które właśnie się skończyły, i do nadpisywania etykiet własnych w trakcie akcji promocyjnej. Ważne zastrzeżenie: feed dodatkowy nadpisuje dane z feedu głównego, więc gdy nadpisanie przestaje być potrzebne, trzeba je świadomie usunąć. Zapomniany feed dodatkowy potrafi trzymać kategorię wyłączoną tygodniami.

Aktualizacje przez API to rozwiązanie właściwe, jeśli sklep sprzedaje na tyle intensywnie, że opóźnienie liczone w godzinach jest kosztem. Sklep wysyła zmianę statusu i ceny w momencie, w którym ona zachodzi. Od sierpnia interfejsem docelowym jest Merchant API — stare Content API for Shopping działa nadal, ale Google podało datę jego wyłączenia na sierpień 2026, więc nowej integracji nie budowałbym już na nim.

Decyzję o integracji podejmuje się jednak przed sezonem, nie w jego trakcie. Jeśli czytasz to na tydzień przed wyprzedażą i nie masz API, to Twoim narzędziem jest feed dodatkowy i mechanizmy z następnej sekcji.

Aktualizacje automatyczne i dane na karcie produktu

Jest mechanizm, który działa bez żadnej integracji i o którym część sklepów nie wie, że ma go włączony.

Aktualizacje automatyczne pozwalają Google korzystać z danych strukturalnych na stronie produktu, żeby poprawić rozbieżność między feedem a stroną, zanim skończy się to odrzuceniem oferty. Warunek jest jeden i całkowicie po Twojej stronie: znaczniki na karcie produktu muszą być poprawne i muszą zawierać cenę oraz dostępność.

Traktuję to jako siatkę bezpieczeństwa, a nie jako podstawowy kanał aktualizacji. Ma dwie wady. Po pierwsze, Google musi stronę odwiedzić, więc reakcja nie jest natychmiastowa. Po drugie, jeśli dane strukturalne są błędne — a bywają, zwłaszcza po wdrożeniu nowego szablonu — mechanizm z entuzjazmem propaguje błąd.

Dlatego przed sezonem robię prostą rzecz: biorę kilka kart produktu z różnych kategorii, w tym wariantowych, i sprawdzam, czy znaczniki podają tę samą cenę i ten sam status dostępności co widoczna część strony. Rozjazd na produktach wariantowych to najczęstsza usterka, jaką w tym miejscu spotykam.

Bufory, reguły i podział asortymentu

Skoro opóźnienia nie da się zredukować do zera, warto zostawić sobie margines.

Najprostszy bufor polega na tym, że produkt przestaje być reklamowany, zanim naprawdę się skończy. Reguła jest banalna: jeśli stan spada poniżej ustalonego progu, feed raportuje niedostępność. Przy niskiej rotacji nie ma to sensu, przy wyprzedaży ratuje przed płaceniem za kliknięcia w pustą kartę. Próg ustalam osobno dla asortymentu szybkorotującego i osobno dla reszty — jedna wartość dla całego katalogu zawsze jest albo zbyt ostrożna, albo bezużyteczna.

Drugi mechanizm to etykiety własne, ale użyte inaczej niż zwykle: nie do dzielenia asortymentu według marży, a do oznaczenia produktów wrażliwych na wyczerpanie. Kilkadziesiąt pozycji, które w tym sezonie odpowiadają za większość obrotu, chcę mieć w osobnej grupie, żeby móc je obserwować i wyłączyć bez ruszania całej kampanii.

Co obserwować, gdy wyprzedaż już trwa

W trakcie akcji nie mam czasu na analizy, więc patrzę na cztery rzeczy i tylko na nie.

Pierwsza: liczba produktów aktywnych w Merchant Center w porównaniu z dniem poprzednim. Nagły spadek o kilka procent oznacza problem z pobraniem albo masowe odrzucenie, nie sukces sprzedażowy. Druga: ostrzeżenia o niezgodności ceny i dostępności. W szczycie ich liczba zawsze rośnie, ale skok o rząd wielkości to sygnał, że feed przestał nadążać.

Trzecia: godzina ostatniego udanego pobrania. Zaskakująco często okazuje się, że ostatnie pobranie nie doszło, bo serwer odrzucił żądanie pod obciążeniem. Czwarta: koszt kliknięć na produktach, które zniknęły z magazynu. To najbardziej bezpośrednia miara tego, ile kosztuje opóźnienie feedu — i najlepszy argument w rozmowie o integracji przez API, którą warto przeprowadzić w styczniu, na spokojnie.