Dyrektywa Omnibus w Magento

Czym jest dyrektywa Omnibus?

Dyrektywa Omnibus wprowadza obowiązek transparentnego prezentowania promocji: przy każdej obniżce ceny należy pokazać najniższą cenę produktu z 30 dni przed wprowadzeniem promocji. Dotyczy to e-commerce od 2023 r. i wpływa bezpośrednio na to, jak wyświetlasz ceny na kartach produktów i listach kategorii.

Co dokładnie trzeba pokazać?

Obok aktualnej ceny promocyjnej (np. special_price) powinna widnieć informacja:

• „Najniższa cena z ostatnich 30 dni: X zł”.

Możesz ją zaprezentować jako:

• osobną linię pod ceną,
• etykietę obok przekreślonej ceny,
• w sekcji szczegółów (o ile jest łatwo dostępna i widoczna bez wysiłku).

Uwaga: dla nowości (produktów młodszych niż 30 dni) pokaż:

• „Najniższa cena od premiery: X zł” (lub równoważny, nie wprowadzający w błąd komunikat).

Jak wdrożyć Omnibus w Magento (technicznie)

1) Dane: gdzie trzymać historię cen

Najczystsze podejście to własna tabela historii cen (np. omnibus_price_history) z polami:

• entity_id (ID produktu),
• store_id (bo Omnibus działa per sklep/rynek),
• price_type (regular, special, tier – jeśli chcesz),
• price (decimal),
• valid_from, valid_to (UTC),
• indeks pomocniczy po (entity_id, store_id, valid_from).

Źródła cen, które warto zapisywać:

• price i special_price (+ special_from_date, special_to_date),
• ceny wariantów (dla configurable, minimum z wariantów eksponowanych),
• ceny zestawów (bundle) – minimalna możliwa konfiguracja zestawu,
• ewentualnie tier price (jeśli promocje komunikujesz na poziomie podstawowej ceny – zazwyczaj nie liczymy rabatów koszykowych).

2) Kiedy zapisywać cenę

Hooki i procesy:

• events/observers: catalog_product_save_after, catalog_product_attribute_update_after,
• cron (np. co noc): walidacja i uzupełnienie historii cen (importy ERP, korekty),
• importy ERP/API: po każdej zmianie ceny rób commit do historii.

3) Algorytm „najniższa z 30 dni”

• Okno czasu: [Dziś – 30 dni, Dziś) w strefie czasu sklepu.
• Bierz cenę referencyjną, od której liczysz obniżkę (najczęściej regularną price; jeżeli komunikujesz „obniżkę” przez special_price, porównuj do wartości realnie prezentowanej jako „cena była”).
• Dla configurable: „najniższa z 30 dni” = minimum z wariantów, które były dostępne (status, stock).
• Dla bundle: minimalny koszt najtańszej poprawnej konfiguracji w danym dniu.
• Gdy brak danych (produkt nowy): komunikat „od premiery”.

4) Prezentacja na froncie (PDP/PLP)

• PDP: pod final_price dodaj blok:
  • „Najniższa cena w ostatnich 30 dniach: X zł”.
• PLP (lista): krótsza etykieta, np. „30-dniowe minimum: X zł” (jeśli masz miejsce).
• Dostępność mobilna: tekst min. 14–16 px, wysoki kontrast, nie chowaj zbyt głęboko w akordeonie.
• Wielosklepowość: pamiętaj o store_id – ceny i historia są per sklep/język/waluta.

5) Wydajność i indeksacja

• Dodaj materialized view lub pole zdenormalizowane (np. omnibus_min_30d) aktualizowane cronen/indekserem – wyświetlanie nie będzie spowalniać PDP/PLP.
• Stwórz indexer typu schedule (np. omnibus_price_indexer) – aktualizuje minima po zmianach cen.
• Pamiętaj o full page cache (FPC) i osobnym cache key zależnym od store_id i customer_group_id (jeśli logika różni się per grupa).

UX i dostępność (WCAG)

• Jasna etykieta: „Najniższa cena z ostatnich 30 dni” – unikaj skrótów i gwiazdek bez wyjaśnienia.
• Kontrast co najmniej 4.5:1.
• Czytelny układ: aktualna cena → przekreślona „była” (jeśli pokazujesz) → „najniższa z 30 dni”.
• Hyvä/Luma: w Hyvä (Tailwind/Alpine) dodaj komponent z a11y; w Lumie pamiętaj o nieprzeładowywaniu DOM.

Automatyzacja i raportowanie

• Raport zmian cen: per produkt, per sklep, z logiem: kiedy, z czego, na co.
• Alerty: jeśli „30-dniowe minimum” = aktualna cena przez dłuższy czas, oceń sensowność komunikatu.
• API/ERP: kontrakt na przesył danych cenowych + webhook po zmianie.

Wyzwania i pułapki

Dynamiczne ceny
Częste zmiany → duży wolumen wpisów. Rozwiązanie: rotacja danych (np. trzymasz 90 dni), indeksy i batchowe crony.

Produkty z wariantami
Pamiętaj, że klient widzi cenę konfiguracji – „minimum 30 dni” licz tak, by nie wprowadzać w błąd (np. najtańszy wariant naprawdę dostępny).

Promocje koszykowe (cart price rules)
Omnibus dotyczy komunikacji obniżki ceny produktu, nie rabatu naliczanego w koszyku. Nie mieszaj tych dwóch mechanik.

Konsekwencje błędów
Ryzyko kar finansowych, utrata zaufania, kontrole. Zadbaj o logi i spójność z regulaminem promocji.

Omnibus a SEO (i dane strukturalne)

• Treść: dodatkowa linia o „najniższej cenie” zwiększa kontekst i zaufanie – to może pośrednio poprawiać SEO.
• UX/SXO: klarowność cen → lepsza konwersja i sygnały behawioralne.
• Schema.org: oznacz Offer (price, priceCurrency, availability). Nie twórz własnych pól strukturalnych dla „najniższej z 30 dni”, jeśli nie są standardem – komunikat pokaż w HTML (widoczny dla użytkownika).

Checklista wdrożeniowa (skrót)

1. Tabela historii cen + indeksy.
2. Observer/cron zapisujący zmiany.
3. Algorytm minimum 30 dni (per store, typ produktu).
4. Indexer + cache z polami zdenormalizowanymi.
5. Komponent front-end (PDP/PLP, desktop + mobile).
6. Komunikaty dla nowości <30 dni.
7. Raporty i logi (śledzenie zmian, audyt).
8. Testy edge cases: configurable, bundle, wycofanie wariantu, brak historii.
9. WCAG/UX: rozmiar/kontrast/aria-labels.
10. Schema.org Offer poprawnie w JSON-LD (bez „custom” pól pod Omnibus).

Zastrzeżenie

To opis technicznego wdrożenia w Magento. Przed publikacją komunikatów i mechaniki promocji skonsultuj wording z prawnikiem, by mieć pewność, że spełniasz lokalne interpretacje przepisów (PL/UE) i wytyczne organów nadzorczych.