Il dibattito tra "server-side e client-side" è da anni uno di quegli argomenti in cui la risposta è sinceramente "dipende", e questo non piace a nessuno. Ecco la versione in linguaggio semplice, senza discorsi di vendita, e con una tabella onesta da inviare al tuo CTO.
Cosa sono in realtà
Il tracking client-side gira nel browser del visitatore. Un piccolo script viene eseguito, legge cosa è successo (visualizzazione pagina, clic, profondità di scrolling) e invia queste informazioni direttamente a un endpoint di raccolta. Il tracking server-side gira sulla tua infrastruttura. Il browser invia dati minimi al tuo server (o a un edge worker leggero), che decide poi cosa trasmettere e dove.
Nessuno dei due è intrinsecamente più "rispettoso della privacy" o più "accurato" dell'altro. Entrambi possono esserlo, a seconda di come sono configurati. Ciò che cambia è dove si trova il punto di controllo — e quanta parte della verità ti raggiunge.
La tabella dei compromessi onesti
| Dimensione | Client-side | Server-side |
|---|---|---|
| Sforzo di configurazione | Basso — basta incollare uno snippet | Maggiore — un servizio e un piccolo livello di routing |
| Resilienza agli Ad-blocker | Debole — lo script viene bloccato alla fonte | Forte — endpoint di prima parte sul proprio dominio |
| Perdita dati sui browser moderni | Significativa (Safari ITP, blocker, modalità protezione) | Minima — sei tu il proprietario della superficie |
| Latenza al first paint | Aggiunge una richiesta di terze parti | Non aggiunge nulla se il collector è in edge-cache |
| Controllo sui dati in uscita | Tutto ciò che decide lo script del vendor | Tutto ciò che decidi tu |
| Facilità di debugging | Tab network dei DevTools | Log del server — competenza diversa, ma più completa |
| Costo su scala | Basso, finché il vendor non cambia tier | Piccoli costi di edge / function visibili direttamente |
| Identificazione B2B a livello aziendale | Funziona ma è fragile | Ideale — il server può risolvere IP → azienda privatamente |
L'ultima riga è quella su cui i team B2B dovrebbero riflettere più a lungo. L'identificazione client-side dipende da uno script che una quota crescente di visitatori blocca del tutto o depotenzia aggressivamente. Il server-side sposta la logica di identificazione sulla tua infrastruttura, dove non può essere disattivata silenziosamente da un aggiornamento del browser.
Dove si inserisce l'identificazione aziendale
L'identificazione a livello aziendale è un carico di lavoro naturale per il server-side. Il browser deve solo effettuare una richiesta molto piccola a un endpoint di prima parte sul tuo dominio. Quel endpoint gira sull'edge (tipicamente <20 ms in Europa), esegue la risoluzione da IP ad azienda privatamente e non restituisce nulla che riveli cosa sia successo al client. L'esperienza utente rimane invariata. Il panorama dei blocker viene aggirato. Il percorso dei dati rimane all'interno di un perimetro che controlli.
Non è un trucco. È una conseguenza diretta dello spostamento della domanda "chi è questo visitatore" dal client a un servizio gestito da te. Nulla della navigazione del visitatore viene alterato; cambia la tua capacità di vedere la risposta.
Cosa non è il server-side
Il tracking server-side non è un modo per eludere il consenso. Se un'attività di trattamento richiede il consenso, lo richiede indipendentemente da dove gira il codice. Ciò che il server-side cambia è la perdita di dati e il controllo — non la base giuridica.
Una nota sulle prestazioni
Spesso si teme che il "tracking" sia ciò che rallenta una pagina. Nelle configurazioni moderne, questo è un timore superato. Un loader ben costruito pesa pochi kilobyte, è differito e viene attivato dopo che la pagina è interattiva; un endpoint server ben costruito risponde in pochi millisecondi dall'edge più vicino. Nessuno dei due rovinerà i tuoi Core Web Vitals. Ciò che li rovina è il tag manager con quattordici script di terze parti che nessuno controlla da tre anni. Percorsi di dati meno numerosi e meglio controllati sono quasi sempre più veloci.
Quando vince ancora il client-side
Il client-side non è sbagliato. Per analisi a basso rischio dove si accetta già la perdita di dati dovuta ai blocker (campionamento dell'utilizzo del prodotto, eventi UX in-app, test rapidi sulle landing page), il client-side è più veloce da implementare e più economico da gestire. Il punto non è che un approccio sia universalmente migliore; è che se il tuo lavoro dipende dai dati — e la pipeline B2B ne è un esempio perfetto — il percorso server-side è più resiliente e più onesto su ciò che sta facendo.
La domanda corretta non è "quale sia il migliore?". È "quale decisione devono alimentare questi dati e quanta perdita di dati può tollerare tale decisione?". Per capire "chi ci ha visitato questa settimana", idealmente, nessuna perdita. E la risposta sull'architettura segue di conseguenza.
Pubblicato da
lead.box Team
Altri articoli
Veda lead.box in azione sul Suo traffico
Inizi gratuitamente — nessuna carta, nessuna chiamata di vendita richiesta. Oppure prenoti una panoramica di 20 minuti per un tour guidato.