Safari ha smesso di far parlare i siti tra loro

Il blocco non riguarda i cookie ma le chiamate di rete verso i domini che ricostruiscono l’identità del lettore

Chi gestisce un sito editoriale apre ogni mattina due cruscotti: quello di Search Console, per sessioni e posizionamenti, e quello della monetizzazione. Nei giorni scorsi il secondo ha mostrato qualcosa che il primo non spiega. Tra i lettori che hanno installato l’ultimo aggiornamento Apple, gli eCPM (il ricavo per mille impression pubblicitarie mostrate) sono calati del 10,5%. Non c’entrano un core update di Google o un crollo in SERP, la pagina dei risultati di ricerca. Il motivo è tecnico e riguarda il browser: come spiegato la scorsa settimana nel post ufficiale del team WebKit, nelle release iOS, iPadOS, macOS e visionOS 27 Safari e WebKit bloccano a livello di dominio l’accesso di rete alle infrastrutture di identity resolution, con lo scopo dichiarato di impedire il tracciamento cross-site.

Stesso traffico, meno valore: il -10,5% che non arriva dalla SERP

Il dato sul calo viene da Aditude ed è stato riportato da Digiday in un’analisi sulle prime perdite dell’industria pubblicitaria dopo il blocco di Safari. Per chi lavora sul traffico organico questo numero rompe un’abitudine. Di solito misuriamo il successo in visite, CTR (la percentuale di clic sui risultati) e posizioni. Qui invece il volume può restare identico mentre il valore di ciascuna sessione scende. Le release 27 sono già sui dispositivi degli utenti, quindi non resta un annuncio da interpretare: l’effetto è in corso e cresce man mano che gli aggiornamenti si diffondono.

Resta una domanda legittima. Safari blocca i cookie cross-site da anni: che cosa è stato tolto, esattamente, questa volta?

Dai cookie al dominio: WebKit chiude anche la porta di servizio

La risposta sta nel livello a cui Apple interviene. Il cookie era solo il primo strato. Una volta chiuso quello, l’ecosistema pubblicitario aveva spostato il riconoscimento degli utenti su servizi di identity resolution, cioè infrastrutture che ricollegano lo stesso lettore tra siti diversi senza appoggiarsi ai cookie di terze parti. Con la versione 27 WebKit non si limita più a impedire che un identificatore venga salvato o letto nel browser. Blocca la connessione di rete verso i domini che quell’identità la risolvono. In altre parole, la chiamata non parte proprio.

Non si tratta di una svolta improvvisa, ma dell’ultimo passo di una linea coerente. Il team WebKit ricorda di aver inventato il partizionamento di storage e cache e di averlo distribuito dieci anni prima degli altri browser principali. Ricorda anche che già sei anni fa aveva bloccato completamente i cookie cross-site. A questo si aggiunge il resto dell’ecosistema Apple. Con Hide My Email gli abbonati iCloud+ possono comunicare a ogni nuovo sito un indirizzo email unico e randomizzato, continuando a ricevere i messaggi nella propria casella. È un dettaglio che pesa, perché l’email era diventata una delle chiavi di identità più usate proprio come alternativa al cookie. Se ogni sito riceve un indirizzo diverso, anche quel collegamento si indebolisce.

Sullo sfondo resta la scelta opposta di Google. Nel luglio 2024, dopo anni di incertezza, l’azienda ha rinunciato a eliminare i cookie di terze parti in Chrome. Ha mantenuto le API di Privacy Sandbox e ha annunciato una nuova esperienza nel browser che lascia agli utenti una scelta informata sulla propria navigazione. Oggi convivono quindi due browser dominanti con due filosofie opposte. Safari blocca del tutto la risoluzione dell’identità, Chrome lascia la decisione all’utente. Chi monetizza su entrambi deve capire dove adattarsi per primo, e i numeri delle ultime settimane indicano chiaramente da che parte arriva la pressione.

I workaround scadono, la relazione con il lettore resta

Il conto non è uguale per tutti. Secondo un dirigente editoriale citato da Digiday, i publisher che dipendono dall’inventario programmatic e indiretto, cioè venduto tramite aste automatizzate, rischiano di perdere più dei brand affermati che vendono campagne direttamente agli inserzionisti. La ragione è semplice: nelle aste il prezzo di un’impression dipende da quanto l’acquirente sa di chi la vedrà. Se l’identità non si risolve, quell’impression vale meno. Una campagna venduta direttamente su una testata, un contesto o un’audience dichiarata dipende molto meno da quel collegamento.

La tentazione, a questo punto, è cercare un workaround tecnico. Conviene essere chiari sul trade-off. Come osserva l’analisi di AdExchanger sull’identity resolution, le soluzioni alternative possono funzionare temporaneamente, ma l’ad tech viene spinta verso schemi di identità basati sul consenso. La storia di WebKit, dal partizionamento al blocco dei cookie fino a quello di rete, mostra che ogni scappatoia diffusa diventa prima o poi il bersaglio del rilascio successivo. Investire tempo di sviluppo in un aggiramento significa comprare qualche settimana, non una strategia.

Per chi fa SEO la conseguenza operativa è concreta. Domani mattina non basta controllare i ranking. Bisogna segmentare sessioni e ricavi per browser e versione del sistema operativo, e verificare quanto valgono davvero le visite da Safari aggiornato rispetto al resto. Poi c’è la parte più impegnativa: progettare i contenuti in modo che la visita organica diventi qualcosa di più di un’impression. Iscrizioni alla newsletter, account, abbonamenti, cioè un rapporto diretto e consensuale che non dipende da un dominio di terze parti raggiungibile o meno dal browser. Un trucco tecnico può durare qualche settimana, mentre il rapporto con il lettore regge anche al prossimo aggiornamento. Resta da chiedersi quanta parte del proprio traffico sia oggi una relazione e quanta sia solo un’impression anonima, che Safari ha appena reso più economica.