Diskusija par "servera puses vs klienta puses" jau gadiem ir bijusi tēma, kur atbilde patiesi ir "tas ir atkarīgs", un visiem tas nepatīk. Šeit ir saprotama versija, bez pārdošanas runām, ieskaitot godīgu tabulu, ko varat nosūtīt savam CTO.
Kas tas patiesībā ir
Klienta puses izsekošana darbojas apmeklētāja pārlūkprogrammā. Tiek izpildīts neliels skripts, kas nolasa notiekošo (lapas skatījums, klikšķis, ritināšanas dziļums) un nosūta šo informāciju tieši uz savākšanas punktu. Servera puses izsekošana darbojas jūsu infrastruktūrā. Pārlūkprogramma nosūta minimālus datus uz jūsu serveri (vai vieglu malu darbinieku), kas pēc tam izlemj, kas un kur tiek pārsūtīts.
Neviena no tām nav dabiski "privātumam draudzīgāka" vai "precīzāka" par otru. Abas var būt, atkarībā no konfigurācijas. Atšķiras tas, kur atrodas kontroles punkts — un cik daudz patiesības jūs sasniedz.
Godīga kompromisu tabula
| Dimensija | Klienta puse | Servera puse |
|---|---|---|
| Instalācijas piepūle | Zema — ielīmēt fragmentu | Augstāka — pakalpojums un neliels maršrutēšanas slānis |
| Izturība pret reklāmu bloķētājiem | Vāja — skripts tiek bloķēts pie avota | Spēcīga — pirmās puses galapunkts jūsu pašu domēnā |
| Datu zudums mūsdienu pārlūkprogrammās | Ievērojams (Safari ITP, bloķētāji, izsekošanas novēršana) | Neliels — jūs esat virsmas īpašnieks |
| Ātrums (latentums) ielādes laikā | Pievieno vienu trešās puses pieprasījumu | Nepievieno neko, ja kolektors ir kešatmiņā |
| Kontrole pār to, kas atstāj jūsu infrastruktūru | Ko izlemj pārdevēja skripts | Ko izlemjat jūs |
| Atkļūdošanas vieglums | DevTools tīkla cilne | Servera žurnāli — cita prasme, bet pilnīgāka |
| Izmaksas mērogojot | Zemas, līdz pārdevēja līmeņi pieaug | Neliels malu / funkciju rēķins, ko jūs patiešām redzat |
| B2B uzņēmuma identifikācija | Darbojas, bet ir neaizsargāta | Ideāli piemērota — serveris var privāti atšifrēt IP → uzņēmumu |
Pēdējā rinda ir tā, uz kuru B2B komandām vajadzētu skatīties visilgāk. Klienta puses identifikācija ir atkarīga no skripta, kas bloķē vai neitralizē arvien lielāku apmeklētāju daļu. Servera puse novieto identifikācijas loģiku jūsu pašu infrastruktūrā, kur to nevar klusi izslēgt pārlūkprogrammas atjauninājums.
Kur uzņēmuma ID iederas attēlā
Uzņēmuma identifikācija ir dabisks uzdevums servera pusei. Pārlūkprogrammai ir jāveic tikai ļoti mazs pieprasījums uz pirmās puses galapunktu jūsu pašu domēnā. Šis galapunkts darbojas malā (parasti <20 ms Eiropā), privāti veic IP-uz-uzņēmumu atšifrēšanu un neko neatgriež, kas atklātu, kas notika klienta pusē. Lietotāja pieredze nemainās. Bloķētāju ainava tiek apieta. Datu portāls paliek jūsu pārvaldītajās robežās.
Tas nav triks. Tā ir loģiska sekas tam, ka jautājums "kas ir šis apmeklētājs" tiek pārvietots no klienta uz pakalpojumu, ko jūs pārvaldāt. Nekas nemainās apmeklētāja pārlūkošanas uzvedībā; mainās jūsu spēja redzēt atbildi.
Kas nav servera puse
Servera puses izsekošana nav veids, kā apiet piekrišanu. Ja apstrādes darbībai ir nepieciešama piekrišana, tā paliek tāda, neatkarīgi no tā, kur darbojas kods. Ko servera puse maina, ir datu zuduma apjoms un kontrole — nevis juridiskais pamats.
Piezīme par veiktspēju
Cilvēki bieži baidās, ka "izsekošana" padara lapu lēnu. Mūsdienu iestatījumos tās ir pagātnes bailes. Labi uzbūvēts ielādētājs ir tikai daži kilobaiti, tiek ielādēts ar aizkavēšanos un aktivizējas tikai pēc tam, kad lapa ir interaktīva; labi uzbūvēts servera galapunkts atbild dažu milisekunžu laikā no tuvākās malas. Neviens no tiem nepasliktinās jūsu Core Web Vitals. Kas tos pasliktina, ir tagu pārvaldnieks ar četrpadsmit trešo pušu skriptiem, ko neviens nav pārbaudījis trīs gadu laikā. Mazāk, labāk kontrolēti datu ceļi gandrīz vienmēr ir ātrāki.
Kad klienta puse joprojām uzvar
Klienta puse nav nepareiza. Mazāk kritiskiem analītikas datiem, kur jūs pieņemat datu zudumu bloķētāju dēļ (produktu lietošanas paraugi, lietotnes UX notikumi, vienkārši mērķlapu testi), klienta puse ir ātrāk ieviešama un lētāka lietošanā. Jautājums nav par to, ka viena pieeja ir universāli labāka; jautājums ir par to, ka, ja jūsu darbs ir atkarīgs no datiem — B2B cauruļvads ir labs piemērs — servera puses ceļš ir izturīgāks un godīgāks par to, ko tas dara.
Pareizais jautājums nav "kura ir labākā?" Tas ir "kādam lēmumam šie dati kalpo, un cik lielu datu zudumu šis lēmums var paciest?" Uz jautājumu "kurš mūs apmeklēja šonedēļ" — ideālā gadījumā bez zudumiem. Atbilde uz arhitektūru izriet no tā.
Published by
lead.box Team
Vairāk rakstu
Skatiet lead.box darbībā uz savas datplūsmas
Sāciet bez maksas — bez kartes un bez pārdošanas zvana. Vai rezervējiet 20 minūšu demonstrāciju, ja vēlaties apskati ar gidu.