IPv6, Facebook Ads, and e-commerce conversions: When IPv4-only hosting can worsen tracking

In the e-commerce world, we're used to talking about conversion rates, Meta Ads campaigns, Google Ads, Pixels, server-side tracking, first-party cookies, and Conversions APIs. Much less often, however, we ask ourselves what happens a few levels lower down, in the network that physically transports requests between smartphones, advertising platforms, CDNs, and e-commerce servers.

One of the most interesting issues concerns IPv6.

Today, a significant portion of Internet users, especially mobile users, already use IPv6. Facebook, Instagram, Google, and the world's major platforms are fully accessible via IPv6. Many websites, however, continue to be published exclusively via IPv4.

This creates a peculiar scenario: a user can browse Facebook using an IPv6 address, click on an ad, and immediately reach an e-commerce site only available in IPv4. The e-commerce server could then observe a completely different IP address from the one the same device was using just moments before communicating with Meta.

Your purchase will continue to function normally. The product will be added to your cart, checkout will be accessible, and payment can be completed.

The interesting question is another:

Could this discontinuity between IPv6 and IPv4 make tracking and therefore conversion attribution less accurate?

The answer is yes, at least potentially. But we need to understand to what extent and, above all, avoid the simplistic conclusion that an IPv4-only site "automatically loses Facebook conversions."

The problem is more subtle and concerns the quality of the signals used to recognize a user and associate a conversion with a previous advertising interaction.

Why tracking is so important for e-commerce

An e-commerce platform shouldn't just sell. It should also be able to understand, to the extent technically and legally possible, where those sales come from.

If an online store invests €20.000 in advertising every month, knowing that 500 orders have been received isn't enough. It's important to determine which campaigns, which ads, which audiences, and which traffic sources contributed to generating them.

This is where systems like Meta Pixel, Meta Conversions API, Google Ads Conversion Tracking, Google Analytics, and the numerous analytics and advertising platforms used daily by e-commerce businesses come into play.

When a user clicks on a Facebook or Instagram ad and subsequently makes a purchase, Meta tries to correlate the two events.

In an ideal world we would have a perfectly recognizable sequence:

Facebook displays an ad, the user clicks it, lands on the e-commerce site, visits a product, adds the product to the cart, starts checkout, and completes the order.

The more clearly Meta can associate these events with the same user or advertising path, the better the attribution will be.

This is important not only for producing better-looking statistics in the Ads Manager panel.

Conversion data is also used by advertising platforms' automated systems to optimize campaign distribution . If the system receives incomplete or lower-quality conversion signals, it may have less information about the characteristics of users who actually purchase.

For this reason, in recent years the e-commerce ecosystem has progressively moved from the simple Pixel running in the browser to more complex implementations that also include the server-side sending of events through tools such as the Meta Conversions API , commonly abbreviated to CAPI.

And it is precisely in server-side tracking that the visitor's IP address becomes a particularly interesting parameter again.

IPv4 and IPv6 explained briefly

Every device that communicates over the Internet uses the IP protocol.

For many years, the Internet was built almost entirely around IPv4 , a protocol that uses 32-bit addresses such as:

192.0.2.123

The theoretical available space is approximately 4,3 billion addresses. This number may have seemed enormous at the dawn of the Internet, but it has become insufficient with billions of computers, smartphones, routers, servers, IoT devices, and connected infrastructure.

The problem isn't theoretical. In Europe, the RIPE NCC exhausted its available pool of new IPv4 addresses in November 2019. Since then, growth has continued through reclaiming and moving existing addresses, NAT, Carrier Grade NAT, and other techniques that allow the limited IPv4 space to be shared.

IPv6 was born precisely to overcome this limitation.

Use 128-bit addresses, for example:

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

The address space becomes so large that it practically eliminates the sparsity problem that characterizes IPv4.

IPv6 is therefore not simply a new notation for indicating an IP address: it represents a fundamental evolution of the Internet infrastructure.

