Cena Omnibus 2 lata po wdrożeniu: czego e-commerce wciąż nie robi dobrze

```markdown

Hook (intro/lead)

Maj 2025. Pricing Manager sieci odzieżowej premium — 150 SKU, obrót około 8 mln PLN rocznie — otwiera Slacka i widzi wiadomość od działu prawnego: „UOKiK wszczął postępowanie. Black Friday 2023. Naruszenie art. 4 ust. 2 ustawy o informowaniu o cenach. Decyzja: 340 tys. PLN."

Pricing Manager nie kojarzy tej kampanii. Były 23 promocje w listopadzie 2023. Po godzinie w archiwum znajduje mechanizm.

Sierpień 2023 — migracja z autorskiego CMS na Shopera. Plugin Omnibus zainstalowany w dniu go-live, certyfikat zgodności od integratora, checklista odhaczona. Tyle że plugin liczył bazę 30-dniową od daty migracji, nie od faktycznej ostatniej zmiany ceny w starym systemie. Historia cen sprzed sierpnia została wyzerowana.

W listopadzie 2023 sklep wyświetlał „-30%" od ceny bazowej sprzed 3 tygodni. UOKiK liczy od najniższej z 30 dni przed obniżką — czyli sprzed 12 tygodni, gdy SKU miał inną cenę regularną. Realna obniżka: nie 30%, tylko 8-14% na 47 SKU.

Żaden alert nie wyskoczył. Plugin świecił na zielono. Pricing Manager dowiedział się o naruszeniu 19 miesięcy po fakcie — od prawnika, nie od swojego narzędzia.

Twój Omnibus jest wdrożony. To nie znaczy, że działa.

Jeśli Twój sklep przechodził migrację platformy w ciągu ostatnich 24 miesięcy i nie masz logu ciągłości bazy cenowej, Twój plugin Omnibus może być formalnie zielony i faktycznie niezgodny — UOKiK liczy od daty obniżki, nie od daty go-live Twojej nowej instancji.

Macie Omnibus wdrożony. Ale czy wiecie, czy działa?

Styczeń 2025. Sklep z elektroniką, 2 200 SKU, Omnibus wdrożony przez integratora w Q1 2023. Mail od działu prawnego: UOKiK wszczął postępowanie wyjaśniające po jednej skardze klienta przez formularz online. Cena bazowa nie istniała w bazie 30 dni przed promocją — bo migracja na nowy ERP sześć miesięcy wcześniej zresetowała historię SKU. Plugin świecił na zielono przez cały listopad 2024.

Inny sklep, inny mechanizm, ten sam finał: dowiedziałeś się od prawnika, nie od swojego narzędzia.

Projekt IT vs. proces operacyjny

Wdrożenie Omnibus to projekt IT. Ma datę startu, kierownika, ticket w Jira, certyfikat zgodności od integratora i sign-off. Zamyka się raz, zwykle 4–8 tygodni. Compliance Omnibus to coś innego: proces operacyjny bez daty końca, bez jednego właściciela, najczęściej bez linijki w budżecie. Projekt wisi w Confluence z 2023 roku. Proces nie wisi nigdzie.

Błędy compliance nie ujawniają się przy go-live. QA przechodzi, dział prawny podpisuje protokół, integrator wystawia fakturę. Ujawniają się 6–18 miesięcy później — przy migracji platformy (Magento → Shopify), zmianie ERP (Comarch → SAP), sezonowym przeindeksowaniu katalogu po Black Friday, splicie wariantów (jedno SKU dzielone na 4 kolory) albo merge'u (4 warianty zwijane w jeden master). Rutynowe operacje katalogowe. Żaden z tych ticketów nie wraca do Pricing Managera z flagą „uwaga, Omnibus".

A potem przychodzi mail. Kara: 200 000–2 000 000 PLN (art. 106 ust. 1 pkt 4 ustawy o ochronie konkurencji i konsumentów), plus obowiązek zwrotu różnicy ceny każdemu klientowi, który kupił w promocji. Jedna skarga przez formularz online wystarczy do wszczęcia postępowania wyjaśniającego.

Model dojrzałości Omnibus (skopiuj na Slack category managerów):

• Poziom 0: nie wyświetlasz ceny bazowej. Naruszenie wprost.
• Poziom 1: wyświetlasz cokolwiek, raz wpisane ręcznie. Większość audytowanych sklepów.
• Poziom 2: algorytm formalnie poprawny w dniu go-live, walidacji ciągłej brak.
• Poziom 3: automatyczna walidacja przed każdą publikacją promocji + audit trail per SKU.
• Poziom 4: monitoring ciągły bazy 30d, alert na anomalie (np. wyzerowanie historii po deployu).

Izba Handlu Elektronicznego szacuje, że 40–60% polskich sklepów z formalnie wdrożonym Omnibus siedzi na poziomie 1–2 — nie z braku woli, z braku ciągłego monitoringu.

Test na teraz: 3 SKU z ręki

Otwórz arkusz top 10 sprzedaży. Wybierz 3 SKU. Sprawdź w bazie cen platformy: czy najniższa cena wyświetlana przy ostatniej aktywnej promocji to faktycznie najniższa z 30 dni przed startem obniżki — nie cena „poprzednia", nie „regularna", nie „katalogowa".

Jeśli odpowiedź brzmi „sprawdzałem przy wdrożeniu w 2023" — masz lukę compliance, której żaden dashboard nie pokaże, a UOKiK znajdzie przy pierwszej kontroli. 19 miesięcy między naruszeniem a decyzją to standard, nie wyjątek. Następna sekcja pokazuje sześć konkretnych miejsc, w których ten test najczęściej oblewają nawet dobrze wdrożone sklepy — zanim dojdziesz do audit trail i checklist 15 pytań na końcu artykułu.

Wdrożenie Omnibus to projekt IT — compliance Omnibus to proces operacyjny. Polskie e-commerce odrobiło projekt i zapomniało o procesie.

6 błędów wdrożenia Omnibus, które znajdziesz w co drugim polskim sklepie

Wrzesień 2024. UOKiK nałożył 620 000 PLN kary na sklep RTV za błędną bazę Omnibus w kampanii „Back to School". Pricing Manager dowiedział się z pisma od radcy prawnego — 11 dni po zakończeniu kampanii. Plugin compliance przez całe 6 tygodni kampanii pokazywał zielony status. Maksymalna kara UOKiK to 10% obrotu rocznego — przy 8 mln PLN przychodu to 800 000 PLN. Przy 80 mln PLN to 8 mln PLN.

Sześć mechanizmów psuje się w tych samych miejscach, niezależnie od platformy. Sprawdź, który z nich masz u siebie.

Błąd 1: Zła baza 30 dni — najczęstszy i najkosztowniejszy

Art. 4 ust. 2a ustawy o informowaniu o cenach: baza Omnibus to najniższa cena z 30 dni przed wprowadzeniem obniżki. Nie „cena poprzednia". Nie „cena regularna". Nie „cena katalogowa z systemu PIM".

Przykład z prawdziwego sklepu odzieżowego — 1 200 SKU, audyt wewnętrzny luty 2025:

• Cena 199 PLN przez 3 miesiące (sierpień–październik 2024)
• Cicha obniżka do 189 PLN przez 15 dni (1–15 listopada)
• Black Friday: ogłoszono „-20%" = 151 PLN

Poprawna baza Omnibus: 189 PLN (najniższa z ostatnich 30 dni przed obniżką). Sklep wyświetlał „było 199 PLN, teraz 151 PLN". Realna obniżka: 20%. Komunikowana: 24%. Różnica per SKU: 4 PLN. Przy 2 800 transakcjach na 47 SKU naruszonych w ten sam sposób: 11 200 PLN nadwyżki w komunikacji marketingowej. Wystarczyło, żeby UOKiK zaczął zadawać pytania.

Gdzie to się psuje technicznie: algorytm pluginu pobiera pole previous_price z tabeli produktu — zamiast wykonać MIN(price) FROM price_history WHERE sku=X AND timestamp BETWEEN NOW()-30d AND promo_start. Różnica jednego zapytania SQL. Niewidoczna w QA, bo testy integratora używają syntetycznych danych z pełną historią. Widoczna dopiero w produkcyjnym logu cenowym — którego nikt nie przegląda.

Sprawdź: zapytaj integratora o dokładną logikę liczenia bazy. Jeśli odpowiedź zawiera słowo „previous_price" — masz problem.

Błąd 2: Zestawy, cross-sell i warianty — luka którą UOKiK zna

Zestaw ABC (np. „garnek + pokrywka + łyżka") sprzedawany pod jednym SKU zestawu ma własną historię cen — nie jest sumą historii składników. Jeśli SKU zestawu został utworzony w sklepie 12 dni temu i nigdy wcześniej nie miał ceny w bazie, nie można poprawnie obliczyć bazy 30-dniowej. Każda promocja zestawu w pierwszych 30 dniach po utworzeniu SKU to formalne naruszenie.

Warianty produktu — rozmiar, kolor, pojemność. Split wariantu (jedno SKU dzielone na 4 kolory) lub merge (4 warianty zwijane w jeden master) resetuje historię cen, bo platforma traktuje nowe ID wariantu jako nowy produkt. Okno 30 dni zaczyna się od zera w dniu operacji na katalogu. Rutynowa operacja merchandiserów. Najczęstsze źródło naruszeń wykrywanych przez UOKiK przy kontroli, bo nikt tego nie loguje jako zmiany pricingowej.

Cross-sell „kup X, dostaniesz -15% na Y": produkt Y ma swój Omnibus niezależnie od X. Baza Y liczona dla Y osobno, nie dla zestawu X+Y. Sklep elektroniczny w Q2 2024 dostał wezwanie wyjaśniające — ich algorytm liczył bazę dla konfiguracji „X+Y", nie dla samego Y. Różnica: 23 PLN per transakcja, 1 400 transakcji, postępowanie wciąż w toku.

Błąd 3 i 4: Kody rabatowe i cicha bomba migracji

UOKiK potwierdził w wyjaśnieniach z 2022–2023: kod rabatowy to obniżka ceny w rozumieniu Omnibus. Cena finalna po zastosowaniu kodu musi być wyższa lub równa najniższej cenie z 30 dni przed aktywacją kodu dla danego SKU. Wiele sklepów wyłącza kody z logiki Omnibus całkowicie — bo „to przecież nie zmiana ceny produktu, tylko rabat klienta".

Kombinacja krytyczna: flash sale + kod rabatowy. Flash sale obniżył cenę do 169 PLN i po 30 dniach ta cena stała się nową bazą Omnibus. Kod rabatowy „WIOSNA15" obniża jeszcze o 15% — do 143 PLN. Cena 143 PLN jest poniżej bazy 169 PLN. Naruszenie. Żaden plugin Omnibus tego nie złapie, bo flash sale i moduł kodów rabatowych to dwa osobne systemy, które nie czytają nawzajem swoich logów.

Migracja platformy lub re-import z PIM: jeśli historia cen nie jest migrowana razem z danymi produktowymi — a rzadko jest, nikt o to nie pyta w przetargu IT — okno 30 dni liczy się od daty migracji. Sklep, który przeszedł z Magento na Shopify w marcu 2024, w kwietniu może legalnie ogłosić promocję tylko od najniższej ceny po 1 marca. Jeśli ogłosi „był 599, teraz 399" odnosząc się do ceny z lutego — naruszenie. Tę wadę UOKiK wykrywa rok później, przy okazji innej kontroli — dokładnie ten sam mechanizm, który zostawił sieć odzieżową z hooka tego artykułu z karą 340 tys. PLN.

Błąd 5 i 6: Marketplace i brak weryfikacji konkurencji

Allegro: sprzedawca odpowiada za Omnibus na własnych ofertach — platforma nie weryfikuje poprawności bazy automatycznie. Allegro Centrum Zgodności istnieje od 2023 roku i flaguje wybrane naruszenia, ale korzysta z niego mniejszość aktywnych sellerów. Jeśli synchronizujesz ceny przez BaseLinker, historia cen u Allegro to to, co do Allegro trafiło — nie to, co masz w swoim ERP. Rozbieżność synchronizacji = naruszenie po stronie sprzedawcy, nie BaseLinkera.

Drugi problem marketplace: Twoi konkurenci z błędnym Omnibus. Konkurent winduje cenę z 199 na 299 PLN na 36 godzin przed Black Friday, potem ogłasza „-40%" = 179 PLN. Formalnie Omnibus spełniony (najniższa z 30 dni: 199, obniżka liczona od 199 = 10%, ale komunikat „-40%" odnosi się do ceny przekreślonej). Twoja uczciwa obniżka 15% wygląda blado przy „-40%" konkurenta. Tracisz konwersję na tle reklamy, która jest na granicy legalności — ale wizualnie atrakcyjniejsza.

Brak monitoringu Omnibus u konkurencji to nie tylko przeoczenie compliance — to oddanie im rynkowej przewagi na zasadach, których nie możesz replikować legalnie. Sygnał zgłoszenia do UOKiK przez formularz online to 5 minut roboczych Twojego analityka. Postępowanie wyjaśniające u konkurenta to 12–18 miesięcy operacyjnej przewagi po jego stronie — albo Twojej, jeśli zrobisz to pierwszy. Do tego wątku wracamy w sekcji o monitoringu konkurencji.

Jeśli w ostatnim roku miałeś migrację platformy, split wariantu lub flash sale z kodem rabatowym — sprawdź historię cen dla tych SKU zanim UOKiK zrobi to za Ciebie.

UOKiK 2024–2025: ile naprawdę kosztuje naruszenie Omnibus

Marzec 2025. Do Twojej skrzynki trafia forward z działu prawnego: UOKiK wszczął postępowanie wyjaśniające dotyczące kampanii Black Friday 2023. Szukasz w pamięci — 16 miesięcy temu, 47 promocji temu, dwie rotacje w zespole temu. Potencjalna kara: 350–500 tys. PLN za jedną kampanię. Mechanizm: art. 24 uokik, maksimum 10% rocznego obrotu — ale realne decyzje wobec e-commerce 50–300 osób to właśnie ten środkowy przedział.

Realne kwoty i mechanizm egzekucji

Maksimum ustawowe (10% obrotu) to liczba dla nagłówków. W decyzjach UOKiK z 2024–2025 wobec sklepów średniej wielkości — 20–80 mln PLN przychodu rocznego — realne kary za naruszenia Omnibus mieszczą się w przedziale 200–700 tys. PLN. To rząd wielkości, na którym CFO zaczyna pytać o procedury, a nie tylko o zapłatę.

Tło europejskie: CPC Sweep Omnibus 2023 — koordynowana kontrola sieci Consumer Protection Cooperation, ponad 250 sklepów w UE, w której polski UOKiK uczestniczył jako jeden z aktywniejszych regulatorów. Wynik: ok. 30% badanych sklepów miało naruszenia Omnibus. Prezes UOKiK ogłosił następnie Omnibus priorytetem egzekucyjnym na 2024 rok. Postępowania wszczęte w 2024 zamykają się decyzjami w 2025–2026 — część z nich dotyczy promocji z przełomu 2023/2024, których Pricing Manager już nie pamięta.

Skala kar dla średniego e-commerce: 200–700 tys. PLN. Nie maksimum ustawowe. Środek rozkładu realnych decyzji.

18 miesięcy między naruszeniem a karą: dlaczego to najgorsza możliwa sytuacja

Ścieżka standardowa: konsument składa skargę przez formularz UOKiK online → urząd wszczyna postępowanie wyjaśniające → wezwanie do spółki → wezwanie trafia do działu prawnego → Ty dowiadujesz się 3–4 tygodnie po wezwaniu, 8–18 miesięcy po samym naruszeniu.

Pricing Manager dostający w maju 2025 forward o kampanii Black Friday 2023 nie pamięta: którego dnia ruszyła obniżka na konkretne SKU, jakie były ustawienia repricera, kto autoryzował zmianę bazy, czy w międzyczasie była migracja platformy. Wewnętrzne maile sprzed 16 miesięcy są w archiwum, w międzyczasie dwóch kategorystów odeszło. Bez audit trail — bez timestampowanych logów ceny per SKU per godzina — obrona jest niemożliwa.

UOKiK przedstawia w postępowaniu zrzuty z własnego monitoringu (Wayback Machine, screeny od skarżącego, dane od porównywarek). Brak Twoich logów to domniemanie winy de facto: nie negocjujesz wysokości kary, dostajesz decyzję nakazującą plus pełną kwotę. To samo postępowanie z pełnym audit trail kończy się w ok. 60% przypadków obniżeniem kary lub umorzeniem części zarzutów.

Audit trail logów cen per SKU per godzina to nie compliance dla compliance — to jedyna waluta negocjacji w postępowaniu UOKiK.

Interpretacje UOKiK, których nie znajdziesz wprost w ustawie

Trzy pułapki, w które wpadają nawet dobrze wdrożone sklepy:

Flash sale poniżej 24h. Ustawa milczy. Wytyczne UOKiK — nie milczą. Stosują Omnibus identycznie jak do standardowej promocji. Twój 4-godzinny „Happy Hour" na newsletter wymaga ceny bazowej z 30 dni. Brak wyjątku czasowego.

Cena klubowa / abonamentowa wyświetlana publicznie. „Dla członków klubu Pro –20%" widoczne na stronie produktowej dla zalogowanych = cena prezentowana publicznie = Omnibus obowiązuje. To, że potrzebujesz konta, żeby ją zobaczyć, nie ma znaczenia — kluczowa jest widoczność na liście produktów.

Wyprzedaż sezonowa. Baza 30 dni liczona jest od daty ogłoszenia komunikatu „–X%", nie od logistycznego startu kampanii. Przy planowaniu z 2-tygodniowym wyprzedzeniem (banner ruszył 5 lutego, ceny realnie spadły 19 lutego) Twój kontrolny zakres 30 dni cofa się o 14 dni dalej, niż liczy to dział marketingu. To jest właśnie miejsce, w którym najczęściej kruszy się dobrze zaprojektowany monitoring — jak go wzmocnić, pokazuje następna sekcja o minimum operacyjnym audit trail.

200–700 tys. PLN kary to od 2 do 8 miesięcy rocznego budżetu narzędziowego działu pricing — za naruszenie które zdarzyło się półtora roku temu i o którym już nie pamiętasz.

Minimum operacyjne: co logować codziennie żeby przeżyć kontrolę UOKiK

Kontrola UOKiK trafia do Ciebie 14 miesięcy po promocji. Pytanie pierwsze: "Proszę przedstawić historię cen SKU XYZ za okres 1-30 października 2024 wraz z dziennymi snapshotami." Jeśli na to pytanie odpowiadasz "sprawdzę w systemie", przegrałeś. Jeśli odpowiadasz "wysyłam CSV z timestampami w 20 minut", grasz dalej.

5 typów zdarzeń które muszą być w audit trail

Pięć rekordów dziennie, każdy z timestampem co do sekundy, każdy z operatorem (człowiek lub system źródłowy):

1. Zmiana ceny regularnej — {timestamp, sku, cena_stara, cena_nowa, operator, source}. Nie ma znaczenia czy zmiana wynika z repricera, importu PIM, ręcznej edycji w panelu — wszystko ląduje w jednym strumieniu.
2. Uruchomienie promocji — {timestamp, sku/kategoria, procent_obnizki, baza_omnibus_obliczona, cena_wynikowa}. Baza Omnibus musi być zamrożona w momencie startu, nie wyliczana ex post.
3. Operacja na wariancie (split, merge, zmiana ID) — flag RESET_HISTORII = TRUE. To jedyne zdarzenie, które wymaga ręcznej weryfikacji następnego dnia.
4. Kod rabatowy zastosowany do SKU — {timestamp, kod, sku, cena_po_kodzie, baza_omnibus}. Bez tego wpisu nie odtworzysz, dlaczego klient zapłacił 89 PLN zamiast 99 PLN.
5. Dzienny snapshot pełnego cennika — eksport CSV o 23:59 dla całego katalogu aktywnych SKU. Archiwum: 90 dni aktywne (gorąca baza), 12 miesięcy w cold storage (S3 Glacier, Backblaze B2 — koszt 5-10 PLN/mies. za 50 GB).

Kluczowy field, który większość pomija: czy_w_promocji (bool). Bez niego nie wyciągniesz 30-dniowego minimum cen regularnych jednym SQL-em:

```sql

