Ukryty koszt złej integracji feedów produktowych

Ostatnia aktualizacja: 7 lipca 2026. Napisane na podstawie budowy integracji importu od dostawców i synchronizacji z marketplace'ami dla PrestaShop 1.7, 8 i 9. Poniższe zapytania diagnostyczne działają na tabelach rdzenia PrestaShop, które możesz sprawdzić we własnym sklepie.

Autor: zespół redakcyjny mypresta.rocks — tworzymy moduły do PrestaShop i prowadzimy sklepy na PrestaShop.

Źle wykonana integracja feedu produktowego to ten rzadki rodzaj awarii, który kosztuje pieniądze, gdy wszystko wygląda w porządku. Nic się nie wywala — żadnego czerwonego banera, żadnego nieudanego crona, żadnego zgłoszenia do supportu. Katalog po prostu po cichu zaczyna podawać klientom złą cenę, zły stan magazynowy, złą dostępność, a każde małe kłamstwo to anulowane zamówienie, zwrot lub chargeback, który czeka, żeby się wydarzyć.

Rzecz jest o klasie ryzyka: co tania, nieprzejrzysta lub nieutrzymywana integracja importu przychodzącego / synchronizacji z marketplace robi ze sklepem i co godna zaufania robi inaczej. Jeśli już taką masz i chcesz tylko wiedzieć, czy to się dzieje u Ciebie, przeskocz do dwóch zapytań — znajdą szkody we własnym katalogu w mniej więcej minutę.

Szybkie porównanie: tani feed vs. godny zaufania feed

1. Fantomowy stan magazynowy: sprzedaż towaru, którego nie masz

Najczęstszy sposób, w jaki tani moduł importu wykrwawia sklep, to fantomowy stan magazynowy — liczba sztuk na stronie sklepu, której nie odpowiada nic realnego w magazynie. Dzieje się tak, gdy synchronizacja zapisuje ilość, której nie potrafi przypisać do właściwego produktu: zmapowano złą kolumnę, flagę „dostępny” odczytano jako liczbę sztuk albo ilość jednego produktu zapisano na inny, bo dopasowanie było błędne. Dwie odmiany: fantomowa (liczba, która nigdy nie odpowiadała rzeczywistości) i nieaktualna (liczba kiedyś prawdziwa, ale feed przestał ją aktualizować, a sklep dalej sprzedawał na zamrożonym stanie). Tak czy inaczej liczba wygląda wiarygodnie, więc nikt jej nie kwestionuje — dopóki nie zaczynasz anulować zamówień, których nie możesz zrealizować, przełykać zwrotów, a na marketplace'ach inkasować cios we wskaźnik wadliwości, który psuje kondycję konta.

Pułapka specyficzna dla PrestaShop: realny stan magazynowy żyje w ps_stock_available (per produkt, per kombinacja, w zakresie id_shop lub id_shop_group) i powinien być zapisywany przez StockAvailable::setQuantity(), żeby odpalił się hook actionUpdateQuantity, a stan zależny pozostał spójny. Tani import, który zapisuje bezpośrednio starszą kolumnę ps_product.quantity, rozjeżdża się z tym, co faktycznie czyta strona sklepu. Połącz to z ustawieniem „zezwól na zamawianie przy braku towaru” (PS_ORDER_OUT_OF_STOCK, globalnie lub per produkt), a fantomowa lub wyzerowana ilość przekłada się wprost na żywą nadsprzedaż. Godna zaufania integracja zapisuje tylko taką ilość, którą potrafi przypisać do poprawnie dopasowanej linii źródłowej, weryfikuje ją względem poprzedniej wartości i wstrzymuje wszystko, za co nie może ręczyć, zamiast na tym sprzedawać.

2. Ten kosztowny przypadek: uszkodzona oferta na marketplace

Kiedy Twój katalog zasila marketplace — Allegro, Amazon, eBay — integracja nie edytuje już tylko wierszy w Twojej bazie. Manipuluje żywym aktywem na cudzej platformie, według jej reguł. Jeden zły push potrafi te reguły naruszyć: cena, którą platforma odczyta jako nieprawidłową, stan wypchnięty do zera, który kończy ofertę, źle zmapowany identyfikator, przez który oferta wygląda jak inny produkt.

