Tracciare dopo iOS: cosa funziona ancora

Tra il 2017 e il 2021 sono arrivati tre cambiamenti che insieme hanno rimosso gran parte dell’infrastruttura di tracking su cui era costruito il paid social. Ognuno ha rotto qualcosa di specifico, e sapere quale è quale ti dice cosa resta disponibile.

I tre cambiamenti

Intelligent Tracking Prevention (Safari, dal 2017). ITP limita a 7 giorni i cookie scritti da JavaScript (e a 24 ore in alcune condizioni) e blocca i cookie di terze parti. In seguito il limite è stato esteso allo storage scrivibile da script. L’effetto pratico: qualsiasi identificatore di click scritto dal tuo pixel tramite document.cookie ha una vita breve e inaffidabile.

ATT — App Tracking Transparency (iOS 14.5+, 2021). Le app devono chiedere permesso prima di tracciare un utente attraverso app e siti di altre aziende. Senza consenso, l’app non ottiene alcun identificatore cross-app. È per questo che il reporting della piattaforma pubblicitaria ha iniziato ad appoggiarsi a conversioni modellate.

Blocco dei cookie di terze parti (Safari, Firefox e in generale le funzionalità di privacy dei browser). I cookie settati da un dominio diverso da quello nella barra degli indirizzi vengono bloccati o partizionati. Chrome ha annunciato una dismissione completa, poi l’ha ritirata nel 2024 a favore di una scelta dell’utente — il che non ripristina il vecchio modello, lascia solo l’esito a ciascun utente.

Cosa ha rotto ciascuno

Nota cosa non è in quella lista: un cookie settato dal server, tramite header Set-Cookie, sul dominio che l’utente sta effettivamente visitando, dalla stessa risposta che renderizza la pagina.

Perché il cookie first-party lato server sopravvive

La distinzione non è un dettaglio tecnico, è l’intero meccanismo:

• I limiti di ITP si applicano ai cookie scritti da JavaScript. Un header di risposta Set-Cookie è scritto dal server.
• Il blocco di terze parti si applica ai cookie settati da un dominio diverso da quello della pagina. Un cookie first-party arriva dallo stesso dominio.
• ATT si applica al tracciamento degli utenti attraverso app e siti di altre aziende. Un cookie first-party misura la visita al tuo sito.

È per questo che il design descritto in tracking first-party insiste su una cosa: la landing page e il tracking devono stare sullo stesso dominio. Non un redirect alla pagina da un dominio di tracking — la pagina stessa servita dal dominio di tracking.

La catena di redirect è dove muore l’identificatore. Una richiesta, una risposta, un cookie.

Quanto ti costa in pratica

Il tracking first-party non è gratis:

• Ti serve un dominio che controlli. DropCPL ne assegna uno per landing page.
• I percorsi cross-domain non sono visibili. Se un utente clicca un annuncio sul tuo dominio di tracking e poi converte su un altro dominio tuo, quella conversione non è legata al click. Tieni la conversione sulla pagina che ha ricevuto il click.
• Le finestre sono esplicite, non implicite. Il click_id di DropCPL vive 7 giorni. Cicli di considerazione più lunghi (B2B con trattative di mesi) non verranno attribuiti al click originale — motivo in più per far uscire i lead con la loro attribuzione invece di provare a ricostruirla dopo.

La configurazione che funziona ancora

1. Servi la landing page dallo stesso dominio che registra il click.
2. Setta l’identificatore di click lato server, HttpOnly, first-party.
3. Attribuisci l’invio del form con quell’identificatore — senza dipendere da uno script che spara.
4. Rimanda la conversione alla piattaforma tramite la sua API server-side, con un ID di deduplicazione, così il suo optimizer continua a funzionare.
5. Decidi sul numero first-party, non su quello modellato — vedi CPL reale vs CPL della piattaforma.

Correlati

• Tracking first-party — l’implementazione
• CPL reale vs CPL della piattaforma — perché i due numeri differiscono
• Cos’è l’attribuzione creativa — perché il click deve sopravvivere