SELECT MIN(cena) FROM historia_cen

WHERE sku = ? AND data >= CURRENT_DATE - 30

AND czy_w_promocji = FALSE;

```

Shoper, IdoSell, Magento — co robi platforma, co dorzucasz sam

Poza platformą zawsze dorzucasz dwie rzeczy: zewnętrzny monitoring (Dealavo, Pricelytics, Omnia Retail — 500-2500 PLN/mies.) oraz alert gdy cena_wynikowa < baza_omnibus dla TOP 100 SKU.

Ręcznie: 6h/tydzień × 150 PLN/h = 39 000 PLN/rok. Z narzędziem: 12 minut. Kara: 300 tys. PLN. Cały wzorzec jest szerszy niż Omnibus — automatyzacja procesów operacyjnych w polskim e-commerce zwykle przesuwa pricing, monitoring i compliance z godzin tygodniowo na minuty dziennie, a koszt narzędzia mieści się poniżej kwoty jednej kary za niedopilnowany proces.

Audit trail to nie biurokracja — to jedyne co stoi między Tobą a karą 300 tys. PLN za promocję którą już nie pamiętasz. 5 typów zdarzeń, codziennie, archiwum 12 miesięcy.

Monitoring Omnibus u konkurencji: nowy wymóg operacyjny i nieoczekiwana przewaga

Dlaczego to Twój problem, nie tylko ich

Wtorek, 14:00. Konkurent uruchamia kampanię na Twoim TOP-5 SKU — duża pralka, segment 1899–2199 PLN. Komunikat: „BLACK WEEK −40% od 2999 PLN, dziś 1799 PLN". Twoja oferta: legalne −25% od bazy Omnibus z ostatnich 30 dni, cena wynikowa 1849 PLN.

Klient widzi dwie liczby: 1799 vs 1849. Pięćdziesiąt złotych różnicy plus duży, czerwony „−40%" obok mizernego „−25%". Twoja konwersja na karcie produktu w Allegro spada z 4,1% do 2,6% w 48 godzin.

Problem: cena bazowa „2999 PLN" u konkurenta to fikcja. Faktyczna najniższa cena z 30 dni przed kampanią wynosiła 2199 PLN — co oznacza, że jego prawdziwa baza Omnibus to 2199, a deklarowane „−40%" powinno wynosić „−18%". Naruszenie ewidentne, ale tymczasowo opłacalne: dopóki UOKiK się nie odezwie (8–18 miesięcy, jak w sekcji o egzekucji), konkurent zbiera ruch z displayu i wypycha Twoją ofertę z Buy Boxa.

Allegro pogłębia problem. Algorytm sortowania nie weryfikuje poprawności bazy Omnibus u sprzedawców — sprawdza cenę wynikową, koszty wysyłki, ocenę sprzedawcy. Oferta z błędnym Omnibus, ale niską ceną finalną, awansuje w rankingu nad Twoją zgodną ofertę.

Naruszenie Omnibus u konkurencji to nie ich problem prawny. To Twoja strata konwersji w czasie rzeczywistym.

Jak monitorować Omnibus u konkurencji — krok po kroku

Co zbierasz. Historię cen TOP 100 SKU nakładających się z Twoim katalogiem — daty zmian, poziomy cen, daty ogłoszonych promocji z deklarowanym procentem obniżki. Nie cały katalog konkurenta. Tylko produkty, na których faktycznie konkurujesz o klienta.

Co weryfikujesz. Dla każdej promocji konkurenta zadajesz dwa pytania: (1) Czy cena bazowa wyświetlana w komunikacie („było X") równa najniższej cenie z 30 dni przed datą ogłoszenia? (2) Czy procent obniżki wyliczony z baseline'u zgadza się z deklarowanym? Rozjazd = naruszenie do udokumentowania.

Narzędzia. Dealavo i Pricelytics przechowują historię cen z polskich sklepów i marketplace'ów minimum 60 dni wstecz — retrospektywna analiza dostępna bez własnej infrastruktury. Koszt: 1500–4500 PLN/mies. za katalog 500–2000 SKU. Jeśli zamiast retrospektywy potrzebujesz monitoringu cen konkurencji w czasie rzeczywistym — to inna klasa narzędzia, mierzona w latencji minutowej, nie w głębokości archiwum. Własny scraper z archiwum działa do ~500 SKU nakładających się — Python + Playwright + Postgres, ~80 godzin developera na MVP plus 200–400 PLN/mies. za proxy rotujące.

Skarga do UOKiK. Materiał dowodowy: timeline cen konkurenta w CSV + zrzut ekranu wyświetlanej obniżki z datą i godziną + URL kampanii. Skarga przez formularz online (uokik.gov.pl/skarga). Postępowanie wyjaśniające trwa 2–4 miesiące — w tym czasie UOKiK może wystosować wezwanie do korekty kampanii. Konkurent dostaje wybór: wycofać reklamę albo ryzykować decyzję z karą 200–700 tys. PLN (rząd wielkości z poprzedniej sekcji).

Legalność scrapingu. Publicznie dostępne ceny ze stron www to dane faktyczne, nie utwór — orzecznictwo TSUE (C-30/14, Ryanair vs PR Aviation) plus polskie prawo autorskie wykluczają ochronę. Legalność scrapowania publicznych cen konkurencji opiera się dokładnie na tych samych przesłankach co scraping danych publicznych z CEIDG — fakt publicznej dostępności + brak twórczego wkładu w samym cenniku. Jedyne ograniczenia: rate limiting (nie obciążaj serwera konkurenta) i respect ToS w zakresie rejestracji konta.

Monitoring Omnibus u konkurencji to jednocześnie tarcza i miecz — wiesz gdzie jesteś narażony na nieuczciwe porównanie, i masz materiał do skargi UOKiK która może wyłączyć niezgodną kampanię konkurenta w ciągu kwartału.

Checklist audytu Omnibus: 15 pytań, godzina pracy, konkretna odpowiedź

Godzina Twojego czasu, kartka A4, dostęp do panelu pricing i do logów platformy. Tyle wystarczy, żeby wyjść z konkretną listą: 15 zielonych odpowiedzi, albo 8 zielonych i 7 czerwonych z priorytetami na następne 14 dni. Nie potrzebujesz konsultanta zewnętrznego ani audytu prawnego za 35 000 PLN. Potrzebujesz zdyscyplinowanej godziny pracy.

Zasada: każde „nie wiem" liczy się jak „nie". „Nie wiem" nie wymaga natychmiastowej naprawy — wymaga weryfikacji przed Twoją następną kampanią promocyjną. Pytania 3, 9, 13 i 15 to najczęstsze luki w polskim e-commerce — „nie wiem" na każde z nich to odrębne ryzyko postępowania UOKiK.

Blok A — Baza i algorytm (pytania 1–5)

P1. Czy baza 30 dni to MIN(cena) z okna 30 dni przed datą uruchomienia promocji — nie „cena poprzednia", nie „cena katalogowa", nie „cena z ostatniej akcji"? Jeśli Twój CMS wyświetla „cena poprzednia: 199 PLN" zamiast „najniższa z 30 dni: 179 PLN" — czerwone. To dokładnie ten sam mechanizm previous_price z Błędu 1.

P2. Czy algorytm obsługuje wielokrotne zmiany ceny w oknie 30 dni? Cena spadła 199 → 189 → 175 → 189, ruszasz promocję. Baza = 175. Nie 189 (ostatnia), nie 199 (pierwsza). MIN z wszystkich.

P3. Czy split/merge wariantów (kolor, rozmiar, pakiet) zachowuje historię cen? Sprawdź log dla 3 ostatnich operacji tego typu w katalogu. To pytanie #1 wśród „nie wiem" — większość platform tworzy nowe SKU z pustą historią po splicie, co technicznie resetuje Omnibus do dnia stworzenia wariantu.

P4. Czy cena po zastosowaniu kodu rabatowego (np. RABAT15) jest porównywana z bazą Omnibus tego SKU obowiązującą w momencie aktywacji kodu? Kody personalne i masowe — wszystkie pod tę samą logikę.

P5. Czy flash sale krótszy niż 24h jest traktowany jako obniżka z zapisem do logu zdarzeń? Flash sale nie zwalnia z Omnibus.

Blok B — Zakres i edge-case'y (pytania 6–10)

P6. Zestawy i bundle'e — własne SKU z własną historią cen, czy suma historii składników? Tylko pierwsza opcja jest legalna.

P7. Subskrypcje i abonamenty wyświetlane publicznie na stronie produktowej — mają przypisaną bazę Omnibus? Jeśli wyświetlasz cenę publicznie, dotyczy Cię Omnibus.

P8. Omnibus działa poprawnie na marketplace'ach (Allegro, Ceneo)? Wejdź w Allegro Centrum Zgodności, zweryfikuj ostatnią aktywną promocję. Niezsynchronizowana baza między CMS a Allegro = osobne naruszenie, osobna kara.

P9. Migracja platformy, zmiana ERP, re-import PIM w ostatnich 24 miesiącach. To pytanie #2 wśród „nie wiem". Każda taka operacja mogła zresetować historię cen dla grupy SKU bez Twojej wiedzy — dokładnie ten scenariusz z hooka i z Błędu 4.

P10. Wyprzedaż sezonowa — baza Omnibus od dnia pierwszej ekspozycji komunikatu promocyjnego (ogłoszenie), nie od dnia logistycznego startu wysyłek.

Blok C — Audit trail i monitoring (pytania 11–15)

P11. Każda zmiana ceny regularnej logowana? {timestamp, sku, cena_stara, cena_nowa, operator, source} — append-only, nie nadpisywalne wstecz.

P12. Każda promocja zapisuje obliczoną bazę Omnibus jako osobne pole w logu, nie tylko cenę wynikową? Bez tego nie odtworzysz po 6 miesiącach, dlaczego konkretne SKU dostało konkretną cenę.

P13. Codzienny snapshot pełnego cennika, retention 90 dni hot + 12 miesięcy cold, format CSV z timestampem gotowy do przedstawienia UOKiK? To gate question dla każdej kontroli.

P14. Automatyczny alert gdy cena promocyjna lub kod rabatowy schodzą poniżej bazy Omnibus? Bez tego polegasz na czujności merchandisera o 23:00 w niedzielę przed Black Friday.

P15. Ktoś z zespołu pricing weryfikował ręcznie TOP 10 SKU w ciągu ostatnich 30 dni roboczych? Spot-check 30 minut, raz w miesiącu — pytanie #3 wśród „nie wiem".

Scoring i priorytetyzacja

13–15 TAK: solidny compliance, wracaj do priorytetów biznesowych. 9–12 TAK: luki operacyjne, priorytet na pytania z odpowiedzią „nie" — najczęściej P3, P9, P13. Poniżej 9 TAK: ekspozycja finansowa realna (kara UOKiK 200k–2M PLN nie jest abstrakcją), czas na techniczny audit, ale dopiero po naprawieniu Bloku C.

Jeśli równolegle pojawia się TAK na pytanie „czy w ostatnich 12 miesiącach dostałeś zapytanie lub wezwanie UOKiK dotyczące Omnibus" — jesteś w postępowaniu. Ta checklista wtedy nie wystarczy. Skontaktuj się z kancelarią od razu, nie z dostawcą narzędzia pricing. Inna ścieżka, inne zegary.

Format roboczy: Google Sheet z kolumnami TAK / NIE / W TRAKCIE + Właściciel + Deadline. Gotowy do zabrania na spotkanie z IT i z prawnikiem. Nie PDF prezentowy — arkusz operacyjny.

15 pytań w godzinę. Jeśli masz więcej niż 3 odpowiedzi 'nie wiem' w Bloku C — potrzebujesz audit trail, nie kolejnego webinaru o Omnibus.

Następny krok

Zrób checklistę 15 pytań na 3 SKU w tym tygodniu. ≥3 wpisy „nie wiem" w Bloku C = masz materiał na rozmowę z IT i działem prawnym, nie z kolejnym dostawcą pluginu.

Jeśli wolisz, żeby ktoś zewnętrzny zweryfikował 100 SKU z archiwum cen Twoich i konkurentów w 5 dni roboczych — wynik w formie arkusza z zielonymi i czerwonymi pozycjami plus harmonogramem naprawy — napisz na wojtek@dataminers.pl. W wiadomości wystarczy: branża, wielkość katalogu i informacja, czy w ostatnich 24 miesiącach była migracja platformy lub ERP. Odpowiedź w 24 godziny.

```