Je li praćenje na strani poslužitelja bolje od piksela u pregledniku?

Potpunije je za kupnje, ali najbolje radi zajedno s pikselom. Piksel dodaje kolačiće preglednika i kontekst stranice, poslužitelj dodaje narudžbe koje je preglednik propustio, a zajednički ID događaja zadržava jednu kopiju svake kupnje.

Radi li praćenje na strani poslužitelja s blokatorima oglasa?

Kupnje poslane iz podataka o narudžbi blokatori ne pogađaju, jer ih ne šalje preglednik kupca. ID klika i dalje se mora spremiti u pregledniku pri dolasku, a prikupljanje na prvoj strani to čini pouzdanijim.

Je li praćenje na strani poslužitelja u skladu s GDPR-om?

Praćenje na strani poslužitelja način je isporuke, a ne pravni temelj. Pravila o privoli vrijede za podatke bez obzira na put kojim idu, pa poštujte izbor posjetitelja i pitajte svojeg pravnog savjetnika koje podatke smijete slati.

Koja je razlika između praćenja na strani poslužitelja i označavanja na strani poslužitelja?

Označavanje na strani poslužitelja prosljeđuje događaje iz preglednika preko vašeg vlastitog poslužitelja, na primjer preko Google Tag Manager poslužiteljskog spremnika. Praćenje na strani poslužitelja iz podataka o narudžbi pokreće kupnju iz narudžbe u vašoj trgovini, pa kupnja ne ovisi o pregledniku.

Treba li mi programer za postavljanje praćenja na strani poslužitelja?

Ne, ako koristite uslugu koja se na vašu trgovinu i oglasne platforme povezuje putem aplikacija i prijava. Samostalno hostirani tag poslužitelj zahtijeva nekoga tko će ga postaviti, hostirati i održavati ažurnim.

Što je praćenje na strani poslužitelja? Vodič za web-trgovine

Ključne poruke

Praćenje na strani poslužitelja šalje događaje konverzije, poput kupnji, s poslužitelja na API oglasne platforme, umjesto samo iz piksela u pregledniku.
Kada se kupnja šalje iz podataka o narudžbi vaše trgovine, blokatori oglasa i stranica zahvale koja se nikad ne učita više ne uzrokuju izgubljene prodaje.
Preglednik je i dalje potreban da bi se pri dolasku spremio ID klika, a piksel može raditi uz poslužitelj s istim event_id, pa se svaka kupnja broji samo jednom.
Označavanje na strani poslužitelja, poput Google Tag Manager poslužiteljskog spremnika, i dalje polazi od događaja u pregledniku, pa ne može povratiti kupnje koje preglednik nikada nije poslao.
Praćenje na strani poslužitelja nije način zaobilaženja privole: pravila o privatnosti vrijede za podatke bez obzira na to kojim putem idu.

Praćenje na strani poslužitelja znači da se događaji konverzije, poput kupnje, oglasnim platformama šalju s poslužitelja, a ne samo iz skripte u pregledniku kupca. Za web-trgovinu poslužitelj svaku narudžbu šalje Meti, TikToku ili Googleu putem njihovih API-ja, pa se prodaja prijavljuje čak i kada je piksel u pregledniku blokiran ili se nikad ne učita.

Ovaj vodič objašnjava razliku između piksela u pregledniku i praćenja na strani poslužitelja, prati podatke od klika na oglas do oglasne platforme i pokazuje što sadrži događaj s poslužitelja. Obrađuje i deduplikaciju, označavanje na strani poslužitelja, privolu te kako procijeniti treba li vašoj trgovini praćenje na strani poslužitelja. Za samo postavljanje na Shopifyju pročitajte praćenje na strani poslužitelja na Shopifyju.

Piksel u pregledniku naspram praćenja na strani poslužitelja