Bądźmy precyzyjni co do tego, co realnie jest zagrożone, bo platformy się różnią. To, co możesz stracić, to dynamika na poziomie oferty — wiek oferty, pozycja, sygnały tempa sprzedaży, które nagradza ranking danego kanału, obserwujący — a na kanałach opartych na ofertach, takich jak Allegro i eBay, historię sprzedaży powiązaną z tą ofertą. Z opiniami o produkcie jest subtelniej: na Amazonie żyją przy ASIN i zwykle przetrwają zmianę oferty; oceny na eBay są na poziomie sprzedawcy, nie oferty. Więc „zły push wymazuje Twoje opinie” nie jest uniwersalnie prawdziwe — ale dynamika, która czyniła ofertę konkurencyjną, jak najbardziej może zostać zresetowana, a ponownie wystawiona oferta buduje ją od zera. Tryb awarii, który czyni to niebezpiecznym, to propagacja: tania integracja odwzorowuje katalog na kanał bez żadnej bramki, więc jeden zły lokalny wiersz dociera do żywej oferty z prędkością maszyny. Godna zaufania waliduje zapis ceny i stanu oraz blokuje do przeglądu masowe pushe typu „zakończ ofertę” / zerowanie, zanim cokolwiek się rozpropaguje.

3. Oferty poniżej realnej ceny: ekspozycja prawna i finansowa

Produkt wystawiony daleko poniżej realnej ceny zwykle wrzuca się do szuflady „utracona marża”. To niedoszacowanie. Gdy już przyjmiesz zamówienie po wyświetlonej cenie, część jurysdykcji oczekuje realizacji (sama wyświetlona cena często nie jest wiążącą ofertą w systemach common-law; oczywiste błędy mogą być odwoływalne — zależy to od prawa lokalnego i Twojego regulaminu), a i tak masowe anulowanie kosztuje w chargebackach i sporach więcej niż marża, której broniłeś. Źle wycenione produkty są też szybko wyłapywane: skrypty resellerskie czatują właśnie na to, więc towar wyceniony daleko poniżej rynku jest wykupiony w minuty. Po stronie zgodności realną ekspozycją jest naruszenie umowy z dostawcą; czysta odpowiedzialność z prawa konkurencji jest wąska (art. 102 UE wymaga dominacji i nadużycia; prawo USA zasadniczo traktuje ceny poniżej kosztu jako legalne, chyba że mają charakter drapieżny). A Google Merchant wymaga, by cena w feedzie zgadzała się z ceną na stronie docelowej, więc rozbieżność przelewa się na odrzucenia w kanale płatnym.

Wyzwalaczem jest niemal zawsze błąd dopasowania powyżej, i żaden wyjątek nie jest rzucany — oferta po prostu staje się żywa za ułamek swojej wartości. Obroną jest cena minimalna, która odmawia nieprawdopodobnego zapisu, zanim dotrze on do strony sklepu lub kanału. Jeden niuans, który warto wbudować: porównuj to samo z tym samym — cena bazowa, która przechodzi próg, i tak może zejść poniżej kosztu, gdy zadziała aktywny rabat ps_specific_price lub reguła katalogu, więc próg musi brać pod uwagę cenę efektywną, nie tylko ps_product_shop.price.

Pierwotna przyczyna: dopasowanie po ulotnych ID dostawcy

To grzech pierworodny integracji feedów. Wewnętrzne ID dostawców nie są stabilne — dystrybutorzy recyklingują je i przypisują na nowo, w miarę jak zmieniają się ich własne systemy. Dopasuj po tym ID, a przywiążesz swój katalog do ruchomego celu: w dniu, w którym dostawca użyje ponownie danego ID dla innego artykułu, Twój drogi produkt przejmie cenę i stan tego taniego. Zamiast tego zakotwicz się na stabilnym identyfikatorze produktu docelowego. W PrestaShop to unikalny GTIN (ean13 / upc), numer części producenta mpn lub Twój własny reference, na poziomie kombinacji (ps_product_attribute). PrestaShop 8.1+ waliduje ean13 jako GTIN na poziomie produktu. Własna referencja dostawcy należy do ps_product_supplier.product_supplier_reference, w zakresie id_supplier, i powinna być używana wyłącznie jako deterministyczny fallback — nigdy jako klucz podstawowy nadpisujący cenę i stan.

Jak poznać, że to już się u Ciebie dzieje

