v1.7.0 — comenzi de test E2E excluse din analitice

1.7.0 — 2026-09-29

Comenzi de test E2E excluse din analitice (poarta #0): o comandă cu meta _sfb_e2e_test=1 sau cu emailul de facturare e2e+<orice>@safebiz.ro (SAFEBIZ_E2E_EMAIL_PATTERN) nu trimite purchase la GA4/Meta (skipped_test), nu trimite refund la anulare/ștergere și primește la creare _gtmkit_order_tracked=1 ca browserul să nu numere vânzarea. Rezolvă incidentul special-plus #32627 (refund fals de 271,50 RON, 28.09.2026).

Corecturi din auditul Codex + contra-verificarea Claude (29.09): bariera E2E și la trimiterea refundului (înaintea verificării „a fost numărată?”); refundul se sare doar când singura dovadă e marcajul pus de noi; SAFEBIZ_E2E_EMAIL_PATTERN definit gol = semn pe email oprit; regex invalid ⇒ implicit + avertisment admin; poarta E2E înaintea comutatorului SAFEBIZ_SEND_PURCHASE=false; gardă function_exists('wc_get_order') în joburile Action Scheduler.

Comenzile reale nu au niciun traseu schimbat. Fără configurare nouă necesară. Bancuri: purchase-gate 17/17 × 8 configurații, refund 33/33, lead 27/27; PHPCompatibility 7.4 curat; verificat pe viu pe safehost (Store API, HPOS). Detalii complete în CHANGELOG.md.

v1.6.0 — SureForms Lead tracking

Adaugă modulul SureForms Lead, oprit implicit, cu consimțământ marketing strict și deduplicare browser/server prin event_id per încercare. Include și corecțiile cumulative v1.4–v1.5.1 pentru purchase/refund. Verificat local: Lead 27/27, purchase gate 66/66, refund 26/26.

v1.3.3 — oglindim implicitul GTM Kit la item_id

Regula din 1.3.1 folosea isset() pe integrations.woocommerce_use_sku si, cand cheia lipsea din optiune, cadea pe implicitul istoric true (SKU). GTM Kit citeste aceeasi cheie cu if ( $this->options->get(...) ), deci pentru el cheie lipsa = fals = ID numeric. Rezultatul era exact dezacordul browser ↔ server pe care regula trebuia sa-l elimine.

Masurat pe boltom.ro: GTM Kit activ, cheia inexistenta, browserul trimitea item_id: "6338" (ID numeric) iar serverul SKU, pe un magazin cu 397 SKU-uri reale.

Acum oglindim GTM Kit inclusiv implicitul lui (! empty() in loc de isset()).

⚠️ Alinierea se aplica DOAR cand integrarea WooCommerce a GTM Kit e pornita — altfel nu exista dataLayer de comert cu care sa ne aliniem si se pastreaza comportamentul istoric.
⚠️ Site-urile fara GTM Kit: neschimbate. Cele cu setarea explicita: neschimbate. Constanta SAFEBIZ_GA4_ITEM_ID_USE_SKU bate orice.

v1.3.2 — proprietate GA4 secundara (implicit doar refund)

Un site poate avea o a doua proprietate GA4 alimentata DOAR din browser (tiparul „Premium sGTM"). Restituirile nu exista in browser — se intampla in administrare, ore sau zile mai tarziu — deci acea proprietate nu putea vedea niciodata o anulare.

Constante noi in wp-config.php:

• SAFEBIZ_GA4_MEASUREMENT_ID_2 / SAFEBIZ_GA4_API_SECRET_2
• SAFEBIZ_GA4_SECONDARY_EVENTS = refund (implicit) | all | off

⚠️ Implicit doar refund, deliberat. purchase ajunge deja pe proprietatea secundara din browser; daca l-ar trimite si serverul, riscam numarare dubla — GA4 nu garanteaza deduplicarea dupa transaction_id.

⚠️ Garda: daca masurarea secundara e identica cu cea principala, trimiterea se sare.

Calea secundara are stari proprii (..._2) si nu atinge starea celei principale. Site-urile fara constantele _2 se comporta exact ca in 1.3.1.

v1.3.1 — aliniere item_id + refund cu items, status si retry

[1.3.1] - 2026-08-23

Fixed

• GA4 primea aceeași tranzacție cu două coduri de produs diferite. Browserul (prin GTM Kit) putea trimite ID numeric iar serverul SKU pentru aceeași comandă; GA4 deduplică pe transaction_id și păstrează una dintre variante — nedefinit care ⇒ raportarea pe produs devenea impredictibilă. Descoperit pe monitorstup (2026-08-23), după ce woocommerce_use_sku a fost oprit în GTM Kit iar serverul a rămas pe SKU.
  Regula nouă (safebiz_ga4_item_id_use_sku()), în ordine: constanta SAFEBIZ_GA4_ITEM_ID_USE_SKU → setarea GTM Kit integrations.woocommerce_use_sku → true (comportamentul istoric).
  ⚠️ Site-urile fără GTM Kit și fără constantă păstrează exact comportamentul vechi — actualizarea nu rupe raportarea nimănui.

Added

• items în evenimentul refund. Până acum restituirea trimitea doar suma ⇒ GA4 nu putea arăta ce produs s-a anulat. Constructor unic safebiz_ga4_build_items(), folosit și la purchase și la refund. Se adaugă și tax, shipping și session_id, ca la purchase.
• Retry pentru restituire. Înainte, restituirea se trimitea sincron, o singură dată; o eroare de rețea o pierdea definitiv, fără urmă. Acum urmează exact modelul de la purchase: _safebiz_ga4_refund_status (queued | sent | error_enqueue | error_http | error_ambiguous | skipped_no_purchase), dispatch prin Action Scheduler și cron orar safebiz_ga4_refund_retry_errors.
  ⚠️ Se reia DOAR ce sigur n-a ajuns (error_enqueue, sau queued blocat > 2h). error_http și error_ambiguous rămân terminale — o a doua restituire ar scădea venitul de două ori.
  ⚠️ Interogarea cronului folosește stările wc-cancelled / wc-refunded, nu wc-processing / wc-completed ca la purchase.
• Guard terminal durabil păstrat pe _safebiz_ga4_refund_sent, compatibil cu comenzile deja restituite înainte de 1.3.1.

Notes

• Meta NU are eveniment standard de restituire și o vânzare deja trimisă NU se poate anula, șterge sau scădea (verificat pe referința oficială Meta Pixel, 2026-08-23: 17 evenimente standard, niciunul pentru refund/cancel/return; „Cancellation and Refund API" e pentru comenzile din magazinul Facebook/Instagram, nu pentru conversii de pe site). Consecință: randamentul raportat de Meta include mereu comenzile anulate — corecția se face din WooCommerce, nu din Meta. Decizie taki 2026-08-23: nu trimitem eveniment personalizat de anulare.
• Restituirea pleacă doar către SAFEBIZ_GA4_MEASUREMENT_ID (o singură proprietate). Pe monitorstup, proprietatea Premium nu are secret Measurement Protocol ⇒ nu primește nici purchase, nici refund de pe server. Rămâne deschis.

v1.3.0 — fix GA4 purchase over-count (exactly-once)

Fix — GA4 purchase over-count (~28x pe MPSS)

Cronul orar stergea singura stare de dedup si re-trimitea acelasi purchase la nesfarsit, backdatat la data comenzii. Fix "exactly once":

• Flag durabil de livrare (_safebiz_ga4_purchase_sent) setat DOAR pe 2xx — supravietuieste oricarei resetari de status.
• Separare stricta "livrat" vs "terminal": dupa orice POST starea e terminala -> zero re-POST -> zero duplicate.
• Retry-ul orar reia DOAR stari fara POST (error_enqueue + queued blocat). Status-wipe eliminat.
• Cutoff 72h (GA4 respinge backdating) -> error_stale.
• Migrare one-time onesta la upgrade: backfill flag doar pe dovada de livrare; error generic -> error_ambiguous terminal (NU marcat fals livrat).
• Meta CAPI simetric.

Integreaza cele 6 corectii din contra-verificarea Codex (2026-07-14). Fara schimbari la consent/session_id/refund. Guard WooCommerce intact (salon-nunta fara WC = fara fatal).

Post-upgrade: datele GA4 istorice inflatate nu pot fi sterse (MP nu are purge) — raporteaza venit din WooCommerce pentru fereastra afectata.

v1.2.0 — session_id join + Meta CAPI + consent + hardening

Versiune unificata care reconciliaza ramurile divergente intr-un singur release canonic.

Nou

• GA4 session_id join: captura _ga_session_id la checkout + atasare in purchase params -> tranzactiile pastreaza sursa reala (fix source=(not set) la newsletter/ads/seo).
• Meta Conversions API + gate pe consimtamant (GDPR) + async via Action Scheduler (din linia 1.1.0).

Hardening

• Gate WooCommerce pe scheduler + callback-urile de retry (function_exists('wc_get_orders')): pluginul poate fi activ si pe site-uri fara WC -> fara gate, cronurile orare ar da fatal.
• Action Scheduler: enqueue esuat -> status error (recuperat de cron), nu queued orfan permanent.
• Watchdog pentru order-ele blocate queued > 2h.
• Regex session_id ancorat /^s?(\d+)(?:\$|$)/ (respinge field-uri malformate).

Testat: php -l curat pe PHP 8.1 + 8.2; test functional complet pe staging (activare, session_id in params, regex clasic/packed, gate WC pozitiv+negativ).

Rollout controlat manual (auto-update OFF pe flota). NU pe salon-nunta.ro (fara WC + fara constante).

v1.0.2 — GitHub Auto-Update Mechanism

Features noi v1.0.2

Auto-update via GitHub Releases

Plugin verifică zilnic Releases pe GitHub. Update-uri viitoare apar în WP Admin → Plugins → Update Available automat.

• Custom updater class (~200 linii PHP), no external dependencies
• Hook-uri WordPress native:
  • pre_set_site_transient_update_plugins → injectează update info
  • plugins_api → modal "View details"
  • upgrader_source_selection → fix folder rename după unzip
• Cache 6h pentru a evita rate-limit GitHub (60/h unauth)
• Suport SAFEBIZ_GITHUB_TOKEN constant pentru repo private

Plugin metadata extins

• Plugin URI, Update URI, License, Author URI, Text Domain (standard WP.org)

---

Carryover din v1.0.1 (Codex review fixes)

• Default consent DENIED/DENIED (era GRANTED/DENIED) — EDPB-aligned
• Moove GDPR mapping strict: doar thirdparty=1 activează ad flags
• Endpoint regional EU region1.google-analytics.com

---

Install

WP Admin → Plugins → Add New → Upload Plugin → upload safebiz-server-side-tracking-1.0.2.zip → Activate.

Vezi README.md pentru config wp-config.php.

---

Backward compatible cu v1.0.0 și v1.0.1 — constants, order meta, hook signatures = neschimbate.