Piksel u pregledniku je dio JavaScripta oglasne platforme. Izvodi se na vašim stranicama i šalje događaje s kupčeva uređaja izravno platformi: prikaz stranice, dodavanje u košaricu, kupnju na stranici zahvale. Radi samo ako se skripta učita, izvrši i dosegne platformu prije nego što kupac napusti stranicu.

Praćenje na strani poslužitelja prebacuje slanje na poslužitelj. Događaj može nastati iz podataka koje vaša trgovina već ima, poput plaćene narudžbe, a poslužitelj ga šalje na API platforme. Meta taj API naziva Conversions API, a TikTok Events API. Google Ads koristi enhanced conversions, koje konverziji dodaju hashirane podatke o kupcu.

Piksel u pregledniku

Radi u pregledniku kupca
Šalje događaje izravno oglasnoj platformi
Postavlja i čita kolačiće prve strane, poput _fbp za Metu
Ne šalje ništa kada je skripta blokirana ili se stranica ne učita

Praćenje na strani poslužitelja

Izvodi se na poslužitelju koji kontrolirate vi ili pružatelj usluge
Šalje događaje na API platforme
Može polaziti od zapisa narudžbe u vašoj trgovini
Ne ovisi o učitavanju stranice zahvale

Obje metode rade zajedno. Većina trgovina koristi obje i prepušta platformi uklanjanje duplikata.

Korištenje obje metode platformi daje najpotpunije podatke. Događaj iz preglednika dodaje kolačiće i kontekst stranice. Događaj s poslužitelja stiže čak i kada preglednik zakaže. Zajednički ID događaja osigurava da platforma svaku kupnju broji samo jednom.

Kako funkcionira praćenje na strani poslužitelja?

Praćenje na strani poslužitelja za web-trgovinu ima dvije polovice. Prva se odvija u pregledniku: kada kupac dođe s oglasa, skripta sprema ID klika iz URL-a. Druga se odvija na poslužitelju: kada je narudžba plaćena, poslužitelj povezuje taj ID klika s narudžbom i šalje kupnju.

Klik na oglasPlatforma dodaje ID klika u URL, na primjer fbclid, ttclid ili gclid.

Odredišna stranicaSkripta prve strane sprema ID klika i UTM parametre uz ID posjetitelja.

Narudžba plaćenaTrgovina bilježi narudžbu i javlja je poslužitelju, na primjer putem webhooka.

PoslužiteljPovezuje narudžbu s posjetiteljem, hashira podatke o kupcu i gradi događaj.

API oglasne platformePrima kupnju i povezuje je s klikom na oglas.

Kupnja polazi od zapisa narudžbe, a ne sa stranice zahvale. U pregledniku se mora spremiti samo ID klika.

Bilježenje klika

Oglasne platforme dodaju ID klika u URL odredišne stranice: fbclid za Metu, ttclid za TikTok, gclid za Google Ads i msclkid za Microsoft Ads. ID klika je najjača veza između prodaje i oglasa koji ju je uzrokovao, zato se mora spremiti pri prvom prikazu stranice. UTM parametri dodaju nazive kampanje, skupa oglasa i oglasa u formatu koji sami kontrolirate.

Povezivanje narudžbe

Poslužitelj zatim mora znati koji je posjetitelj napravio narudžbu. Najpouzdanija veza je vrijednost koja putuje s košaricom u narudžbu, poput ID-a posjetitelja spremljenog na košarici. Ostale metode slabije su: e-adresa koju je posjetitelj ranije upisao na stranici ili ista IP adresa i preglednik viđeni neposredno prije narudžbe. Svaka platforma web-trgovine nudi različite mogućnosti. Naš vodič za ostale web-trgovine navodi metode koje ROASaurus koristi po platformi.

Slanje događaja

Na kraju poslužitelj šalje kupnju na API svake platforme. Događaj uključuje vrijednost narudžbe, ID klika i podatke o kupcu koji platformi pomažu pronaći osobu koja je kliknula. Ako platforma ne radi ili vrati pogrešku, dobra postava pokušava ponovno kasnije, pa kupnja nije izgubljena.

