Cookie 30 zile vs 90 zile: 60% conversii întârziate pe care nu le vezi

Statisticile sugerează că 60% din conversiile întârziate sunt neobservate dacă folosești o fereastră de cookie de 30 de zile. Dar ce se întâmplă dacă extinzi această fereastră la 90 de zile?

Tensiunea — numește durerea

Pare că echipa ta a tratat atribuirea ca pe o problemă de marketing. Probabil e o problemă de arhitectură. Când folosești un cookie de doar 30 de zile, pierzi până la 60% din conversii care apar după această perioadă. Asta înseamnă că investiția ta în Meta Ads ar putea fi subevaluată, iar deciziile tale de marketing bazate pe date incomplete.

De ce acum / 2026

Meta API changes, AI Search și trecerea la un ecosistem fără cookie ne obligă să regândim fereastra de atribuire. Într-o lume în care algoritmii devin din ce în ce mai sofisticați, ignorarea acestor conversii întârziate poate duce la decizii financiare greșite și la stagnare în scalarea afacerii tale.

Mecanismul — cum funcționează cu adevărat

Cookie drop și pierderea datelor

• User → Browser → Pixel (drop la 30 de zile)
• Datele critice sunt pierdute odată ce fereastra de cookie expiră.

Atribuirea multi-model

• Channel classifier separat pentru a evalua canalele care contribuie la conversii întârziate.
• Realtime rollup permite urmărirea în timp real a atribuirii corecte.

Server-side tracking cu GA4

• GA4 Measurement Protocol server-side pentru o capturare mai precisă a datelor.

Cum rezolvă Commerce OS

Cookie de 30 zile e o decizie istorică dintr-o lume cu lookup imediat. În realitate, ciclul de conversie în B2B sau ecommerce cu ticket mediu peste 500 lei e 35-60 zile. Pierzi între 40 și 60% din conversii întârziate doar pentru că fereastra ta de atribuire e prea scurtă. Commerce OS împinge fereastra la 90 zile, controlată end-to-end.

• Cookie referral 90 zile first-touch — co_ref HttpOnly + SameSite=Lax setat în middleware la primul touch (ex: ?ref=PARTENER). Survey cookie deletion soft prin server-side bind la momentul submisiei.
• Server-side bind permanent — la /api/whitelist/apply, applicant-ul e legat de partner ID în DB. Cookie-ul poate dispărea; binding-ul nu. Asta îți dă 90 zile cookie + lifetime bind în DB.
• Event store cu first_seen_at — fiecare sesiune are timestamp first-touch și last-touch. Modelele de atribuire pot folosi orice fereastră (7, 30, 60, 90, 180 zile) post-hoc, nu ești blocat pe decizia inițială.
• Atribuire multi-model retroactivă — schimbi fereastra de la 30 la 90 zile, rerulezi calculul, vezi delta. Cu pixel-only, rerularea istorică e imposibilă.
• GA4 Measurement Protocol — server-side dispatch acoperă lookup-urile delayed care altfel ar cădea în "Direct" pe GA4.

Cei 60% conversii întârziate devin vizibili în raportul tău first-party în prima săptămână după switch; impactul real pe buget vine în 30-60 zile când rerulezi mix-ul de canale.

Întrebări pe care ți le pui

Q: De ce să extind fereastra de cookie la 90 de zile?

A: Extinderea ferestrei de cookie îți permite să captezi conversii care apar în urma interacțiunilor pe termen lung, maximizând valoarea investiției tale în campanii publicitare.

Q: Cum afectează asta raportarea ROAS?

A: Cu o fereastră extinsă, ROAS-ul raportat va reflecta mai bine succesul real al campaniilor tale, oferindu-ți o imagine completă a performanței.

Q: Este dificil de implementat această schimbare?

A: Cu Commerce OS, implementarea este simplificată datorită sincronizării automate și a proceselor de deduplicare eficientizate.

Într-o lume digitală în continuă schimbare, cum te asiguri că nu pierzi conversii valoroase? Explorează cum Commerce OS poate transforma abordarea ta asupra atribuției aici.