Jak sklep z 3,5 tysiąca produktów sam pilnuje cen i stanów — przypadek gabinetu.pl

Punkt wyjścia: kilka hurtowni, każda po swojemu

Jedna hurtownia wysyła plik XML z produktami raz na dobę i osobny plik dostępności w ciągu dnia. Druga udostępnia API z ceną zakupu. Trzecia przysyła roczny cennik w PDF. Do tego zdjęcia, kody EAN, stawki VAT i kategorie — w każdym źródle zapisane inaczej.

Sklep (WordPress z WooCommerce) dobrze pokazuje produkty, ale nie jest dobrym miejscem na porównywanie ofert kilku dostawców. Dlatego obok sklepu zbudowaliśmy własny rdzeń danych: osobne tabele, w których oferty wszystkich hurtowni leżą obok siebie, a do sklepu idzie dopiero wynik.

Jak to działa

1. Każdy dostawca ma swój „adapter”

Adapter to mały program, który zna format jednego dostawcy i zamienia go na wspólny język rdzenia: produkt, oferta, cena zakupu, stan, termin. Ten sam produkt od dwóch hurtowni łączy się po kodzie EAN. Dzięki temu nowy dostawca to nowy adapter, a nie przebudowa sklepu.

2. Dostępność sprawdzana co 5 minut — pobierana tylko, gdy się zmieniła

Plik dostępności największego dostawcy sprawdzamy co 5 minut, ale pobieramy go tylko wtedy, gdy hurtownia wygenerowała nowy (pytamy najpierw o datę zmiany pliku). Stan w sklepie liczy jedna reguła, w obie strony:

Przy produktach z wariantami (kolor, rozmiar) wariant, którego chwilowo nie ma, zostaje na liście przekreślony, a klient może zapisać się na powiadomienie — mail wychodzi automatycznie, gdy wariant wróci.

3. Cena: algorytm z dolną granicą marży

Cenę sprzedaży liczy algorytm z dolną granicą marży — poniżej niej żadna cena nie trafi do sklepu. Cena sugerowana dostawcy jest dla nas sygnałem, a nie sufitem. Cenę ustawioną ręcznie przez człowieka algorytm zostawia w spokoju — decyzja człowieka ma pierwszeństwo przed automatem.

4. Człowiek tylko przy wyjątkach

To, czego automat nie powinien rozstrzygać sam, trafia do kolejki wyjątków:

• nowy produkt u dostawcy (trzeba zdecydować, czy wchodzi do oferty i do jakiej kategorii),
• oferta bez ceny zakupu,
• dwa różne produkty pod jednym kodem EAN,
• kategoria dostawcy, której nie przypisaliśmy jeszcze do drzewa sklepu.

Spraw, które wstrzymują sprzedaż, jest zwykle kilka (9 października — 4) — reszta dzieje się sama.

5. Każda zmiana ma ślad

Każdy zapis — automatu i człowieka — trafia do dziennika: kto, kiedy, co było, co jest. Większe zmiany (np. poprawka kategorii dla kilkuset produktów) idą z punktem powrotu, więc da się je cofnąć jednym poleceniem.

produktów w katalogu

3 489

2 930 do kupienia od ręki albo na zamówienie

sprawdzana dostępność

co 5 minut

rodzaje wyjątków, które trafiają do człowieka

4

Czego nauczyły nas dane od dostawców

• Kody EAN bywają błędne. Trafiliśmy na kody z błędną cyfrą kontrolną, same zera i jeden kod dla kilku kolorów. Sprawdzamy sumę kontrolną i takie przypadki odkładamy do wyjątków, zamiast łączyć produkty na ślepo.
• Zdjęcia producenta potrafią mieć nakładki. Ikony i napisy w rogu zdjęcia nie przeszkadzają w sklepie, ale Google Merchant Center odrzuca takie zdjęcia — dla Google przygotowujemy osobne kopie bez nakładek.
• Zamknięcie wyjątku to nie naprawa. Jeśli przyczyna dalej działa, wyjątek wróci przy następnym imporcie — naprawiamy źródło, a wyjątek zamyka się sam.

Dla kogo to ma sens

Jeśli Twój sklep żyje z plików od hurtowni, a ceny i stany przepisujesz ręcznie albo przez wtyczkę, której nikt nie rozumie:

Napisz do nas — zaczniemy od rozmowy o tym, skąd przychodzą dane i co musi być w sklepie rano.

Napisz w tej sprawie →

Nota redakcyjna Treść przygotowana z pomocą narzędzi AI, sprawdzona przez autora — Jacek Iwaszkiewicz.