Przed Black Friday: co przegadać z zespołem o monitoringu sklepu

Black Friday wypada w tym roku 27 listopada. Jeśli Twój sklep robi wtedy dużą część listopadowej sprzedaży, godzina, w której klienci nie mogą kupić, kosztuje w ten dzień więcej niż zwykle, a zespół ma mniej czasu na szukanie przyczyny. W poprzednim wpisie, Sklep ma działać przez 99,99% czasu. Tylko czy to wystarczy, żeby dobrze sprzedawał?, pisałem, że sam uptime niewiele mówi o tym, czy klient może kupić. Ten tekst jest praktyczny: to pytania, które warto przegadać z zespołem deweloperskim albo agencją przed listopadem.

Nie jest to lista do odhaczenia. Każdy sklep jest zbudowany inaczej, ma inne integracje i inaczej zarabia. Część rzeczy da się sprawdzać automatycznie, część nie, i wtedy zamiast alertu potrzebny jest człowiek, który wie, na co patrzeć.

Zielony monitoring nie znaczy, że sklep sprzedaje

Najprostszy monitoring sprawdza, czy strona główna odpowiada. W wielu sklepach strona główna i karty produktów są podawane z pamięci podręcznej, czyli cache, bez udziału samej aplikacji. Dokumentacja Magento podaje koszyk i checkout jako przykłady stron, których cache nie obsłuży. Strona główna może więc działać, kiedy koszyk już nie działa, a monitoring będzie zielony.

Pierwsze pytanie do zespołu jest proste: co dokładnie sprawdza nasz monitoring? Dobra odpowiedź jest konkretna: który adres, jak często, co uznajemy za błąd i kto dostaje alert. Jeśli żaden test nie dochodzi do koszyka, przynajmniej wiesz, czego monitoring nie zobaczy.

Czy klient może znaleźć produkt i dodać go do koszyka

Ścieżka zakupu to zwykle wyszukiwarka albo kategoria, karta produktu, koszyk i checkout. Pytania do zespołu:

• Które z tych kroków sprawdza test automatyczny i jak często?
• Czy test sprawdza treść strony, na przykład czy widać cenę i przycisk „Dodaj do koszyka”, czy tylko to, że strona odpowiada?
• Jeśli przestanie działać wyszukiwarka, kto się dowie i po jakim czasie?

Drugie pytanie wynika z tego, że błąd modułu potrafi zostawić stronę, która technicznie odpowiada poprawnie, ale nie ma na niej ceny. Trzecie też nie jest teoretyczne. W Magento gotowy plik do monitoringu, health_check.php, sprawdza połączenie z bazą danych i cache, ale nie wyszukiwarkę. Sklep z niedziałającą wyszukiwarką może taki test przejść.

Test przechodzący przez koszyk zatrzymałbym przed złożeniem zamówienia, chyba że sklep ma testową metodę płatności, którą da się bezpiecznie włączyć tylko dla monitoringu.

Czy płatność wraca do sklepu

Po zapłacie bramka płatnicza wysyła do sklepu powiadomienie, że pieniądze wpłynęły. Monitoring strony tego nie widzi, bo ten ruch idzie z bramki do sklepu, a nie od klienta. Jeśli powiadomienie nie dotrze, klient zapłacił, a zamówienie może dalej czekać na płatność. Co dzieje się potem, zależy od bramki i modułu płatności, i to warto ustalić z zespołem:

• Co się stanie z zamówieniem, jeśli sklep nie odbierze powiadomienia z bramki?
• Czy ktoś zauważy, że zamówień oczekujących na płatność jest więcej niż zwykle?

Drugie pytanie to przykład sygnału, który widzi strona biznesowa, a nie serwer. Liczbę zamówień w danym statusie widać w panelu sklepu. W dniu dużej sprzedaży ktoś może po prostu regularnie na nią patrzeć.

Czy promocje wystartują o czasie

Część pracy sklepu dzieje się w tle, według harmonogramu, który programiści nazywają cronem: włączanie zaplanowanych promocji, odświeżanie indeksów, generowanie feedów, w części konfiguracji także wysyłka maili. Jeśli harmonogram stanie, sklep zwykle dalej przyjmuje zamówienia i z zewnątrz wygląda normalnie.

Przed Black Friday dobrze jest wiedzieć, co w Twoim sklepie od niego zależy. W Magento reguły cenowe katalogu wymagają crona, więc promocja ustawiona jako reguła cenowa katalogu na piątek o północy przy stojącym cronie się nie włączy. Kupony i reguły koszyka działają inaczej, więc warto zapytać, jak są ustawione promocje w Twoim sklepie. Maile o zamówieniach Magento domyślnie wysyła od razu, ale jeśli sklep ma włączoną wysyłkę w tle, one też zależą od crona. W WordPressie od harmonogramu zależą między innymi zaplanowane publikacje i zadania wtyczek.

Pytania do zespołu:

• Które promocje na Black Friday włączają się automatycznie o określonej godzinie i od czego to zależy?
• Jak się dowiemy, że harmonogram przestał działać?
• Kto sprawdzi o północy, że promocja się włączyła i ma właściwe ceny?

Odpowiedź „monitoring sprawdza adres crona” tu nie wystarcza. W WordPressie odpowiedź z wp-cron.php nie dowodzi, że jakiekolwiek zadanie się wykonało. Pewniej jest, gdy samo zadanie zgłasza monitoringowi, że skończyło przebieg, a brak takiego zgłoszenia uruchamia alert. To się nazywa heartbeat. Nawet on mówi jednak tylko, że zadanie się wykonało, a nie, że promocja ma dobre ceny. Dlatego trzecie pytanie dotyczy człowieka, a nie narzędzia.

