Tracciamento server-side vs client-side

Qual è la differenza, in una riga?

Il tracciamento client-side vede il contesto; quello server-side vede la verità. Il browser conosce i parametri UTM, il referrer, il dispositivo e la pagina, e perde eventi a causa dei blocker. Il tuo back end sa cosa è successo davvero (un abbonamento attivato, un pagamento non riuscito) e non sa nulla di come l’utente ci è arrivato. Questa guida spiega dove strumentare. Per cosa tracciare, i nomi e l’elenco degli eventi di partenza, leggi il piano di tracciamento degli eventi per startup; per capire perché i dati dovrebbero essere first-party, leggi dati first-party e tracciamento. Entrambe le metà stanno in un unico piano di tracciamento.

Cosa vede il tracciamento client-side, e cosa perde?

Il contesto vive sul lato client. L’SDK nel browser cattura i parametri UTM, il referrer, la pagina di atterraggio, il dispositivo e il comportamento nella sessione: tutto ciò che serve all’attribuzione e all’analisi del funnel. Quello che perde sono utenti interi: secondo i dati GWI aggregati da Backlinko, il 29,5% degli utenti di internet nel mondo ha usato un ad blocker almeno ogni tanto nel secondo trimestre 2025, circa 1,77 miliardi di persone. Molti blocker fermano gli script di analisi insieme alla pubblicità, quindi una quota misurabile dei tuoi eventi client-side non viene mai inviata.

Anche senza blocker, Safari rende il tracciamento client-side lacunoso. Secondo la documentazione ITP di WebKit, Safari limita a sette giorni la scadenza dei cookie impostati via JavaScript ed elimina tutto il resto dello storage scrivibile dagli script (localStorage, IndexedDB) dopo sette giorni di uso di Safari senza interazioni con il tuo sito. Trascorsa quella finestra di sette giorni di uso, un visitatore che torna sembra del tutto nuovo e l’identità si rompe. La perdita è misurabile: quando Plausible ha confrontato i propri conteggi con quelli di Google Analytics su un sito in tendenza su Hacker News e Reddit, in un test di fine agosto 2021, Google Analytics ha perso il 58,67% dei visitatori. È un caso estremo, con un pubblico molto tecnico; Plausible cita ricerche precedenti che collocano il blocco sotto il 10% sui siti lifestyle e sopra il 25% su quelli dedicati alla tecnologia.

Cosa vede il tracciamento server-side, e cosa perde?

Il tracciamento server-side è il tuo back end che comunica i cambi di stato all’API degli eventi: subscription_started, payment_failed, plan_changed. Questi eventi avvengono sui tuoi server, non nel browser: registrarli lì non è un espediente, è la fonte onesta. Nessun blocker si mette in mezzo, nessun limite di storage li fa scadere, e il conteggio corrisponde al tuo database perché viene dal tuo database. Un evento server-side fa fede perché registra ciò che il tuo sistema ha fatto, non ciò che un browser è riuscito a comunicare. Il punto cieco è il contesto: il tuo back end non ha idea di quale campagna, referrer o dispositivo abbia portato l’utente, perché quel contesto è esistito solo lato client.

Client o server: quali eventi vanno dove?

Come dovrebbe dividerli un piccolo team?

• Tutto ciò che riguarda il denaro (prove, abbonamenti, pagamenti, rimborsi) va lato server. Quando churn o MRR devono essere esatti, la fonte di verità è il server.
• Tutto ciò che riguarda l’attribuzione (visualizzazioni di pagina, campagne, referrer) resta lato client. Quel contesto non si può ricostruire dopo.
• Identifica l’utente su entrambe le strade con lo stesso ID, così i funnel si ricompongono e i test A/B con poco traffico assegnano ogni utente a una sola variante su tutti i dispositivi.
• Accetta lo scarto. I conteggi client sono bassi per natura; usali per capire la direzione, e gli eventi server per tutto ciò che riporti.

Perché i due numeri non coincidono mai?

Se usi entrambi, i conteggi non coincideranno mai, e la differenza resterà. Il numero client è basso perché blocker e ITP si mangiano eventi; al numero server manca il contesto per dire da dove arrivano gli utenti. Non è un bug da correggere ma una proprietà da riconoscere: aspettati uno scarto permanente tra l’analisi lato client e la verità lato server, conosci la sua dimensione approssimativa per il tuo pubblico e smetti di inseguirlo. Riporta ogni numero dal suo lato onesto: attribuzione e direzione del funnel dai dati client; tutto ciò che finisce in una presentazione per gli investitori o in una fattura, come il tasso di churn, l’MRR e gli abbonamenti attivi, calcolato dagli eventi server. Le piattaforme di engagement come Iterable e Ortto accettano entrambe le fonti per lo stesso motivo.

Come lo gestisce fromHello?

fromHello tratta la divisione come impostazione predefinita. L’SDK JS/TS traccia lato client e mantiene una coda offline basata su localStorage: gli eventi inviati durante una perdita di connessione restano salvati e vengono rinviati quando il browser torna online. La stessa API degli eventi accetta invii lato server, così subscription_started arriva direttamente dal tuo back end con una chiave API. Entrambe le strade scrivono su un unico profilo: l’attribuzione catturata dall’SDK e gli eventi di ricavo inviati dal tuo server descrivono la stessa persona. Segmenti, percorsi e analisi leggono da quell’unico profilo: dividi la strumentazione, non l’identità.