Black Friday pe Magento: 9 verificări înainte de 6 noiembrie

eMAG a anunțat Black Friday 2026 pentru vineri, 6 noiembrie. Anul trecut, pe 7 noiembrie 2025, aceeași zi i-a adus comenzi de peste 986 de milioane de lei de la peste 702.000 de clienți, potrivit StartupCafe. Dacă și campania ta pornește pe 6 noiembrie, pregătirea a început deja, chiar dacă încă n-ai atins nimic: fereastra de 30 de zile din care se calculează prețul tăiat s-a deschis pe 7 octombrie.

Mai jos sunt 9 verificări pentru un magazin Magento, în ordinea în care le-am face noi: prețurile, motorul care le calculează, checkout-ul și ziua campaniei. Toate exemplele presupun o campanie care începe pe 6 noiembrie. Dacă a ta începe în altă zi, mută datele cu același număr de zile.

1. Prețul tăiat: cel mai mic din ultimele 30 de zile

În România, regula vine din HG 947/2000, articolul 4¹, introdus prin HG 686/2022: orice anunț de reducere arată prețul anterior, iar prețul anterior e cel mai mic preț practicat în cele 30 de zile dinaintea reducerii. Pentru o reducere care pornește pe 6 noiembrie, fereastra merge de la 7 octombrie la 5 noiembrie.

În exemplul din grafic, un produs de 499 lei a avut o promoție la 429 lei între 14 și 16 octombrie. Pe 6 noiembrie îl vinzi cu 399 lei. Prețul tăiat corect e 429 lei, iar reducerea afișată e de 7%, nu de 20%. Patru situații merită verificate produs cu produs:

• Scumpirile din octombrie nu ajută. Referința e cel mai mic preț din fereastră, nu ultimul, deci un preț mai mare înainte de campanie nu mărește reducerea pe care o poți afișa.
• Reducerile care cresc în aceeași campanie păstrează prețul dinaintea primei reduceri. Dacă pornești pe 2 noiembrie cu 10% și ajungi la 20% pe 6 noiembrie, referința rămâne prețul dinainte de 2 noiembrie.
• O a doua campanie are propria fereastră. Dacă reduci din nou pe 27 noiembrie, ziua de Black Friday din SUA, fereastra merge de la 28 octombrie la 26 noiembrie. Ea include cei 399 de lei din 6 noiembrie, care devin noul preț tăiat.
• Produsele noi, aflate la vânzare de mai puțin de 30 de zile, au ca referință cel mai mic preț de la lansare, iar perioada se afișează.

Lipsa prețului anterior se amendează cu 5.000 până la 30.000 de lei, iar la un control ANPC magazinul își dovedește prețul cu propriile documente. Magento Open Source nu păstrează istoricul prețurilor. Dacă nu ai un modul care îl ține, exportă de azi, zilnic, produsele din campanie din System > Data Transfer > Export și păstrează fișierele cu data lor. Regula pe larg, plus modulul Omnibus pe care îl folosim, sunt în articolul despre GPSR și Omnibus. Acest articol nu e consultanță juridică.

2. Regulile de preț: calculate doar pentru ieri, azi și mâine

Dacă reducerea vine dintr-o regulă de preț de catalog (Marketing > Catalog Price Rule), Magento nu îi calculează prețul pentru toată perioada campaniei. În codul modulului Magento_CatalogRule, fiecare reindexare scrie prețuri pentru 3 zile: ieri, azi și mâine. O regulă care începe pe 6 noiembrie primește prețuri abia când indexul rulează pe 5 noiembrie sau mai târziu.

Reîmprospătarea zilnică e jobul de cron catalogrule_apply_all, programat la 01:00 în fusul orar al magazinului. El doar marchează indexul ca invalid, iar refacerea o face alt job, care rulează în fiecare minut. Dacă cron-ul stă în noaptea de 5 noiembrie, Black Friday începe la preț întreg, deși regula arată corect în admin.

A doua capcană: dacă schimbi prețul de bază al unui produs, prețul regulii nu se recalculează singur, iar procentul se aplică în continuare la prețul vechi. După orice import de prețuri, rulează bin/magento indexer:reindex catalogrule_rule catalog_product_price.

Pe 5 noiembrie, după 01:00, numără rândurile pentru ziua campaniei: SELECT COUNT(*) FROM catalogrule_product_price WHERE rule_date = '2026-11-06'; Zero rânduri înseamnă că Black Friday nu are încă prețuri.

3. Cron-ul: citește baza de date, nu logul

Verificarea de mai sus depinde de cron, la fel ca indexurile pe programare, cozile de mesaje și multe integrări. Un fișier de log gol nu spune nimic, pentru că sursa de adevăr e tabela cron_schedule: SELECT status, COUNT(*), MAX(finished_at) FROM cron_schedule GROUP BY status;

• Sănătos: rânduri success cu un finished_at din ultimele 5 minute.
• Blocat: un job în running de ore întregi, cu finished_at gol. E un proces mort care ține locul altor joburi.
• Oprit: multe rânduri pending și niciun success nou. Cron-ul nu mai pornește deloc.

4. Sortarea după preț în categoriile mari

