Misurare è indispensabile: senza analytics non si sa da dove arrivano i visitatori, cosa fanno, quali campagne funzionano e dove il percorso d’acquisto si interrompe. Ma gli strumenti di misura non sono gratuiti per chi visita il sito. Ogni script di analisi, ogni pixel pubblicitario, ogni strumento di registrazione delle sessioni aggiunge codice da scaricare ed eseguire, connessioni verso altri domini e lavoro sul processore del dispositivo. Su molti siti, la somma di questi strumenti pesa più del sito stesso.
Il paradosso è evidente: gli strumenti con cui si cerca di capire perché gli utenti abbandonano possono essere una delle ragioni per cui abbandonano. In questo articolo vediamo quanto costa davvero il tracciamento, come governare un tag manager, cosa cambia con il tracciamento lato server, quando hanno senso gli strumenti di analisi più leggeri e come misurare l’impatto degli strumenti di misura.
Il costo del tracciamento
Uno script di analytics moderno pesa diverse decine di kilobyte compressi, spesso oltre cento, e il suo costo non si esaurisce nel download: va analizzato ed eseguito, registra gestori per gli eventi della pagina, invia richieste di rete a ogni interazione significativa. Moltiplicato per il numero di strumenti presenti, analytics, pubblicità, pixel dei social, mappe di calore, test A/B, il totale raggiunge facilmente il mezzo megabyte di JavaScript, come abbiamo visto nell’articolo sugli script di terze parti.
L’effetto sulle Core Web Vitals è di due tipi. Durante il caricamento, gli script competono per la banda e per il main thread con le risorse della pagina, e possono ritardare l’LCP. Dopo il caricamento, molti strumenti ascoltano clic, scorrimenti e movimenti del mouse per registrarli: ogni interazione dell’utente attiva anche il loro codice, e l’INP ne risente. Gli strumenti di registrazione delle sessioni, che ricostruiscono ogni cambiamento della pagina, sono in genere i più pesanti da questo punto di vista.
Governare il tag manager
Il tag manager è lo strumento che permette al marketing di aggiungere e modificare i codici di tracciamento senza passare dagli sviluppatori. È comodo, ed è per questo che spesso diventa il punto in cui il peso si accumula: tag aggiunti per una campagna e mai rimossi, strumenti provati per un mese e dimenticati, lo stesso strumento installato due volte, una nel tag manager e una da un plugin del CMS.
Una revisione periodica del contenitore riporta ordine. Per ogni tag conviene sapere chi l’ha chiesto, a cosa serve, se i dati che raccoglie vengono davvero usati e fino a quando serve. I tag senza risposta a queste domande possono essere sospesi e, dopo qualche settimana senza che nessuno ne senta la mancanza, eliminati. Anche la configurazione conta: molti tag possono essere attivati quando la pagina ha finito di caricarsi, o dopo qualche secondo, invece che all’inizio, senza perdere dati significativi.
- Analytics principale: al caricamento, perché serve a misurare anche chi abbandona subito.
- Pixel pubblicitari di conversione: sulle pagine di conversione, non su tutte le pagine se non servono al remarketing.
- Mappe di calore e registrazioni: solo su una percentuale delle sessioni e sulle pagine in analisi, per il periodo necessario.
- Chat e widget: alla prima interazione o dopo alcuni secondi, come nella tecnica del delay del JavaScript.
I test A/B e lo schermo bianco
Un caso particolare merita attenzione: gli strumenti di test A/B che modificano la pagina nel browser. Per evitare che l’utente veda la versione originale per un istante prima della variante, molti suggeriscono un frammento di codice che nasconde tutta la pagina finché lo script del test non si è caricato e ha applicato le modifiche. Se lo script arriva in ritardo, la pagina resta invisibile, fino a un tempo massimo che può arrivare a qualche secondo. L’effetto sull’LCP è diretto e spesso pesante, e riguarda tutti i visitatori, non solo quelli coinvolti nel test. Le alternative sono limitare il frammento alle sole pagine in test, ridurre il tempo massimo, o eseguire i test lato server, dove la variante viene decisa prima di inviare la pagina.
Il tracciamento lato server
Il tracciamento lato server sposta una parte del lavoro dal browser a un server controllato dal sito. Invece di caricare nel browser gli script di ogni fornitore, la pagina invia gli eventi a un unico punto, di solito un sottodominio del sito, dove un contenitore lato server li riceve, li elabora e li inoltra ai diversi servizi di analisi e pubblicità.
I vantaggi per le prestazioni sono concreti: meno script nel browser, meno connessioni verso domini esterni, meno lavoro sul dispositivo dell’utente. Ci sono anche vantaggi di controllo, perché il sito decide quali dati inoltrare a ciascun fornitore. I costi sono l’infrastruttura del server di tracciamento, da ospitare e mantenere, e una configurazione più complessa. Soprattutto, il tracciamento lato server non è un modo per aggirare il consenso: le regole sulla privacy si applicano allo stesso modo, e i dati vanno inoltrati solo quando l’utente ha dato il consenso per quella finalità, come spiegato nell’articolo sui consent banner.
Gli strumenti di analytics leggeri
Per molti siti, soprattutto quelli editoriali, aziendali e di servizi, le esigenze di misura sono semplici: visite, pagine più viste, sorgenti di traffico, qualche obiettivo di conversione. Per questi casi esistono strumenti di analytics progettati per essere leggeri e rispettosi della privacy, con script di pochi kilobyte, spesso senza cookie, alcuni ospitabili sui propri server. Offrono meno funzioni degli strumenti più diffusi, ma per molti siti sono sufficienti, e semplificano anche la gestione del consenso.
La scelta non deve essere radicale. Molti siti mantengono lo strumento principale per le esigenze di marketing e pubblicità, alleggerendone la configurazione, e affiancano misure proprie, come un sistema di Real User Monitoring, per le prestazioni. Il criterio è sempre lo stesso: ogni dato raccolto deve valere il costo che impone ai visitatori.
Le interazioni e l’INP
Il tracciamento degli eventi, come clic sui pulsanti, invii dei moduli, scorrimento della pagina, aggiunge lavoro a ogni interazione. Alcune accortezze ne limitano l’impatto. L’invio dei dati dovrebbe avvenire con metodi non bloccanti, come navigator.sendBeacon, e dopo che l’interfaccia ha risposto all’utente. Gli eventi molto frequenti, come lo scorrimento, andrebbero raggruppati invece che inviati uno per uno. E i tracciamenti automatici che ascoltano tutti i clic della pagina vanno attivati solo se i dati servono davvero.
pulsante.addEventListener( 'click', () => {
aggiornaInterfaccia(); // 1. prima la risposta all’utente
requestAnimationFrame( () => setTimeout( () => {
navigator.sendBeacon( '/eventi', JSON.stringify( { evento: 'aggiunta_carrello' } ) );
}, 0 ) ); // 2. poi il tracciamento, dopo il disegno
} );Anche il momento in cui lo script principale di analytics viene caricato merita attenzione. Inserirlo in modo asincrono, dopo le risorse critiche e senza anticiparlo con un preload che lo metterebbe in competizione con il CSS e l’immagine principale, permette di misurare quasi tutte le visite senza incidere sul primo disegno. Le poche visite che si chiudono prima che lo script parta sono, di norma, un prezzo accettabile rispetto al beneficio per tutte le altre.
Il caso WordPress
Sui siti WordPress il tracciamento arriva spesso da più fonti contemporaneamente: un plugin per gli analytics, il tag manager inserito dal tema, un plugin di pubblicità con il proprio pixel, un plugin di e-commerce che aggiunge i propri eventi. Il primo passo è fare l’inventario, guardando nel pannello Network dei DevTools tutte le richieste verso domini di analisi e pubblicità, e risalendo a chi le genera. Duplicati e strumenti dimenticati sono molto frequenti. Il secondo è centralizzare: un solo punto di inserimento, di solito il tag manager, invece di codici sparsi tra tema e plugin.
Misurare il costo degli strumenti di misura
Il costo del tracciamento si misura confrontando la pagina con e senza gli script. Nei DevTools di Chrome si possono bloccare singoli domini dal pannello Network e ripetere il caricamento; strumenti come WebPageTest permettono di fare lo stesso in modo ripetibile, confrontando LCP, Total Blocking Time e peso della pagina. Il pannello Performance, durante un’interazione, mostra quanta parte del lavoro è dovuta agli script di tracciamento. Sul campo, il confronto delle metriche prima e dopo la rimozione o il differimento di un tag, per esempio con i dati giornalieri di un sistema di monitoraggio, dà la misura più affidabile.
Una politica per i nuovi tag
Pulire il tag manager una volta è utile; evitare che si riempia di nuovo è più importante. Alcune regole semplici, concordate tra marketing e sviluppo, funzionano bene. Ogni nuovo tag ha un responsabile, uno scopo scritto e una data di revisione. Prima dell’attivazione viene misurato il suo peso e il suo effetto su una pagina di prova. I tag temporanei, come quelli delle campagne, hanno una data di scadenza. E il numero complessivo di strumenti attivi rientra in un limite concordato, come in un budget di prestazioni: per aggiungerne uno, se ne valuta un altro da togliere. Non servono procedure complesse, ma una tabella condivisa e l’abitudine di consultarla.
Meno strumenti, dati migliori
C’è un beneficio collaterale che spesso sorprende: ridurre gli strumenti migliora anche la qualità dei dati. Due strumenti di analytics che misurano la stessa cosa danno numeri diversi e alimentano discussioni inutili; tag duplicati gonfiano le conversioni; script che si caricano tardi perdono le visite più brevi, quelle di chi abbandona subito. Una configurazione essenziale, ben documentata, produce numeri più coerenti e più facili da interpretare, e libera tempo per analizzare i dati invece di riconciliarli.
Un esempio
Un sito di formazione online ha un tag manager con 34 tag attivi, raccolti in cinque anni di campagne. L’inventario rivela lo strumento di analytics installato due volte, sei pixel di piattaforme pubblicitarie non più usate, uno strumento di mappe di calore attivo su tutte le pagine e tutte le sessioni, e un frammento di test A/B che nasconde la pagina fino a quattro secondi, anche se nessun test è in corso da mesi. Dopo la pulizia restano 11 tag: l’analytics principale al caricamento, i pixel delle campagne attive solo sulle pagine di iscrizione, le mappe di calore sul dieci per cento delle sessioni e solo sulle pagine dei corsi, la chat alla prima interazione. Il JavaScript di terze parti si riduce di due terzi, l’LCP da mobile migliora di quasi un secondo grazie alla rimozione del frammento del test A/B, e i numeri delle conversioni, prima gonfiati dai tag duplicati, tornano coerenti con quelli del gestionale.
In sintesi
Analytics, pixel e strumenti di analisi del comportamento sono necessari, ma pesano sul caricamento e sulle interazioni, spesso più del sito stesso. Governarli significa fare l’inventario dei tag, eliminare quelli inutilizzati e i duplicati, attivare al momento giusto quelli che non servono subito, limitare mappe di calore e registrazioni a una parte delle sessioni, evitare che i test A/B nascondano la pagina.
Il tracciamento lato server riduce il lavoro nel browser, a costo di un’infrastruttura in più e senza cambiare gli obblighi di consenso; gli strumenti di analytics leggeri sono una scelta sensata per molti siti con esigenze semplici. In ogni caso, il costo degli strumenti di misura va misurato a sua volta: solo così si può decidere quali dati valgono il tempo che fanno aspettare ai visitatori.
