IPv6, Facebook Ads e conversioni e-commerce: quando un hosting IPv4-only può peggiorare il tracking

Nel mondo e-commerce siamo abituati a parlare di conversion rate, campagne Meta Ads, Google Ads, Pixel, server-side tracking, cookie first-party e Conversions API. Molto più raramente, però, ci si domanda cosa accada qualche livello più in basso, cioè nella rete che materialmente trasporta le richieste tra smartphone, piattaforme pubblicitarie, CDN e server dell’e-commerce.

Una delle questioni più interessanti riguarda IPv6.

Oggi una parte molto consistente degli utenti Internet, soprattutto da rete mobile, utilizza già IPv6. Facebook, Instagram, Google e le principali piattaforme mondiali sono perfettamente raggiungibili attraverso IPv6. Molti siti web, al contrario, continuano a essere pubblicati esclusivamente attraverso IPv4.

Questo crea uno scenario particolare: un utente può navigare su Facebook utilizzando un indirizzo IPv6, cliccare su una pubblicità e raggiungere subito dopo un e-commerce disponibile solamente in IPv4. Il server dell’e-commerce potrebbe quindi osservare un indirizzo IP completamente differente da quello con cui pochi istanti prima lo stesso dispositivo stava comunicando con Meta.

L’acquisto continuerà normalmente a funzionare. Il prodotto finirà nel carrello, il checkout sarà accessibile e il pagamento potrà essere completato.

La domanda interessante è un’altra:

questa discontinuità tra IPv6 e IPv4 può rendere meno preciso il tracking e quindi l’attribuzione delle conversioni?

La risposta è sì, almeno potenzialmente. Ma occorre capire bene in quale misura e, soprattutto, evitare la conclusione semplicistica secondo cui un sito IPv4-only “perde automaticamente le conversioni Facebook”.

Il problema è più sottile e riguarda la qualità dei segnali utilizzati per riconoscere un utente e associare una conversione a una precedente interazione pubblicitaria.

Perché il tracking è così importante per un e-commerce

Una piattaforma e-commerce non deve solamente vendere. Deve anche riuscire a capire, per quanto tecnicamente e legalmente possibile, da dove provengono le vendite.

Se un negozio online investe ogni mese 20.000 euro in campagne pubblicitarie, sapere che sono avvenuti 500 ordini non è sufficiente. Bisogna cercare di stabilire quali campagne, quali annunci, quali audience e quali sorgenti di traffico abbiano contribuito a generarli.

È qui che entrano in gioco sistemi come Meta Pixel, Meta Conversions API, Google Ads Conversion Tracking, Google Analytics e le numerose piattaforme di analytics e advertising utilizzate quotidianamente dagli e-commerce.

Quando un utente clicca su una pubblicità di Facebook o Instagram e successivamente effettua un acquisto, Meta cerca di correlare i due eventi.

In un mondo ideale avremmo una sequenza perfettamente riconoscibile:

Facebook mostra una pubblicità, l’utente fa clic, arriva sull’e-commerce, visita un prodotto, aggiunge il prodotto al carrello, inizia il checkout e completa l’ordine.

Più chiaramente Meta riesce ad associare questi eventi allo stesso utente o allo stesso percorso pubblicitario, migliore potrà essere l’attribuzione.

Questo è importante non soltanto per produrre statistiche più belle nel pannello Ads Manager.

I dati sulle conversioni vengono infatti utilizzati anche dai sistemi automatici delle piattaforme pubblicitarie per ottimizzare la distribuzione delle campagne. Se il sistema riceve segnali di conversione incompleti o di qualità inferiore, può avere meno informazioni sulle caratteristiche degli utenti che effettivamente acquistano.

Per questo negli ultimi anni l’ecosistema e-commerce è progressivamente passato dal semplice Pixel eseguito nel browser a implementazioni più articolate che prevedono anche l’invio server-side degli eventi attraverso strumenti come la Meta Conversions API, comunemente abbreviata in CAPI.

Ed è proprio nel server-side tracking che l’indirizzo IP del visitatore torna a essere un parametro particolarmente interessante.

IPv4 e IPv6 spiegati brevemente

