IP block lists (IPv4 and IPv6)

The IP block lists contain IP addresses that Pixalate has linked to malicious or compromised devices. Use them to block, or alert on, bid requests and other traffic from those addresses before you bid or serve.

Each IP comes with a fraud type and a probability from 0.5 to 1, so you choose how strict to be. There are two separate lists: one for IPv4 and one for IPv6.

What’s in the lists

An IP is added when Pixalate sees suspicious activity from it, and only once that activity is statistically significant. Listed IPs can belong to data centers, bad proxies, infected machines on home or cable connections, or organizations. They aren’t necessarily part of a botnet.

• Proxies and Tor. Tor and proxy IPs are included in these lists, for example under the proxy fraud type. Tor IPs appear less often because there are very few of them.
• highriskapp. This fraud type marks an IP that generates high volumes on one or more high-risk apps, meaning apps blocked for high invalid traffic (IVT) rates.

For the meaning of each fraud type, see Reported Invalid Traffic (IVT) Types.

Why there are two lists

IPv4 and IPv6 need separate integrations: the address formats differ, and you may see each type in a different place in your stack. The lists are also built independently. One IPv4 address can sit in front of many IPv6 addresses, so an IPv4 address with lots of good traffic may stay off the IPv4 list while some of its IPv6 addresses are listed.

An IPv4 address is often shared by a whole household or a cell tower, so blocking it also blocks good traffic. IPv6 addresses are more granular, which lets you block only the bad devices. Use both lists while IPv4 and IPv6 coexist.

Pixalate collects both the IPv4 and the IPv6 address (when available) for each ad transaction, so each list also informs the other.

At a glance

The file name carries a date only, not a time or version, and a newer file can reuse an earlier file’s name and replace it. Don’t use the file name to find the newest file; check its last-modified time instead. See Delivery and integration.

Schema

Example IPv4 rows (made-up values):

198.51.100.23,datacenter,1.0
203.0.113.45,proxy,0.82
192.0.2.117,highriskapp,0.64

Example IPv6 rows (made-up values; <ipType> stands in for the type value):

2001:db8:5c1::17,<ipType>,proxy,0.91
2001:db8:a40:3::2,<ipType>,datacenter,1.0

Choose a probability threshold

Every listed IP has a probability of at least 0.5, calculated by Pixalate’s machine learning models. You decide where to set your threshold, based on the quality and scale of your supply. As a general guide:

Lowering the threshold can reduce the number of impressions you deliver. Each time you change it, check the effect on impression delivery.

Apply the lists pre-bid

1. Load the latest IPv4 and IPv6 files on the servers that make your bid or serving decisions.
2. For each request, find the IP addresses involved (see Handle X-Forwarded-For).
3. Look up each IP in the list for its address family. If it’s listed at or above your threshold, block the request.

Use the IP lists alongside the user-agent feed, and block a request if either its IP or its user agent is listed.

Check for new files

The IPv4 list updates hourly. Poll for it like this:

• Start checking at the top of the hour.
• Check every 15 minutes.
• Download only when a new file is available, then stop checking.
• Start again at the next hour.

The IPv6 list updates twice a day. For access, file locations and how to read a file’s last-modified time, see Delivery and integration.

Handle X-Forwarded-For

This matters most for the proxy, datacenterProxy, IPObfuscation and MaskedIP IVT types.

When traffic passes through a proxy, gateway or peer-to-peer connection, the de facto standard X-Forwarded-For header lists the IP addresses involved. In this example, a client at 203.0.113.10 reaches you through a proxy at 198.51.100.20:

Source IP: 198.51.100.20
X-Forwarded-For: 203.0.113.10, 198.51.100.20

Handle a missing or zero last octet

Some requests arrive with the last octet of the IPv4 address removed, and a small number of IPs in the IP and data center feeds end in .0. In both cases the aim is usually to hide the true IP from downstream partners. You can:

• Use other feeds, such as the mobile and CTV device ID feeds or the app block lists. A device ID can still catch a source of IVT whose IP has been masked.
• Apply frequency caps per IP for residential IPs.
• Work with trusted partners and publishers.

A last octet of 0 doesn’t on its own indicate invalid traffic. If you pass IPs on and the last octet isn’t available, Pixalate recommends setting it to 0 rather than leaving it blank.

Related