SSAI spoofing is the search for a CTV failure that looks like ordinary stitching. People also type server-side ad insertion fraud, CTV spoofing, and whether a data-center IP on a CTV impression is bots. The Media Rating Council's June 2020 IVT addendum puts SSAI spoofing among falsified measurement events, in the sophisticated category, alongside falsified viewability, clicks, and location. Sophisticated detection is encouraged. It is not the required general list. General invalid traffic is the shared floor: known data-center ranges, declared crawlers, prefetch, placements that cannot have been a real opportunity.
The awkward fact is that legitimate server-side insertion also emits the impression from a server. The stitcher, not the television, often fires the beacon. A post-bid check that treats every data-center IP as general invalid traffic will flag the architecture. A pre-bid check that trusts the device fields in the request will miss a stitch that never had that device. The MRC category exists because those two honest signals can describe a fraud, and they can describe a person watching a stitched stream. Telling them apart is the sophisticated judgment. It is not a row in the data-center list.
vastlint does not decide which beacon was spoofed. It checks the VAST 2.0–4.4 tag the stitcher will parse: media files, tracking events, wrapper depth, and whether a verification node is present for whatever post-bid judgment comes later.
What the category is asking you to separate
Falsified measurement, in the addendum's examples, is an event that claims something that did not happen: a view, a click, a place, a completed play, a device that was not there. SSAI spoofing is that claim dressed as a stitch. The stream may not have contained the ad. The app may not have been the app in the request. The beacon still arrives from a server, which is what a real stitch also does. The proof is corroboration, which is why the addendum puts it on the sophisticated side and why two accredited firms can disagree. Their general lists should be close. Their SSAI judgments need not be.
DoubleVerify's regional mix is easy to misuse here. In the May 7, 2026 release, data-center traffic was 98 percent of APAC violations, 91 percent in LATAM, and 66 percent in EMEA, while North American violations were 82 percent bot fraud. Those are mixes of what was flagged, not impression rates, and data-center traffic in that sentence is not a synonym for SSAI spoofing. A violation tagged data-center might be the general list doing its job on a non-stitch impression. A stitched impression a person watched can carry a server IP and not be in the violation set at all. Reading 98 percent as the share of APAC CTV that is spoofed stitches three units into one.
What pre-bid and post-bid each fail to finish
Pre-bid sees the request: bundle, device, IP, supply chain. A spoofed app id is on the sophisticated list because the request can lie about where the ad will land. The stitch has not happened. The model is predicting. HUMAN's MediaGuard is this hop, and the MRC says the platform decides whether the suggestion becomes a drop. A drop avoids the invoice. It does not inspect the beacon that would have fired.
Post-bid sees the beacon and, when a client player is involved, the render. If the only beacon is the stitcher's, the device context the fraud model wanted is the one the server asserted. Pixalate's 19 percent US CTV figure is a classification of impressions in an open-auction quarter, not a count of spoofed stitches. An impression rate cannot tell you how many of its invalid rows were SSAI spoofing versus bots versus data-center lists, unless the release breaks that out. The March 9 benchmark does not break SSAI spoofing out as its own percent.
The architecture note, SSAI versus CSAI, is about where the ad is inserted. This note is about a fraud category that imitates the server-side path. A campaign can be legitimately stitched and still be spoofed, and it can be stitched and clean. The tag is the piece both paths share. A wrapper that arrives without media files, or without the tracking events the stitcher is supposed to fire, fails before anyone has to decide whether the beacon was a person.
SSAI sentences that are not an impression rate
- MRC, June 2020: SSAI spoofing is a falsified measurement event, in the sophisticated category, which is encouraged rather than required.
- A legitimate stitcher fires impression beacons from a server. A data-center IP is the architecture and the suspect list.
- Pre-bid judges the request. Post-bid judges the beacon. They can disagree on one opportunity a person watched.
- DoubleVerify, May 7, 2026: data-center share of violations by region is not an SSAI spoofing rate.
- Pixalate, March 9, 2026: 19 percent of US CTV impressions invalid is not a published SSAI-spoofing share.
- SSAI versus client-side insertion is where the ad is stitched. Spoofing is whether the measurement event was real.
Server-side beacons are how a stitch reports, and spoofing is the case where that report describes an ad the viewer did not get.
Check the tag the stitcher has to parse
Run VAST 2.0–4.4 tags against specification-derived rules so media files, tracking events, and verification nodes are present. Nothing is stored. This does not detect SSAI spoofing.
Sources
SSAI spoofing among falsified measurement events. SIVT is encouraged. GIVT filtration is required.
Why a request and a server beacon can disagree on one stitched impression.
Where the ad is inserted, which is the architecture this fraud category imitates.
Why a data-center list and an SSAI judgment are different categories.
