Meta (Facebook) Event Manager Warning: IPv6 is preferable over IPv4 for IPv6-enabled users
Some Facebook marketers have seen the following warning message in their Facebook Event Manager:
Change IPv4 addresses for AddToCart events to IPv6. IPv6 is preferable over IPv4 for IPv6-enabled users. IPv6 is currently the industry-accepted standard and offers durability for your integration.
The short message makes it sound simple, but what does it mean? And how do you do it? How simple is it? And how did we implement it in the Pixel Manager?
This is what we'll cover in this article.
This solution is available in the Pro version of the Pixel Manager from version 1.35.1 onwards.
An example of the warning message
Here's what the warning message looks like in the Facebook Event Manager:
And here's what Facebook suggests on how to fix it:
Looks simple, right?
Let me tell you, there is so much to unpack here. And Facebook doesn't help with their documentation. Let alone the fact that the "fix" is only for a small subset of the events you can send to Facebook and that it probably won't do much to improve your results.
What is IPv6?
IPv6 is the latest version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion. IPv4 address range is 32-bit, which allows for 4.3 billion unique IP addresses. The IPv6 system uses 128-bit addresses, which allows for approximately 3.4×10^38 addresses. This is a huge number and should be enough for the foreseeable future.
Here's an example of an IPv4 address:
192.168.1.1
Here's an example of an IPv6 address:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
Facebook Warning: Report the IPv6 address of the user instead of the IPv4 address
Here's where it gets tricky. IPv6 has been around for a while but is not widely adopted. Most users still use IPv4. (And there is nothing you can do about it. It is the users's ISP that decides which protocol is available.)
Today, most users have either an IPv4 address or an IPv6 address. Due to some smart engineering, some ISPs offer IPv4 and IPv6 addresses for the same clients. This is called dual-stack.
In a dual-stack configuration, it is the user's browser that decides which address to use. It depends on the entire network path between the user and the server. If the entire path supports IPv6, the browser will likely use IPv6 (but not necessarily).
While Facebook didn't make it very clear when to report the IPv6, it is clear to me that Facebook only tries to address those events for users that have both an IPv4 and an IPv6 address, which is only possible in a dual-stack configuration. For all other IPv4 users, there is no IPv6 address to report. For the remaining IPv6 users, the IPv6 address is already reported.
Why does Facebook want the IPv6 address?
Facebook doesn't say why they want the IPv6 address. But I can think only of one reason: to improve the matching accuracy between the visitor and the Facebook user.
Since IPv6 is more unique and identifies a single device, not just a network, it is more accurate than the IPv4 address. So it makes it a much better identifier for the user. (User devices usually are behind a NAT router, meaning that multiple devices share the same IPv4 address. IPv6 usually gets a unique address for each device.)
How to get the IPv6 address from a dual-stack user?
Many Facebook CAPI implementations use server-side logic to send events to Facebook. Naturally, the server knows the IPv4 address of the client that's connected to the server. So, one would think that it is easy for the server to request the IPv6 address from the client. But this is not the case. The server has no control over how the client connects to the server, and there is no technical way for the server to request the IPv6 address from the client if they are already connected through IPv4.
Fortunately, there is another way to get the IPv6 address of the client. The server can add a script to the website viewed by the browser (the client) which is then run in the browser to determine the IPv6 address of the client and sends it to the server. The server can then send the IPv6 address to Facebook.
But, again, this is not as easy as it sounds. There is no function in modern browsers that simply returns the IPv6 address of the client.
The only way is to request the IP information from one of many, free-to-use, IP information services. These services return the IP address of the client that requested the information.
But it's getting more complicated. Some of those services just return the current IP address of the client, and in the dual-stack configuration it could still be the IPv4 address. Remember, the browser decides which address to use. So, even if the client has an IPv6 address, the browser could still use the IPv4 address to connect to the IP information server.
Luckily, some IP information services have a solution for this. They offer servers that are only accessible via IPv6. Connection requests through IPv4 get refused. So, if the client can connect to such a server, it must have an IPv6 address. If the IP information server returns the IPv6 address, it is the IPv6 address of the client.
Which service to use to get the IPv6 address?
There are many IP information services. However, only a few offer IPv6-only servers that reliably return the IPv6 address of the client (if an IPv6 address is available on the client side).
Many of those services are paid services. But there are a few free services. And because our detection script will run on browsers of our users we can't use a paid service. We couldn't use any form of authentication. Plus we would not be able to pay for the traffic. So we need to use a free service. This shortens the list of services to just a few.
But it's getting even more complicated. Not all of those IP information services allow to be accessed from browsers as those servers are protected by CORS. So the list of services is even shorter.
But things are getting even more complicated. Some of those IP information services get blacklisted regularly because they often are used by malware authors, even though the IP information services are not malicious themselves. Here's an interesting story about one of those IP information services called icanhazip.com: A new future for icanhazip. So, we need to ensure that if a browser denies access to the IP information service, we can fall back to another service.
After a lot of research, here's a very short list of IP information services to retrieve the IPv6 address that we use in the Pixel Manager:
There may be more such services around. But those two are certainly the most reliable and fastest ones. They can handle billions of requests per day. And they are free to use.
Please let us know if you know of a service that needs to be added to this list. The more we have, the more reliable our detection script will be.
How to implement the IPv6 detection script?
Nothing comes for free. Even this part is more complex than I hoped it would be.
Because we want the IPv6 check to be as fast as possible and not block any other scripts from executing, we don't check each service one after the other. Instead, we use the relatively new Promise.any() function to check all services simultaneously and return as soon as we have the first valid result. Since Promise.any() is not supported by all browsers yet, it usually would be too risky to rely on it. Luckily in the Pixel Manager, we can rely on it because the Pixel Manager's library is compiled with Babel, which allows us to automatically use polyfills for functions not supported by all browsers yet.
Unfortunately, this solution will not work for Google Tag Manager implementations since the GTM doesn't allow the use of functions like Promise.any() or compiled libraries directly. One could prepare such a library, host it on a server, and then load it in the GTM. This would add more complexity and dependency to the implementation. Especially making this a reliable solution for all browsers would be a challenge. Sure, you could just implement requests to https://ipv6.icanhazip.com, for instance. But that would also be less reliable than our approach, which currently uses two services for this task.
Conclusion
Even after having researched all of this and having implemented it in the Pixel Manager, I still don't know if it is worth the effort. I learned a lot about IPv6 and how to detect it in the browser. But does it really help Facebook marketers to comply with Facebook's request to report the IPv6 where available?
Here are some of my thoughts:
- I'm unsure if Facebook will remove the warning message after implementing this. After all, it could be a bug on their side, which would be nothing new. Or they might have a different "opinion" for which browsers an IPv6 can be reported. In that case, our approach to detecting dual-stack configurations and reporting the IPv6 would not remove the warning. Again, Facebook is very vague on what they want and how to achieve it.
- I'm unsure if reporting the IPv6 address (for IPv4 connections) will significantly improve the matching accuracy between the visitor and the Facebook user. It probably will improve it, but just a tiny bit.
- Even if it improves the matching accuracy, I don't believe it will significantly impact campaign performance.
One thing is for sure. Users of our Pixel Manager can now comply with Facebook's request to report the IPv6 address where available. It is a very robust solution that works in all browsers. The methods we implemented into the Pixel Manager will be available for future use cases where we must detect and process a browser's IP address.