Czy reklamy pokazują prawdziwe ceny

Jeśli sklep sprzedaje przez Google Shopping albo porównywarki, ceny trafiają tam z feedu produktowego. Według pomocy Merchant Center Google porównuje cenę w danych produktu z ceną na stronie i przy niezgodności może odrzucić produkt, a niezgodne ceny mogą prowadzić do zawieszenia konta. Jeśli przy Black Friday ceny zmieniają się częściej i w krótszym czasie niż zwykle, łatwiej o rozjazd.

• Jak często odświeża się feed i czy to pasuje do godzin, w których zmieniają się ceny?
• Kto w czasie kampanii patrzy w Merchant Center na produkty odrzucone za niezgodną cenę?

To przykład rzeczy, której test z zewnątrz nie zmierzy. Świeży plik feedu mówi tylko, że generator się uruchomił. Zgodność cen widać dopiero w Merchant Center.

Czy stany magazynowe się zgadzają

Jeśli stany przychodzą z ERP albo systemu magazynowego, to, że integracja odpowiada, nie znaczy jeszcze, że synchronizacja działa. Więcej mówi pytanie, kiedy ostatnio zaktualizowały się stany. Gdzie to sprawdzić, zależy od integracji, więc to pytanie do zespołu. Jeśli synchronizacja stanie w dniu dużego ruchu, sklep może sprzedawać towar, którego już nie ma.

Czy sklep wytrzyma ruch, który nie jest klientem

Duża kampania to nie tylko klienci. Podręcznik WordPressa opisuje ataki na logowanie, zwłaszcza przez plik xmlrpc.php, i zaznacza, że nawet nieudane próby potrafią przeciążyć stronę samą liczbą żądań.

• Czy logowanie i xmlrpc.php są ograniczone na poziomie serwera, CDN albo zapory aplikacyjnej?
• Czy zobaczymy, że takiego ruchu nagle przybyło?

Wdrożenia przed kampanią

Kilka rzeczy łatwo zepsuć przy wdrożeniu, a ich skutki widać dopiero po czasie: robots.txt, który blokuje sklep, znacznik noindex, który został na produkcji, niedziałająca sitemapa albo certyfikat TLS, który wygasa w listopadzie. Warto, żeby zespół sprawdzał je po każdej zmianie przed kampanią.

Jest też pytanie organizacyjne: do kiedy wdrażamy zmiany, a od kiedy tylko poprawki błędów? Nie ma tu jednej dobrej daty dla wszystkich sklepów. Ważne, żeby strona biznesowa i zespół znały tę samą.

Kto odbiera alert w nocy z czwartku na piątek

Monitoring, który wysyła alerty do skrzynki, której nikt nie czyta, niewiele daje. Przed kampanią ustaliłbym:

• kto dostaje alerty w czasie Black Friday i jaką drogą: telefon, komunikator czy mail;
• kto może podjąć decyzję biznesową, na przykład wyłączyć promocję albo metodę płatności;
• gdzie są kontakty do hostingu, operatora płatności i agencji.

To nie jest pomiar, tylko ustalenie. Część problemów i tak pierwszy zauważy człowiek, który widzi, że zamówień jest mniej, niż się spodziewał.

Od czego zacząć

Nie każde z tych pytań jest tak samo ważne w każdym sklepie. Jeśli większość sprzedaży idzie z reklam produktowych, pierwszym tematem może być feed i zgodność cen. Jeśli promocje są zaplanowane na konkretne godziny, harmonogram. Jeśli większość klientów płaci online przez jedną bramkę, powiadomienia o płatnościach. Ja zacząłbym od pytania, która awaria w Twoim sklepie najdłużej zostałaby niezauważona, i od niej zaczął rozmowę.

Czego nie widać na dashboardzie

Przygotowanie do Black Friday łatwo sprowadzić do zakupu lepszego narzędzia albo dopisania kolejnych testów. Narzędzie pomaga, ale nie powie, co w Twoim sklepie jest najważniejsze ani kto zareaguje, kiedy coś przestanie działać. To wychodzi dopiero z rozmowy strony biznesowej z zespołem, najlepiej kilka tygodni przed kampanią, a nie w jej trakcie.

Jeśli po takiej rozmowie zostanie czas na sprawdzenie czegoś w praktyce, poprosiłbym zespół na przykład o to, żeby:

• pokazał, jaki alert przyjdzie, gdy przestanie działać koszyk albo harmonogram zadań, i do kogo trafi;
• przeszedł ścieżkę zakupu na telefonie, tak jak robi to klient;
• wyjaśnił, od czego zależy start promocji o północy i jak sprawdzimy, że się udał;
• wskazał, czego obecny monitoring nie widzi wcale.

Część odpowiedzi będzie brzmiała „tego nie mierzymy”. To też dobra odpowiedź, jeśli wiadomo, kto w takim razie patrzy. Moim zdaniem w Black Friday bardziej niż awarii, która wyłącza sklep, warto się bać takiej, przy której strona działa, a sprzedaż po cichu spada. Tę pierwszą ktoś szybko zauważy.

Źródła

1. Magento 2, pub/health_check.php, Sales/etc/config.xml i OrderSender.php, gałąź 2.4-develop.
2. Adobe Commerce. Page caching.
3. Adobe Commerce. Configure and run cron jobs.
4. WordPress, wp-cron.php, gałąź trunk.
5. WordPress Advanced Administration Handbook. Brute force attacks.
6. Google Merchant Center Help. How to fix: Mismatched product price.