Promocja, która się nie kończy

Objaw

Ustawiłeś promocję na dwa tygodnie w marcu. Jest wrzesień. Karta produktu wciąż pokazuje przekreśloną cenę regularną i pobiera promocyjną.

Nikt się nie poskarżył, bo z perspektywy klienta nic nie jest nie tak. To jest dobra cena.

Ile to kosztuje

To rzadki przypadek, w którym koszt jest dokładny, nie szacowany: liczba sztuk sprzedanych po dacie końca × różnica między ceną regularną a promocyjną. Bez modelowania, bez założeń o konwersji.

Warto zrozumieć mechanizm, bo tłumaczy, dlaczego to jest tak częste. WooCommerce nie porównuje dat przy wyświetlaniu produktu. Trzyma trzy wartości — _regular_price, _sale_price i _price — a zaplanowane zadanie wc_scheduled_sales przepisuje _price z powrotem na cenę regularną, gdy promocja wygasa.

To zadanie jedzie na kolejce. Jeśli kolejka stanęła, promocja nie kończy się nigdy — i nie kończy się po cichu: bez powiadomienia, bez maila, bez wpisu w jakimkolwiek logu. Patrz zaplanowane zadania nie działają: w większości sklepów te dwa znaleziska pojawiają się razem, a prawdziwą naprawą jest kolejka.

Jak to sprawdzić samodzielnie

Najważniejsza w tym zapytaniu jest ostatnia linia: zgłasza wyłącznie produkty, w których rabat nadal obowiązuje, a nie takie, którym po prostu została stara data w polu meta.

wp db query "SELECT p.ID, p.post_title,
    FROM_UNIXTIME(dt.meta_value) AS koniec,
    rp.meta_value AS regularna, sp.meta_value AS promocyjna
  FROM wp_posts p
  JOIN wp_postmeta dt ON dt.post_id = p.ID AND dt.meta_key = '_sale_price_dates_to'
  JOIN wp_postmeta rp ON rp.post_id = p.ID AND rp.meta_key = '_regular_price'
  JOIN wp_postmeta sp ON sp.post_id = p.ID AND sp.meta_key = '_sale_price'
  JOIN wp_postmeta pr ON pr.post_id = p.ID AND pr.meta_key = '_price'
  WHERE p.post_status = 'publish'
    AND dt.meta_value <> '' AND dt.meta_value < UNIX_TIMESTAMP()
    AND pr.meta_value = sp.meta_value"

Podmień wp_ na własny prefiks. Warianty trzymają własne kopie tych trzech pól, więc w katalogu wariantowym dodaj post_type IN ('product','product_variation') — produkt nadrzędny może wyglądać poprawnie, a jeden jego wariant siedzi na cenie z zeszłej wiosny.

Jak naprawić

1. Niech zrobi to WooCommerce, raz, ręcznie:

   wp eval 'wc_scheduled_sales();'

   To ta sama funkcja, którą miała wykonać kolejka. Kończy wygasłe promocje poprawnie — razem z polem _price i wierszem w tabelach pomocniczych produktu.

2. Napraw kolejkę, inaczej powtórzy się to za kwartał. To jest właściwa naprawa.

3. Potem zdecyduj, co ze złożonymi już zamówieniami. Nic nie wymusza tu decyzji, ale warto znać liczbę, zanim stanie się niespodzianką w zestawieniu marż.

Jedyna rzecz, której nie należy robić, to edycja _price prosto w bazie — WooCommerce trzyma pochodne kopie w tabelach pomocniczych, a ręcznie poprawiony wiersz sprawia, że katalog i raporty mówią co innego.

Kiedy to fałszywy alarm

• Świadomie przedłużyłeś promocję i nie zaktualizowałeś daty końca. Częste, nieszkodliwe, warto uporządkować, żeby następny audyt był cichy.
• Cena promocyjna równa się regularnej. Niektóre importery zapisują oba pola identycznie — nie ma rabatu do stracenia. Merchlint takie pomija.
• Wtyczka cenowa nadpisuje wszystko — dynamic pricing, ceny per rola, hurt. Takie rozwiązania ustalają cenę końcową w locie, więc zapisane pola niewiele mówią. Jeśli używasz którejś, potraktuj to znalezisko jako powód do sprawdzenia, nie jako werdykt.

Jak znajduje to Merchlint

Merchlint odczytuje _sale_price_dates_to, _regular_price, _sale_price i _price każdego opublikowanego produktu i wariantu, a zgłasza pozycję wyłącznie wtedy, gdy data końca minęła i _price wciąż równa się _sale_price — czyli gdy rabat naprawdę jest nadal pobierany. Przy znalezisku widać datę końca, obie ceny i różnicę.

Pewność: F — fakt z bazy. Dwie zapisane wartości porównane z zapisaną datą; nic nie jest wnioskowane.

Tam, gdzie dostępne są dane zamówień, znalezisko niesie też liczbę sztuk sprzedanych po dacie końca i wynikającą z tego różnicę — jedna z niewielu liczb w całym raporcie, która jest arytmetyką, a nie szacunkiem.