Blocking FAQ

• Data feeds: lists you load onto your own servers. See Pre-bid data feeds for every feed.
• Fraud API: real-time lookups of one IP address, device ID or user agent at a time. See Fraud API.
• Amazon DSP: Pixalate filtering that you turn on in your line items. See Amazon DSP.
• Website tag blocking: for publishers using Google Ad Manager. See Website tag blocking.

Feeds update at different frequencies:

• Hourly: IPv4 IP block list, mobile device ID feed, CTV device ID feed. The CTV device ID feed has been hourly since August 28, 2026.
• Twice a day: IPv6 IP block list.
• Weekly: data center feeds (Fridays) and the malformed CTV bundle ID feed.
• Daily or weekly: the user-agent feed, depending on the version you receive. Ask your account manager which version you’re on.
• Daily: all other feeds.

See How often each feed is updated for the full table.

Match your checks to the feed’s update frequency:

• Hourly feeds: from the top of each hour, check every 15 minutes until the new file appears.
• Daily feeds: check every hour, and keep checking after you download, since more than one file is occasionally uploaded in a day.
• Weekly feeds: on Fridays, check every hour until the new file appears.

Use each file’s last-modified time, not its name, to tell whether it’s new. See Poll for new files.

Every feed is a CSV file available over FTP. Some feeds can also be delivered through Amazon S3, AWS RTB Fabric or an API. See Delivery methods.

It depends on the feed. Device ID files can be up to 5 GB, and IP files up to 1 GB. See Typical file sizes.

Use version 2.0: High Risk Mobile Apps 2.0 and High Risk CTV Apps 2.0. High Risk Mobile App Lists 1.0 was deprecated on September 23, 2026. If you still receive a 1.0 list, contact your account manager to move to 2.0.

Yes. The lists are pre-bid, and you apply them on your own servers, so you can apply them any way you want, including leaving out entries you don’t want to block.

Feeds such as the IP and device ID block lists give each entry a probability between 0.5 and 1. It’s the likelihood that the entry is associated with the listed risk: 0.7 means 70%. The higher the number, the higher the risk. An entry needs a probability of at least 0.5 to be on the list.

Pixalate doesn’t make a strong recommendation, because the right threshold depends on the quality and scale of your supply. Most clients start testing at 0.75 to 1 and adjust from there. As a general guide:

Lowering the threshold blocks more traffic, so check your impression delivery whenever you change it.

1. Tell Pixalate who the IP address belongs to, how it’s used, whether bots are used in your testing, and when the problem started. Email support@pixalate.com or contact your account manager.
2. Pixalate checks the IP’s fraud type, and how many impressions come from it each day and how often.
3. If Pixalate confirms the IP is used for legitimate testing, it adds the IP to the whitelist. If not, the IP stays on the block list.

Pixalate presents IVT differently in each place:

• Analytics shows IVT in your own first-party data.
• The Media Ratings Terminal (MRT) shows IVT based on Pixalate’s global data, not only your traffic.
• The block lists flag apps using Pixalate’s own criteria.

Not every IVT type measured in your Analytics data goes into the MRT, and not every IVT type flagged in your data leads to an app being added to a block list. IVT can come from compromised devices, bot farms or the app itself. Pixalate looks at how flagged impressions correlate with the app versus the devices generating them, so that an app isn’t penalized for bad devices or misrepresented traffic. To find the source of problem devices, work directly with the seller or publisher.