The migration, however, didn't happen overnight by replacing IPv4. Both protocols have coexisted for decades.

And it is this coexistence that makes the tracking problem interesting.

IPv6 is no longer a fringe technology

For many years, IPv6 was perceived by website administrators as something that could be implemented “later.”

Today this position is much more difficult to sustain.

Google continuously measures the percentage of its users who access Google services over IPv6. As of June 13, 2026, it had already detected 50,29% of accesses over native IPv6.

Measurement methodologies can produce different percentages. APNIC, for example, uses its own measurement systems and estimates global IPv6 capability of over 40% by September 2026.

So, there's no need to get hung up on a single number. The important thing is the order of magnitude: IPv6 now covers hundreds of millions of users and a huge share of global Internet traffic.

This is particularly important in the mobile world, where IPv6-only, NAT64, and 464XLAT technologies allow operators to limit the need for public IPv4 addresses.

Facebook, Instagram, Google and many other major platforms are of course reachable via IPv6.

The Web as a whole, however, presents a very different situation.

Users are increasingly IPv6-only, but many sites are still IPv4-only

As of September 2026, W3Techs detects IPv6 support on approximately 31,5% of analyzed websites .

The situation improves considerably when looking at the most important sites: IPv6 is present on 44,2% of the top 1 million sites, on 52,9% of the top 100.000 and on 56,6% of the top 10.000.

These data show an interesting phenomenon.

IPv6 availability grows with the size and relevance of the site.

The major platforms have long invested in dual-stack infrastructure, while a significant portion of the traditional web continues to run solely on IPv4.

According to W3Techs, as of July 2026, only 13,7% of sites detected with cPanel and 19,1% of those with Plesk were using IPv6. These statistics shouldn't be interpreted as an intrinsic limitation of the two panels, but they clearly illustrate how much of the traditional hosting ecosystem remains heavily IPv4-centric.

WordPress, taken as a whole, also showed an IPv6 presence of approximately 32,9% as of June 2026.

It is therefore perfectly plausible that a modern smartphone uses IPv6 for Facebook, Instagram, or Google, and is immediately forced to use IPv4 when it opens the advertiser's site.

Why many hosting providers are still IPv4-only

The problem is rarely the Linux kernel or the web server.

Linux, NGINX, Apache, HAProxy, Varnish, PHP and major databases have supported IPv6 for a very long time.

The limitation is often in the overall hosting architecture.

Many shared hosting platforms emerged when IPv4 was still considered the absolute standard. Virtual host configurations, DNS systems, firewalls, provisioning software, control panels, statistics, anti-fraud systems, legacy applications, and operational procedures were built around the IPv4 address.

Adding IPv6 therefore does not simply mean assigning an address to the server.

This means making sure your DNS, firewall, monitoring, logging, rate limiting, reverse proxy, applications, and security software handle it properly.

Modern hosting should be designed to treat IPv4 and IPv6 as two standard modes of access to the same service. In many older infrastructures, however, IPv6 is still treated as an optional extra.

For years, this shortcoming had little obvious consequences for the site owner: thanks to transition technologies, an IPv6 user was still able to open virtually any IPv4 site.

Today, however, there are additional reasons to be interested in it. One of these is the continuity of the data used in server-side tracking.

What Happens When Facebook Sees IPv6 But E-Commerce Is IPv4-Only

Let's consider a user who uses Facebook from the application installed on his smartphone.

The mobile network provides IPv6 connectivity and Facebook is therefore reached directly through IPv6.

We can imagine that, during this phase, the device is identifiable on the network through an address of the type:

2a01:xxxx:xxxx:xxxx::1234

The user sees an advertising campaign, clicks and is directed to:

https://www.ecommerce.it/

However, the e-commerce DNS only has one A record:

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

There is no AAAA record.

At this point the device needs to reach a resource that is only available in IPv4.

On many modern mobile networks this is done through systems such as 464XLAT , standardized by the IETF in RFC 6877.

