Deduplicarea evenimentelor: cum oprești numărarea dublă a achizițiilor

În momentul în care adaugi tracking server-side peste tag-urile tale client-side existente, creezi un risc nou: numărarea aceleiași achiziții de două ori. Este efectul secundar natural al trimiterii unei vânzări pe două căi, iar dacă nu îl gestionezi deliberat, cifrele tale de venit se umflă și algoritmii tăi de licitare învață lecția greșită.

Vestea bună este că deduplicarea este o problemă rezolvată cu un răspuns curat și determinist. Acest articol explică de ce apar dublurile în primul rând, de ce eșuează soluțiile naive și cum un event_id comun derivat din referința comenzii face ca o vânzare să fie numărată exact o dată — pe GA4, Meta și Google Ads deopotrivă.

De ce apar dublurile

Există două surse frecvente de conversii duplicate, iar majoritatea magazinelor le ating în cele din urmă pe amândouă.

Prima sunt configurările hibride. Pentru a recupera conversiile pe care le ascund ad blocker-ele și ITP, abordarea recomandată trimite fiecare purchase atât din browser (pixelul sau tag-ul client-side), cât și din server (Conversions API sau tag-ul server-side). Acea redundanță este intenționată și bună — dar fără deduplicare, platforma de analiză primește două evenimente și creditează două vânzări.

A doua sunt reîncărcările de pagină și reîncercările. O pagină de confirmare pe care cumpărătorul o reîmprospătează, la care navighează înapoi sau care reîncearcă un beacon eșuat poate declanșa din nou evenimentul purchase. Dacă fiecare declanșare folosește un identificator aleatoriu nou, fiecare reîncărcare arată ca o comandă complet nouă. Pune cele două cauze laolaltă și o singură vânzare poate fi numărată de trei sau patru ori.

De ce ID-urile aleatorii înrăutățesc situația

Instinctul este să dai fiecărui eveniment un ID unic ca să le poți deosebi. Pentru deduplicare, asta este exact pe dos. Un event_id aleatoriu garantează că evenimentul de browser și evenimentul de server pentru aceeași vânzare poartă ID-uri diferite — așa că platforma vede două conversii distincte și le numără pe amândouă.

Același defect strică gestionarea reîncărcărilor. Dacă pagina de confirmare generează un ID aleatoriu nou de fiecare dată când se încarcă, o reîmprospătare produce o a doua achiziție „unică” pe care nimic nu o recunoaște ca duplicat.

Deduplicarea are nevoie de proprietatea opusă: aceeași vânzare logică trebuie să producă mereu același ID, indiferent de câte ori sau din câte locuri se declanșează evenimentul. Unicitatea per declanșare este dușmanul; consecvența per vânzare este scopul.

event_id-ul determinist

Soluția robustă este un event_id determinist derivat din ceva care este deja stabil și unic per vânzare: referința comenzii PrestaShop. Pentru că referința comenzii nu se schimbă, fiecare cale și fiecare reîncărcare pot calcula independent același event_id — fără să se coordoneze între ele.

Când pixelul și Conversions API trimit amândouă o achiziție cu același event_id, Meta le recunoaște ca o singură vânzare și o numără o dată. GA4 deduplică în același mod folosind un transaction_id determinist din referința comenzii, iar conversiile Google Ads se contopesc și ele curat.

Aceasta este decizia de design centrală din spatele unei configurări hibride curate: identitatea vine din comandă, nu dintr-un număr aleatoriu generat la momentul declanșării. Reîncărcările, click-urile pe butonul înapoi și livrarea pe două căi se rezolvă toate într-o singură conversie canonică.

Cum deduplică configurările hibride de la cap la coadă

Într-un pipeline hibrid construit corect, deduplicarea nu este un singur comutator, ci un principiu consecvent aplicat peste tot. Tag-ul client-side și tag-ul server-side pentru o anumită vânzare împart un singur event_id determinist. Platformele — Meta pentru CAPI, GA4 pentru analiză, Google Ads pentru conversii — folosesc fiecare acea identitate comună pentru a contopi duplicatul într-unul singur.

Recompensa este că obții fiabilitatea livrării server-side și bogăția comportamentală a tracking-ului client-side, fără inflația care ar veni altfel din trimiterea totului de două ori. Redundanța te protejează împotriva pierderii; deduplicarea te protejează împotriva numărării duble.

PrestaSignal implementează exact asta: un singur event_id determinist per comandă, reutilizat de Meta CAPI, Tracking GA4 și Tracking Google Ads, astfel încât o singură vânzare să fie numărată o dată peste tot.

Cum să-ți dai seama dacă ai o problemă

Suspectează numărarea dublă atunci când GA4 sau Meta raportează mai multe conversii sau mai mult venit decât back office-ul tău PrestaShop, mai ales după adăugarea unei configurări server-side sau pixel-plus-CAPI. O cifră de venit care se situează constant peste încasările tale reale este indiciul cel mai clar.

Un alt simptom este un comportament de licitare neregulat: dacă Smart Bidding-ul sau optimizarea Meta cheltuie brusc prea mult, poate că a învățat că anumite click-uri valorează de două ori cât valorează cu adevărat, pentru că dublurile au învățat-o cu valori umflate. Conversiile duplicate distorsionează optimizarea la fel de rău ca cele lipsă.

Dacă ceva din toate astea îți sună familiar, diagnosticul este de obicei un event_id lipsă sau nedeterminist. Ca să-ți verifici configurarea față de comenzile tale reale, programează o analiză și vom identifica exact de unde vin dublurile.