Razprava o "strežniški strani proti odjemalski strani" je že leta ena tistih tem, kjer je odgovor iskreno "odvisno je", in vsi to sovražijo. Tukaj je razumljiva različica, brez prodajnih govoric, vključno s pošteno tabelo, ki jo lahko pošljete svojemu CTO-ju.
Kaj v resnici sta
Sledenje na strani odjemalca se izvaja v brskalniku obiskovalca. Izvede se majhen skript, ki prebere, kaj se dogaja (ogled strani, klik, globina pomikanja) in te informacije pošlje neposredno na zbirno točko. Sledenje na strani strežnika se izvaja na vaši infrastrukturi. Brskalnik pošlje minimalne podatke vašemu strežniku (ali lahkemu robu), ki nato odloči, kaj se posreduje kam.
Nobena od obeh ni po naravi bolj "prijazna do zasebnosti" ali "natančnejša" od druge. Obe sta lahko, odvisno od konfiguracije. Razlika je v tem, kje je kontrolna točka — in koliko resnice vas doseže.
Tabela poštenih kompromisov
| Dimenzija | Stran odjemalca | Stran strežnika |
|---|---|---|
| Napor pri namestitvi | Nizek — prilepite izrezek | Višji — storitev in majhen usmerjevalni sloj |
| Odpornost na blokatorje oglasov | Šibka — skript je blokiran pri viru | Močna — prva končna točka na vaši domeni |
| Izguba podatkov v sodobnih brskalnikih | Pomembna (Safari ITP, blokatorji, preprečevanje sledenja) | Majhna — vi ste lastnik površine |
| Hitrost (latenca) nalaganja | Doda eno zahtevo tretje osebe | Ne doda ničesar, če je zbiralnik predpomnjen na robu |
| Nadzor nad tem, kaj zapusti vašo infrastrukturo | Kar določi skript prodajalca | Kar določite vi |
| Enostavnost odpravljanja napak | Zavihek omrežja DevTools | Dnevniki strežnika — drugačna veščina, vendar popolnejša |
| Stroški pri skaliranju | Nizki, dokler se ravni prodajalca ne povečajo | Majhen račun za rob / funkcijo, ki ga resnično vidite |
| B2B identifikacija podjetja | Deluje, vendar je ranljiva | Idealno ujemanje — strežnik lahko zasebno preslika IP → podjetje |
Zadnja vrstica je tista, ki bi jo morale B2B ekipe najdlje preučevati. Identifikacija na strani odjemalca je odvisna od skripta, ki ga rastoči del obiskovalcev blokira ali onesposobi. Identifikacija na strani strežnika postavi logiko identifikacije na vašo lastno infrastrukturo, kjer je ne more tiho izklopiti posodobitev brskalnika.
Kje se identifikacija podjetja prilega sliki
Identifikacija podjetja je naravna naloga za strežniško stran. Brskalnik mora poslati le zelo majhno zahtevo na končno točko prve stranke na vaši domeni. Ta končna točka se izvaja na robu (običajno <20 ms v Evropi), zasebno izvede preslikavo IP-ja v podjetje in ne pošlje ničesar nazaj, kar bi razkrilo, kaj se je zgodilo na strani odjemalca. Uporabniška izkušnja se ne spremeni. Pokrajina blokatorjev je zaobidena. Podatkovni portal ostane znotraj meja, ki jih upravljate.
To ni trik. To je logična posledica premikanja vprašanja "kdo je ta obiskovalec" od odjemalca k storitvi, ki jo upravljate. Nič se ne spremeni v brskalnem vedenju obiskovalca; spremeni se vaša sposobnost, da vidite odgovor.
Kaj strežniška stran ni
Sledenje na strani strežnika ni način za obhod soglasja. Če dejavnost obdelave zahteva soglasje, potem to ostane tako, ne glede na to, kje se koda izvaja. Kar strežniška stran spremeni, je količina izgube podatkov in nadzor — ne pravna podlaga.
Opomba o zmogljivosti
Ljudje se pogosto bojijo, da "sledenje" upočasni stran. V sodobnih nastavitvah je to strah iz preteklosti. Dobro zgrajen nalagalnik je le nekaj kilobajtov, se naloži z zamikom in se aktivira šele, ko je stran interaktivna; dobro zgrajena strežniška končna točka se odzove v nekaj milisekundah z najbližjega roba. Nobena od obeh ne bo poslabšala vaših Core Web Vitals. Kar jih poslabša, je upravitelj oznak s štirinajstimi skripti tretjih oseb, ki jih nihče ni preveril v treh letih. Manj, bolje nadzorovanih podatkovnih poti je skoraj vedno hitrejših.
Ko stran odjemalca še vedno zmaga
Stran odjemalca ni napačna. Za manj kritično analitiko, kjer sprejemate izgubo podatkov zaradi blokatorjev (vzorce uporabe izdelka, dogodki UX v aplikaciji, preprosti testi pristajalnih strani), je stran odjemalca hitrejša za implementacijo in cenejša za uporabo. Bistvo ni v tem, da je en pristop univerzalno boljši; bistvo je v tem, da če je vaše delo odvisno od podatkov — B2B cevovod je dober primer — je pot na strani strežnika bolj odporna in poštenejša glede tega, kaj počne.
Pravo vprašanje ni "kateri je najboljši?" Je "za katero odločitev služijo ti podatki in koliko izgube podatkov lahko ta odločitev prenese?" Za vprašanje "kdo nas je obiskal ta teden" — idealno brez izgube. Odgovor na arhitekturo sledi iz tega.
Published by
lead.box Team
Več člankov
Oglejte si lead.box na lastnem prometu
Začnite brezplačno — brez kartice in brez prodajnega klica. Ali pa rezervirajte 20-minutno predstavitev, če želite voden ogled.