hello@rawideas.ro
ȘTII CE VREI? SARI PESTE LABIRINT →
← BLOG
Tracking 10 iun. 2026 · 8 min de citit

Ghidul de tracking server-side: recuperează conversiile pe care GA4 le ascunde

Un ghid practic, fără vrăjeală, despre tracking-ul server-side: ce e, de ce browserul îți pierde datele și cum recuperezi cele 30–60% din conversii pe care GA4 le ascunde.

Tracking
30–60% din conversii, recuperate din întuneric

Aproape toată lumea măsoară la fel ca în 2015: un tag se încarcă în browserul vizitatorului, citește click-ul și trimite evenimentul direct la Google sau Meta. Atunci funcționa impecabil. Acum se destramă, iar majoritatea celor care încă îl folosesc nu văd cât au pierdut deja.

Numărul pe care-l întâlnesc constant la audituri: între 30 și 60% din conversii nu ajung niciodată din browser înapoi la platforma care ar trebui să le numere. Pe un magazin cu mult trafic de Safari și mult consimțământ din UE, mai mult de jumătate din ce ai vândut de fapt e invizibil pentru algoritmul pe care-l plătești să-ți aducă clienți. Licitezi orb și nici nu știi.

Tracking-ul server-side e felul în care recuperezi asta. Ăsta e ghidul lung — ce e, de ce pierde browserul, cum funcționează setup-ul, la ce să te aștepți și unde nu te ajută. Fără vrăjeală nicăieri.

Ce e de fapt tracking-ul server-side

Într-un setup normal, totul se întâmplă în browser. Tagul de Google, pixelul de Meta, GA4 — toate se încarcă drept JavaScript third-party, citesc pagina și trimit date către o duzină de servere cu care vizitatorul tău n-a cerut niciodată să vorbească.

Tracking-ul server-side mută pasul din mijloc pe un server pe care-l controlezi tu. Browserul trimite un singur eveniment către endpoint-ul tău — de obicei un subdomeniu de tipul sgtm.domeniultau.ro. Acel server decide apoi ce trimite mai departe, către cine și cu ce date. Instrumentul Google pentru asta e Google Tag Manager server-side: un container care rulează în cloud, nu în browser.

Schimbarea asta de arhitectură repară surprinzător de multe probleme, pentru că majoritatea pierderilor de tracking se întâmplă fix în golul dintre browser și acele servere third-party. Închizi golul, datele nu mai curg pe lângă.

De ce browserul a încetat să fie un loc sigur pentru măsurat

Browserul n-a fost niciodată gândit să fie depozitul tău de analytics. Patru forțe ți-l iau treptat înapoi:

  • Ad blockere. Undeva între 20 și 40% dintre utilizatori folosesc unul, și blochează tagul de Google și pixelul de Meta după nume. O cerere first-party către propriul tău subdomeniu nu apare pe listele alea de blocare.
  • Safari și ITP. Intelligent Tracking Prevention de la Apple limitează cookie-urile client-side la 7 zile, deseori la 24 de ore. Pe audiențe cu mult iPhone, ferestrele tale de retargeting se prăbușesc tăcut.
  • Ziduri de consimțământ. De la Consent Mode v2, un vizitator care refuză cookie-urile de analytics pornește un tag fără cookie, fără identificator. Gestionat prost, fiecare dintre ei devine o sesiune pierdută sau neatribuită.
  • Moartea cookie-urilor și duratele scurte. Cookie-urile third-party sunt practic moarte, iar cele first-party devin tot mai scurte. Întregul model pe care s-a construit pixelul se demontează.

Niciuna dintre astea nu e un bug pe care să-l repari cu un petic. E direcția în care se mișcă tot web-ul, intenționat, și nu se întoarce. Să măsori din interiorul browserului înseamnă să înoți împotriva curentului.

Cum funcționează un setup de GTM server-side

Mecanica e mai simplă decât sună:

  1. Ridici un container server. O instanță GTM găzduită în cloud, pe Google Cloud sau ceva similar.
  2. Îndrepți un subdomeniu spre el. sgtm.domeniultau.ro, pe propriul tău DNS. Acum cererea de tracking e first-party — același domeniu ca site-ul tău — deci supraviețuiește ad blockerelor și primește durata de cookie mai lungă pe care o permite contextul first-party.
  3. Browserul trimite un singur eveniment curat către acel subdomeniu. Nu douăsprezece cereri către doisprezece furnizori. Unul.
  4. Serverul îl distribuie. Îl trimite mai departe către GA4, Google Ads, Meta, orice folosești, server-to-server, cu datele îmbogățite și curățate înainte să plece.