Ogni dispositivo che comunica attraverso Internet utilizza il protocollo IP.

Per molti anni Internet è stata costruita quasi interamente attorno a IPv4, protocollo che utilizza indirizzi a 32 bit come:

192.0.2.123

Lo spazio teorico disponibile è di circa 4,3 miliardi di indirizzi. Un numero che poteva sembrare enorme agli inizi di Internet, ma che è diventato insufficiente con miliardi di computer, smartphone, router, server, dispositivi IoT e infrastrutture connesse.

Il problema non è teorico. In Europa il RIPE NCC ha esaurito il proprio pool disponibile di nuovi indirizzi IPv4 nel novembre 2019. Da allora la crescita continua attraverso recupero e trasferimento di indirizzi esistenti, NAT, Carrier Grade NAT e altre tecniche che permettono di condividere il limitato spazio IPv4.

IPv6 nasce proprio per superare questo limite.

Utilizza indirizzi a 128 bit, ad esempio:

2001:db8:85a3::8a2e:370:7334

Lo spazio di indirizzamento diventa talmente grande da eliminare, nella pratica, il problema della scarsità che caratterizza IPv4.

IPv6 non è quindi semplicemente una nuova notazione per indicare un indirizzo IP: rappresenta un’evoluzione fondamentale dell’infrastruttura Internet.

La migrazione, tuttavia, non è avvenuta sostituendo IPv4 dall’oggi al domani. Da decenni convivono entrambi i protocolli.

Ed è questa convivenza a rendere interessante il problema del tracking.

IPv6 non è più una tecnologia marginale

Per molti anni IPv6 è stato percepito dagli amministratori di siti web come qualcosa che si sarebbe potuto implementare “più avanti”.

Oggi questa posizione è molto più difficile da sostenere.

Google misura continuamente la percentuale dei propri utenti che raggiunge i servizi Google attraverso IPv6. Il 13 giugno 2026 aveva già rilevato il 50,29% degli accessi attraverso IPv6 nativo.

Le metodologie di misurazione possono produrre percentuali differenti. APNIC, per esempio, utilizza propri sistemi di misurazione e a settembre 2026 stima una IPv6 Capability mondiale superiore al 40%.

Non bisogna quindi fissarsi sul singolo numero. Il dato importante è l’ordine di grandezza: IPv6 riguarda ormai centinaia di milioni di utenti e una quota enorme del traffico Internet mondiale.

È particolarmente importante nel mondo mobile, dove tecnologie IPv6-only, NAT64 e 464XLAT permettono agli operatori di limitare la necessità di indirizzi IPv4 pubblici.

Facebook, Instagram, Google e molte altre grandi piattaforme sono naturalmente raggiungibili attraverso IPv6.

Il Web nel suo complesso, però, presenta una situazione molto diversa.

Gli utenti sono sempre più IPv6, ma molti siti sono ancora IPv4-only

A settembre 2026 W3Techs rileva supporto IPv6 su circa il 31,5% dei siti web analizzati.

La situazione migliora considerevolmente osservando i siti più importanti: IPv6 risulta presente sul 44,2% dei primi un milione di siti, sul 52,9% dei primi 100.000 e sul 56,6% dei primi 10.000.

Questi dati mostrano un fenomeno interessante.

La disponibilità IPv6 cresce insieme alla dimensione e alla rilevanza del sito.

Le grandi piattaforme hanno da tempo investito in infrastrutture dual-stack, mentre una parte consistente del Web tradizionale continua a funzionare solamente su IPv4.

Secondo W3Techs, a luglio 2026 solo il 13,7% dei siti rilevati con cPanel e il 19,1% di quelli con Plesk utilizzava IPv6. Sono statistiche che non devono essere interpretate come una limitazione intrinseca dei due pannelli, ma descrivono bene quanto una parte del tradizionale ecosistema hosting sia ancora fortemente IPv4-centrica.

Anche WordPress, preso complessivamente, mostrava a giugno 2026 una presenza IPv6 di circa il 32,9%.