Jeśli prowadzisz dziś tani moduł importu, nie musisz czekać na reklamację. Szkody zostawiają odciski palców. To są wstępne, szybkie testy — tylko do odczytu, bezpieczne na kopii — nie pełny audyt, ale wydobywają dwie awarie, które kosztują najwięcej.

Zduplikowana tożsamość — warunek konieczny dla dopasowania do złego produktu. Każdy GTIN współdzielony przez dwa produkty bazowe to defekt danych i przygotowanie pod podmianę na zły produkt:

SELECT ean13, COUNT(*) AS n
FROM ps_product
WHERE ean13 <> ''
GROUP BY ean13
HAVING n > 1;
-- powtórz dla upc, mpn oraz identyfikatorów z ps_product_attribute (kombinacje)

Oferty poniżej kosztu — wszystko wycenione poniżej własnego kosztu zakupu to żywy wyciek marży albo błąd dopasowania, który już zadziałał. Zwróć uwagę na id_shop: w multistore ten sam produkt może być bezpieczny w jednym sklepie i poniżej kosztu w innym. To sprawdza wyłącznie cenę bazową — nie nettuje aktywnych rabatów specific_price, podatku, opłat ani kombinacji, więc czysty wynik traktuj jako „brak oczywistego wycieku na cenie bazowej”, a nie „wszystko w porządku”:

SELECT p.id_product, p.reference, ps.id_shop, ps.price, ps.wholesale_price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
WHERE ps.wholesale_price > 0
  AND ps.price < ps.wholesale_price;

Wiersze poniżej kosztu to aktywna awaria; zduplikowane identyfikatory to defekt danych i podmiana na zły produkt czekająca, żeby się wydarzyć. Tak czy inaczej jest to w Twoim katalogu teraz, nie w teorii.

Natywne dla PrestaShop pułapki, o których warto wiedzieć

• Pole wyboru „Usuń wszystkie produkty przed importem” w imporcie CSV — w połączeniu z „Wymuś wszystkie numery ID” to najsłynniejsza akcja niszcząca katalog w PrestaShop. Jeden przebieg bez nadzoru może wymazać i przenumerować katalog.
• Zapisywanie ps_product.quantity zamiast używania StockAvailable. Realny stan magazynowy żyje w ps_stock_available; ominięcie API pomija hook actionUpdateQuantity, więc cache i wszelkie listenery, które od niego zależą, nigdy nie dowiadują się, że liczba się zmieniła.
• Zakresy multistore. Ceny są w zakresie id_shop; stany w zakresie id_shop lub współdzielonej id_shop_group. Import, który ignoruje zakresy, aktualizuje niewłaściwą stronę sklepu albo wszystkie naraz.

Dryf katalogu i ucięte feedy

Dryf katalogu to powolne rozejście się między tym, co dostawca oferuje dziś, a tym, co Twoja strona sklepu wciąż pokazuje — dodane, wycofane i przecenione SKU, których feed nie odzwierciedlił. Najgorszy przypadek to wycofany produkt wciąż pokazujący fantomowy stan: klient kupuje coś, czego nie jesteś w stanie kupić. Obsługa tego jest subtelna. Wykryj „zniknięcie z feedu”, ale nie zabijaj produktu ślepo — wyprzedaż realnego, posiadanego stanu (na ręku po rezerwacjach, nie liczby dostawcy) to pieniądze, które już zapłaciłeś. W katalogu wielodostawcowym „brak w jednym feedzie” powinien odciąć to źródło, nie produkt, a na „już niedostępne” przełączasz się dopiero, gdy realny stan na ręku spadnie do zera i żaden inny dostawca go nie pokrywa.

Awaria, która zamienia mały problem w katastrofę, to ucięty feed — pobieranie, które umiera w połowie, a które naiwny moduł traktuje jako kompletne. Nagle duża część SKU wygląda na „brakującą” i zostaje wyzerowana lub wycofana masowo. Naprawą jest audyt przebiegu importu: nigdy nie działaj na feedzie, którego nie zwalidowałeś względem poprzedniego przebiegu.

CREATE TABLE ps_feedrun (
  id_run         INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  supplier       VARCHAR(64),
  started_at     DATETIME,
  row_count      INT UNSIGNED,
  prev_row_count INT UNSIGNED,
  checksum       CHAR(64),
  state          ENUM('running','applied','rejected'),
  reject_reason  VARCHAR(255)
);
-- Odrzuć przebieg (nigdy nie stosuj usunięć), gdy pobieranie jest niekompletne,
-- suma kontrolna nie przechodzi, znacznik czasu eksportu jest nieaktualny albo
-- row_count zapada się względem prev_row_count.

