Zmiana wymagań platformy — jak zaktualizować tysiące ofert bez ręcznej roboty
Kolejność jest zawsze ta sama: ustal, czego dokładnie dotyczy zmiana i od kiedy obowiązuje, wyfiltruj SKU, których realnie dotyka (zwykle to część katalogu, nie całość), przygotuj poprawioną treść dla tego zakresu i wypchnij ją aktualizacją istniejących ofert po ich identyfikatorach — nigdy przez skasowanie i wystawienie od nowa. Ręcznie ta ścieżka jest wykonalna dla kilkudziesięciu ofert; przy kilku tysiącach kończy się tym, że poprawiane są bestsellery, a reszta katalogu wypada z wyników albo zostaje zablokowana. MAMS przechodzi ten cykl na całym katalogu naraz: regeneruje brakujące pola per marketplace, sprawdza je walidatorami z auto-korektą i zapisuje zwrotnie do BASE — 10 000+ ofert w mniej niż 24 godziny, przy niemal zerowym odsetku błędów publikacji.
Rozpoznaj typ zmiany — bo od tego zależy zakres pracy
Platformy zmieniają wymagania nieustannie i nie każda zmiana kosztuje tyle samo. Najczęstszy typ to nowy wymagany parametr w kategorii: pole, które wcześniej było opcjonalne, staje się obowiązkowe, a oferty bez niego przestają przechodzić walidację przy najbliższej aktualizacji albo tracą obecność w filtrach. Drugi typ to zmiana formatu tytułu — inna dopuszczalna długość, zakaz określonych znaków czy fraz promocyjnych, wymóg kolejności marka–model–cecha. Trzeci to przebudowa drzewa kategorii: kategoria zostaje podzielona albo scalona, a wraz z nią zmienia się komplet wymaganych parametrów, więc oferta przypisana do starej gałęzi trafia w próżnię. Czwarty to wymogi zgodnościowe i dokumentacyjne, takie jak dane GPSR czy informacje o producencie i osobie odpowiedzialnej. Piąty, najbardziej zdradliwy, to zmiana progów jakości: nic formalnie nie przestaje być dozwolone, ale platforma zaczyna niżej wyświetlać oferty z niekompletnymi danymi. Ten ostatni typ nie generuje żadnego komunikatu o błędzie — widać go dopiero w spadku wyświetleń. Zanim zaczniesz cokolwiek poprawiać, ustal trzy rzeczy: czego zmiana dotyczy pole po polu, od kiedy obowiązuje i czy dotyka wyłącznie nowych ofert, czy również tych już wystawionych.
Wytnij zakres — prawie nigdy nie chodzi o cały katalog
Odruch przy komunikacie o zmianie wymagań to „trzeba przerobić wszystko”. Zwykle to nieprawda i kosztuje najwięcej czasu. Zmiana dotyczy konkretnej kategorii albo konkretnego pola, więc pierwszym krokiem jest lista SKU, których naprawdę dotyczy: filtr po kategorii na danej platformie, po obecności lub braku wskazanego parametru, po długości tytułu, po dacie ostatniej aktualizacji oferty. Taki filtr zwykle zamienia „11 000 pozycji do przerobienia” w „1400 pozycji w trzech kategoriach”, a to już jest zakres, który da się zaplanować. Drugi krok to ustalenie, skąd weźmiesz brakujące dane. Część wartości jest w katalogu, tylko w innym polu lub w opisie tekstowym — wtedy to kwestia przepisania danych, nie ich zdobycia. Część da się wywieść z tego, co już wiadomo o produkcie i z jego zdjęć. Reszta — realnie brakująca u producenta — musi zostać oznaczona do ręcznego uzupełnienia, bo wpisanie zgadywanej wartości w wymagane pole to najprostsza droga do zwrotów i do ograniczenia konta. Trzeci krok to kolejność: najpierw SKU, które sprzedają i mają ruch, potem reszta zakresu. Jeżeli deadline platformy jest krótki, ta kolejność decyduje o tym, ile obrotu przetrwa zmianę.
Wypchnij poprawki aktualizacją, nie ponownym wystawieniem
Poprawiona treść musi trafić na platformę jako aktualizacja istniejącej oferty — po zapisanym identyfikatorze oferty, EAN-ie i SKU. Skasowanie oferty i wystawienie jej na nowo z lepszymi danymi zeruje historię sprzedaży, oceny i wypracowaną pozycję w wynikach, czyli płacisz za zgodność z nowym wymogiem walutą, której nie da się szybko odzyskać. Praktyczny przebieg wygląda tak: katalog źródłowy zostaje w jednym miejscu — zwykle w BASE (BaseLinker) — tam wprowadzasz poprawki, a stamtąd idą one na platformy istniejącymi powiązaniami ofert. MAMS czyta wskazany zakres produktów, generuje brakujące elementy per marketplace (komplet parametrów kategorii, tytuł w wymaganym formacie, opis pod limity danej platformy, wersje językowe, dane GPSR, grafiki A+ ze zdjęcia), przepuszcza to przez walidatory z auto-korektą i zapisuje publikacją zwrotną do pól produktowych w BASE. Zanim ruszy cały zakres, warto puścić partię testową — jedna kategoria, kilkadziesiąt SKU — i sprawdzić, jak oferty wyglądają po aktualizacji na żywej platformie. U Dystrybutora 11 000+ SKU ten sam mechanizm pozwolił zbudować i utrzymać 20 000+ ofert na kilku platformach, z generacją 10 000+ ofert w czasie poniżej doby i przy ~0% błędów walidacyjnych; w skali konta wdrożenie dało +130% GMV rok do roku, czyli 139 723 → 321 652 zł miesięcznie (+181 929 zł miesięcznie). Przy takiej organizacji pracy zmiana wymagań platformy przestaje być projektem awaryjnym, a staje się kolejnym przebiegiem na wskazanym zakresie katalogu.
| Ręczna reakcja na zmianę wymagań | Aktualizacja przez MAMS | |
|---|---|---|
| Ustalenie zakresu | Przegląd kategorii „na oko”, zwykle za szeroki | Filtr po kategorii, polu i formacie — konkretna lista SKU |
| Uzupełnienie brakujących pól | Ręcznie, więc realnie tylko bestsellery | Generowane dla całego zakresu, per marketplace |
| Kontrola poprawności | Wychodzi dopiero na odrzuceniu przez platformę | Walidatory z auto-korektą przed publikacją, ~0% błędów |
| Wersje językowe | Poprawiane osobno na każdym rynku | Agent-tłumacz, 97–99,8% poprawności terminologii |
| Sposób publikacji | Ryzyko wystawienia od nowa i utraty historii | Aktualizacja po identyfikatorze oferty, historia zachowana |
| Czas dla 10 000 SKU | Miesiące pracy zespołu | Mniej niż 24 godziny |
Najczęstsze pytania
Skąd mam wiedzieć, których ofert dotyczy zmiana?
Z filtra po tym, co się zmieniło, a nie z przeglądu całego katalogu. Jeśli doszedł wymagany parametr — filtrujesz oferty w danej kategorii, które go nie mają. Jeśli zmienił się format tytułu — filtrujesz po długości i po zakazanych elementach. Jeśli przebudowano drzewo kategorii — po przypisaniu do gałęzi, która przestała istnieć. Taki filtr zwykle pokazuje, że zmiana dotyczy kilkunastu procent katalogu, a nie całości, i pozwala zaplanować realny zakres pracy.
Czy poprawienie ofert pod nowe wymagania kasuje ich historię sprzedaży?
Nie, o ile idziesz ścieżką aktualizacji. Oferta zaktualizowana po swoim identyfikatorze pozostaje tą samą ofertą — z historią, ocenami i pozycją — zmienia się tylko jej zawartość. Utrata dorobku następuje wyłącznie wtedy, gdy ofertę usuwasz i wystawiasz nową w jej miejsce. Przy dużym katalogu to rozróżnienie jest najważniejszą decyzją w całym procesie.
Co zrobić, gdy producent nie ma danych, których wymaga platforma?
Rozdzielić trzy sytuacje. Dane, które są w katalogu, ale w innym polu lub w opisie — przenieść do właściwego parametru. Dane, które da się wywieść w sposób pewny z tego, co wiadomo o produkcie — uzupełnić i sprawdzić na próbce. Dane, których po prostu nie ma — wystawić do ręcznego uzupełnienia u producenta i wstrzymać publikację tych pozycji, zamiast wpisywać wartość zgadywaną. Kilkadziesiąt pozycji do ręcznego domknięcia jest tańsze niż tysiąc ofert z błędnym parametrem, które wracają jako zwroty.
Czy da się przygotować katalog tak, żeby kolejne zmiany były tańsze?
Tak — przez trzymanie jednego źródła prawdy o produktach i generowanie treści per platforma zamiast wpisywania jej osobno na każdym koncie. Wtedy zmiana wymagań dotyczy jednego przebiegu na wskazanym zakresie, a nie ręcznej pracy pomnożonej przez liczbę platform i języków. Pomaga też porządek w danych wejściowych: komplet identyfikatorów, parametry w polach zamiast w tekście opisu i zdjęcia w wymaganej jakości.