Pre-bid vs post-bid IVT is the comparison vendors blur in a single phrase like "fraud protection." The two checks happen at different times and see different fields. Pre-bid runs before money moves. The input is the bid request: URL or app, device, IP, supply path, whatever the OpenRTB object carries. The output is a decision to bid or not. Post-bid runs after the ad is served. The input can include the rendered page or the player, the verification tag, and events the request never had. The output is a label on an impression you may already owe.
HUMAN's MediaGuard and FraudSensor docs are unusually plain about running both on purpose. MediaGuard predicts from the bid. FraudSensor measures the served ad and retrains the prediction. The docs say MediaGuard allows 0.5 percent of traffic flagged as sophisticated invalid traffic to pass so FraudSensor can rescan it, and 0.05 percent of general invalid traffic for the same loop. The pass-through exists because a pre-bid decision that never lets the post-bid tag see a positive cannot check itself.
IAS describes the same two moments in its own fraud write-up: a pre-bid avoidance segment that tells a DSP whether an opportunity looks like invalid traffic from the bid fields, and a tag that runs before render and can see URL, IP, user agent, and signals that were not available pre-bid, then block or report. Two stages, one vendor, and the second stage is there because the first stage is blind to part of the evidence. Remove the vendor names and a decision not to buy still does not equal a label on what served.
What a pre-bid decision can see
The bid request is a claim about the opportunity. Bundle, domain, device type, IP, user agent, and a supply chain. A model can learn that some combinations have a history of invalid outcomes and refuse them in milliseconds. That is MediaGuard's documented job, and it is the job of any pre-bid IVT segment that returns a yes or no to the bidder. The strength is timing. An impression you do not buy cannot invoice you.
The weakness is the same timing. The creative has not run. A hidden webview, a click injected after render, a stitcher that will fire beacons from a data center with a spoofed device: none of that is finished when the bid is scored. The model is predicting from reputation and from fields that can themselves be spoofed. App ID and domain misrepresentation are on the MRC's sophisticated-invalid list precisely because the request can lie about where the ad will land.
A pre-bid block rate is therefore a property of the requests you were willing to refuse, on the fields you sent. It is not the IVT rate of the impressions you served. A strict threshold makes the block rate high and the served-impression IVT rate low. Quoting only the served rate hides the refusals. Quoting only the block rate hides what got through.
What a post-bid label can see
After the impression, a tag or a player callback can observe render, viewability, player size, and whether the media actually started. IAS's description of its JavaScript stage is this moment: more signals than the bid, and a choice to block the render or to report. HUMAN's FraudSensor is this moment for the ads that were allowed to serve, including the thin slice the pre-bid model intentionally let through.
Post-bid is also where a quarterly benchmark lives. Pixalate's Q4 2025 figure, 19 percent of US CTV impressions invalid in a predominantly open-auction set, is a classification of impressions, not a count of bids refused. DoubleVerify's under-1-percent fraud rate on protected CTV campaigns is likewise a statement about campaigns after controls, not a statement about every request the bidder saw. Comparing a pre-bid block rate to either of those numbers compares refusals to a classified log of what remained.
The bill follows the impression. A post-bid label can still dispute it, credit it, or exclude it from a viewability denominator. It cannot un-buy it. That is why buyers pay for pre-bid even when they already have post-bid: the expensive failure is the one that clears the auction. The reason they still pay for post-bid is that pre-bid is a prediction, and the pass-through percentages in HUMAN's docs are an admission that the prediction wants a later look.
Why the two rates diverge on the same campaign
They should diverge. The pre-bid rate's denominator is requests. The post-bid rate's denominator is impressions, or viewable impressions, or completed plays. Dropping the worst requests makes the impression log look cleaner without the request log looking cleaner. A quarterly open-auction benchmark that includes unfiltered demand will look worse than a protected campaign from the same season. DoubleVerify's own split, under 1 percent protected and nearly 9 percent with controls off, is this gap measured inside one firm's tests.
They can also disagree on one opportunity. The bid fields say the app is a known streaming bundle. The rendered result is a hidden webview or a different bundle. Pre-bid says buy. Post-bid says invalid. That disagreement is the false-representation case, and it is not a bug in the spreadsheet. It is the reason the second check exists. The reverse happens too: pre-bid refuses a request that would have rendered cleanly, and the post-bid tag never sees it, so the refusal is only visible in the bid log.
SSAI adds a third twist. If the stitcher fires the impression beacon, the post-bid "device" is a server. A pre-bid model that trusted the device fields in the request, and a post-bid model that sees a data-center IP on the beacon, will disagree even when a person watched the ad. The MRC addendum lists SSAI spoofing under sophisticated invalid traffic. Distinguishing spoofing from legitimate server-side beaconing is exactly the kind of judgment a bid-field check cannot finish.
Get VAST spec updates, platform guides, and release notes in your inbox.
What to do with the two checks
Report them on separate rows. Requests scored, requests refused, impressions served, impressions labeled invalid, impressions missing a verification event. A single "IVT percent" that does not say which row it came from will be compared with someone else's row, and the comparison will be wrong in a predictable direction.
Keep a sample of pre-bid positives in the post-bid path if you want the model to stay honest. HUMAN documents that sample as a fraction of a percent. The size is their choice. The existence of the sample is the lesson: a block that is never checked against a served impression drifts.
The tag is the post-bid instrument for video. If AdVerifications never survive the wrapper, the post-bid vendor is labeling from a pixel that is not on the creative, or labeling nothing. vastlint does not make the pre-bid call and does not label IVT. It checks that the VAST 2.0–4.4 document still contains the verification and impression nodes a post-bid check is supposed to use.
Rows that should not share one rate
- Bid requests scored, and bid requests refused, before an impression exists.
- Impressions served, and impressions labeled invalid after the fact.
- A deliberate pass-through of flagged traffic, used to retrain, not a market IVT rate.
- A protected-campaign rate and an open-auction benchmark from the same quarter.
- Server-fired SSAI beacons versus device-fired beacons on the same creative.
The check before the bid can only refuse a request, and the check after the impression can only argue with a bill.
Make sure the post-bid tag is still in the VAST
Run VAST 2.0–4.4 tags against specification-derived rules so verification companions survive the wrapper. Nothing is stored.
Open the VAST validatorSources
Pre-bid prediction on the OpenRTB bid, documented as paired with a post-bid tag.
Why a fraction of pre-bid flags are allowed through for post-bid rescanning.
IAS on pre-bid avoidance from bid fields and a later tag with signals the bid did not have.
Why some of what post-bid can see will never be a pre-bid list.