Quando apri un sito qualsiasi e il tuo browser scarica, oltre al contenuto della pagina, anche pezzetti di codice provenienti da Google, Meta, LinkedIn, un servizio di chat o una piattaforma di email marketing, quei domini esterni possono installare i propri cookie sul tuo dispositivo. Sono i cookie di terze parti, e sono al centro di due dei problemi più comuni nella conformità di un sito italiano: la sottovalutazione di quanti se ne installano realmente, e l'errata convinzione che siano "responsabilità del fornitore" e non del titolare del sito che li ha inclusi.

Questo articolo spiega cosa sono tecnicamente i cookie di terze parti, in cosa differiscono dai cookie di prima parte, perché la responsabilità della loro installazione ricade comunque sul titolare del sito, e la stretta eccezione in cui alcuni analytics di terze parti possono essere trattati come tecnici.

Un cookie di prima parte viene impostato dal dominio che l'utente sta effettivamente visitando: se sei su iltuosito.it, un cookie impostato da iltuosito.it è di prima parte. Serve tipicamente a funzioni proprie del sito: sessione, preferenze, autenticazione, carrello.

Un cookie di terze parti viene impostato da un dominio diverso da quello che l'utente sta visitando, tipicamente perché la pagina carica una risorsa (uno script, un'immagine, un iframe) ospitata su quel dominio esterno. Se iltuosito.it include il pixel di Meta, il tag di Google Ads, un widget di chat o l'embed di un video di YouTube, ciascuno di questi fornitori può impostare i propri cookie sul browser del visitatore, con dominio proprio, indipendentemente dal fatto che il visitatore non abbia mai visitato direttamente meta.com o google.com in quella sessione.

I cookie di terze parti nascono, nella grande maggioranza dei casi commerciali, per finalità di profilazione: reti pubblicitarie che seguono lo stesso utente su più siti per costruire un profilo di interessi, piattaforme social che collegano la visita al profilo dell'utente loggato, strumenti di analisi che aggregano dati cross-sito per il proprio fornitore. Per definizione, questo è esattamente il tipo di trattamento che l'articolo 122 del Codice Privacy e le linee guida del Garante qualificano come profilazione, quindi soggetto a consenso preventivo, come spieghiamo nel dettaglio nel nostro approfondimento su cookie tecnici vs cookie di profilazione.

Esistono eccezioni legittime di cookie di terze parti che sono davvero tecnici: un fornitore di pagamenti che deve verificare l'autenticità della transazione, un servizio anti-frode, un CDN che serve solo contenuto statico senza tracciare l'identità dell'utente. La differenza non sta nel fatto che il dominio sia "terzo", ma in cosa fa concretamente quel cookie, esattamente lo stesso criterio che si applica ai cookie di prima parte.

Un errore diffuso è pensare che, se il cookie viene tecnicamente impostato dal dominio di Google o di Meta, la responsabilità della conformità sia del fornitore, non del sito che lo ha integrato. Non è così. Il titolare del trattamento è chi decide di includere quello script sul proprio sito e chi raccoglie il consenso (o non lo raccoglie) prima di lasciarlo partire. Se un'ispezione del Garante rileva che il tuo sito trasmetteva dati a Meta prima che l'utente acconsentisse, la contestazione è rivolta al titolare del sito, non a Meta.

Questo vale anche per la corretta informativa: la cookie policy deve elencare ogni fornitore terzo presente, con link alla sua rispettiva informativa sulla privacy quando disponibile, perché l'utente ha diritto di sapere esattamente a chi vengono trasmessi i suoi dati, non solo che "esistono cookie di terze parti". Questo diritto all'informazione è lo stesso che alimenta il portale dei diritti dell'interessato: un utente può chiedere in ogni momento con quali terze parti i suoi dati sono stati condivisi, e il sito deve poter rispondere con precisione, non con una lista generica.

Le linee guida del Garante ammettono che alcuni strumenti di analytics di terze parti possano essere trattati come assimilabili ai cookie tecnici, quindi senza obbligo di consenso preventivo, ma solo a condizioni molto specifiche: il mascheramento di almeno l'ultimo ottetto dell'indirizzo IP (una misura di minimizzazione che introduce un margine di incertezza nell'attribuzione del dato a uno specifico utente pari a circa 1 su 256, ossia circa lo 0,4%), e la garanzia contrattuale che il fornitore terzo non incroci quei dati minimizzati con altre elaborazioni proprie né li trasmetta a soggetti ulteriori.

Questa eccezione è rara nella pratica commerciale per un motivo semplice: la maggior parte dei grandi fornitori di analytics (a partire da Google Analytics 4 nella sua configurazione standard) utilizza quei dati anche per finalità proprie, come il miglioramento dei propri prodotti pubblicitari, il che rompe automaticamente la seconda condizione. Verificarlo richiede leggere i termini di servizio specifici del fornitore, non assumerlo per analogia con altri strumenti.

L'elenco "di cosa dovrebbe esserci" scritto a tavolino raramente corrisponde a quello che il sito installa davvero, perché ogni team che aggiunge uno strumento (marketing con un nuovo pixel, supporto con una chat, prodotto con uno strumento di analisi comportamentale) introduce nuovi domini di terze parti senza necessariamente avvisare chi gestisce la conformità. La mappatura corretta richiede una scansione tecnica del sito, non una checklist statica compilata una volta.

Una piattaforma di gestione del consenso come AdOpt automatizza esattamente questo passaggio: scansiona periodicamente il sito, rileva ogni dominio di terze parti che tenta di impostare cookie o eseguire script, li classifica per categoria e fornitore, e blocca l'esecuzione di quelli non essenziali finché l'utente non presta il consenso specifico per quella categoria.

Non sempre, ma nella grande maggioranza dei casi commerciali sì, perché il motivo per cui un fornitore esterno installa un cookie sul tuo sito è tipicamente costruire o alimentare un profilo dell'utente attraverso più siti. Le eccezioni tecniche legittime (pagamenti, sicurezza) esistono ma sono minoritarie.

I browser moderni limitano sempre di più i cookie di terze parti per impostazione predefinita, ma questo non sostituisce l'obbligo del sito di ottenere consenso: molti fornitori hanno già adottato tecniche alternative di tracciamento (identificatori lato server, fingerprinting) che aggirano il blocco tecnico del browser mantenendo la stessa finalità di profilazione, quindi restano comunque soggetti alla stessa regola del consenso.

Il titolare del sito resta responsabile della propria decisione di includere quel fornitore senza le garanzie adeguate. È buona pratica verificare, prima di integrare un nuovo strumento, se il fornitore offre un accordo sul trattamento dei dati (Data Processing Agreement) e quali garanzie di minimizzazione applica.

La prassi più solida elenca ogni fornitore con la finalità dichiarata, la categoria (tecnico, analytics, profilazione) e un link alla sua informativa sulla privacy quando disponibile. Vedi la nostra guida su cosa deve contenere una cookie policy e, per il documento più ampio che la ospita, il nostro esempio di informativa privacy per siti web.

Serve una scansione tecnica del codice reale della pagina, non un'ispezione visiva del sito: molti script di terze parti sono invisibili all'utente finale ma comunque attivi. È esattamente la funzione di uno scanner automatico come quello integrato in AdOpt.

• Cookie tecnici vs cookie di profilazione: la differenza che decide se serve il consenso
• Banner cookie a norma del Garante: cosa deve avere davvero

Scopri esattamente quali fornitori di terze parti stanno raccogliendo dati sul tuo sito in questo momento. Prova AdOpt gratis e ottieni la mappa completa in pochi minuti.