Tracciamento server-side: quando conviene e quando no

Da qualche anno il tracciamento server-side è presentato come la soluzione a quasi tutti i problemi della misurazione: dati persi per i blocchi dei browser, pixel che non registrano le conversioni, siti appesantiti da decine di script, perfino il consenso privacy. Una parte di queste promesse è vera, una parte è esagerata, e una è proprio sbagliata.

Qui spieghiamo cos’è in pratica il tracciamento server-side con Google Tag Manager, cosa risolve davvero, cosa non risolve, quanto costa tenerlo in piedi, e come decidiamo se proporlo a un’azienda o no.

Come funziona il tracciamento “classico”

Nella configurazione più diffusa, sul sito è installato un contenitore web di Google Tag Manager. Quando una persona visita una pagina o invia un modulo, il browser carica i tag configurati (Google Analytics 4, Google Ads, il pixel di Meta, magari LinkedIn e TikTok) e ognuno invia i dati direttamente ai server della sua piattaforma.

Il risultato è che il browser dell’utente parla con molti servizi esterni diversi, ognuno con il suo script, i suoi cookie e le sue richieste. Chi gestisce il sito decide quali tag caricare, ma una volta caricati non controlla nel dettaglio cosa inviano.

Cosa cambia con Google Tag Manager server-side

Con il tracciamento server-side si aggiunge un passaggio. Il sito invia i dati a un contenitore server, un ambiente di Google Tag Manager che gira su un server gestito dall’azienda (o da chi lavora per lei), di solito su un sottodominio del sito come una ipotetica *misure.nomeazienda.it*. È il contenitore server a ricevere gli eventi e a smistarli verso GA4, Google Ads, Meta e le altre piattaforme.

La documentazione di Google sul tagging lato server lo descrive così: il contenitore gira in un progetto Google Cloud o in un altro ambiente scelto da chi lo installa, i dati restano accessibili solo a chi lo gestisce finché non decide di inoltrarli, e si può stabilire come trasformarli e dove inviarli. Il contenitore web sul sito non sparisce: resta, ma invece di parlare con dieci servizi diversi parla soprattutto con il proprio server.

Cosa risolve

Più controllo sui dati che escono

È il vantaggio principale, e il più sottovalutato. Nel contenitore server si può decidere campo per campo cosa inoltrare a ogni piattaforma: togliere l’indirizzo IP, eliminare parametri dagli URL che contengono dati personali (succede più spesso di quanto si pensi, con email o nomi finiti nei link dei moduli), inviare a un servizio solo gli eventi che gli servono. In una configurazione solo browser questo controllo è molto più limitato.

Contesto first-party

Le richieste partono verso un dominio dell’azienda, non verso decine di domini di terze parti, e i cookie possono essere impostati dal server sul proprio dominio. In pratica le misure tendono a essere più stabili, perché alcune limitazioni dei browser e dei blocchi di annunci colpiscono meno le richieste verso il proprio dominio. Non è però una garanzia di dati completi: è un miglioramento, di entità variabile da sito a sito.

Prestazioni del sito

Se una parte dei tag passa dal browser al server, nel sito si caricano meno script di terze parti. Su siti con molti pixel e strumenti di marketing la differenza sulle prestazioni può essere visibile. Su un sito con GA4 e poco altro, invece, il guadagno è piccolo.

Conversioni inviate da server alle piattaforme

Il contenitore server è uno dei modi più comodi per inviare eventi alle API delle piattaforme pubblicitarie, a cominciare dalla Conversions API di Meta, di cui abbiamo parlato a maggio. Lo stesso evento (un acquisto, un contatto) può essere inviato sia dal browser sia dal server, con un identificativo comune per evitare che venga contato due volte. Lo stesso approccio vale per le conversioni avanzate di Google Ads, che usano dati forniti dall’utente come l’email, trattati con hashing.

Cosa non risolve

Non aggira il consenso

Questo va detto chiaramente, perché è l’equivoco più pericoloso. Il tracciamento server-side non è un modo per misurare chi ha rifiutato i cookie. Il GDPR e le regole sui cookie si applicano al trattamento dei dati, non alla tecnologia con cui vengono inviati: se per un certo trattamento serve il consenso, serve anche quando i dati passano da un server.