Što sadrži događaj s poslužitelja?

Svaka platforma ima vlastite nazive polja, ali događaj kupnje svugdje nosi iste vrste podataka. Evo skraćenog primjera za Meta Conversions API:

Primjer: događaj Purchase za Meta Conversions API

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Polje	Što je to	Hashirano?
Naziv i vrijeme događaja	Purchase i vrijeme kada je narudžba napravljena	Ne
Vrijednost i valuta	Vrijednost narudžbe koju platforma koristi za ROAS i licitiranje prema vrijednosti	Ne
`event_id`	Jedinstveni ID po događaju, isti u pregledniku i na poslužitelju, za deduplikaciju	Ne
E-adresa, telefon, ime, adresa	Podaci o kupcu iz narudžbe, normalizirani i hashirani algoritmom SHA-256	Da
ID klika (fbc, ttclid, gclid)	ID s klika na oglas, spremljen kada je kupac stigao	Ne
IP adresa i user agent	Pomažu platformi povezati događaj s uređajem	Ne

Podaci o kupcu hashiraju se prije nego što napuste vaš poslužitelj. Meta zahtijeva da se IP adresa, user agent i ID-ovi klika šalju bez hashiranja.

Hashiranje pretvara e-adresu u niz znakova fiksne duljine. Ista adresa uvijek daje isti niz, ali niz ne otkriva adresu. Platforma koristi hashirane vrijednosti samo za traženje podudaranja među vlastitim korisnicima. Tako se kupnja može povezati s osobom koja je vidjela ili kliknula oglas, čak i kada je preglednik te osobe blokirao piksel.

Kako funkcionira deduplikacija?

Kada piksel i poslužitelj šalju istu kupnju, platforma je mora brojati jednom. Obje kopije nose isti naziv događaja i isti ID događaja, na primjer order-1042. Meta uspoređuje par i zadržava jednu kopiju, pod uvjetom da druga kopija stigne unutar 48 sati od prve.

Purchase event_id=order-1042 browserPrimljeno iz piksela

Purchase event_id=order-1042 serverIsti naziv i ID: broji se jednom

Purchase event_id=order-1043 serverPiksel je bio blokiran: kopija s poslužitelja jedina je

Purchase event_id=1044 serverPreglednik je poslao order-1044: ID-ovi se razlikuju, pa se broji dvaput

Deduplikacija radi samo kada obje kopije koriste potpuno isti ID događaja.

Većina dvostrukog brojanja dolazi od dva pošiljatelja koji ne dijele ID-ove. Tipičan slučaj je aplikacija same platforme za trgovinu i zaseban alat za praćenje koji oba šalju kupnje sa svojim ID-ovima. Naš članak pomoći o sprječavanju dvostrukog brojanja navodi uobičajene uzroke i rješenja.

Označavanje na strani poslužitelja naspram slanja iz podataka o narudžbi

Pojam praćenje na strani poslužitelja koristi se za dvije različite postave. Obje šalju događaje s poslužitelja, ali počinju na različitim mjestima.

Označavanje na strani poslužitelja, poput Google Tag Manager poslužiteljskih spremnika

Kod označavanja na strani poslužitelja preglednik svoje događaje šalje vašem poslužitelju umjesto svakom pružatelju zasebno. Google Tag Manager poslužiteljski spremnik poznat je primjer. Izvodi se u vašem Google Cloud projektu ili u drugom okruženju po vašem izboru. Prima zahtjeve iz preglednika, a njegove oznake prosljeđuju podatke Google Analyticsu, Meti i drugim pružateljima. Vi odlučujete koji podaci idu kamo, a poslužitelj može raditi na poddomeni vaše stranice.

