A „szerveroldali vs. kliensoldali” vita évek óta olyan téma, ahol a válasz őszintén „attól függ”, és ezt mindenki utálja. Itt van a közérthető változat, értékesítési szöveg nélkül, beleértve egy őszinte táblázatot, amelyet elküldhetsz a CTO-dnak.
Mi is ez valójában
A kliensoldali követés a látogató böngészőjében fut. Egy kis szkript fut le, leolvassa, mi történik (oldalmegtekintés, kattintás, görgetési mélység), és ezt az információt közvetlenül egy gyűjtőpontra küldi. A szerveroldali követés a te infrastruktúrádon fut. A böngésző minimális adatot küld a szerveredre (vagy egy könnyű edge workerre), amely ezután eldönti, hogy mi hova továbbítódik.
Egyik sem természeténél fogva „adatvédelmi szempontból barátságosabb” vagy „pontosabb” a másiknál. Mindkettő lehet az, a konfigurációtól függően. Ami eltér, az az ellenőrzési pont helye – és az, hogy az igazságnak mekkora része jut el hozzád.
Az őszinte kompromisszumtáblázat
| Dimenzió | Kliensoldali | Szerveroldali |
|---|---|---|
| Telepítési erőfeszítés | Alacsony – snippet beillesztése | Magasabb – egy szolgáltatás és egy kis routing réteg |
| Adblockerekkel szembeni ellenállás | Gyenge – a szkriptet a forrásnál blokkolják | Erős – első féltől származó végpont a saját domaineden |
| Adatvesztés modern böngészőkben | Jelentős (Safari ITP, blokkolók, követésmegelőzés) | Kicsi – te birtoklod a felületet |
| Sebesség (késleltetés) betöltéskor | Egy harmadik féltől származó kérést ad hozzá | Semmit sem ad hozzá, ha a gyűjtő edge-gyorsítótárazott |
| Kontroll az infrastruktúrádat elhagyó adatok felett | Amit a szállító szkriptje eldönt | Amit te eldöntesz |
| Hibakeresés egyszerűsége | DevTools hálózati lap | Szerver naplók – más készség, de teljesebb |
| Költségek skálázáskor | Alacsony, amíg a szállítói szintek nem emelkednek | Kis edge / funkció számla, amit tényleg látsz |
| B2B cégazonosítás | Működik, de sebezhető | Ideális párosítás – a szerver privát módon tudja az IP-t cégre fordítani |
Az utolsó sor az, amire a B2B csapatoknak a leghosszabb ideig figyelniük kellene. A kliensoldali azonosítás egy olyan szkripttől függ, amelyet a látogatók egyre nagyobb része blokkol vagy hatástalanít. A szerveroldali azonosítási logika a saját infrastruktúrádra helyezi, ahol egy böngészőfrissítés nem kapcsolhatja ki csendesen.
Hol illeszkedik a cégazonosítás a képbe
A cégazonosítás természetes feladat a szerveroldalon. A böngészőnek csak egy nagyon kis kérést kell küldenie egy első féltől származó végpontra a saját domaineden. Ez a végpont az edge-en fut (általában <20 ms Európában), privát módon végzi el az IP-cég fordítást, és semmit sem küld vissza, ami felfedné, mi történt a kliensoldalon. A felhasználói élmény nem változik. A blokkolók tájképe megkerülhető. Az adatportál a te általad kezelt határokon belül marad.
Ez nem trükk. Ez logikus következménye annak, hogy a „ki ez a látogató” kérdést a klienstől egy általad kezelt szolgáltatásra helyezzük át. A látogató böngészési viselkedése nem változik; az a képességed változik, hogy lásd a választ.
Mi nem a szerveroldali
A szerveroldali követés nem módja a hozzájárulás (consent) megkerülésének. Ha egy feldolgozási tevékenység hozzájárulást igényel, akkor az továbbra is így marad, függetlenül attól, hogy hol fut a kód. Amit a szerveroldali változtat, az az adatvesztés mértéke és az ellenőrzés – nem a jogi alap.
Megjegyzés a teljesítményről
Az emberek gyakran félnek attól, hogy a „követés” lelassítja az oldalt. Modern beállításokban ez a múlt félelme. Egy jól felépített betöltő csak néhány kilobájt, késleltetve töltődik be, és csak az oldal interaktívvá válása után aktiválódik; egy jól felépített szervervégpont néhány milliszekundum alatt válaszol a legközelebbi edge-ről. Egyik sem rontja a Core Web Vitals értékeidet. Ami rontja, az a tag manager tizennégy harmadik féltől származó szkripttel, amelyet senki sem ellenőrzött három éve. Kevesebb, jobban ellenőrzött adatútvonal szinte mindig gyorsabb.
Amikor a kliensoldali még mindig nyer
A kliensoldali nem rossz. Kevésbé kritikus analitikákhoz, ahol elfogadod a blokkolók okozta adatvesztést (termékhasználati mintavétel, alkalmazáson belüli UX események, egyszerű landing page tesztek), a kliensoldali gyorsabban implementálható és olcsóbb a használata. A lényeg nem az, hogy az egyik megközelítés univerzálisan jobb; a lényeg az, hogy ha a munkád az adatoktól függ – a B2B pipeline jó példa erre –, akkor a szerveroldali út rugalmasabb és őszintébb abban, amit tesz.
A helyes kérdés nem az, hogy „melyik a legjobb?” Hanem az, hogy „milyen döntéshez szolgál ez az adat, és mennyi adatvesztést képes elviselni ez a döntés?” A „ki látogatott meg minket ezen a héten” kérdésre – ideális esetben nulla veszteség. Az architektúra válasza ebből következik.
Published by
lead.box Team
További cikkek
Nézze meg a lead.box-ot a saját forgalmán
Kezdje ingyen — bankkártya és értékesítési hívás nélkül. Vagy foglaljon egy 20 perces bemutatót, ha vezetett túrát szeretne.