- A szerveroldali követés a konverziós eseményeket, például a vásárlásokat, egy szerverről küldi a hirdetési platform API-jának, nem csak a böngészőben futó pixelről.
- Ha a vásárlást a webáruházad rendelési adataiból küldöd el, a reklámblokkolók és a soha be nem töltődő köszönőoldal már nem okoznak elveszett eladásokat.
- A böngészőre továbbra is szükség van, hogy a landing oldalon elmentse a kattintásazonosítót, a pixel pedig ugyanazzal az event_id-val futhat a szerver mellett, így minden vásárlás egyszer számít.
- A szerveroldali címkézés, például egy Google Tag Manager szerverkonténer, még mindig böngészős eseményekből indul ki, ezért nem tudja visszaszerezni azokat a vásárlásokat, amelyeket a böngésző sosem küldött el.
- A szerveroldali követés nem kerülő út a hozzájárulás elől: az adatvédelmi szabályok az adatra vonatkoznak, bármilyen úton halad is.
A szerveroldali követés azt jelenti, hogy a konverziós eseményeket, például a vásárlást, egy szerver küldi el a hirdetési platformoknak, nem csak a vásárló böngészőjében futó script. Egy webáruháznál a szerver minden rendelést elküld a Metának, a TikToknak vagy a Google-nek az API-jaikon keresztül, így az eladásról akkor is értesül a platform, ha a böngészőpixelt blokkolják, vagy az be sem töltődik.
Ez az útmutató elmagyarázza a böngészőpixel és a szerveroldali követés közötti különbséget, végigköveti az adatot a hirdetési kattintástól a hirdetési platformig, és megmutatja, mit tartalmaz egy szerveroldali esemény. Szó esik a deduplikációról, a szerveroldali címkézésről, a hozzájárulásról, és arról is, hogyan derítheted ki, szükséged van-e rá a webáruházadban. Magához a Shopify-beállításhoz olvasd el a szerveroldali követés Shopifyon című cikket.
Böngészőpixel és szerveroldali követés
A böngészőpixel a hirdetési platform egy JavaScript-darabja. Az oldalaidon fut, és az eseményeket a vásárló eszközéről közvetlenül a platformnak küldi: oldalmegtekintést, kosárba helyezést, vásárlást a köszönőoldalon. Csak akkor működik, ha a script betöltődik, lefut, és eléri a platformot, mielőtt a vásárló elhagyja az oldalt.
A szerveroldali követés a küldést egy szerverre helyezi át. Az esemény olyan adatból indulhat, amely már megvan a webáruházadban, például egy kifizetett rendelésből, és a szerver elküldi a platform API-jának. A Meta ezt az API-t Conversions API-nak, a TikTok Events API-nak nevezi. A Google Ads az enhanced conversions megoldást használja, amely hashelt ügyféladatokat ad a konverzióhoz.
- A vásárló böngészőjében fut
- Az eseményeket közvetlenül a hirdetési platformnak küldi
- First-party sütiket állít be és olvas, például a Metához tartozó _fbp-t
- Semmit nem küld, ha a scriptet blokkolják, vagy az oldal nem töltődik be
- Olyan szerveren fut, amelyet te vagy egy szolgáltató irányít
- Az eseményeket a platform API-jának küldi
- A webáruházad rendelési rekordjából indulhat
- Nem függ attól, hogy a köszönőoldal betöltődik-e
A kettő együttes futtatása adja a platformnak a legteljesebb adatot. A böngészős esemény sütiket és oldalkontextust ad hozzá. A szerveroldali esemény akkor is megérkezik, ha a böngésző cserben hagy. Egy közös eseményazonosító biztosítja, hogy a platform minden vásárlást egyszer számoljon.
Hogyan működik a szerveroldali követés?
A webáruházak szerveroldali követése két félből áll. Az első fele a böngészőben történik: amikor egy vásárló hirdetésből érkezik, egy script elmenti az URL-ből a kattintásazonosítót. A második fele a szerveren történik: amikor a rendelés ki van fizetve, a szerver ehhez a kattintásazonosítóhoz köti a rendelést, és elküldi a vásárlást.
A kattintás rögzítése
A hirdetési platformok kattintásazonosítót adnak a landing URL-hez: fbclid-et a Metánál, ttclid-et a TikToknál, gclid-et a Google Adsnél és msclkid-et a Microsoft Adsnél. A kattintásazonosító a legerősebb kapocs egy eladás és az azt kiváltó hirdetés között, ezért az első oldalmegtekintéskor el kell menteni. Az UTM-paraméterek a kampány, a hirdetéscsoport és a hirdetés nevét adják hozzá egy általad szabályozott formátumban.
A rendelés párosítása
A szervernek ezután tudnia kell, melyik látogató adta le a rendelést. A legmegbízhatóbb kapocs egy olyan érték, amely a kosárral együtt eljut a rendelésig, például egy látogatóazonosító, amelyet a kosáron mentettek el. A többi módszer gyengébb: egy e-mail-cím, amelyet a látogató korábban megadott az oldalon, vagy ugyanaz az IP-cím és böngésző, amelyet röviddel a rendelés előtt láttak. Minden webáruház-platform más lehetőségeket kínál. A más webáruházakról szóló útmutatónk felsorolja, platformonként milyen módszereket használ a ROASaurus.
Az esemény elküldése
Végül a szerver elküldi a vásárlást az egyes platformok API-jának. Az esemény tartalmazza a rendelés értékét, a kattintásazonosítót és az ügyféladatokat, amelyek segítenek a platformnak megtalálni a kattintó személyt. Ha egy platform nem elérhető, vagy hibát ad vissza, egy jó beállítás később újra próbálkozik, így a vásárlás nem vész el.
Mit tartalmaz egy szerveroldali esemény?
Minden platformnak megvannak a saját mezőnevei, de a vásárlási esemény mindenhol ugyanolyan fajta adatokat hordoz. Íme egy rövidített példa a Meta Conversions API-hoz:
{
"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 }
}]
}| Mező | Mi ez | Hashelve? |
|---|---|---|
| Eseménynév és időpont | Purchase, és az, hogy mikor adták le a rendelést | Nem |
| Érték és pénznem | A rendelés értéke, amelyet a platform a ROAS-hoz és az értékalapú licitáláshoz használ | Nem |
event_id | Eseményenként egyedi azonosító, a böngészőben és a szerveren ugyanaz, a deduplikációhoz | Nem |
| E-mail, telefonszám, név, cím | A rendelés ügyféladatai, normalizálva és SHA-256-tal hashelve | Igen |
| Kattintásazonosító (fbc, ttclid, gclid) | A hirdetési kattintás azonosítója, elmentve a vásárló megérkezésekor | Nem |
| IP-cím és user agent | Segítenek a platformnak párosítani az eseményt egy eszközzel | Nem |
A hashelés egy e-mail-címet egy rögzített karaktersorrá alakít. Ugyanaz a cím mindig ugyanazt a karaktersort adja, de a karaktersorból nem látszik a cím. A platform a hashelt értékeket csak arra használja, hogy egyezést keressen a saját felhasználói között. Így párosítható egy vásárlás ahhoz a személyhez, aki látta vagy rákattintott a hirdetésre, még akkor is, ha a böngészője blokkolta a pixelt.
Hogyan működik a deduplikáció?
Ha a pixel és a szerver is ugyanazt a vásárlást küldi el, a platformnak egyszer kell számolnia. Mindkét példány ugyanazt az eseménynevet és ugyanazt az eseményazonosítót hordozza, például order-1042. A Meta összehasonlítja a párt, és az egyik példányt megtartja, feltéve, hogy a második példány az elsőtől számított 48 órán belül megérkezik.
Purchase event_id=order-1042 browserA pixelről érkezettPurchase event_id=order-1042 serverAzonos név és azonosító: egyszer számolvaPurchase event_id=order-1043 serverA pixelt blokkolták: a szerveroldali példány az egyetlenPurchase event_id=1044 serverA böngésző az order-1044 azonosítót küldte: az azonosítók eltérnek, ezért kétszer számítA dupla számolás nagy része két olyan küldőtől ered, amelyek nem osztoznak azonosítókon. Tipikus eset a platform saját webáruház-alkalmazása és egy külön követőeszköz, amelyek mindketten a saját azonosítójukkal küldik a vásárlásokat. A dupla számolás megelőzéséről szóló súgócikkünk felsorolja a szokásos okokat és javításokat.
Szerveroldali címkézés és küldés rendelési adatokból
A szerveroldali követés kifejezést két különböző beállításra használják. Mindkettő egy szerverről küld eseményeket, de más helyen indulnak.
Szerveroldali címkézés, például a Google Tag Manager szerverkonténerei
Szerveroldali címkézésnél a böngésző az eseményeit a saját szerveredre küldi, nem az egyes szolgáltatóknak. A Google Tag Manager szerverkonténere jól ismert példa. A saját Google Cloud projektedben vagy egy másik, általad választott környezetben fut. Kéréseket fogad a böngészőtől, a címkéi pedig továbbítják az adatot a Google Analyticsnek, a Metának és más szolgáltatóknak. Te döntöd el, milyen adat hová kerül, és a szerver az oldalad egy aldomainjén futhat.
Az események ettől még a böngészőben indulnak. Ha a böngészőben lévő címkét blokkolják, vagy a köszönőoldal sosem töltődik be, a szerverkonténernek nincs mit továbbítania. A szervert emellett te magad futtatod, fizeted és frissíted.
Küldés rendelési adatokból
A második megközelítés a vásárlást a webáruházad rendelési rekordjából indítja. A webáruház webhookon vagy API-n keresztül jelenti a kifizetett rendelést a szervernek, a szerver pedig elküldi minden csatlakoztatott platformnak. A böngészőre csak korábban van szükség, hogy elmentse a kattintásazonosítót, amikor a vásárló megérkezik.
| Szerveroldali címkézés | Küldés rendelési adatokból | |
|---|---|---|
| Ahol a vásárlás elindul | Egy címke a böngészőben | A kifizetett rendelés a webáruházadban |
| A köszönőoldalt idő előtt bezárták | A vásárlás elveszett | A vásárlás elküldve |
| A címkét blokkolták a böngészőben | A vásárlás elveszett, kivéve, ha a first-party végpont átjut | A vásárlás elküldve |
| Utánvét és külső fizetési oldalak | A köszönőoldaltól függ | A rendelés létrehozásakor vagy kifizetésekor megy el |
| Böngészési események (oldalmegtekintések, kosárba helyezés) | Igen | Külön böngészős gyűjtőre van szükség |
| Ki üzemelteti a szervert | Te: tárhely és frissítések | Te vagy egy szolgáltató |
A két megközelítés kombinálható. Sok webáruház az oldalmegtekintéseket és a kosárba helyezéseket a böngészőben gyűjti, a vásárlást pedig rendelési adatokból küldi. A vásárlás az az esemény, amelyet a hirdetési platformok a ROAS jelentéséhez és a licitálás optimalizálásához használnak, ezért ennek kell a legteljesebbnek lennie.
Mit javít meg a szerveroldali követés, és mit nem?
- Elveszett vásárlások, mert egy reklámblokkoló megállította a pixelt
- Elveszett vásárlások, mert a köszönőoldal nem töltődött be
- Az oldaladon kívül befejeződő fizetési módokkal történt vásárlások
- Gyenge párosítás: minden eseményhez hashelt ügyféladatot ad
- Hozzájárulás: aki elutasította, annak az elutasítása érvényes marad
- Platformonként eltérő attribúciós ablakok és modellek
- Eltérő eseményazonosítót használó duplikált küldők
- Kattintásazonosítók, amelyeket sosem mentettek el a landing oldalon
A hozzájárulás továbbra is szükséges
A szerveroldali követés az adat kézbesítésének egy módja, nem az adatvédelmi szabályok megkerülésének módja. Ahol a jog hozzájárulást követel a marketingsütikhez vagy a követéshez, ez a követelmény az általad gyűjtött adatra vonatkozik, bármilyen úton jut el a platformhoz. Ha egy követőt a szerveredre helyezel át, az nem változtatja meg, hogy a látogató mibe egyezett bele.
Az attribúció platformspecifikus marad
Minden platform a saját ablakaival és szabályaival írja jóvá a vásárlásokat. A szerveroldali események minden platformnak jobb adatot adnak, de a Meta, a TikTok és a Google összesített számai így is többet tehetnek ki, mint a webáruházad bevétele. A csatornák egyetlen szabályrendszerrel való összehasonlításához használj mindegyikre egy attribúciós modellt, például a ROASaurus attribúciójának modelljeit.
Szükséged van a webáruházadhoz szerveroldali követésre?
Általában az a webáruház jár jól, amely érdemi költségvetést költ fizetett közösségimédia- vagy keresőhirdetésekre. Az érv akkor a legerősebb, ha ezek közül több is igaz:
- A hirdetési platform egyértelműen kevesebb vásárlási eseményt kap, mint ahány webes rendelés van a webáruházadban. A reklámblokkolókról és a követésről szóló útmutatónk megmutatja, hogyan mérheted ezt a hiányt.
- A látogatóid közül sokan Safarit használnak iPhone-on vagy Macen, ahol a scriptek által beállított sütik legfeljebb 7 napig élnek. Lásd: Safari ITP és hirdetéskövetés.
- A vásárlók gyakran napokkal az első hirdetési kattintás után vásárolnak.
- A fizetés az oldaladon kívül fejeződik be, vagy a rendelések később kerülnek kifizetésre, például utánvét vagy banki átutalás esetén.
- A kampányaidat vásárlásra vagy vásárlási értékre optimalizálod, ezért a platformnak minden eladásra szüksége van, hogy tanuljon belőlük.
Íme, hogyan változtatja meg a hiány a döntéseket a gyakorlatban. Egy példa webáruháznak egy hónap alatt 1,000 webes rendelése van. A Meta pixele 820 Purchase eseményt jelentett, vagyis a rendelések 18%-a sosem jutott el a böngészőből a Metához.
A webáruház megtérülési ROAS-a 2.5, az Ads Manager pedig 2.3-as ROAS-t mutat a pixeladatok alapján. Ezekkel a számokkal a kampányok veszteségesek. Ha a hirdetésből származó rendeléseket ugyanilyen, 18%-os arányban nem látták, a valódi ROAS körülbelül 2.3 ÷ 0.82 = 2.8, ami a megtérülési ROAS fölött van. Ez felső becslés, mert nem minden hiányzó rendelés származott hirdetésből. Így is megmutatja, hogyan tüntethet fel egy követési hiány nyereséges kampányt veszteségesnek.
A szerveroldali követés kevésbé fontos annak a webáruháznak, amely nem hirdet, vagy nagyon keveset költ hirdetésekre.
Hogyan küld szerveroldali eseményeket a ROASaurus
A ROASaurus érkezéskor 19 kattintásazonosítót és hat UTM-mezőt rögzít, és egy first-party látogatóazonosítóval együtt tárolja őket. A webáruházad kifizetett rendeléseiből minden vásárlást elküld a következő platformoknak: Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll és Outbrain. Shopifyon a Google Ads konverziók a Shopify pénztárából mennek el. A böngészős pixelek ugyanazzal az eseményazonosítóval futhatnak a szerveroldali események mellett, a Meta, a TikTok, a Snapchat, a Pinterest, a Reddit, az OpenAI Ads, az AppLovin és a Spotify pedig deduplikálja őket. Minden kézbesítést és a platform válaszát az Event log sorolja fel.
Bővebben a szerveroldali követés oldalon olvashatsz, vagy keresd meg a webáruházadat az integrációk oldalon.
Források
- Meta for Developers: Conversions API
- Meta for Developers: Handling Duplicate Pixel and Conversions API Events
- Meta for Developers: Customer Information Parameters
- Google for Developers: An introduction to server-side tagging
- Google Ads Help: About enhanced conversions