Deschide 3 categorii mari și sortează după preț, descrescător. Dacă una iese goală sau cu mai puține produse decât are, indexul de prețuri are rânduri lipsă. Se întâmplă, de exemplu, pe magazinele care au scos MSI, ascund produsele fără stoc și țin indexul de prețuri pe Update by Schedule: un produs care revine în stoc nu își primește înapoi rândul din index. Înaintea unei campanii cu multe reaprovizionări, o reindexare completă a catalog_product_price, noaptea, umple golurile.

5. Înghețarea deploy-urilor și cache-ul

Alege o zi după care nu mai livrezi nimic nou, de exemplu 3 noiembrie, și de atunci repari doar ce e stricat. Motivul ține de cache. Magento golește Varnish pe etichete: când salvezi un produs, o categorie sau un bloc CMS, cere golirea doar pentru paginile care îl conțin. O schimbare de temă, de CSS sau de layout nu atinge nicio etichetă, deci nu golește nimic.

Pe magazinul nostru demo, după un deploy reușit, Varnish servea încă o pagină randată cu 8 zile înainte, deși bin/magento cache:flush rulase. Golirea nu ajungea la Varnish, și doar repornirea lui a scos pagina veche. După ultimul deploy dinaintea înghețării, caută în sursa paginii publice schimbarea pe care tocmai ai livrat-o și verifică în app/etc/env.php că http_cache_hosts indică serverul Varnish.

Tot aici intră încălzirea cache-ului. După o golire completă, fiecare pagină se randează de la zero, iar un cache warmer care parcurge tot magazinul în paralel concurează cu clienții pentru același server. Programează parcurgerea completă noaptea, cu puține cereri simultane, și nu goli tot cache-ul în ziua campaniei.

6. Checkout-ul, testat la ora de vârf

Testează checkout-ul la ora cu cele mai multe comenzi din ultima lună, pe care o vezi în Analytics, nu dimineața, când serverul e liber. La ora de vârf, același server servește clienți, crawlere și încălzirea cache-ului. Ce urmărești:

• Tarifele de livrare. Fiecare schimbare din checkout le recalculează. În profilările noastre pe Hyvä Checkout, o singură schimbare a metodei de livrare a cerut tarifele de 3 ori, între salvare și cererile care o urmează. Dacă modulul de curier cere prețul de la API-ul curierului la fiecare calcul, un API lent la ora de vârf se adună de 3 ori, așa că apelul are nevoie de o limită de timp și de un cache scurt. Despre curieri în checkout am scris în articolul despre Hyvä Checkout.
• Blocarea sesiunii. Cu sesiunile în Redis și blocarea pornită, cum e implicit, două cereri ale aceluiași client nu rulează în paralel: a doua așteaptă în pași de 0,5 secunde, iar pe un server încărcat pașii se adună.
• Rambursul. Pe slide-ul Heureka Group de la The Base Event, 51% din comenzile din România se plăteau cash. Verifică că plata la livrare apare la toate metodele de livrare și că Maximum Order Total din setările ei permite coșurile mari de Black Friday.

7. Patch-urile de securitate, înainte de înghețare

Un patch aplicat după 3 noiembrie e un deploy în zilele în care nu mai vrei deploy-uri. Verifică versiunea cu bin/magento --version, compar-o cu buletinele de securitate Adobe și aplică ce lipsește înainte de înghețare, testat întâi pe staging. Excepția e un patch de urgență pentru o vulnerabilitate deja exploatată: acela se aplică imediat, chiar și în ziua campaniei. Lista completă e în checklist-ul de securitate Magento.

8. Testele de viteză pe care te poți baza în noiembrie

Datele clienților reali din PageSpeed Insights acoperă 28 de zile. O reparație făcută pe 1 noiembrie are cel mult 5 zile în fereastra de pe 6 noiembrie, deci nu o vei vedea acolo înainte de campanie. În ultimele săptămâni bazează-te pe două teste repetate în aceeași zi: scorul PageSpeed rulat de 5 ori, din care păstrezi mediana, și testul drumului de cumpărături în 6 pași. De ce scorul și datele reale spun lucruri diferite am explicat în articolul despre scorul PageSpeed.

9. Ziua campaniei: cine se uită și la ce

Pe 6 noiembrie nu e suficient să afli că ceva s-a stricat, trebuie să afli primul. Hyvä Pocket, aplicația gratuită a Hyvä pentru iPhone, iPad, Mac și Apple Watch, trimite o notificare la fiecare comandă nouă, deci observi imediat când comenzile se opresc. Stabilește dinainte cine e de serviciu, cine poate face rollback și ce faci dacă plata cu cardul cade: rambursul rămâne pornit.

Calendarul, pe scurt

• De azi: export zilnic al prețurilor din campanie, verificarea cron_schedule și testul checkout-ului la ora de vârf.
• Până pe 3 noiembrie, de exemplu: patch-urile de securitate și ultimul deploy, apoi înghețarea.
• 5 noiembrie, după 01:00: rândurile pentru 6 noiembrie în catalogrule_product_price și sortarea după preț în 3 categorii mari.
• 6 noiembrie: notificările de comenzi pornite, fără golirea completă a cache-ului și fără deploy-uri.
• 27 noiembrie, dacă mai faci o campanie: prețul tăiat pornește de la cel mai mic preț dintre 28 octombrie și 26 noiembrie.

Vrei să treci prin cele 9 verificări pe magazinul tău înainte de 6 noiembrie? Programează un apel de strategie gratuit. Ne uităm împreună la prețuri, cron și checkout și îți spunem ce merită reparat primul.