È quindi perfettamente plausibile che uno smartphone moderno utilizzi IPv6 per Facebook, Instagram o Google e venga immediatamente costretto a utilizzare IPv4 quando apre il sito dell’inserzionista.

Perché molti hosting continuano a essere IPv4-only

Il problema raramente è rappresentato dal kernel Linux o dal web server.

Linux, NGINX, Apache, HAProxy, Varnish, PHP e i principali database supportano IPv6 da moltissimo tempo.

Il limite è spesso nell’architettura complessiva dell’hosting.

Molte piattaforme shared hosting sono nate quando IPv4 era ancora considerato lo standard assoluto. Intorno all’indirizzo IPv4 sono state costruite configurazioni dei Virtual Host, sistemi DNS, firewall, software di provisioning, pannelli di controllo, statistiche, sistemi antifrode, applicazioni legacy e procedure operative.

Aggiungere IPv6 non significa quindi soltanto assegnare un indirizzo al server.

Significa assicurarsi che DNS, firewall, monitoring, logging, rate limiting, reverse proxy, applicazioni e software di sicurezza sappiano gestirlo correttamente.

Un hosting moderno dovrebbe essere progettato considerando IPv4 e IPv6 come due normali modalità di accesso allo stesso servizio. In molte infrastrutture più datate, invece, IPv6 continua a essere trattato come un’aggiunta opzionale.

Per anni questa mancanza ha avuto conseguenze poco evidenti per il proprietario del sito: grazie alle tecnologie di transizione, un utente IPv6 riusciva comunque ad aprire praticamente qualsiasi sito IPv4.

Oggi però esistono motivi ulteriori per interessarsene. Uno di questi è proprio la continuità dei dati utilizzati nel tracking server-side.

Cosa succede quando Facebook vede IPv6 ma l’e-commerce è solo IPv4

Consideriamo un utente che utilizza Facebook dall’applicazione installata sul proprio smartphone.

La rete mobile fornisce connettività IPv6 e Facebook viene quindi raggiunto direttamente attraverso IPv6.

Possiamo immaginare che, durante questa fase, il dispositivo sia identificabile in rete attraverso un indirizzo del tipo:

2a01:xxxx:xxxx:xxxx::1234

L’utente vede una campagna pubblicitaria, fa clic e viene indirizzato verso:

https://www.ecommerce.it/

Il DNS dell’e-commerce presenta però solamente un record A:

[www.ecommerce.it](http://www.ecommerce.it) → 192.0.2.50

Non esiste alcun record AAAA.

A questo punto il dispositivo deve raggiungere una risorsa disponibile solamente in IPv4.

Su molte reti mobili moderne questo avviene attraverso sistemi come 464XLAT, standardizzato dalla IETF nella RFC 6877.

464XLAT combina una traduzione lato client, chiamata CLAT, con una traduzione lato rete dell’operatore, chiamata PLAT. Quest’ultima può effettuare una traduzione N:1, facendo quindi apparire più sorgenti IPv6 attraverso un numero molto più limitato di indirizzi IPv4 pubblici.

Il risultato pratico è semplice.

Facebook può aver comunicato con:

2a01:xxxx:xxxx:xxxx::1234

mentre il web server dell’e-commerce registra:

93.45.120.38

I due indirizzi non hanno alcuna somiglianza evidente.

E soprattutto quell’IPv4 potrebbe essere condiviso, attraverso infrastrutture dell’operatore, con numerosi altri utenti.

Significa che Meta perde automaticamente la conversione?

No.

Questo è probabilmente il punto più importante dell’intero articolo.

L’indirizzo IP non è l’unico dato utilizzabile per correlare click, sessioni ed eventi di conversione.

Se l’infrastruttura di tracking è realizzata correttamente, Meta può ricevere diversi segnali.

Tra questi troviamo identificatori derivati dal click pubblicitario, cookie come _fbc e _fbp, browser User-Agent, URL dell’evento, identificatori first-party, eventuali dati cliente opportunamente normalizzati e sottoposti ad hashing quando previsto, oltre all’indirizzo IP.

Nel caso della Conversions API può inoltre essere utilizzato un event_id condiviso tra Pixel browser-side e evento server-side per consentire la deduplicazione dello stesso evento.

Un cambio di indirizzo IP tra la navigazione su Facebook e l’arrivo sul sito non equivale quindi automaticamente alla perdita dell’attribuzione.

Un utente potrebbe entrare su Facebook dalla rete mobile, aprire il sito attraverso Wi-Fi, cambiare rete durante il checkout oppure utilizzare tecnologie di privacy che modificano l’indirizzo osservabile.

Un sistema di advertising mondiale non può realisticamente basarsi sul presupposto che l’IP sia immutabile.

L’indirizzo IP deve essere considerato uno dei segnali di matching, non una chiave primaria universalmente stabile.

Il problema nasce quando, insieme alla discontinuità dell’indirizzo IP, vengono persi anche gli altri segnali.

Perché un IPv4 condiviso può comunque essere un segnale peggiore

Esiste però una differenza sostanziale tra dire che l’IP non è l’unico identificatore e sostenere che qualsiasi IP abbia la stessa qualità informativa.

Meta stessa fornisce un’indicazione estremamente interessante all’interno del proprio progetto ufficiale CAPI Parameter Builder.

Parlando della raccolta dell’indirizzo IP del client, la documentazione raccomanda:

“Prefer IPv6 (more precise than IPv4); fall back to IPv4 if IPv6 is not available.”

In altre parole: preferire IPv6, perché più preciso, utilizzando IPv4 come fallback.

La ragione tecnica è facilmente comprensibile.

Un indirizzo IPv4 può trovarsi dietro Carrier Grade NAT e rappresentare contemporaneamente numerosi abbonati.

Un indirizzo IPv6 offre generalmente maggiore granularità dal punto di vista della sorgente di rete, pur non dovendo essere interpretato come un identificatore personale permanente: gli indirizzi IPv6 possono cambiare, esistono privacy extensions, prefissi dinamici e numerose altre variabili.

La raccomandazione di Meta è comunque significativa perché dimostra che, ai fini del proprio sistema di raccolta dei parametri CAPI, IPv6 viene considerato un segnale preferibile rispetto all’IPv4 quando disponibile.

E questo rende meno trascurabile il fatto che un hosting IPv4-only possa trasformare un utente originariamente raggiungibile in IPv6 in un visitatore osservabile dal sito soltanto attraverso un IPv4 condiviso.

Pixel e Conversions API possono addirittura vedere due famiglie IP differenti

Esiste un altro scenario che rende la questione ancora più interessante.

Supponiamo che l’e-commerce sia solamente IPv4.

Il browser raggiunge:

www.ecommerce.it

attraverso IPv4.

Una volta caricata la pagina viene eseguito Meta Pixel.

Il browser deve quindi comunicare direttamente con infrastrutture Meta, che supportano IPv6.

Nulla impedisce che si verifichi una situazione del genere:

Per la stessa conversione possono quindi esistere contemporaneamente osservazioni di rete differenti.

Non significa necessariamente che qualcosa non funzioni. Meta dispone degli altri parametri dell’evento e, soprattutto in una corretta configurazione Pixel + CAPI, della possibilità di deduplicare e correlare le informazioni.

Dimostra però quanto sia sbagliato pensare al tracking moderno come a qualcosa che dipenda da un singolo indirizzo IP.

Il vero caso problematico: quando vengono persi più segnali contemporaneamente

Un’infrastruttura IPv4-only diventa più interessante dal punto di vista negativo quando si somma ad altri errori di implementazione.

Immaginiamo un utente proveniente da Facebook in IPv6.

Fa clic sulla pubblicità, ma un redirect mal configurato elimina i parametri utilizzati per conservare l’origine del click. Il sistema non mantiene correttamente _fbc. _fbp non viene raccolto o trasmesso alla componente server-side. Non esiste un external_id. L’utente non si è ancora autenticato e quindi non sono disponibili altri identificatori deterministici utilizzabili dall’integrazione. Infine la CAPI invia soltanto User-Agent e un IPv4 condiviso proveniente dal CGNAT dell’operatore.

A questo punto la qualità del matching può essere molto inferiore.

Non perché IPv4 impedisca tecnicamente il tracciamento, ma perché è rimasto ben poco con cui effettuare il matching.

La corretta domanda da porre non è quindi:

“Un sito senza IPv6 perde conversioni Facebook?”

La domanda tecnicamente più corretta è:

“Un sito IPv4-only può eliminare o rendere meno preciso uno dei segnali che contribuiscono alla corretta attribuzione delle conversioni?”

A questa domanda la risposta è sì.

Attenzione ai redirect: perdere il click identifier è probabilmente peggio che cambiare IP

Nella nostra esperienza di sistemisti è frequente concentrarsi su strumenti complessi dimenticando problemi infrastrutturali molto più banali.

Un esempio sono i redirect.

L’utente arriva da una campagna attraverso un URL contenente i parametri necessari all’attribuzione. Prima di raggiungere l’applicazione attraversa magari diversi passaggi:

• HTTP → HTTPS;
• dominio senza www → dominio con www;
• landing page → URL canonicale;
• sistema di tracking → e-commerce;
• redirect applicativo o plugin WordPress/WooCommerce.

Se uno di questi componenti ricostruisce male l’URL e scarta la query string, un segnale estremamente prezioso può scomparire ancora prima che il sistema di tracking abbia avuto la possibilità di conservarlo.

In termini pratici, un e-commerce perfettamente dual-stack ma con una catena di redirect sbagliata può avere un tracking peggiore di un e-commerce IPv4-only con una corretta implementazione CAPI.

IPv6 deve quindi essere considerato un tassello di un’architettura corretta, non una soluzione magica.

Dual-stack: la soluzione tecnicamente più naturale

La configurazione ideale per un servizio web pubblico moderno rimane il dual-stack.

Nel DNS vengono pubblicati sia il record A IPv4 sia il record AAAA IPv6.

Ad esempio:

[www.example.com](http://www.example.com). A 192.0.2.10
[www.example.com](http://www.example.com). AAAA 2001:db8::10

Un client che dispone di IPv6 potrà collegarsi attraverso IPv6, mentre un client che dispone solamente di IPv4 continuerà normalmente a utilizzare IPv4.

I sistemi operativi e i browser moderni implementano algoritmi appartenenti alla famiglia Happy Eyeballs, formalizzati nella RFC 8305, che interrogano A e AAAA e gestiscono tentativi di connessione attraverso le differenti famiglie IP cercando di evitare ritardi percepibili dall’utente e privilegiando IPv6 quando appropriato.

Non è quindi necessario scegliere tra utenti IPv4 e utenti IPv6.

Si offrono entrambi.

Per un e-commerce significa permettere allo smartphone che stava già comunicando nativamente in IPv6 con Facebook o Instagram di continuare a raggiungere anche il negozio attraverso IPv6, invece di costringerlo a passare attraverso un meccanismo di compatibilità verso IPv4.

Non è necessario avere IPv6 sull’origin per offrire IPv6 agli utenti

Questo punto è particolarmente importante perché consente di risolvere il problema anche in presenza di infrastrutture legacy.

Un e-commerce può essere raggiungibile pubblicamente attraverso IPv6 anche quando il server origin rimane esclusivamente IPv4.

È sufficiente che davanti all’origin esista un reverse proxy o una CDN dual-stack.

Un esempio molto diffuso è Cloudflare.

Con IPv6 Compatibility abilitato, Cloudflare genera automaticamente la connettività AAAA per i record proxied, permettendo ai client IPv6 di collegarsi alla propria rete edge. La connessione successiva tra Cloudflare e l’origin può continuare a utilizzare IPv4.

L’architettura diventa quindi:

Utente IPv6 → Cloudflare IPv6 → origin IPv4

Dal punto di vista dell’infrastruttura interna non è necessario migrare immediatamente ogni singolo server a IPv6.

Il frontend Internet diventa dual-stack mentre il backend può continuare, almeno temporaneamente, a funzionare su IPv4.

È una strategia estremamente utile durante una migrazione graduale.

Il reverse proxy deve però conservare il vero IP del visitatore

Mettere una CDN davanti all’e-commerce e dimenticare di configurare correttamente il Real IP può produrre un problema persino peggiore.

Il backend potrebbe infatti iniziare a considerare come indirizzo del visitatore quello del reverse proxy.

In presenza di Cloudflare, l’header CF-Connecting-IP contiene normalmente l’indirizzo del client che si è collegato all’edge Cloudflare. Se il client è arrivato in IPv6, tale valore può quindi essere un IPv6.

Il web server deve essere configurato affinché gli indirizzi provenienti dai proxy autorizzati vengano trattati correttamente e l’IP originale sia ripristinato.

Con NGINX questo avviene normalmente attraverso il modulo Real IP e una configurazione analoga concettualmente a:

real_ip_header CF-Connecting-IP;

set_real_ip_from RETE_CLOUDFLARE;
set_real_ip_from ALTRA_RETE_CLOUDFLARE;

Naturalmente le reti considerate trusted devono essere esclusivamente quelle ufficiali del proxy utilizzato e devono essere mantenute aggiornate.

Una volta ripristinato correttamente il Real IP, applicazione, PHP, logging e componente CAPI possono lavorare sull’indirizzo reale del visitatore anziché sull’indirizzo della CDN.

Questo è un dettaglio infrastrutturale che può avere conseguenze su tracking, rate limiting, sistemi antifrode, geolocalizzazione, sicurezza e analisi dei log.

Attenzione anche a Pseudo IPv4

Cloudflare mette a disposizione una funzione denominata Pseudo IPv4, pensata per applicazioni legacy che non riescono a elaborare indirizzi IPv6.

È una funzione utile quando si devono mantenere software nati esclusivamente per IPv4, ma deve essere compresa bene.

Con la modalità Overwrite Headers, Cloudflare può sostituire CF-Connecting-IP e X-Forwarded-For con uno pseudo-indirizzo IPv4, conservando l’IPv6 reale nell’header CF-Connecting-IPv6.

Se l’applicazione supporta correttamente IPv6 e l’obiettivo è conservare il miglior dato possibile sul client, trasformare inutilmente l’indirizzo IPv6 in uno pseudo IPv4 non offre alcun vantaggio.

È quindi importante conoscere l’intera catena:

client → CDN → reverse proxy → web server → applicazione → tracking server-side

Un solo componente che normalizza o sostituisce impropriamente l’indirizzo può cambiare il dato successivamente inviato alle piattaforme di advertising.

Le best practice per un e-commerce moderno

Una buona architettura non dovrebbe cercare di affidare l’attribuzione a un singolo segnale.

L’e-commerce dovrebbe essere raggiungibile in dual-stack direttamente oppure attraverso una CDN o un reverse proxy dual-stack. L’indirizzo originale del visitatore dovrebbe essere conservato correttamente attraverso l’intera catena dei proxy. I parametri provenienti dalle campagne non dovrebbero essere eliminati accidentalmente durante redirect e canonicalizzazioni.

_fbc e _fbp, quando previsti dalla configurazione e dal relativo regime di consenso, dovrebbero essere raccolti e trasmessi correttamente alla componente server-side. Pixel e CAPI dovrebbero utilizzare una strategia coerente di event_id e deduplicazione. Gli eventuali dati first-party utilizzabili per il matching dovrebbero essere gestiti nel rispetto delle specifiche della piattaforma e della normativa applicabile.

Infine è essenziale verificare che la CAPI riceva l’indirizzo IP del client e non l’indirizzo di NGINX, Varnish, HAProxy, Cloudflare, un load balancer interno o il server applicativo stesso.

La qualità del tracking nasce dall’insieme di tutti questi elementi.

Come verificare se il proprio e-commerce è IPv6

Il test più banale consiste nel controllare il DNS.

Su Linux:

dig A [www.example.com](http://www.example.com)
dig AAAA [www.example.com](http://www.example.com)

Se il primo comando restituisce un indirizzo IPv4 e il secondo non restituisce alcun indirizzo IPv6, il sito è presumibilmente pubblicato solamente attraverso IPv4.

È possibile effettuare anche un controllo HTTP vero e proprio:

curl -4 -I https://www.example.com/
curl -6 -I https://www.example.com/

Entrambi dovrebbero riuscire su un frontend realmente dual-stack.

A livello NGINX, in un server direttamente esposto a Internet, possiamo trovare ad esempio listener IPv4 e IPv6:

listen 443 ssl;
listen [::]:443 ssl;

Naturalmente avere il listen IPv6 non è sufficiente: server, routing, firewall e DNS devono essere configurati correttamente.

Su un’infrastruttura dietro CDN la verifica dovrà invece tenere conto del fatto che il frontend pubblico e l’origin sono due elementi differenti. È perfettamente normale avere il sito pubblicamente raggiungibile in IPv6 mentre l’origin accetta esclusivamente connessioni IPv4 dalla CDN.

IPv6 migliora direttamente il conversion rate?

Qui è necessaria molta prudenza.

Non esistono, almeno allo stato della documentazione pubblica che abbiamo analizzato, dati affidabili che permettano di sostenere qualcosa del tipo:

“abilitando IPv6 aumenterete le conversioni del 5%”.

Sarebbe una conclusione commercialmente accattivante ma tecnicamente priva di fondamento.

L’abilitazione IPv6 non convince un cliente ad acquistare un prodotto che non vuole e non modifica direttamente il funnel commerciale.

Esiste però una distinzione fondamentale tra conversione e conversione attribuita.

Se dieci persone acquistano, il negozio ha realizzato dieci conversioni indipendentemente da ciò che appare in Meta Ads Manager.

Se Meta riesce ad attribuirne correttamente soltanto otto, dal punto di vista del sistema pubblicitario ne risultano otto.

Il fatturato reale non è scomparso, ma il dataset utilizzato per misurare e ottimizzare la campagna è diventato meno completo.

È su questo secondo aspetto che IPv6 può avere un ruolo.

Mantenere una connettività IPv6 nativa evita una traduzione inutile e consente di preservare un segnale che Meta stessa dichiara di preferire rispetto a IPv4 quando disponibile.

Non significa che IPv6 sia indispensabile per Meta Ads.

Significa che un’infrastruttura moderna dovrebbe evitare di degradare un’informazione disponibile senza avere una buona ragione tecnica per farlo.

IPv6 come parte della Web Performance e non soltanto del networking

Noi di Managed Server abbiamo sempre considerato le performance di un sito come il risultato dell’intero stack e non semplicemente della potenza della CPU o della quantità di RAM installata.

DNS, TCP, TLS, HTTP/2, HTTP/3, QUIC, CDN, caching, web server, PHP, database e applicazione partecipano tutti all’esperienza finale.

IPv6 appartiene allo stesso livello infrastrutturale.

Per molto tempo è stato trattato quasi esclusivamente come un argomento da network engineer. Oggi interessa invece anche chi gestisce e-commerce, advertising, analytics e sistemi antifrode.

In una moderna architettura web non dovremmo più chiederci semplicemente:

“Il sito funziona?”

Dovremmo chiederci:

“Il sito funziona correttamente attraverso tutte le modalità di connessione normalmente utilizzate dai suoi utenti?”

Se una quota importante dei potenziali clienti arriva da smartphone con connettività IPv6 e le principali piattaforme pubblicitarie comunicano nativamente attraverso IPv6, mantenere il frontend esclusivamente IPv4 diventa sempre più difficile da giustificare.

Un problema che diventerà sempre più rilevante

IPv4 non sparirà domani.

Esiste un’enorme quantità di infrastrutture, software e dispositivi che continueranno a utilizzarlo ancora per molti anni.

La tendenza però è chiara.

Gli indirizzi IPv4 sono una risorsa scarsa. Le reti degli operatori utilizzano sempre più frequentemente IPv6 e tecnologie di transizione. Le grandi piattaforme Internet sono dual-stack da anni. Una quota crescente degli utenti è perfettamente in grado di comunicare direttamente in IPv6.

Allo stesso tempo, secondo W3Techs, nel settembre 2026 meno di un sito su tre nel campione complessivo risultava ancora dotato di supporto IPv6, mentre tra i siti con maggiore traffico la percentuale era sensibilmente superiore.

È una fotografia molto chiara della fase di transizione in cui ci troviamo.

Gli utenti sono più avanti di una parte dell’infrastruttura web.

Per un piccolo sito istituzionale questo può sembrare irrilevante. Per un e-commerce che investe migliaia o decine di migliaia di euro ogni mese in advertising, ogni elemento capace di migliorare qualità e continuità dei dati dovrebbe invece essere valutato.

Conclusioni

Il fatto che un utente navighi su Facebook o Instagram attraverso IPv6 e raggiunga successivamente un e-commerce IPv4-only non impedisce l’acquisto e non provoca automaticamente la perdita della conversione.

Il sistema operativo e la rete dell’operatore permettono normalmente di raggiungere senza problemi il server IPv4 attraverso meccanismi dual-stack o tecnologie come NAT64 e 464XLAT.

Il server dell’e-commerce può però osservare un IPv4 diverso dall’IPv6 utilizzato pochi istanti prima verso Meta. Quell’IPv4 può inoltre essere condiviso attraverso Carrier Grade NAT con numerosi altri utenti.

Questo rende il segnale di rete potenzialmente meno preciso.

Meta non si affida esclusivamente all’indirizzo IP e utilizza una combinazione di segnali, motivo per cui una corretta implementazione di Pixel, Conversions API, _fbc, _fbp, event_id, User-Agent e identificatori first-party rimane decisamente più importante della semplice presenza di IPv6.

Ma la stessa documentazione tecnica ufficiale Meta consiglia di preferire IPv6 perché più preciso rispetto a IPv4, utilizzando IPv4 come fallback.

Per questo consideriamo il dual-stack una best practice anche per gli e-commerce.

Quando possibile, il frontend pubblico dovrebbe accettare sia IPv4 sia IPv6. Dove l’infrastruttura origin è ancora IPv4-only, una CDN o un reverse proxy dual-stack può offrire IPv6 agli utenti continuando a comunicare con il backend attraverso IPv4.

Il vero IP del visitatore deve poi essere preservato correttamente attraverso tutta la catena infrastrutturale e consegnato alla componente applicativa e ai sistemi server-side che ne hanno legittimamente necessità.

Non stiamo parlando di un trucco per aumentare magicamente il conversion rate.

Stiamo parlando di qualità dell’infrastruttura, qualità del dato e riduzione delle discontinuità all’interno di un ecosistema pubblicitario sempre più complesso.

E quando un e-commerce investe cifre importanti per acquistare traffico, avere un’infrastruttura in grado di preservare nel modo più corretto possibile i segnali generati da quel traffico non dovrebbe essere considerato un dettaglio.

Fonti e riferimenti tecnici

• Google, IPv6 Adoption Statistics: Google misura continuamente la quota dei propri utenti che raggiunge i servizi attraverso IPv6; nel giugno 2026 il dato aveva superato il 50%.
• APNIC Labs, IPv6 Measurement: statistiche mondiali e per nazione sulla capacità e preferenza IPv6.
• W3Techs, Usage Statistics of IPv6 for Websites: statistiche sull’adozione IPv6 dei siti web e distribuzione in funzione della popolarità, CMS e web panel.
• Meta, CAPI Parameter Builder: implementazione di riferimento che raccomanda di preferire l’indirizzo IPv6 del client rispetto a IPv4 quando disponibile.
• IETF RFC 6877, 464XLAT: Combination of Stateful and Stateless Translation: descrive l’architettura utilizzata per fornire accesso a risorse IPv4 attraverso reti IPv6.
• IETF RFC 8305, Happy Eyeballs Version 2: descrive gli algoritmi utilizzati dai client dual-stack per gestire connessioni IPv4 e IPv6 riducendo ritardi e problemi di raggiungibilità.
• RIPE NCC, IPv4 Run-Out: documentazione sull’esaurimento del pool IPv4 disponibile nella regione RIPE avvenuto nel novembre 2019.
• Cloudflare, IPv6 Compatibility, HTTP Headers, Pseudo IPv4 e Restoring Original Visitor IPs: documentazione sul frontend IPv6, CF-Connecting-IP, CF-Connecting-IPv6 e gestione degli origin IPv4.