Invalid Traffic Filtering for an Ad Platform: What Your Team Can Build and When to Buy a Verification Vendor

Build general invalid traffic filtering yourself, and buy detection of the sophisticated kind from a verification vendor unless you can afford a fraud team of your own. General invalid traffic, such as known data-centre addresses, declared bots and invisible 1x1 ads, is caught with lists and rules. Your own engineers can run them when a request arrives and again in the logs. Sophisticated invalid traffic, such as hijacked devices and spoofed apps, needs data from far more traffic than one platform sees, and analysts who study it. Certification programmes such as TAG's also expect filtering by a qualified third party.

What counts as invalid traffic?

The Media Rating Council (MRC) is the US body that accredits advertising measurement. Its Invalid Traffic Detection and Filtration Standards Addendum (the June 2020 update, read on 27 October 2026 like the other sources here) splits invalid traffic into two kinds. General invalid traffic, or GIVT, is “traffic identified through routine means of filtration executed through application of lists or with other standardized parameter checks”. The MRC's examples include:

• Known invalid traffic from data centres
• Bots, spiders and other crawlers
• Requests from non-browser user agents or unknown browsers
• Pre-fetched or pre-rendered pages that no real user went on to see
• Invisible placements, such as ads of 0x0 or 1x1 pixels

Sophisticated invalid traffic, or SIVT, covers “more difficult to detect situations that require advanced analytics, multi-point corroboration/coordination, significant human intervention, etc., to analyze and identify”. The MRC's examples include:

• Automation software and emulators
• Infected and hijacked devices
• Organised paid human activity, such as click farms
• Forced clicks and redirects
• Falsified measurement events
• Spoofed domains and apps

Which filters can our own engineers build?

The general kind is meant to be shared. The MRC says that GIVT filtration “is intended to be consistent between vendors”, which is why it rests on common lists. An in-house team works from two of them:

• The IAB/ABC International Spiders & Bots List, which the Alliance for Audited Media maintains on behalf of the IAB Tech Lab
• The Data Center IP List, which the Trustworthy Accountability Group (TAG) produces each month

On top of the lists, the team writes rules for user agents, ad sizes and pre-fetch requests, applied when a request arrives and again when events are logged. It also keeps a record of every filtered request and the reason for it, so the numbers can be explained to partners.

For the measurement firms it audits, the MRC sets a starting point for data-centre traffic. They have to filter invalid traffic from IP addresses of “the three largest known hosting entities: Amazon AWS, Google and Microsoft”. Exceptions keep real users who reach the web through those networks from being filtered by mistake.

Filtering can happen at two moments. Up front, the platform blocks an ad request or declines to bid on it. Afterwards, it removes invalid events from the logs and the counts. The MRC writes: “Each technique has certain strengths and weaknesses, and both have a place in a well-executed traffic protection strategy.” Blocking early also saves the cost of processing a request that would be thrown away later.

Lists lose power as browsers and apps share less. In a 2024 update, the MRC put it this way: “Limited or no IP address and less granular User Agent (UA) string may impair list-based approaches”.

When is a verification vendor worth paying for?

Sophisticated detection depends on seeing patterns across many publishers, apps and devices, and on analysts who follow new schemes as they appear. One platform sees only its own traffic, so it misses patterns that show up only across many of them. A team that does this well amounts to a fraud detection company inside your company.

Certification can settle the question. TAG's Certified Against Fraud programme names as one of its key requirements that “100% of their monetizable transactions are filtered for IVT detection and removal by a qualified third party”. TAG lets publishers meet it through a supply-side platform that holds a valid certification seal. If your buyers or partners ask for TAG certification, filters you build yourself will not meet that requirement on their own.

The MRC publishes a list of the services it accredits. Its digital list includes verification firms such as DoubleVerify, HUMAN, Integral Ad Science, Pixalate and Protected Media. Accreditation covers specific services and metrics, so ask a vendor which of its services are accredited and whether that includes sophisticated invalid traffic.

Build, buy or both: what does each route cover?

• In-house only: you catch general invalid traffic for the cost of your engineers' time and any list subscriptions, and you own the rules and the data. Sophisticated schemes pass through, and requirements for third-party filtering stay unmet.
• A vendor only: both kinds are detected, but every decision depends on the vendor's systems and fees, and a vendor check inside the bid path adds time to each request.
• Both: your own filters drop the obvious traffic early and cheaply, and the vendor sees only the traffic that passed them.

What does the platform need to log for either route?

Whoever does the detection needs the details of each ad transaction. The MRC lists fields that a measurement firm must capture where possible, including:

• The event type, a transaction ID and a timestamp
• The IP address, including the X-Forwarded-For header when traffic passes through proxies
• The full user agent string and the device type
• The app identifier, or the full URL of the page where the ad ran
• Publisher, site and placement IDs, and the publisher's ads.txt or app-ads.txt information
• OpenRTB attributes from the bid request

Reports should keep raw and filtered numbers apart. For campaign reports, the MRC's standard lists “Gross Metrics (Completely Unfiltered)” and “Net Metrics (Filtered for GIVT Requirements)”. Where they apply, figures filtered for sophisticated invalid traffic appear as a separate step. If your event pipeline already loses or double-counts events, fix that first: filtering cannot repair numbers that were wrong before it ran.

What should we ask a firm that builds filtering into our platform?

• Where in the bid path does each filter run, and how much time does it add to a request?
• If the vendor's check does not answer in time, does the request go through or get dropped?
• How are the lists updated, and who checks that real users are not filtered by mistake?
• How will gross and filtered counts appear in our reports and in our partners' reports?
• Which fields from each request are stored, for how long, and under which privacy rules?

The last question matters to the MRC too. Its 2024 update says that “privacy regulations are not a barrier to be engineered around, but hard and fast requirements that must be adhered to”.

Where does amBrain fit?

amBrain, which publishes this blog, builds the systems that filtering plugs into. One of its lines reads: “amBrain builds ad servers: targeting, frequency capping and reporting.” Another reads: “amBrain builds event analytics pipelines for ad tech: collection, processing and reporting of impression and click events.” Its AdTech work includes RTBBidder, a demand-side platform it built for a client.

It has been building software since 2019 and works in three formats: full delivery, a dedicated team, or engineers embedded in your team. Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.”

This article is not a case study. It does not say that amBrain has built fraud detection for any client or that it offers verification. If amBrain is on your shortlist, give it the same questions as any other firm.