Sprzedawał się rok, dziś nie da się go kupić

Objaw

Nie ma objawu. I to jest cały problem.

Produkt, który sprzedawał się równo przez rok, przestaje być kupowalny — brak w magazynie, brak możliwości zakupu, brak poprawnej ceny — i nic nigdzie tego nie mówi. Żadnego błędu, powiadomienia ani maila. Zamówienia na niego po prostu przestają przychodzić, a sklep, do którego zamówienia wpadają codziennie, nie zauważa nieobecności jednego konkretnego produktu wśród nich.

Dowiadujesz się miesiącami później, zwykle dlatego, że pyta klient.

Ile to kosztuje

To jest kontrola, dla której powstała cała ta wtyczka, a powód jest arytmetyczny: już wiesz, ile ten produkt jest wart. Zarobił konkretną kwotę przez ostatnie dwanaście miesięcy. Dziś zarabia zero. Różnica nie jest prognozą — jest własnym dorobkiem tego produktu.

Ukrywa się tak dobrze dlatego, że WooCommerce ma obie połowy odpowiedzi i nigdy ich nie zestawia:

• Raport magazynowy wypisuje wszystko, czego nie ma na stanie — łącznie z trzema tysiącami produktów, które nigdy nie sprzedały ani jednej sztuki. Nikt nie czyta go dwa razy.
• Raport sprzedaży wypisuje to, co się sprzedało — ale nie mówi ani słowa o tym, czy nadal da się to kupić.

Interesujący jest przecięcie tych dwóch: rzeczy, które się sprzedawały i których nie da się kupić. Żaden ekran w WooCommerce tego nie pokazuje, żadna wtyczka w darmowym katalogu nie pokazywała tego, gdy powstawała ta — a to jedyna lista, na podstawie której właściciel sklepu faktycznie działa.

Jak to sprawdzić samodzielnie

Dwa kroki. Najpierw: co zarabiało przez ostatnie dwanaście miesięcy. WooCommerce trzyma tabelę analityczną dokładnie do tego i jest ona znacznie tańsza w odpytaniu niż pozycje zamówień:

wp db query "SELECT product_id, SUM(product_net_revenue) AS przychod, SUM(product_qty) AS sztuk
  FROM wp_wc_order_product_lookup
  WHERE date_created > DATE_SUB(NOW(), INTERVAL 12 MONTH)
  GROUP BY product_id
  ORDER BY przychod DESC"

Potem sprawdź bieżący stan czubka tej listy. Nie rób tego SQL-em — zapytaj WooCommerce, bo kupowalność zależy naraz od stanu magazynowego, ceny, typu produktu, wariantów i statusu, a odtwarzanie tej logiki w zapytaniu jest najkrótszą drogą do złej listy:

wp eval '
foreach ( [123, 456, 789] as $id ) {          // identyfikatory z zapytania wyżej
    $p = wc_get_product( $id );
    if ( ! $p ) { echo "$id: nie ma\n"; continue; }
    if ( ! $p->is_purchasable() || ! $p->is_in_stock() ) {
        printf( "%d\t%s\t%s\n", $id, $p->get_name(), $p->get_stock_status() );
    }
}'

Jak naprawić

1. Pracuj od góry kolumny z kwotami i skończ wcześnie. Trzy zatowarowane produkty to wynik, który zmierzysz w tym tygodniu. Dwieście przejrzanych produktów to tydzień bez czego pokazać.
2. Decyduj, nie zatowarowuj odruchowo. Przy każdym są trzy uczciwe odpowiedzi: przywrócić, zastąpić następcą i przekierować, albo wyjąć z katalogu, żeby przestał pochłaniać ruch — patrz sprzedawał się i został ukryty, dlaczego ukrycie bije widoczny-i-martwy.
3. Sprawdź, czy to w ogóle była decyzja. Produkt, który zniknął ze stanu w dniu importu, to inna historia niż taki, który się wyprzedał.
4. Potem zobacz, na co to wskazuje. Dostawca, który przestał dowozić, skasowany wariant, synchronizacja stanów, która nie chodzi od wiosny — znalezisko bywa objawem czegoś o szerszym zasięgu.

Kiedy to fałszywy alarm

• Świadomie wycofane linie. Zachowane w katalogu dla historii zamówień, i słusznie. Ukryj znalezisko — zostanie ukryte przy kolejnych skanach i przeżyje aktualizację.
• Towar sezonowy w niewłaściwej połowie roku.
• Rzeczy jednorazowe albo limitowane — vintage, rękodzieło, pojedyncze sztuki. Sprzedały się raz i nigdy nie miały wrócić.
• Produkty zastąpione następcą. Przychód przeniósł się na nowy produkt, a stary jest martwy poprawnie. Warte przekierowania, nie zatowarowania.

Jak znajduje to Merchlint

Dwa etapy, a podział jest ważniejszy, niż wygląda.

Wąski odczyt tabeli analitycznej wybiera kandydatów. wc_order_product_lookup to jedyne miejsce, w którym przychód per produkt jest już zagregowany; przejście przez zamówienia zwykłym API, żeby zsumować dwanaście miesięcy sprzedaży w sklepie z dwudziestoma tysiącami zamówień, nie jest czymś, co się robi, gdy ktoś czeka przed ekranem.

Potem każdego kandydata potwierdza WooCommerce przez wc_get_product(), zanim cokolwiek zostanie zgłoszone. O kupowalności rozstrzyga sam WooCommerce, a nie nasze odczytanie tabel.

Wniosek wart powiedzenia wprost, bo to świadomy wybór projektowy: jeśli schemat bazy się zmieni, ta kontrola może pominąć znalezisko — nigdy nie może go wymyślić. Cisza zaniża; nie kłamie. W sklepie, w którym tabela analityczna jest pusta albo wyłączona, kontrola mówi, że nie mogła się wykonać, zamiast zgłaszać zero problemów.

Pewność: F — fakt z bazy, potwierdzony drugi raz przez własne API WooCommerce.

Przychód nigdy nie jest sumowany między walutami. Sklep sprzedający w euro i w złotych dostaje osobną kwotę dla każdej, z jawnie podaną walutą — bo dodanie ich bez kursu byłoby wymyśleniem liczby, a jedna wymyślona liczba kosztuje wiarygodność całego raportu.