In this blog post, Pixalate explains X-Forwarded-For (XFF) and the best practices as it relates to detecting, targeting and even blocking the IP addresses associated with programmatic advertising transactions to reduce ad fraud and improve quality. This is a common issue digital marketers encounter, but it’s one that remains a mystery to many in the industry.
Proxying internet traffic through a server, gateway or peer-to-peer connection has become an increasingly common phenomenon on the web. However, when the internet protocol was originally designed, there was no standard method implemented to capture all the IP addresses involved in proxied transactions. As a result, a de facto standard has emerged, known as “X-Forwarded-For” (XFF).
The term “X-Forwarded-For” is added to an internet transaction to display the list of all IP addresses involved in a given transaction.
In the example web transaction below, this browser is using a proxy to reach its destination (www.pixalate.com). It is using the de facto X-Forwarded-For standard to send both the originating client IP address and the proxy IP address to the destination.
In the most recent publisher spec, OpenRTB 2.5*, and all prior specs, the IP address of the targeted client is sent in the Device Object as “IP” and defined as “IPv4 address closest to the device.”
If an SSP or exchange offering bid requests is not sending the correct IP address from the XFF header, they should be queried as to their methods of IP address detection.
Additionally, you can ask exchanges and SSPs to provide the full contents of the XFF header in the Device Object “ext,” or extension field. This field is reserved for customizations to the bid request made by agreements between you and your suppliers
Per the OpenRTB guidelines, Pixalate specifies using the left-most IP address in the X-Forwarded-For header as the client IP address in all transactions including targeting, filtering and blocking.
When the XFF header is present, Pixalate also recommends checking all other IP values in the header for filtering or blocking, while not using them for targeting. In almost all cases, such IP addresses will result in false user-targeting, or even fraud.
The source IP address from the header data should be used in the transaction for targeting, filtering or blocking.
If you are not a direct party to the transaction and do not have access to HTTP header info, you should ensure that your partners are making this information available to you for every transaction in order to make your IP address targeting and filtration accurate.
If the information contained in the HTTP Header is simply not available in any context during the transaction, proceed with caution, and consider a solution for post-impression filtering and validation.
*OpenRTB 3.0 is expected to be released in early 2018 and is not anticipated to change this part of the specification.
Want more data-driven insights? Sign up for our blog!