464XLAT combines a client-side translation, called CLAT, with a carrier-side translation, called PLAT. The latter can perform an N:1 translation, thus making more IPv6 sources appear through a much more limited number of public IPv4 addresses.

The practical result is simple.

Facebook may have communicated with:

2a01:xxxx:xxxx:xxxx::1234

while the e-commerce web server records:

93.45.120.38

The two addresses have no obvious similarity.

And most importantly, that IPv4 could be shared, through the operator's infrastructure, with numerous other users.

Does this mean Meta automatically loses conversions?

No.

This is probably the most important point of the entire article.

The IP address isn't the only data that can be used to correlate clicks, sessions, and conversion events.

If the tracking infrastructure is built correctly, Meta can receive various signals.

Among these we find identifiers derived from advertising clicks, cookies such as _fbc e _fbp, browser User-Agent, event URL, first-party identifiers, any customer data appropriately normalized and hashed where applicable, as well as the IP address.

In the case of the Conversions API, a event_id shared between browser-side Pixel and server-side event to enable deduplication of the same event.

A change in IP address between browsing Facebook and arriving at the site does not therefore automatically equate to a loss of attribution.

A user could log in to Facebook from a mobile network, open the site over Wi-Fi, switch networks during checkout, or use privacy technologies that change the observable address.

A global advertising system cannot realistically be based on the assumption that IP is immutable.

The IP address should be considered one of the matching signals , not a universally stable primary key.

The problem arises when, along with the IP address discontinuity, other signals are also lost.

Why a shared IPv4 can still be a worse signal

However, there is a substantial difference between saying that IP is not the only identifier and maintaining that any IP has the same information quality.

Meta itself provides an extremely interesting guide within its official CAPI Parameter Builder project.

When talking about collecting the client's IP address, the documentation recommends:

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

In other words: prefer IPv6, because it is more precise, using IPv4 as a fallback.

The technical reason is easily understandable.

An IPv4 address can be behind Carrier Grade NAT and represent many subscribers at the same time.

An IPv6 address generally offers greater granularity from the network source perspective, while not being intended as a permanent personal identifier: IPv6 addresses can change, there are privacy extensions, dynamic prefixes, and numerous other variables.

Meta's recommendation is significant, however, because it demonstrates that, for the purposes of their CAPI metrics collection system, IPv6 is considered a preferable signal over IPv4 when available.

And this makes it less negligible that IPv4-only hosting can transform a user originally reachable via IPv6 into a visitor observable by the site only via a shared IPv4.

Pixel and Conversions API can even see two different IP families

There is another scenario that makes the issue even more interesting.

Let's assume that e-commerce is IPv4 only.

The browser reaches:

www.ecommerce.it

via IPv4.

Once the page is loaded, Meta Pixel is executed.

The browser must then communicate directly with Meta infrastructures, which support IPv6.

Nothing prevents such a situation from occurring:

For the same conversion, different network observations can therefore exist simultaneously.

This doesn't necessarily mean something isn't working. Meta has the other event parameters and, especially with a proper Pixel + CAPI configuration, the ability to deduplicate and correlate information.

But it shows how wrong it is to think of modern tracking as something that depends on a single IP address.

The real problem case: when multiple signals are lost at the same time

An IPv4-only infrastructure becomes more negatively interesting when coupled with other implementation errors.

Let's imagine a user coming from Facebook in IPv6.

You click on the ad, but a poorly configured redirect deletes the parameters used to store the click source. The system doesn't properly store _fbc. _fbp is not collected or transmitted to the server-side component. There is no external_idThe user has not yet authenticated, so there are no other deterministic identifiers available for integration. Finally, CAPI only sends the User-Agent and a shared IPv4 from the operator's CGNAT.

At this point the quality of the matching can be much lower.

Not because IPv4 technically prevents tracking, but because there is very little left to match with.

The correct question to ask is therefore not:

“Does a site without IPv6 lose Facebook conversions?”

The most technically correct question is:

