Arutelu "serveripoolne vs kliendipoolne" on aastaid olnud teema, kus vastus on ausalt "see sõltub", ja kõik vihkavad seda. Siin on arusaadav versioon, ilma müügijututa, sealhulgas aus tabel, mille saate oma CTO-le saata.
Mis see tegelikult on
Kliendipoolne jälgimine töötab külastaja brauseris. Väike skript käivitatakse, loeb, mis toimub (lehevaade, klõps, kerimissügavus) ja saadab selle teabe otse kogumispunkti. Serveripoolne jälgimine töötab teie infrastruktuuris. Brauser saadab minimaalsed andmed teie serverisse (või kergele ääretöötajale), mis seejärel otsustab, mida ja kuhu edasi saata.
Kumbki pole olemuselt rohkem "privaatsussõbralik" ega "täpsem" kui teine. Mõlemad võivad seda olla, sõltuvalt konfiguratsioonist. Erinevus seisneb selles, kus kontrollpunkt asub – ja kui palju tõde teieni jõuab.
Aus kompromisside tabel
| Mõõde | Kliendipoolne | Serveripoolne |
|---|---|---|
| Paigalduspingutus | Madal – koodilõigu kleepimine | Kõrgem – teenus ja väike marsruutimiskiht |
| Vastupidavus reklaamiblokeerijatele | Nõrk – skript blokeeritakse allikas | Tugev – esimese osapoole lõpp-punkt teie enda domeenil |
| Andmekadu kaasaegsetes brauserites | Märkimisväärne (Safari ITP, blokeerijad, jälgimise vältimine) | Väike – teie olete pinna omanik |
| Kiirus (latentsus) laadimisel | Lisab ühe kolmanda osapoole päringu | Ei lisa midagi, kui kogur on ääre-vahemälus |
| Kontroll selle üle, mis teie infrat lahkub | Mida müüja skript otsustab | Mida teie otsustate |
| Silumise lihtsus | DevTools võrgutabel | Serveri logid – teine oskus, kuid täielikum |
| Kulud skaleerimisel | Madal, kuni müüja tasemed tõusevad | Väike ääre- / funktsioonikonto, mida te tõesti näete |
| B2B ettevõtte identifitseerimine | Töötab, kuid on haavatav | Ideaalne sobivus – server saab IP → ettevõtte privaatselt tuvastada |
See viimane rida on see, mida B2B meeskonnad peaksid kõige kauem vaatama. Kliendipoolne identifitseerimine sõltub skriptist, mis blokeerib või neutraliseerib kasvava osa külastajatest. Serveripoolne paigutab identifitseerimisloogika teie enda infrastruktuuri, kus brauseri uuendus seda vaikselt välja lülitada ei saa.
Kuhu ettevõtte identifitseerimine pildile sobib
Ettevõtte identifitseerimine on serveripoolse jaoks loomulik ülesanne. Brauser peab tegema vaid väga väikese päringu esimese osapoole lõpp-punkti teie enda domeenil. See lõpp-punkt töötab äärel (tavaliselt <20 ms Euroopas), teostab IP-st ettevõttesse tuvastamise privaatselt ja ei saada tagasi midagi, mis paljastaks, mis kliendipoolsel toimus. Kasutajakogemus ei muutu. Blokeerijate maastikust möödutakse. Andmeportaal jääb teie hallatavate piiride sisse.
See ei ole trikk. See on loogiline tagajärg küsimuse "kes on see külastaja" viimisest kliendilt teenusele, mida teie haldate. Külastaja sirvimiskäitumises ei muutu midagi; teie võimes vastust näha muutub aga midagi.
Mida serveripoolne ei ole
Serveripoolne jälgimine ei ole viis nõusolekust mööda hiilida. Kui töötlemistegevus nõuab nõusolekut, siis see jääb nii, olenemata sellest, kus kood töötab. Mida serveripoolne muudab, on andmekao hulk ja kontroll – mitte õiguslik alus.
Märkus jõudluse kohta
Inimesed kardavad sageli, et "jälgimine" muudab lehe aeglaseks. Kaasaegsetes seadistustes on see mineviku hirm. Hästi ehitatud laadur on vaid paar kilobaiti, laaditakse viivitusega ja aktiveeritakse alles pärast lehe interaktiivseks muutumist; hästi ehitatud serveri lõpp-punkt reageerib mõne millisekundi jooksul lähimast äärest. Kumbki ei halvenda teie Core Web Vitals'i. Mis neid aga halvendab, on sildihaldur neljateistkümne kolmanda osapoole skriptiga, mida keegi pole kolme aasta jooksul kontrollinud. Vähem, paremini kontrollitud andmeteid on peaaegu alati kiiremad.
Millal kliendipoolne ikka veel võidab
Kliendipoolne ei ole vale. Vähem kriitiliste analüüside puhul, kus nõustute andmekaoga blokeerijate tõttu (tootekasutuse valimid, rakendusesisesed UX-sündmused, lihtsad maandumislehe testid), on kliendipoolne kiirem juurutada ja odavam kasutada. Küsimus ei ole selles, et üks lähenemine on universaalselt parem; küsimus on selles, et kui teie töö sõltub andmetest – B2B torujuhe on selle hea näide – siis serveripoolne tee on vastupidavam ja ausam selles, mida see teeb.
Õige küsimus ei ole "milline on parim?" See on "millise otsuse jaoks need andmed on, ja kui palju andmekadu see otsus talub?" Küsimuse "kes meid sel nädalal külastas" puhul – ideaalis ei mingit kadu. Arhitektuuri vastus tuleneb sellest.
Published by
lead.box Team
Rohkem artikleid
Vaata, mida lead.box sinu enda liikluses näeb
Alusta tasuta — kaarti ega müügikõnet pole vaja. Või broneeri 20-minutiline läbivaatus, kui eelistad juhendatud tuuri.