Anche Google lo imposta così. La guida all’uso del Consent Mode con Tag Manager lato server richiede un banner o una piattaforma di gestione del consenso sul sito, compatibile con il Consent Mode: il consenso si raccoglie nel contenitore web, viaggia con ogni richiesta verso il server, e i tag Google nel contenitore server si comportano di conseguenza. Per i tag di altre piattaforme, come Meta, il rispetto del consenso va configurato a mano. Su come funziona il Consent Mode rimandiamo a che cos’è il Consent Mode V2 e alla differenza tra Consent Mode e Consent Mode V2.

Diffidiamo di chi propone il server-side come modo per “recuperare” i dati di chi non ha dato il consenso: è un rischio legale che ricade sull’azienda, non su chi ha fatto l’installazione.

Non sistema un tracciamento sbagliato

Se gli eventi sono definiti male, se le conversioni contano cose diverse da quelle che interessano o se GA4 è installato in modo incompleto, spostare tutto su un server sposta anche gli errori. Il server-side viene dopo una misurazione di base fatta bene, a partire da un’installazione di GA4 corretta e da conversioni verificate.

Non è “installa e dimentica”

Un contenitore server è un pezzo di infrastruttura. Va aggiornato, monitorato, controllato quando cambiano le piattaforme o il sito. Se si ferma, si fermano le misure, e spesso nessuno se ne accorge per giorni.

Quanto costa

I costi sono di due tipi.

L’hosting. Il contenitore server deve girare da qualche parte. Google consiglia Cloud Run e, nella sua guida all’installazione su Cloud Run, indica per un ambiente di produzione almeno due istanze, per ridurre il rischio di perdere dati in caso di problemi, con un costo stimato intorno ai 45 dollari al mese per istanza; il costo sale con il traffico. In alternativa esistono servizi di hosting dedicati al contenitore server, con piani mensili che dipendono dal numero di richieste. Per un sito di una PMI si parla in genere di qualche decina di euro al mese fino a qualche centinaio per i siti con molto traffico.

Il lavoro. Configurare il contenitore, il sottodominio, i tag lato server, la deduplica degli eventi e i controlli sul consenso richiede competenze specifiche. A questo si aggiunge la manutenzione: aggiornamenti, verifiche periodiche, interventi quando una piattaforma cambia qualcosa. È questa voce, più dell’hosting, a fare la differenza nel budget.

Quando conviene a una PMI

Nei progetti che seguiamo lo proponiamo quando ci sono più di queste condizioni insieme:

• investimenti pubblicitari significativi, soprattutto su Meta e Google, dove misure più complete migliorano l’ottimizzazione delle campagne e il costo del progetto si ripaga;
• e-commerce o generazione di contatti con conversioni ad alto valore, dove ogni conversione persa pesa;
• molti strumenti di marketing installati sul sito, con un impatto visibile sulle prestazioni;
• esigenze di controllo sui dati, per settori sensibili o per una politica interna sulla privacy che chiede di sapere esattamente cosa esce dal sito;
• qualcuno che lo mantenga, interno o in agenzia.

Quando non conviene

• Sito vetrina con poco traffico e nessuna campagna attiva: il costo fisso non si ripaga.
• Misurazione di base ancora da sistemare: prima si mette in ordine quella.
• Budget pubblicitario contenuto e su una sola piattaforma: spesso bastano le conversioni avanzate e un Consent Mode configurato bene.
• Nessuno che possa seguirlo nel tempo: un contenitore server abbandonato è peggio di un buon tracciamento solo browser.

Il nostro approccio

Il tracciamento server-side è uno strumento utile, non un livello obbligatorio. Quando lavoriamo sui tracciamenti di un’azienda partiamo sempre dalla fotografia di quello che c’è: quali dati servono, quali si stanno raccogliendo, con quale consenso, con quali errori. Solo dopo decidiamo se il passaggio al server porta un beneficio che giustifica costi e manutenzione.

Se state valutando il server-side perché qualcuno vi ha promesso “più dati”, la prima domanda da fare è quali dati, e con quale consenso.