“Can an IPv4-only site eliminate or make less accurate one of the signals that contribute to correct conversion attribution?”

The answer to this question is yes.

Beware of redirects: losing your click identifier is probably worse than changing your IP address.

In our experience as systems engineers, it is common to focus on complex tools while forgetting much more trivial infrastructure problems.

One example is redirects.

The user arrives from a campaign via a URL containing the parameters needed for attribution. Before reaching the application, they may go through several steps:

• HTTP → HTTPS;
• domain without www → domain with www;
• landing page → canonical URL;
• tracking system → e-commerce;
• WordPress/WooCommerce application or plugin redirect.

If one of these components misconstructs the URL and discards the query string, an extremely valuable signal can disappear before the tracking system has even had a chance to preserve it.

In practical terms, a perfectly dual-stack e-commerce site with a flawed redirect chain can have worse tracking than an IPv4-only e-commerce site with a correct CAPI implementation.

IPv6 should therefore be considered a piece of a correct architecture , not a magic solution.

Dual-stack: the most technically natural solution

The ideal configuration for a modern public web service remains dual-stack.

Both the IPv4 A record and the IPv6 AAAA record are published in the DNS.

For example:

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

A client that has IPv6 will be able to connect using IPv6, while a client that only has IPv4 will continue to use IPv4 normally.

Modern operating systems and browsers implement algorithms belonging to the Happy Eyeballs family , formalized in RFC 8305, which query A and AAAA and manage connection attempts across the different IP families trying to avoid user-perceivable delays and favoring IPv6 when appropriate.

There is therefore no need to choose between IPv4 users and IPv6 users.

Both are offered.

For an e-commerce site, this means allowing a smartphone that was already communicating natively in IPv6 with Facebook or Instagram to continue to reach the store via IPv6, instead of forcing it to go through an IPv4 compatibility mechanism.

You do not need to have IPv6 on the origin to offer IPv6 to users

This point is particularly important because it allows you to solve the problem even in the presence of legacy infrastructures.

An e-commerce site can be publicly reachable via IPv6 even when the origin server remains exclusively IPv4.

All that is needed is a reverse proxy or a dual-stack CDN in front of the origin.

A very popular example is Cloudflare.

With IPv6 Compatibility enabled, Cloudflare automatically generates AAAA connectivity for proxied records, allowing IPv6 clients to connect to its edge network. Subsequent connections between Cloudflare and the origin can continue to use IPv4.

The architecture then becomes:

Utente IPv6 → Cloudflare IPv6 → origin IPv4

From an internal infrastructure perspective, it is not necessary to immediately migrate every single server to IPv6.

The Internet frontend becomes dual-stack while the backend can continue, at least temporarily, to run on IPv4.

This is an extremely useful strategy during a gradual migration.

However, the reverse proxy must retain the visitor's real IP address.

Putting a CDN in front of your e-commerce site and forgetting to properly configure the Real IP can lead to an even worse problem.

The backend could in fact start considering the reverse proxy address as the visitor's address.

In the presence of Cloudflare, the header CF-Connecting-IP It typically contains the address of the client that connected to the Cloudflare edge. If the client arrived via IPv6, this value may be IPv6.

The web server must be configured so that addresses from authorized proxies are treated correctly and the original IP is restored.

With NGINX this is normally done through the Real IP module and a configuration conceptually similar to:

real_ip_header CF-Connecting-IP;

set_real_ip_from RETE_CLOUDFLARE;
set_real_ip_from ALTRA_RETE_CLOUDFLARE;

Naturally, the networks considered trusted must be exclusively the official ones of the proxy used and must be kept up to date.

Once the Real IP is successfully restored, the application, PHP, logging, and CAPI component can work on the visitor's real address instead of the CDN address.

This is an infrastructure detail that can have consequences on tracking, rate limiting, anti-fraud systems, geolocation, security and log analysis.

Beware of Pseudo IPv4 too

Cloudflare offers a feature called Pseudo IPv4 , which is intended for legacy applications that cannot process IPv6 addresses.

