Tagging lato server e consenso: cosa cambia e cosa no

Il tagging lato server sposta i tag dei fornitori dal browser del visitatore a un server sotto il tuo controllo: la pagina invia gli eventi al tuo endpoint e il tuo server li inoltra alle piattaforme di analisi e pubblicitarie. Questo può migliorare le prestazioni e il controllo sui dati, ma non elimina gli obblighi di consenso. Cookie e identificativi restano sul dispositivo del visitatore, e i dati personali continuano a raggiungere i fornitori.

Che cos’è il tagging lato server?

È una configurazione in cui la pagina invia un unico flusso di eventi a un server di tagging, ed è quel server, anziché il browser, a chiamare ciascun fornitore. Il server di solito risiede su un sottodominio del tuo sito, come metrics.example.com.

I container lato server di Google Tag Manager sono un esempio noto, ma lo stesso schema funziona con una edge function o con una piccola API scritta da te. In una classica configurazione lato client, lo script di ogni fornitore viene eseguito nel browser del visitatore e decide che cosa raccogliere. In una configurazione lato server, il browser carica meno codice dei fornitori, e i fornitori ricevono ciò che il tuo server sceglie di inviare.

Che cosa cambia quando sposti i tag sul server?

Soprattutto le prestazioni e il controllo. I vantaggi tipici:

• Meno codice nel browser. Meno script dei fornitori significa meno JavaScript da scaricare ed eseguire, a vantaggio del caricamento e della reattività.
• Un punto in cui ripulire i dati. Il tuo server può esaminare ogni evento prima di inoltrarlo: eliminare o troncare gli indirizzi IP, rimuovere i parametri URL che possono contenere indirizzi email ed eliminare i campi di cui un fornitore non ha bisogno.
• Una gestione diversa dei cookie. Il tuo server può impostare cookie di prima parte tramite header HTTP Set-Cookie anziché tramite JavaScript. In alcuni casi i browser trattano diversamente i cookie impostati da script e quelli impostati dal server, e queste regole cambiano di continuo, quindi non fare affidamento su una durata specifica dei cookie.
• Meno connessioni dirette con terze parti. Il browser del visitatore comunica con il tuo dominio anziché con ciascun fornitore.

Che cosa non cambia?

L’analisi giuridica. La direttiva ePrivacy e il Regolamento generale sulla protezione dei dati (GDPR) guardano a ciò che accade sul dispositivo e a ciò che accade ai dati personali, non a quale server si trovi nel mezzo.

Domanda	Tagging lato client	Tagging lato server
Gli identificativi vengono archiviati sul dispositivo del visitatore?	Sì, impostati dagli script dei fornitori	Di solito sì, impostati dal tuo dominio
Il consenso ePrivacy si applica all’archiviazione e all’accesso non essenziali?	Sì	Sì
I dati personali raggiungono i fornitori?	Sì, dal browser	Sì, dal tuo server
Ogni finalità richiede una base giuridica ai sensi del GDPR?	Sì	Sì
I destinatari vanno comunicati ai visitatori?	Sì	Sì
Chi decide che cosa riceve ciascun fornitore?	In gran parte lo script del fornitore	Tu

L’articolo 5, paragrafo 3, della direttiva ePrivacy riguarda l’archiviazione di informazioni sul dispositivo e l’accesso a esse. Se il tuo server imposta un cookie con un identificativo di analisi e lo rilegge a ogni richiesta, si tratta di archiviazione e accesso sul dispositivo, qualunque sia il dominio o il codice che lo fa. L’esenzione dipende dalla finalità, cioè dall’essere strettamente necessario per un servizio richiesto dall’utente, non dal fatto che il cookie sia di prima parte; leggi tipi di cookie.

Il GDPR si applica anche ai dati degli eventi. Identificativi, indirizzi IP e URL di pagina riferibili a una persona sono dati personali, quindi ogni flusso verso un fornitore richiede una base giuridica ai sensi dell’articolo 6 e, se tale base è il consenso, questo deve soddisfare le condizioni dell’articolo 7. Se quello che vuoi davvero è una misurazione senza identificativi, l’analytics senza cookie è un discorso diverso.