Partea cu subdomeniul contează mai mult decât crede lumea. Pentru că cererea e first-party, Safari tratează cookie-ul ca fiind al tău, nu al unui tracker, iar ad blockerele care caută google-analytics.com nu-l văd niciodată. Ai mutat măsurarea acolo unde apărarea browserului nu e îndreptată.

Conversions API și enhanced conversions

GTM server-side e instalația. Câștigul e ce poți acum să alimentezi direct la platforme, server la server:

  • Conversions API (CAPI) de la Meta trimite conversiile de pe serverul tău, în loc să se bazeze pe pixel. Când un eveniment din browser e blocat, cel de pe server tot ajunge.
  • Enhanced conversions de la Google atașează date first-party hash-uite și consimțite — de obicei un email — ca Google să poată potrivi o conversie chiar și când cookie-ul a dispărut.

Trucul care le face pe amândouă sigure e deduplicarea. Trimiți aceeași conversie din browser și de pe server, cu un ID de eveniment comun, iar platforma o păstrează o singură dată. Deci nu numeri dublu. Umpli golurile lăsate de browser, și doar golurile.

Asta e partea care se plătește singură. Când Google și Meta licitează pe date de conversie complete, nu pe cele două treimi găurite pe care le dădea browserul, același buget devine mai deștept peste noapte. Semnal mai bun intră, licitare mai bună iese. Nimic altceva din campanie nu se schimbă.

De asta stă sub rezultatele tale de PPC, nu lângă ele. Algoritmii de licitare sunt buni exact cât conversiile pe care le hrănești.

Consimțământul — partea sinceră

Tracking-ul server-side nu e o metodă de a ocoli consimțământul, și oricine ți-l vinde așa o să-ți aducă o amendă. Dacă un user refuză, îl respecți. Ce face un setup corect e să oprească pierderea inutilă a userilor care au consimțit, și să folosească modeling-ul din Consent Mode ca să recupereze forma restului fără să stocheze ce n-ar trebui. Făcut bine, e mai respectuos cu confidențialitatea decât împroșcarea de pixeli pe care o înlocuiește, pentru că tu decizi ce pleacă de pe serverul tău.

La ce să te aștepți cu adevărat

Numere reale, nu numere de broșură:

  • În jur de 95% acuratețe de tracking, în sus de la 40–70% cât livrează de obicei un setup client-side găurit.
  • Cu 30 până la 60% mai multe conversii vizibile pentru Google și Meta. Nu vânzări noi — vânzări pe care le-ai făcut deja și nu le vedeai.
  • Ferestre de atribuire mai lungi pe Safari și iOS, ca retargeting-ul să nu mai uite oamenii după o zi.
  • Un număr de comenzi în GA4 care în sfârșit se potrivește cu ce spun banca ta și adminul de Shopify.

Ce nu face: nu inventează cerere, nu-ți repară o ofertă proastă și nu salvează campanii care nu merg din motive fără legătură cu tracking-ul. Face măsurarea sinceră. Dacă problema e businessul de dedesubt, măsurarea sinceră doar ți-o arată mai repede.

De unde începi

Dacă raportarea ta și extrasul de cont se contrazic cu mai mult decât o eroare de rotunjire, lași bani pe masă în fiecare zi în care gaura rămâne deschisă. Și sunt cei mai ieftini bani pe care-i vei recupera vreodată, pentru că deja ai plătit ca să atragi clienții ăia.

Serviciul nostru Fix My Tracking e un preț fix de 1.500 €, gata în 7 zile, cu garanție scrisă: dacă nu atingem acuratețea promisă, nu plătești. E același setup server-side pe care-l rulăm pentru branduri ca Rolls-Royce, Engie și A&D Pharma. Instalația nu ține cont de cât de mare ești.

Vezi exact ce include pe pagina de tracking server-side, verifică prețurile, sau citește de ce fondatorul e dispus să pună garanția aia în scris în primul rând.

Recunoști problema?

Site-ul ăsta e o calificare, nu un pitch. Două minute și afli sincer dacă ne potrivim.