This is a useful feature when maintaining software designed exclusively for IPv4, but it must be well understood.

With the mode Overwrite Headers, Cloudflare can replace CF-Connecting-IP e X-Forwarded-For with a pseudo-IPv4 address, keeping the real IPv6 in the header CF-Connecting-IPv6.

If the application properly supports IPv6 and the goal is to preserve the best possible data on the client, needlessly transforming the IPv6 address into a pseudo IPv4 offers no advantage.

It is therefore important to know the entire chain:

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

A single component that improperly normalizes or replaces the address can change the data subsequently sent to advertising platforms.

Best practices for modern e-commerce

A good architecture should not try to rely on a single signal for attribution.

E-commerce should be accessible in dual-stack mode, either directly or through a CDN or a dual-stack reverse proxy. The visitor's original address should be preserved correctly across the entire proxy chain. Parameters from campaigns should not be accidentally deleted during redirects and canonicalizations.

_fbc e _fbp, when provided for by the configuration and the related consent regime, should be collected and transmitted correctly to the server-side component. Pixel and CAPI should use a consistent strategy of event_id and deduplication. Any first-party data used for matching should be managed in compliance with platform specifications and applicable regulations.

Finally, it is essential to verify that the CAPI receives the client's IP address and not the address of NGINX, Varnish, HAProxy, Cloudflare, an internal load balancer, or the application server itself.

Tracking quality comes from the combination of all these elements.

How to check if your e-commerce site is IPv6-enabled

The most basic test is to check the DNS.

On Linux:

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

If the first command returns an IPv4 address and the second returns no IPv6 address, the site is presumably served via IPv4 only.

You can also perform a real HTTP check:

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

Both should work on a truly dual-stack frontend.

At the NGINX level, in a server directly exposed to the Internet, we can find for example IPv4 and IPv6 listeners:

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

Of course having the listen IPv6 is not enough: servers, routing, firewalls and DNS must be configured correctly.

On a CDN-backed infrastructure, however, verification must take into account that the public frontend and the origin are two different elements. It's perfectly normal for the site to be publicly accessible in IPv6 while the origin only accepts IPv4 connections from the CDN.

Does IPv6 directly improve conversion rates?

Great caution is required here.

There is no reliable data, at least in the state of the public documentation we have analyzed, that allows us to support something like this:

“enabling IPv6 will increase conversions by 5%.”

It would be a commercially appealing but technically unfounded conclusion.

IPv6 enablement doesn't convince a customer to buy a product they don't want, and it doesn't directly change the sales funnel.

However, there is a fundamental distinction between conversion and attributed conversion.

If ten people purchase, the store has achieved ten conversions regardless of what appears in Meta Ads Manager.

If Meta can only correctly attribute eight of them, from the advertising system's perspective, that makes eight.

Actual revenue hasn't disappeared, but the dataset used to measure and optimize the campaign has become less complete.

It is in this second aspect that IPv6 can play a role.

Maintaining native IPv6 connectivity avoids unnecessary translation and preserves a signal that Meta itself claims to prefer over IPv4 when available.

This does not mean that IPv6 is essential for Meta Ads.

This means that a modern infrastructure should avoid degrading available information without having a good technical reason to do so.

IPv6 as part of Web Performance and not just networking

At Managed Server, we have always considered a site's performance to be the result of the entire stack, not simply the CPU power or amount of RAM installed.

DNS, TCP, TLS, HTTP/2, HTTP/3, QUIC, CDN, caching, web server, PHP, database, and application all contribute to the final experience.

IPv6 belongs to the same infrastructure layer.

For a long time, it was treated almost exclusively as a topic for network engineers. Today, however, it also concerns those managing e-commerce, advertising, analytics, and anti-fraud systems.

In a modern web architecture we should no longer simply ask ourselves:

“Is the site working?”

We should ask ourselves:

“Does the site function properly across all connection methods typically used by its users?”

