15' di lettura
Consenso al pixel di tracciamento su Klaviyo
Come si gestisce la revoca del tracciamento aperture su Klaviyo, prima che arrivi la soluzione nativa?
Nicola Severino
Marketing Automation Expert
Per chi legge di corsa
Dal 29 ottobre 2026 il pixel che misura le aperture delle eMail richiede un consenso, e chi lo revoca deve poter continuare a ricevere le eMail.
Klaviyo gestisce questo consenso solo via API: la raccolta nei form e un'azione di flow dedicata arriveranno dopo la scadenza.
Il sistema che racconto qui usa una landing per la scelta, tre flow che coprono ogni situazione (chi sceglie, chi si iscrive, chi riceve eMail senza essersi iscritto) e un ponte esterno che chiama l'API, perché oggi i webhook diretti verso Klaviyo si bloccano.
Serve un account Klaviyo, uno strumento che riceva un webhook e chiami un'API (io uso n8n, ma vanno bene anche Make o Zapier) e testi di consenso aggiornati nei form. Il consenso marketing non viene mai toccato.
Perché questa guida?
Entro il 29 ottobre 2026 chi fa eMail marketing verso destinatari in Italia e ne misura le aperture deve adeguarsi alle linee guida del Garante Privacy sui pixel di tracciamento (provvedimento n. 284). Il Garante tratta il pixel che misura le aperture come un cookie: serve un consenso, e l'utente deve poter revocare il tracciamento continuando però a ricevere le eMail.
Ho cercato di riassumere il quadro normativo completo, insieme a cosa chiede il provvedimento, in questo articolo. Qui affrontiamo invece la parte tecnica.
Una premessa, casomai servisse: non sono un avvocato. La parte tecnica l'ho costruita e testata io; testi del form, informativa e base giuridica vanno validati con il proprio consulente privacy.
Ad oggi, 28 settembre, Klaviyo non ha ancora reso disponibile una funzione nativa che permetta di gestire a livello di profili il tracciamento delle aperture delle email. Questo articolo esiste per spiegare cosa ho fatto per adeguare gli account dei miei clienti, spiegare il sistema che ho costruito e, passaggio per passaggio, le domande che mi sono posto.
Cosa fa Klaviyo oggi, e cosa (ancora) no?
Su Klaviyo uno switch esiste già: si può scegliere se disattivare o lasciare attivo il tracciamento delle aperture. Il punto però è che, come è adesso, la scelta vale per l'intero account, e non per il singolo profilo.
Ciò che chiede il Garante, però, è che a decidere sia il singolo iscritto. Spegnere tutto è la via più rapida per perdere del tutto informazioni - per quanto da tempo non affidabilissime - su quanti aprono le eMail.
Sì, disattivando il tracciamento, di passerebbe di fatti ad una situazione dove si smette completamente di sapere in quanti aprono le eMail del proropio brand.
Arriviamo quindi al… momento spiegone.
Da luglio 2026 Klaviyo ha reso disponibile un consenso dedicato alle aperture, open_tracking, separato da quello marketing, che vale per il singolo profilo. Il "problema" è che ci si arriva solo via API, con gli endpoint di subscription bulk. Ogni cambio genera sul profilo un evento nativo, Consented to Open Tracking quando viene concesso e Revoked Open Tracking Consent quando viene revocato. Non esiste però un modo nativo per raccogliere il consenso nei form, né un'azione di flow che lo aggiorni - Klaviyo li ha annunciati per fine 2026.
Perché la strada più ovvia non basta
Detto così, per chi ha costruito flow mediamente più complicati di un recupero checkout, sembra semplice: una pagina dove l'iscritto lascia la propria preferenza e un flow che chiama l'API.
Nella pratica, però, è emerso un ostacolo: quella che doveva essere la strada più diretta e ovvia, un webhook inserito un flow Klaviyo verso l'API di Klaviyo, oggi si blocca per un problema - mi dicono - noto al supporto.
C'erano poi diversi casi limite a cui pensare: la revoca raccolta tramite una pagina avrebbe coperto solo chi effettivamente effettua una scelta, ma la maggior parte delle persone non sceglierà probabilmente mai. In più, chi si iscrive dal checkout, chi riceve eMail in regime di soft spam, chi arriva da un'integrazione: anche loro vanno gestiti, e il sistema deve sapere cosa fare con ognuno.
Come funziona l'infrastruttura in breve?
Il percorso di una scelta, dal click all'aggiornamento del profilo, è questo:
L'utente apre da un link inserito nelle eMail una landing page creata direttamente in Klaviyo;
Sceglie se accetta o revoca il tracciamento delle aperture;
Il form salva la scelta sul profilo come proprietà;
Un flow Klaviyo legge la proprietà e chiama un webhook sulla mia istanza n8n.
n8n chiama l'API di Klaviyo con la chiave del cliente e aggiorna il consenso
open_tracking.
Il consenso marketing non viene mai toccato: chi revoca il tracciamento resta iscritto e continua a ricevere le eMail, semplicemente senza misurazione delle aperture.
La landing però copre solo chi sceglie volontariamente, e a posteriori, se preferisce o meno essere tracciato. E questo da solo non basta perché i casi di fronte cui possiamo trovarci sono più di uno…
Situazione | Flow | Cosa succede |
|---|---|---|
Sceglie dalla landing | Landing Choice |
|
Si iscrive da un form con il testo del disclaimer aggiornato | New Subscriber |
|
Si iscrive da una fonte con il testo non aggiornato (per esempio il checkout di Shopify) | New Subscriber |
|
Riceve eMail senza essersi mai iscritto (soft spam, checkout abbandonati, fonti future) | Not Covered |
|
Passo 1: come è fatta la landing page?
La scelta dell'utente passa da una landing page Klaviyo con un form molto essenziale.
Il form non ha il campo eMail e non è collegato a nessuna lista, quindi compilarlo non iscrive né effettua cambi di consenso alla ricezione di eMail marketing. Contiene una sola scelta, salvata sul profilo come proprietà booleana Accept OpenTracking (true se accetta, false se revoca). Il profilo viene riconosciuto perché l'utente arriva cliccando il link nella eMail: niente da digitare, e nessuno può cambiare il consenso di un indirizzo che non è il suo semplicemente scrivendolo.
È una delle scelte su cui mi sono soffermato di più.
In alcune landing di revoca che ho analizzato ho quasi sempre trovato il campo eMail, con il form verosimilmente collegato ad una lista (è una richiesta specifica di Klaviyo che altrimenti ne blocca la pubblicazione). Il punto è che iscrivendosi ad una lista da un form nativo, si attiva anche l'evento Subscribe to email marketing… e far ritrovare un utente che voleva solo dirci “non tracciare le mie aperture” con un consenso marketing attivo - che non ha mai dato esplicitamente dato - è un problema piuttosto importante.
Il link alla landing va nelle eMail, e il posto naturale è il footer, vicino ai link di disiscrizione.
Passo 2: quali flow servono su Klaviyo?
I flow che ho costuito sono tre.
Landing Choice
[SYSTEM] Open Tracking - Landing Choice gestisce le scelte fatte dalla landing:
Trigger “Form submitted by profile”, filtrato sull'ID del form della landing.
Un'attesa breve, qualche minuto, per dare alla proprietà il tempo di essere scritta sul profilo prima dello split.
Conditional split su
Accept OpenTrackinguguale a true.Sul ramo sì un webhook verso n8n con consenso
SUBSCRIBED, sul ramo no lo stesso webhook conUNSUBSCRIBED.
Anche il ramo sì è una scelta. La norma chiede che si possa revocare, ma chi ha revocato deve poter tornare indietro dalla stessa pagina, e il suo nuovo consenso resta registrato sul profilo con la sua data.
Il webhook porta nell'header il token dell'account (X-Consent-Token) , e nel body solo l'essenziale:
New Subscriber
Per stare dentro il perimetro normativo, verosimilmente basterebbe il flow della landing, che gestisce la revoca. Questo però lascerebbe l'account con una maggioranza di profili senza l'indicazione di alcunchè. Una situazione che trovo non ottimale, soprattutto in virtù di probabilissimi aggiornamenti prossimi sul tema.
Il secondo flow, [SYSTEM] Open Tracking - New Subscriber, risponde a questo caso. Parte a ogni iscrizione alle eMail marketing, senza filtri sul trigger, e uno split sul metodo di iscrizione separa due casi.
Se l'iscrizione arriva - nel mio caso da un form Klaviyo (KLAVIYO_ONSITE_FORM oppure KLAVIYO_HOSTED_PAGE) - da una fonte dove il disclaimer riporta l'aggiornamento con l'indicazione del tracciamento sulle apertura, il flow manda a n8n un SUBSCRIBED e scrive Accept OpenTracking = true. La chiamata viene sempre inviata, anche se per un nuovo iscritto il tracciamento è già attivo di default, per rispondere a diverse esigenze.
Lo stato in Klaviyo diventa esplicito e coincide con la proprietà;
È scritto sul profilo e resta valido anche quando Klaviyo introdurrà la propria impostazione predefinita;
Chi aveva revocato il consento e poi si reiscrive da un form con disclaimer aggiornato, ritrova il tracciamento attivo (ha dato un nuovo consenso informato, e vale l'ultima scelta).
Tutte le altre iscrizioni finiscono nel secondo ramo.
Il caso tipico è la casella del checkout di Shopify, che non permette di modificare il testo del consenso: registrare lì un consenso al pixel vorrebbe dire dichiarare qualcosa che la persona non ha letto. Il flow quindi manda un UNSUBSCRIBED e scrive Accept OpenTracking = false, ma solo se la proprietà non è già impostata. Senza questa condizione, una persona già iscritta da un form aggiornato che spunta di nuovo la casella al checkout perderebbe un consenso valido.
Not Covered
Restano le persone che ricevono eMail da Klaviyo senza essersi mai iscritte: i clienti in regime di soft spam, ad esempio. Tracciamento disattivato d'ufficio.
La domanda vera è stata come intercettarle. La prima idea era agganciare il flow a un evento, un ordine o un checkout avviato. Un profilo può nascere da eventi diversi, e dovendo diffondere la soluzione su più account con fonti diverse (API, WooCommerce, Shopify, App terze, …) un flow legato a un evento non era la scelta migliore. Ho preferito quindi descrivere la condizione, con un segmento:
[SYSTEM] Open Tracking - Not Covered
profilo creato dopo la data di avvio dell'adeguamento;
può ricevere eMail marketing perché mai iscritto (quindi senza opt-in e non soppresso);
Accept OpenTrackingnon impostata.
Il flow, attivato dall'ingresso del profilo nel segmento, scrive Accept OpenTracking = false e poi chiama n8n con UNSUBSCRIBED.
Perché un ponte con n8n e non il webhook diretto?
La strada più diretta, come detto sopra, sarebbe quella di far chiamare l'API di Klaviyo direttamente dal webhook del flow, ed è la prima cosa che ho costruito. Nei test, però, i webhook diretti verso i domini di Klaviyo (sia /api/ sia /client/) restavano fermi in “Waiting rate limited”. Anche con una sola chiamata in coda, e quindi ben lontani dai limiti documentati dell'endpoint (75 richieste al secondo, 750 al minuto).
Per capire se il problema fosse nella mia configurazione ho fatto la controprova: stesso flow, stesso webhook, destinazione esterna (webhook.site). Consegnato subito. Il blocco, quindi, riguardava solo le chiamate che dal flow tornano verso Klaviyo.
[DIAGRAMMA: due percorsi a confronto. Sopra il webhook diretto: flow → API Klaviyo, bloccato in “Waiting rate limited” e poi “Skipped”. Sotto il ponte: flow → n8n → API Klaviyo, consegnato.]
Il supporto Klaviyo è stato molto chiaro a riguardo: si tratta di un problema noto, già in carico ai team Product ed Engineering, per il quale al momento non c'è però una data di risoluzione.
The issue you're experiencing has been identified as a known issue currently being worked on by our Product and Engineering teams. […] There's no provided timeline by our Engineering team at the moment, unfortunately.
La soluzione
Visto che i webhook verso destinazioni esterne funzionano, il flow chiama n8n, e n8n chiama l'API di Klaviyo al posto suo. Uso un'istanza self-hosted su Railway che gestisco già per altre automazioni (Serve una guida su come l'ho installata e, soprattutto, ottimizzata? Fammelo sapere!).
Non serve per forza n8n. Il ponte funziona con qualsiasi strumento capace di ricevere un webhook e chiamare un'API, quindi anche con Make o Zapier: la logica resta la stessa, cambiano solo i nomi dei moduli.
Il ponte ha anche dei vantaggi che restano validi quando Klaviyo avrà risolto. Nel webhook diretto la chiave API privata del cliente sta negli header, visibile a chiunque apra il flow; con n8n resta salvata come credenziale e dal flow sparisce. Tutte le chiamate di tutti i clienti passano da un punto solo, con retry e notifica se qualcosa fallisce.
Passo 3: come è fatto il workflow su n8n?
Il workflow è unico per tutti gli account. La struttura è fatta così:
Un nodo Webhook per ogni account, con path e token propri (per esempio
/webhook/klaviyo-open-tracking/<account>).Subito dopo, un nodo Edit Fields che assegna il nome dell'account. L'account lo decide il webhook che ha ricevuto la chiamata, non il body.
Un nodo di validazione controlla che l'eMail ci sia e che il consenso sia
SUBSCRIBEDoUNSUBSCRIBED.Uno Switch smista per account verso il suo nodo HTTP Request, che usa la credenziale API di quel cliente riprovando fino a 5 volte in caso di errore.
Se qualcosa fallisce comunque, arriva una notifica su Slack.
La chiamata finale aggiorna solo il canale open_tracking del profilo. La prova del consenso resta sul profilo Klaviyo, con l'evento nativo e la sua data. Le esecuzioni di n8n servono solo alla diagnosi e vengono eliminate in automatico dopo un periodo limitato, così un'altra copia delle eMail non resta in giro più del necessario.
Leggendo il provvedimento mi sono chiesto se servisse salvare a mano un timestamp di ogni scelta. Klaviyo lo registra già, solo non dove ci si aspetterebbe. La traccia è doppia: l'evento che origina la scelta (l'invio del form della landing, oppure l'iscrizione) dice chi ha scelto, quando e da quale IP, e il cambio di consenso genera a sua volta un evento nativo con data e ora, “Consented to Open Tracking” oppure “Revoked Open Tracking Consent”. Una proprietà custom con la data sarebbe una seconda fonte di verità, che prima o poi rischia di non coincidere con la prima.
Il segmento di controllo
La notifica di n8n copre gli errori che n8n vede, ma due casi le sfuggono: la chiamata di Klaviyo verso n8n che non arriva mai, e Klaviyo che accetta la richiesta ma poi non completa il cambio di consenso. Per questi serve un controllo lato Klaviyo.
Klaviyo non ha un filtro nativo sullo stato del consenso al tracciamento (o, almeno, non ancora), quindi un segmento che lo legga direttamente non si può costruire. Si può però costruire sull'evento:
Accept OpenTrackinguguale a false;ha fatto “Revoked Open Tracking Consent” zero volte, da sempre.
Chi finisce lì ha la proprietà a “revocato”, ma Klaviyo non ha mai registrato la revoca. Il segmento deve restare vuoto; se non lo è, per quei profili la chiamata va rilanciata.
Come si gestiscono i nuovi iscritti?
Per chi si iscrive da ora in poi non serve un secondo consenso. Il Garante ammette che il consenso al pixel sia compreso in quello alle comunicazioni promozionali, a patto che la richiesta sia formulata in modo chiaro e neutro, e che sia raccolto preferibilmente al momento dell'iscrizione.
Il punto è che il consenso non si può dare per scontato. Tecnicamente Klaviyo traccia il nuovo iscritto anche senza far nulla, ma quel tracciamento è coperto solo se il form e l'informativa dicono esplicitamente che le aperture vengono misurate.
Per il testo non serve una formula lunga. Basta che dica, in modo neutro, che le eMail vengono misurate all'apertura:
Cliccando su “ISCRIVITI” acconsenti a ricevere eMail promozionali e alla rilevazione delle loro aperture, e dichiari di aver letto e compreso la nostra privacy policy.
“Rilevazione delle aperture” è specifico: il pixel rileva l'apertura, e formule più ampie come “il tracciamento del tuo comportamento” sono meno precise e più allarmanti.
Per la base contatti già esistente, invece, il Garante ritiene sufficiente informare con il primo invio utile, o al primo momento di discontinuità nella relazione. Per questo il segmento Not Covered considera solo i profili creati dopo l'avvio, e la base precedente resta nel regime transitorio.
Quali sono i limiti del sistema?
È una soluzione custom e, come tale, dei compromessi vanno accettati.
Se un utente inoltra la eMail e il destinatario clicca il link, la scelta viene applicata al profilo di chi l'ha inoltrata, perché il riconoscimento passa dal link. Allo stesso modo, una pagina aperta senza identificativo (un link copiato e incollato, per esempio) non aggiorna nessun profilo. Sono queste, però, situazioni create dall'utente stesso. Tentare di arginarle avrebbe richiesto, per esempio, un identificativo personale nel link e più logica da mantenere per ogni cliente: ho preferito un disclaimer nella landing che trovo sia una risposta proporzionata all'eventualità.
Se una lista usa il double opt-in, chi compila il form resta “mai iscritto” finché non conferma, e nel frattempo può entrare nel segmento Not Covered. Alla conferma, se l'iscrizione arriva da un form aggiornato, il New Subscriber riattiva il tracciamento: lo stato finale è corretto, ma con due chiamate in più.
Le eMail transazionali (conferme d'ordine, spedizioni), se partono da Klaviyo, arrivano anche ai disiscritti, che nessun segmento del sistema intercetta, e contengono il pixel. Il provvedimento non le esenta in modo esplicito: se considerarle coperte dall'esecuzione del contratto, o disattivare il tracciamento anche per i disiscritti, è una domanda per il consulente privacy.
Il sistema dipende da un servizio esterno. L'istanza n8n è monitorata con un controllo di uptime ogni 5 minuti, e in caso di irraggiungibilità Klaviyo riprova i webhook da sola.
È un ponte, nel senso letterale: quando Klaviyo rilascerà la raccolta nativa del consenso e un'azione di flow dedicata, andrà rivalutato.
In sintesi
Finché Klaviyo non rilascia la raccolta nativa del consenso, la revoca granulare del tracciamento si può costruire con ciò che la piattaforma offre e un po' di giuste domande: una landing, tre flow e un ponte esterno verso l'API.
Vuoi applicare questo sistema al tuo account Klaviyo e non restare scoperto? Prenota una call di 20 minuti e vediamo insieme come adattarlo alle tue fonti di iscrizione.