Događaji i dalje počinju u pregledniku. Ako je oznaka u pregledniku blokirana ili se stranica zahvale nikad ne učita, poslužiteljski spremnik nema što proslijediti. Poslužitelj pritom sami pokrećete, plaćate i ažurirate.

Slanje iz podataka o narudžbi

Drugi pristup pokreće kupnju iz zapisa narudžbe u vašoj trgovini. Trgovina plaćenu narudžbu prijavljuje poslužitelju putem webhooka ili API-ja, a poslužitelj je šalje svakoj povezanoj platformi. Preglednik je potreban samo ranije, da spremi ID klika kada kupac stigne.

	Označavanje na strani poslužitelja	Slanje iz podataka o narudžbi
Odakle kupnja polazi	Oznaka u pregledniku	Plaćena narudžba u vašoj trgovini
Stranica zahvale zatvorena prerano	Kupnja je izgubljena	Kupnja je poslana
Oznaka blokirana u pregledniku	Kupnja je izgubljena, osim ako prođe endpoint prve strane	Kupnja je poslana
Plaćanje pouzećem i vanjske stranice za plaćanje	Ovisi o stranici zahvale	Šalje se kada je narudžba kreirana ili plaćena
Događaji pregledavanja (prikazi stranice, dodavanje u košaricu)	Da	Treba zaseban prikupljač u pregledniku
Tko pokreće poslužitelj	Vi: hosting i ažuriranja	Vi ili pružatelj usluge

Označavanje na strani poslužitelja poboljšava isporuku događaja iz preglednika. Slanje iz podataka o narudžbi čini kupnju neovisnom o pregledniku.

Ta se dva pristupa mogu kombinirati. Mnoge trgovine prikaze stranice i događaje dodavanja u košaricu prikupljaju u pregledniku, a kupnju šalju iz podataka o narudžbi. Kupnja je događaj koji oglasne platforme koriste za izvješćivanje o ROAS-u i optimizaciju licitiranja, pa je upravo ona ta koja najviše mora biti potpuna.

Što praćenje na strani poslužitelja rješava, a što ne rješava?

Rješava

Kupnje izgubljene jer je blokator oglasa zaustavio piksel
Kupnje izgubljene jer se stranica zahvale nije učitala
Kupnje načinima plaćanja koji završavaju izvan vaše stranice
Slabo povezivanje, dodavanjem hashiranih podataka o kupcu svakom događaju

Ne rješava

Privola: posjetitelj koji je odbio i dalje je posjetitelj koji je odbio
Različite atribucijske prozore i modele po platformi
Dvostruke pošiljatelje koji koriste različite ID-ove događaja
ID-ove klika koji nikad nisu spremljeni pri dolasku

Praćenje na strani poslužitelja podatke čini potpunijima. Ne mijenja pravila koja vrijede za te podatke.

Privola i dalje vrijedi

Praćenje na strani poslužitelja način je isporuke podataka, a ne način zaobilaženja pravila o privatnosti. Ondje gdje zakon zahtijeva privolu za marketinške kolačiće ili praćenje, taj se zahtjev odnosi na podatke koje prikupljate, bez obzira na to kojim putem dolaze do platforme. Premještanje alata za praćenje na vaš poslužitelj ne mijenja ono na što je posjetitelj pristao.

Atribucija ostaje specifična za platformu

Svaka platforma i dalje pripisuje kupnje prema vlastitim prozorima i pravilima. Događaji s poslužitelja svakoj platformi daju bolje podatke, ali ukupni iznosi Mete, TikToka i Googlea i dalje zajedno mogu premašiti prihod vaše trgovine. Da biste kanale usporedili prema jednom skupu pravila, koristite jedan model atribucije za sve njih, poput modela u ROASaurus atribuciji.

Treba li vašoj trgovini praćenje na strani poslužitelja?

Trgovina koja troši značajan budžet na plaćene oglase na društvenim mrežama ili u pretraživanju obično ima koristi. Opravdanost je najjača kada vrijedi nekoliko sljedećih točaka:

Oglasna platforma prima jasno manje događaja kupnje nego što vaša trgovina ima web-narudžbi. Naš vodič o blokatorima oglasa i praćenju pokazuje kako izmjeriti taj jaz.
Mnogi vaši posjetitelji koriste Safari na iPhoneu ili Macu, gdje kolačići koje postavljaju skripte traju najviše 7 dana. Pogledajte Safari ITP i praćenje oglasa.
Kupci često kupuju nekoliko dana nakon prvog klika na oglas.
Plaćanje završava izvan vaše stranice ili se narudžbe plaćaju kasnije, kao kod plaćanja pouzećem ili bankovnim prijenosom.
Kampanje optimizirate za kupnje ili vrijednost kupnje, pa platformi treba svaka prodaja da bi iz nje učila.

Evo kako jaz u praksi mijenja odluke. Primjer trgovine ima 1,000 web-narudžbi u mjesecu. Njezin Meta piksel prijavio je 820 događaja Purchase, pa 18% narudžbi nikad nije stiglo do Mete iz preglednika.

Primjer trgovine: kupnje koje su stigle do Mete u jednom mjesecu

Web-narudžbe u trgovini

1,000

Samo piksel

820

Piksel + poslužitelj, deduplicirano

1,000

U ovom primjeru sam piksel propušta 180 od 1,000 narudžbi. Slanje kupnji iz podataka o narudžbi zatvara taj jaz.

ROAS točke pokrića te trgovine je 2.5, a Ads Manager na temelju podataka piksela prikazuje ROAS od 2.3. Prema tim brojkama kampanje gube novac. Ako su narudžbe potaknute oglasima propuštene istom stopom od 18%, stvarni ROAS je oko 2.3 ÷ 0.82 = 2.8, što je iznad točke pokrića. To je gornja procjena, jer nije svaka propuštena narudžba došla od oglasa. Ipak pokazuje kako jaz u praćenju može učiniti da profitabilna kampanja izgleda kao gubitak.

Praćenje na strani poslužitelja manje je važno za trgovinu koja se ne oglašava ili troši vrlo malo na oglase.

Kako ROASaurus šalje događaje sa strane poslužitelja

ROASaurus pri dolasku bilježi 19 ID-ova klikova i šest UTM polja i sprema ih uz ID posjetitelja prve strane. Svaku kupnju iz plaćenih narudžbi vaše trgovine šalje platformama Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll i Outbrain. Na Shopifyju se konverzije za Google Ads šalju iz Shopify naplate. Pikseli u pregledniku mogu raditi uz događaje s poslužitelja s istim ID-om događaja, a Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin i Spotify ih dedupliciraju. Svaka isporuka i odgovor platforme navedeni su u odjeljku Event log.

Više pročitajte na stranici praćenje na strani poslužitelja ili pronađite svoju web-trgovinu na stranici integracije.

Izvori

U ROASaurusu

Nastavite čitati

PraćenjeBlokatori oglasa i praćenje: što vaša trgovina gubiBlokatori oglasa zaustavljaju piksele za praćenje, pa oglasne platforme propuštaju kupnje. Pogledajte koji se događaji gube, zašto se oni sa strane poslužitelja ne gube i kako izmjeriti koliko vam nedostaje.PraćenjeConsent Mode v2 i GDPR: što web-trgovina smije slatiConsent Mode v2 za web-trgovine: četiri Googleova signala privole, što traži pravo EU-a i što praćenje na strani poslužitelja i dalje smije slati. Samo opće informacije.PraćenjeDvostruki događaji kupnje: zašto se prodaje broje dvaputDvostruki događaji kupnje napuhuju konverzije i ROAS. Pogledajte uzroke, kako Meta, TikTok, Snapchat, Pinterest i Reddit provode deduplikaciju i kako to ispraviti.