"Server-side vs client-side" -keskustelu on jo vuosia ollut niitä aiheita, joissa vastaus on turhauttavasti "se riippuu". Tässä on kuitenkin selkokielinen versio ilman myyntipuheita, sisältäen rehellisen taulukon, jonka voit lähettää suoraan CTO:llesi.
Mitä ne oikeastaan ovat
Client-side seuranta tapahtuu kävijän selaimessa. Pieni skripti suoritetaan, se lukee mitä tapahtui (sivun katselu, klikkaus, selaussyvyys) ja lähettää tiedon suoraan keräyspisteeseen. Server-side seuranta taas tapahtuu sinun infrastruktuurissasi. Selain lähettää vain pienen määrän dataa palvelimellesi (tai kevyelle edge-palvelimelle), joka päättää, mitä se välittää eteenpäin ja minne.
Kumpikaan ei ole itsessään "yksityisyyden suojan kannalta parempi" tai "tarkempi" kuin toinen. Molemmat voivat olla kumpaakin riippuen konfiguraatiosta. Ero on siinä, kuka hallitsee kontrollipistettä — ja kuinka paljon totuudesta todella saavuttaa sinut.
Rehellinen vertailu
| Ulottuvuus | Client-side | Server-side |
|---|---|---|
| Asennusvaiva | Matala — koodinpätkä sivuille | Korkeampi — tarvitaan palvelu ja reitityskerros |
| Mainostenesto-ohjelmien sietokyky | Heikko — skripti estetään heti lähteellä | Vahva — first-party päätepiste omassa domainissasi |
| Datahävikki nykyselaamilla | Merkittävä (Safari ITP, estot, seurannan suojaus) | Pieni — hallitset pintaa itse |
| Viive latauksessa | Lisää yhden kolmannen osapuolen pyynnön | Ei lisäystä, jos keräyspiste on edge-välimuistissa |
| Hallinta (mitä lähtee infrasta) | Se mitä toimittajan skripti päättää | Se mitä sinä päätät |
| Vianetsinnän helppous | DevTools-verkkovälilehti | Palvelinloki — eri osaamista, mutta kattavampi |
| Kustannus skaalautuessa | Halpa, kunnes toimittajan hintarajat paukkuvat | Pieni ja läpinäkyvä edge-/funktiolasku |
| Yritystason B2B-tunnistus | Toimii, mutta on hauras | Ihanteellinen — palvelin voi selvittää IP → yritys -yhteyden yksityisesti |
Tuo viimeinen rivi on se, jota B2B-tiimien kannattaa tuijottaa pisimpään. Client-side tunnistus on riippuvainen skriptistä, jonka yhä useampi kävijä joko estää kokonaan tai tekee toimintakyvyttömäksi. Server-side siirtää tunnistuslogiikan omaan infrastruktuuriisi, josta selainpäivitykset eivät voi kytkeä sitä hiljaa pois päältä.
Miten yritystason tunnistaminen istuu kuvaan
Yritystason tunnistus on luonteva tehtävä server-side-tasolla. Selaimen tarvitsee tehdä vain hyvin pieni pyyntö omassa domainissasi olevaan first-party-päätepisteeseen. Päätepiste toimii edgellä (yleensä <20 ms Euroopassa), tekee IP-osoitteen muuntamisen yritystiedoksi yksityisesti eikä palauta selaimelle mitään, mikä paljastaisi tapahtuman käyttäjälle. Käyttäjäkokemus ei muutu, estolistat ohitetaan ja datat säilyvät hallitsemasi rajan sisäpuolella.
Tämä ei ole kikkailua. Se on suora seuraus siitä, että kysymys "kuka tämä vierailija on" siirretään selaimesta palveluun, jota sinä hallinnoit. Kävijän selauskokemusta ei muuteta; vain kykysi nähdä vastaus paranee.
Mitä server-side ei ole
Server-side seuranta ei ole tapa kiertää suostumusta. Jos jokin käsittely vaatii suostumuksen, se vaatii sen riippumatta siitä, missä koodi ajetaan. Server-side muuttaa datahävikkiä ja hallintaa — ei laillista perustetta.
Huomio suorituskyvystä
Monet pelkäävät, että "seuranta" hidastaa sivustoa. Nykyisissä ratkaisuissa tämä on vanhentunut pelko. Hyvin rakennettu latausohjelma on vain muutaman kilotavun kokoinen, se ladataan viivästettynä ja ajetaan vasta, kun sivu on interaktiivinen. Oikein rakennettu palvelinpäätepiste vastaa muutamassa millisekunnissa lähimmältä edgeltä. Kumpikaan näistä ei pilaa Core Web Vitals -lukujasi. Sen tekee tag manager, jossa on neljätoista vanhentunutta kolmannen osapuolen skriptiä, joita kukaan ei ole tarkistanut kolmeen vuoteen. Vähemmän ja paremmin hallittuja datapolkuja on lähes aina nopeampi vaihtoehto.
Milloin client-side on yhä parempi
Client-side ei ole väärä valinta. Jos kyse on matalan riskin analytiikasta, jossa hyväksyt jo valmiiksi blokkerien aiheuttaman datahävikin (kuten tuotteen käytön otanta, sovelluksen sisäiset UX-tapahtumat tai nopeat laskeutumissivutestit), client-side on nopeampi ottaa käyttöön ja halvempi ylläpitää. Pointti ei ole se, että yksi tapa on universaalisti parempi; kyse on siitä, että jos työsi riippuu datasta — kuten B2B-putken rakentamisessa — server-side-polku on kestävämpi ja rehellisempi.
Oikea kysymys ei ole "kumpi on paras?", vaan "mitä päätöksentekoa tämä data ruokkii ja kuinka paljon datahävikkiä kyseinen päätös kestää?" Vastaukseen "kuka vieraili sivuillamme tällä viikolla" ei ihanteellisesti pitäisi sisältyä lainkaan hävikkiä. Arkkitehtuurivalinta seuraa tästä.
Julkaisija
lead.box Team
Lisää artikkeleita
Näe lead.box omassa liikenteessäsi
Aloita ilmaiseksi — ei korttia, ei myyntipuhelua. Tai varaa 20 minuutin esittely, jos haluat opastetun kierroksen.