Jak jeden zły przebieg wywołuje kaskadę

Poglądowo, ale każdy krok to realny mechanizm: zaplanowany import rusza w nocy, jak od miesięcy. Tym razem eksport ucina się w połowie, a moduł przyjmuje go jak ewangelię. Produkty za punktem odcięcia wyglądają na „zniknięte”, więc ich stan zostaje wyzerowany. Garść ID, które dostawca zrecyklingował w tym tygodniu, wiąże drogie produkty z tanimi liniami, a te ceny zostają nadpisane. Zanim ktokolwiek się zaloguje, strona sklepu pokazuje brak towaru na żywych produktach, kilka pozycji stoi daleko poniżej kosztu, sprzedając się już botom, a — ponieważ katalog wypchnął to wszystko dalej bez żadnej bramki — oferty na marketplace zostały zresetowane z powodu nieprawidłowych danych. Ani jedna linia nie rzuciła błędu. Każde zabezpieczenie, które by to złapało — audyt przebiegu importu, cena minimalna, kontrola pochodzenia, bramka kanału — było po prostu nieobecne.

Co musi robić godna zaufania integracja feedu

• Dopasowanie po stabilnej tożsamości — GTIN (ean13/upc), mpn lub Twój własny reference, na poziomie kombinacji; referencja dostawcy tylko jako fallback w zakresie.
• Ochrona cen przed publikacją — próg na cenie efektywnej (po specific_price i regułach katalogu), odmawiający i alarmujący zamiast publikować.
• Przypisywalny zapis stanu — przez StockAvailable, wyłącznie z poprawnie dopasowanej linii źródłowej, z pasmem poprawności na dużych skokach.
• Audyt każdego przebiegu importu — suma kontrolna, liczba wierszy vs. poprzednia, świeżość eksportu; podejrzany feed nigdy nie napędza usunięć.
• Bramkowanie propagacji na kanały i odwracalność — waliduj, zanim cokolwiek dotrze do marketplace, i rób snapshot przed zmianą, żeby odzyskiwanie było przywróceniem, a nie odbudową.

FAQ

Dlaczego mój sklep sprzedaje produkty, których nie ma na stanie?

Zwykle to fantomowy lub nieaktualny stan magazynowy, często wzmocniony przez „zezwól na zamawianie przy braku towaru”, albo zamówienie trafiające w okno między synchronizacjami. Naprawą jest integracja, która zapisuje stan przypisywalnie przez StockAvailable, odróżnia potwierdzone zero od brakującej aktualizacji i pilnuje nieprawdopodobnych skoków.

Jak przestać sprzedawać poniżej kosztu?

Postaw próg przed każdym zapisem ceny, porównywany na cenie efektywnej po każdym aktywnym specific_price lub regule katalogu — nie tylko na ps_product_shop.price. Odmawiaj i alarmuj zamiast publikować oraz utrzymuj aktualne dane o koszcie, bo nieaktualny koszt ukrywa sprzedaż poniżej kosztu do czasu, aż nadejdzie raport marżowy. Zapytanie o sprzedaż poniżej kosztu powyżej znajduje te, które już są żywe.

Czym jest dryf katalogu?

Rosnąca luka między tym, co dostawca oferuje teraz, a tym, co Twoja strona sklepu wciąż pokazuje. Zmierz swoją, porównując bieżący feed dostawcy z żywym katalogiem — każdy SKU obecny w jednym, a nieobecny w drugim to dryf: zła cena, fantomowy stan lub produkt, którego nie jesteś już w stanie kupić.

Sedno

Integracja feedu zarabia na siebie w swój najgorszy dzień, nie w przeciętny. Gdy eksport się utnie, ID zostanie zrecyklingowane albo dystrybutor przeceni z dnia na dzień, dobrze zbudowana integracja odrzuci złe dane, a tania je zastosuje. Żadna z tych awarii nie jest egzotyczna — to przewidywalny skutek pominięcia garstki zabezpieczeń, których zbudowanie nie jest trudne. Uruchom dwa powyższe zapytania na własnym katalogu; jeśli zwrócą wiersze, odpowiedź już masz.