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

În momentul în care magazinul tău trimite aceeași vânzare pe două drumuri — unul din browser, unul din server — creezi un risc nou: numărarea acelei vânzări de două ori. Livrarea pe două căi este deliberată și bună, dar dacă nu gestionezi deduplicarea la fel de 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 repetabil. Acest articol explică de ce apar dublurile în primul rând, de ce eșuează soluțiile naive și cum un event_id comun construit din comanda însăși 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 este livrarea pe două căi. 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.

Un event_id construit din comanda însăși

Soluția robustă este un event_id construit din ceva care este deja stabil și unic per vânzare: comanda însăși. Pentru că identitatea 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. O reîmprospătare produce același ID ca prima încărcare — așa că o reîncărcare nu poate număra niciodată dublu.

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 construit din comandă, iar conversiile Google Ads se contopesc și ele curat.

Aceasta este decizia de design centrală din spatele unui tracking curat pe două căi: 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 pe două căi de la cap la coadă

Într-un pipeline pe două căi construit corect, deduplicarea nu este un singur comutator, ci un principiu consecvent aplicat peste tot. Evenimentul de browser și evenimentul de server pentru o anumită vânzare împart un singur event_id, construit din comanda însăși. Platformele — Meta pentru CAPI, GA4 pentru analiză, Google Ads pentru conversii — folosesc fiecare acea identitate comună pentru a contopi duplicatul într-unul singur.

PrestaSignal implementează exact asta ca un singur design integrat. Evenimentele de browser de zi cu zi se înregistrează printr-un mic conector pe adresa propriului tău site, în timp ce vânzarea însăși este raportată de back office-ul tău pe un al doilea drum fără browser — înregistrată exact o singură dată, cu retururile purtând transaction_id-ul corespunzător, așa că venitul se stornează corect. Achiziția pe care o declanșează pixelul tău din browser și achiziția pe care o trimite serverul nostru împart un singur ID construit din comandă, așa că Meta CAPI păstrează exact una, GA4 contopește pe transaction_id-ul corespunzător, iar Google Ads numără o singură conversie.

Recompensa este că obții fiabilitatea livrării server-side și bogăția comportamentală a tracking-ului de browser, 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.

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 aleatoriu. Portalul de comerciant al PrestaSignal îți arată un flux live al evenimentelor pe măsură ce sosesc, ca să vezi ce raportează efectiv magazinul tău în loc să aștepți totalurile lunare. Ca să-ți verifici configurarea față de comenzile tale reale, programează o analiză și vom identifica exact de unde vin dublurile.