If a significant portion of potential customers come from smartphones with IPv6 connectivity and major advertising platforms communicate natively via IPv6, keeping the frontend exclusively IPv4 becomes increasingly difficult to justify.

A problem that will become increasingly relevant

IPv4 won't go away tomorrow.

There is a huge amount of infrastructure, software, and devices that will continue to use it for many years to come.

The trend, however, is clear.

IPv4 addresses are a scarce resource. Operator networks are increasingly using IPv6 and transition technologies. Major Internet platforms have been dual-stacking for years. A growing share of users are perfectly capable of communicating directly in IPv6.

At the same time, according to W3Techs, as of September 2026, fewer than one in three sites in the overall sample still had IPv6 support, while among the most trafficked sites the percentage was significantly higher.

It is a very clear photograph of the transition phase we are in.

Users are ahead of some of the web infrastructure.

For a small institutional website, this may seem irrelevant. For an e-commerce site investing thousands or tens of thousands of euros in advertising each month, every element capable of improving data quality and consistency should be evaluated.

Conclusions

The fact that a user browses Facebook or Instagram via IPv6 and subsequently reaches an IPv4-only e-commerce site does not prevent the purchase and does not automatically cause the conversion to be lost.

The operator's operating system and network usually allow you to reach the IPv4 server without problems through dual-stack mechanisms or technologies such as NAT64 and 464XLAT.

However, the e-commerce server may observe a different IPv4 than the IPv6 it was using a few moments earlier towards Meta. That IPv4 may also be shared via Carrier Grade NAT with numerous other users.

This makes the network signal potentially less accurate.

Meta does not rely solely on the IP address and uses a combination of signals, which is why a proper implementation of Pixel, Conversions API, _fbc, _fbp, event_id, User-Agent and first-party identifiers remain far more important than the simple presence of IPv6.

But the official Meta technical documentation itself recommends preferring IPv6 because it is more precise than IPv4 , using IPv4 as a fallback.

This is why we consider dual-stack a best practice for e-commerce as well.

Whenever possible, the public frontend should accept both IPv4 and IPv6. Where the origin infrastructure is still IPv4-only, a CDN or dual-stack reverse proxy can offer IPv6 to users while still communicating with the backend over IPv4.

The visitor's true IP address must then be correctly preserved throughout the entire infrastructure chain and delivered to the application component and server-side systems that legitimately need it.

We're not talking about a trick to magically increase conversion rates.

We're talking about infrastructure quality, data quality, and reducing disruption within an increasingly complex advertising ecosystem.

And when an e-commerce site invests significant sums to acquire traffic, having an infrastructure capable of preserving the signals generated by that traffic as accurately as possible should not be considered a minor detail.

Sources and technical references

• Google IPv6 Adoption StatisticsGoogle continuously measures the share of its users accessing its services over IPv6; as of June 2026, the figure had exceeded 50%.
• APNIC Labs, IPv6 Measurement: Global and country statistics on IPv6 capacity and preference.
• W3Techs, Usage Statistics of IPv6 for Websites: Statistics on IPv6 adoption of websites and distribution by popularity, CMS and web panels.
• Goal, CAPI Parameter Builder: Reference implementation that recommends preferring the client's IPv6 address over IPv4 when available.
• IETF RFC 6877, 464XLAT: Combination of Stateful and Stateless Translation: Describes the architecture used to provide access to IPv4 resources across IPv6 networks.
• IETF RFC 8305, Happy Eyeballs Version 2: Describes the algorithms used by dual-stack clients to handle IPv4 and IPv6 connections while reducing delays and reachability issues.
• RIPE NCC, IPv4 Run-Out: Documentation of the exhaustion of the available IPv4 pool in the RIPE region in November 2019.
• cloudflare, IPv6 Compatibility, HTTP headers, Pseudo IPv4 e Restoring Original Visitor IPs: IPv6 frontend documentation, CF-Connecting-IP, CF-Connecting-IPv6 and IPv4 origin management.