A sütik „halála” után a marketing-attribúció nem szűnik meg, hanem a böngészőből a saját szerveredre költözik: a konverziót a webshop vagy az app backendje küldi el a hirdetési platformoknak (szerveroldali mérés, konverziós API-k), saját, first-party adatra építve. Ettől pontosabb és jobban kontrollálható lesz a mérés, de a hozzájárulást nem kerüli meg: amit a látogató elutasított, azt a szerveredről sem küldheted tovább.
A helyzet ráadásul paradox. A Chrome végül nem vezette ki a harmadik féltől származó sütiket: a Google 2025. októberi bejelentésében megerősítette, hogy marad a felhasználói választáson alapuló megközelítés, és több Privacy Sandbox-technológiát, köztük az Attribution Reporting API-t is kivezeti. A mérés mégis egyre lyukasabb. A „süti nélküli világ” tehát nem egy dátum, amire várni kell, hanem egy állapot, amiben a legtöbb webshop már most is benne van.
- A Chrome megtartotta a harmadik féltől származó sütiket, de a Safari korlátozásai, az elutasított hozzájárulások és a blokkolók miatt a böngészős mérés már most hiányos.
- Szerveroldali mérésnél a böngésző a te domainedre küld adatot, és te döntöd el, mi megy tovább a Metához vagy a Google-höz.
- A konverziós API-k a backendből küldik a valódi üzleti eseményt (sikeres fizetés, ajánlatkérés), egyedi eseményazonosítóval.
- A szerveroldali mérés nem jogalap. A hozzájárulási állapotnak minden eseménnyel együtt kell utaznia.
- A platformok számai irányjelzők. A viszonyítási alap a saját rendelési adatbázisod.
Ha a Chrome megtartja a sütiket, miért romlik mégis a mérés?
Mert a harmadik féltől származó süti csak egy szelete a problémának. A gyakorlatban három dolog eszi a mérést.
A Safari és az ITP
A WebKit hivatalos dokumentációja szerint az Intelligent Tracking Prevention (ITP) a JavaScriptből létrehozott sütiket és minden más, scriptből írható tárhelyet töröl, ha a felhasználó hét napig (Safari-használatban számolva) nem lép interakcióba az oldallal. Ez pont az a fajta süti, amire a legtöbb pixel és analitikai kód épít. Ha valaki egy hirdetésre kattint, majd jóval később tér vissza vásárolni, a böngésző addigra jó eséllyel „elfelejti”, honnan jött.
A hozzájárulás
Az EU-ban a marketingcélú sütikhez és követéshez hozzájárulás kell, és a látogatók egy része nemet mond. Ez így van rendjén. Ezt a lyukat nem trükkökkel kell betömni, hanem tudatosan kezelni: tudni, mekkora, és úgy dönteni, hogy számolsz vele.
A blokkolók és a böngészőbeállítások
A reklámblokkolók és a szigorúbb adatvédelmi beállítások sokszor már a mérőkód betöltését is megakadályozzák. Ilyenkor nem a süti hiányzik, hanem a pixel le sem fut.
Hogy nálad mekkora a lyuk, azt ne iparági átlagokból becsüld. Vesd össze egy hónap rendeléseit a webshop adatbázisából azzal, amit az Analytics és a hirdetési fiókok jelentenek ugyanarra az időszakra. Ez a különbség lesz a kiindulópontod.
Mit csinál másképp a szerveroldali mérés?
Kliensoldalon a látogató böngészője tölti be a Meta-pixelt, a Google-taget és a többit, és mindegyik maga küldi az adatot a saját szerverére. Szerveroldalon a böngésző egy, a te domainedről elérhető mérőszervernek küld adatot (ez lehet például a Google Tag Manager szerveroldali konténere), és onnan te döntöd el, melyik adat, milyen formában, melyik platformhoz megy tovább.
| Szempont | Kliensoldali pixel | Szerveroldali mérés |
|---|---|---|
| Ki küldi az adatot a platformnak? | A látogató böngészője | A te szervered |
| Mit kap meg a platform? | Amit a script az oldalon elér | Csak amit továbbengedsz |
| Üzleti események (fizetés, lemondás) | Csak ha van köszönőoldal, és az betölt | Közvetlenül a backendből |
| Bevezetés | Gyors, kódbeillesztés | Szerver, beállítás, tesztelés |
| Üzemeltetés | Minimális | Folyamatos monitorozás kell |
Egy csapdát érdemes ismerni. Gyakori megoldás, hogy a mérőszerver egy aldomainre kerül (például mero.sajatdomain.hu), ami valójában egy másik szolgáltató hálózatára mutat. A WebKit dokumentációja szerint az ITP felismeri az ilyen CNAME- és IP-alapú álcázást, és az ilyen válaszban beállított sütik élettartamát is hét napra vágja, akkor is, ha a sütit a szerver állította be. Ezért mi a mérést lehetőleg ugyanarra az infrastruktúrára tesszük, mint magát az oldalt, ideális esetben ugyanazon a domainen, egy útvonal alatt.
Hogyan működnek a konverziós API-k a gyakorlatban?
A Meta Conversions API és a Google hirdetési rendszerének szerveroldali konverziós bekötései részleteikben eltérnek, a lényegük viszont azonos: a konverziót nem (csak) a böngésző jelzi, hanem a szervered közvetlenül. Szerintünk a legjobb jelforrás nem a köszönőoldal, hanem az a pillanat, amikor a backend rögzíti a sikeres fizetést. Így a félbehagyott fizetés nem lesz konverzió, a lemondott rendeléseket pedig a saját riportodban külön tudod kezelni.
Nálunk egy ilyen bekötés így néz ki:
- Esemény a backendben: sikeres fizetés, regisztráció vagy ajánlatkérés, nem pedig egy oldalbetöltés.
- Hozzájárulás csatolása: a sütibanneren hozott döntést (Google Consent Mode esetén például az
ad_user_dataés azad_personalizationállapotát) az eseménnyel együtt tároljuk. Ha nincs hozzájárulás a hirdetési célú adatküldéshez, az esemény nem megy ki személyes adattal. - Egyedi eseményazonosító: ha böngészőből és szerverről is mérsz, mindkét úton ugyanazt az azonosítót küldjük, hogy a platform ki tudja szűrni a duplikációt.
- Adattakarékosság: csak azt a mezőt küldjük, amire a platformnak tényleg szüksége van, az ő előírása szerint előkészítve.
- Monitorozás: rendszeresen összevetjük a kiküldött események számát a rendelések számával. Ha elcsúszik, valami eltört, és jobb ezt hétfőn tudni, mint a havi riportnál.
Egy belső esemény nálunk nagyjából ilyen, mielőtt bármelyik platform formátumára alakítanánk:
{
"event": "purchase",
"event_id": "order-10482",
"value": 18990,
"currency": "HUF",
"consent": {
"ad_user_data": "denied",
"ad_personalization": "denied"
}
}Ebben az esetben a vásárlás megtörtént, a saját statisztikádba bekerül, de a hirdetési platformokhoz személyes adat nem megy. Ha több felületed van (például app, webshop és weboldal, ahogy a G8 Alakváltóknak építettük), ez a megközelítés különösen sokat ér: az események egy közös backendből jönnek, nem három külön pixelből.
Hogyan marad GDPR-barát a szerveroldali mérés?
Ez a legfontosabb rész, mert a szerveroldali mérést sokan a hozzájárulás kikerülésének eszközeként árulják. Szerintünk ez veszélyes félreértés. A GDPR a személyes adatok kezelésére vonatkozik, nem arra, hogy melyik gépen fut a kód. Ha egy e-mail-címet vagy egy azonosítót a szerveredről küldesz tovább a Metának, az ugyanúgy adattovábbítás, mintha a pixel tette volna.
- Előbb hozzájárulás, utána mérés. A Google Consent Mode leírása kétféle bevezetést különít el: alap módban a Google-tagek a hozzájárulásig nem töltődnek be, haladó módban betöltődnek, és elutasításkor süti nélküli jelzéseket küldenek, a hiányzó adatot pedig a Google modellezéssel becsülheti. A haladó mód bevezetése előtt kérj jogi véleményt.
- Adatminimalizálás a szerveren. Mielőtt bármi kimenne, levághatod az IP-címet, a felesleges URL-paramétereket és a nem szükséges eszközadatokat. Ez a szerveroldali mérés valódi adatvédelmi előnye.
- Átláthatóság. Az adatkezelési tájékoztatóban szerepeljen, milyen adat megy melyik platformhoz és milyen célból.
- Tudd, hol fut a mérőszerver. Melyik szolgáltatónál, melyik régióban, ki fér hozzá, és megvan-e az adatfeldolgozói szerződés.
Nem vagyunk ügyvédek: a jogalapot és a tájékoztató szövegét adatvédelmi szakemberrel érdemes véglegesíteni. Mi a technikai oldalt építjük úgy, hogy a jogi döntés be is tartható legyen.
Mire építsd az attribúciót, ha a kép sosem lesz teljes?
Először is: engedd el a tökéletes képet. Minden platform a saját szemszögéből számol, és a tapasztalatunk az, hogy a hirdetési fiókok által jelentett konverziók összeadva gyakran nem egyeznek a valódi rendelésszámmal. Ezért nálunk a sorrend ez:
- Saját igazságforrás: a backend rendelési adatai, UTM-paraméterekkel és bejelentkezett vásárlóknál saját azonosítóval összekötve.
- Platformszámok irányjelzőként: a kampányoptimalizáláshoz kellenek, az üzleti döntéshez nem elegendők.
- Inkrementalitás-teszt: egy kampányt egy időszakra vagy egy régióban szüneteltetsz, és megnézed, mi történik a rendelésekkel. Ez többet mond bármelyik attribúciós modellnél.
- Modellezett adat jelölése: ha a Google modellezett konverziókat mutat, kezeld becslésként, ne mért adatként.
A tiszta, backendből jövő konverziós adat egyébként nemcsak a hirdetéseknek kell. Erre épül minden későbbi automatizálás is, például egy saját AI marketing-asszisztens, amely csak annyira okos, amennyire jó adatot kap.
Gyakori kérdések
Kell szerveroldali mérés egy kisebb webshopnak is?
Nem mindig. Ha kevés a hirdetési költés, és főleg organikus forgalomból élsz, előbb a hozzájárulás-kezelést és az alap analitikát érdemes rendbe tenni. Ha viszont rendszeresen hirdetsz Metán vagy Google-ön, és a platform a te adataidra optimalizál, a backendből küldött konverzió hamar a legfontosabb jel lesz.
Kiváltja a szerveroldali mérés a sütibannert?
Nem. A hozzájárulás-kezelés marad, a szerveroldali mérés csak azt teszi lehetővé, hogy a döntést pontosan érvényesítsd, és kevesebb adatot adj ki, mint egy pixel.
Mi a különbség a Consent Mode és a konverziós API között?
A Consent Mode azt közli a Google-tagekkel, mihez járult hozzá a látogató. A konverziós API az a csatorna, amelyen a szervered közvetlenül elküldi az eseményt. A kettő együtt működik: az API-n küldött eseménynek is tisztelnie kell a hozzájárulási állapotot.
Elég, ha csak szerverről mérünk, böngészőből egyáltalán nem?
Bizonyos eseményeknél igen, de a legtöbb helyen a kettő kombinációját javasoljuk: a böngésző látja a viselkedést az oldalon, a szerver a megbízható üzleti eseményt. Ilyenkor az egyedi eseményazonosító akadályozza meg a dupla számolást.
Ha nem tudod, mekkora rés van a rendeléseid és a hirdetési fiókjaid számai között, nézzük meg együtt. Új webshopnál a szerveroldali mérést és a hozzájárulás-kezelést eleve a backend részeként tervezzük, meglévő rendszereknél pedig a marketingcsapatunk és a fejlesztők közösen kötik be.