Come passo il consenso al server?

Invia lo stato del consenso con ogni evento, applicalo sul server e tratta qualsiasi valore mancante come negato. Il server deve decidere per ogni destinazione, perché un singolo evento in ingresso può essere distribuito a più fornitori con finalità diverse.

Sul client, non inviare nulla senza consenso e includi lo stato nel payload:

type ConsentState = { analytics: boolean; marketing: boolean };

export function track(event: string, props: Record<string, unknown>, consent: ConsentState) {
  if (!consent.analytics && !consent.marketing) return; // non si può inviare nulla
  navigator.sendBeacon(
    'https://metrics.example.com/collect',
    JSON.stringify({ event, props, consent, ts: Date.now() }),
  );
}

Sul server, inoltra a ciascuna destinazione solo ciò che la sua categoria consente:

export async function handleCollect(req: Request): Promise<Response> {
  const body = await req.json().catch(() => null);
  const analytics = body?.consent?.analytics === true; // mancante significa negato
  const marketing = body?.consent?.marketing === true;
  if (!analytics && !marketing) return new Response(null, { status: 204 });

  const event = minimize(body); // elimina gli IP, rimuove le query string e i campi inutilizzati
  const jobs: Promise<unknown>[] = [];
  if (analytics) jobs.push(sendToAnalytics(event));
  if (marketing) jobs.push(sendToAdPlatform(event));
  await Promise.allSettled(jobs);

  return new Response(null, { status: 204 });
}

Se usi i tag Google con Consent Mode, lo stato del consenso viaggia con le richieste inviate dai tag, e Google documenta il comportamento dei suoi tag con ciascun segnale. Verifica che ogni tag del tuo container lato server, in particolare i modelli di terze parti, rispetti davvero quello stato, invece di darlo per scontato. La nostra guida a Google Consent Mode v2 illustra i quattro segnali.

Che cosa deve fare il mio server con i dati?

Tratta il server di tagging come un sistema di trattamento dei dati con regole proprie, non come un semplice tubo:

1. Nega per impostazione predefinita. Scarta gli eventi con campi di consenso mancanti o non validi.
2. Instrada in base alla finalità. Invia ai fornitori di analisi solo gli eventi con consenso all’analisi e ai fornitori pubblicitari solo quelli con consenso al marketing.
3. Minimizza prima di inoltrare. Tronca o rimuovi gli indirizzi IP, elimina query string e frammenti e invia a ciascun fornitore solo i campi di cui ha bisogno.
4. Limita la conservazione. Anche i log grezzi degli eventi sul tuo server sono dati personali. Imposta tempi di conservazione brevi e limita gli accessi.
5. Documenta ogni flusso. Elenca ciascun fornitore, i dati che riceve e la finalità nella tua informativa privacy e nella cookie policy, perché i visitatori non possono più vedere questi flussi nel browser.
6. Verifica entrambi i lati. Gli scanner basati sul browser non vedono il traffico da server a server, quindi affianca a un audit dei cookie periodico una revisione dei tag e delle destinazioni del tuo container lato server.

In sintesi

Il tagging lato server cambia il luogo in cui vengono eseguiti i tag e ti dà più controllo su ciò che ricevono i fornitori. Non cambia quando ti serve il consenso, che cosa costituisce un dato personale né che cosa devi comunicare. Rendi il consenso parte di ogni evento, applicalo sul server e minimizza ciò che ne esce. Strumenti come Cookiesh possono fornire lo stato del consenso di cui hanno bisogno i tuoi tag e il tuo server, grazie al supporto a Google Consent Mode v2, a un modello per Google Tag Manager e a un’API JavaScript.

Questo articolo ha carattere puramente informativo e non costituisce consulenza legale. Per decisioni relative alla tua situazione specifica, rivolgiti a un professionista qualificato in materia di privacy.