CTV Ad Fraud Looks Like Perfect Delivery

The uncomfortable thing about CTV ad fraud is that it does not look like fraud. It looks like the best-performing line item in the campaign.

Completion rates near 100%. No skips, because nobody is there to skip. Perfectly consistent delivery across dayparts. Zero viewability complaints. On a dashboard built to reward completion and delivery consistency, fraudulent CTV inventory outperforms the legitimate inventory sitting next to it, and it does so at a bid price that wins the auction.

That inversion — where the fake inventory grades better than the real inventory — is the core of the problem, and it is why CTV fraud persists in campaigns that are nominally protected. This guide covers the mechanics of the main schemes, why the metrics mislead, where filtering has to happen to actually work, and what both buyers and publishers should verify.

Why CTV is structurally more exposed than web video

Three properties of the CTV environment make it harder to police than a browser, and they compound.

There is no browser and no JavaScript. Web display and video verification relies heavily on client-side tags that execute in the page, measure viewability, and report back. A connected TV app runs no third-party JavaScript. Verification has to happen through the ad request, the VAST response, and server-side beacons, all of which are easier to fabricate than a browser environment under observation.

Server-side ad insertion removes the client from the transaction. With server-side ad insertion, the ad request comes from a stitching server rather than the device. That is what makes SSAI resistant to ad blocking, and it is also what makes it a fraud surface: the buyer sees a request from a server, and the claim that a real device sits behind it is a claim the server makes.

Device identifiers are declared, not derived. A CTV bid request carries device type, model, IFA, app bundle ID, and content metadata as fields. In a browser, some of this can be corroborated against observable behaviour. In CTV, most of it is asserted by the supply side and taken on trust unless something downstream verifies it.

DoubleVerify's 2026 CTV research reported a 140% year-over-year increase in the number of distinct CTV fraud schemes, alongside a sharp rise in fraudulent app listings. The direction of travel is not subtle, and the growth tracks CTV budget growth almost exactly — fraud follows money into a channel with weaker native verification than the one it left.

The four schemes that matter

SSAI spoofing

The dominant CTV-specific scheme. A fraudster operates infrastructure in a data centre that emulates an SSAI stitching server, generating ad requests that carry legitimate-looking device identifiers, app bundle IDs, and content metadata. No device exists. No stream is playing. No human is present.

What makes this effective is that a genuine SSAI request also originates from a data centre. The traffic signature that would flag a bot in web display — server IP, no browser fingerprint — is the normal, expected signature for legitimate SSAI. The usual detection heuristic is inverted.

The countermeasure is IP-level verification against known publisher and CDN infrastructure, combined with request-pattern analysis. A legitimate stitcher serving a real audience produces request volumes that track content schedules and audience behaviour. A spoofing operation produces volumes that track whatever the operator configured, which is usually smoother and more consistent than real viewing ever is.

App and device spoofing

The bid request declares a premium app bundle ID and a high-value device model. The actual traffic originates somewhere else entirely, frequently from low-value inventory or from nothing at all. The buyer thinks they bought a placement in a well-known streaming app on a modern smart TV. They bought a field in a JSON object.

This is what app-ads.txt and sellers.json exist to constrain: they let a buyer verify that the seller in the supply chain is actually authorised to sell that app's inventory. They are necessary and they are not sufficient, because they authenticate the seller relationship rather than the individual request. Supply chain hygiene is covered further in the supply path optimization guide.

Fake apps and fabricated inventory

A functioning but essentially unwatched app is published to a CTV app store, then used to generate large volumes of ad requests. The app is real, the bundle ID is genuine, and app-ads.txt checks pass — because everything about the seller relationship is legitimate. The only fictional element is the audience.

Detection here is behavioural rather than structural. Real apps have audience patterns: daypart curves, session-length distributions, seasonal variation, a long tail of irregular viewers. Fabricated inventory has volume without shape.

Ad pod stuffing and hidden inventory

A more mundane scheme, and closer to grey than black. A publisher declares a pod with a certain number of slots and inserts more, or serves ads into positions the player never reaches because the break ends first. Impressions are recorded for ads that never played.

This blurs into a legitimate measurement problem — ads that are billed but never render, which happens to honest publishers through technical failure rather than intent. The distinction matters for remediation, and the mechanics are covered in fill rate versus rendered impressions. Pod construction itself is covered in ad pod strategy.

Why fraudulent inventory grades better than real inventory

This is the part that causes the most damage, because it corrupts optimisation rather than just wasting spend.

Consider what a campaign optimiser does. It shifts budget toward the placements with the strongest completion rates and the most consistent delivery. That is a sensible rule for legitimate inventory.

Now consider what fraudulent inventory reports. Completion rate at or very near 100%, because there is no viewer to abandon the stream. Delivery consistent to the point of being smooth, because it is generated rather than observed. No frequency irregularity. No dayparting noise.

The optimiser sees this and does exactly what it was designed to do: it moves more budget toward the fraud. The better your automated optimisation, the faster it finds and funds the fake inventory, because the fake inventory is engineered to score well on precisely the metrics the optimiser reads.

The practical implication is a diagnostic one. A completion rate of 99–100% sustained across a large placement is a red flag, not an achievement. Real CTV completion rates are high — meaningfully higher than web video — but they are not perfect, and they vary by content type, daypart, and pod position. A placement with no variance is telling you something about how the number is produced. This is worth reading alongside VCR versus completion rate, which covers what the metric legitimately measures.

The waterfall economics nobody discusses

Most fraud coverage frames the problem as wasted advertiser budget. For publishers running an exchange or a mediated waterfall, there is a second cost that is less obvious and arguably worse.

A fraudulent demand source has no real customer acquisition cost attached to its bids. It is not trying to reach a buyer profitably — it is trying to win impressions. That means it can bid above what legitimate demand will pay, consistently, because its economics are not constrained by campaign performance.

In a price-priority waterfall, that bid wins.

The consequence is that fraudulent demand displaces legitimate demand from a publisher's inventory, at a price the publisher may never actually collect once the impressions are disputed, reversed, or written off. The publisher does not merely fail to catch fraud — the publisher's own auction actively selects for it, for the same structural reason the advertiser's optimiser does.

This is why filtering has to sit upstream of the auction rather than in post-campaign reporting. A fraud finding that arrives in a monthly report describes budget that is already spent and legitimate demand that was already displaced. The waterfall priority logic is covered in FAST channel yield optimization.

Pre-bid, in-flight, and post-bid: where filtering actually works

Detection at three points, with very different value.

Pre-bid filtering evaluates the request before the auction runs: is this IP consistent with declared publisher infrastructure, is the app bundle ID authorised via app-ads.txt, does the declared device profile cohere with the request, has this supply path been flagged. Requests that fail are dropped before any buyer sees them. This is the only stage that prevents both the wasted spend and the displacement of legitimate demand.

In-flight detection watches delivery patterns as the campaign runs: completion rate distributions, frequency anomalies, delivery smoothness, beacon timing. It catches schemes that pass structural checks but behave wrongly, and it can pause a placement mid-campaign rather than after it.

Post-bid verification is what most third-party vendors provide, and it is genuinely useful for accountability, makegoods, and supply-path decisions for the next flight. It is an audit, not a control. By the time it reports, delivery has happened.

A reasonable programme runs all three, weighted toward pre-bid. LtvAdx applies request-level filtering ahead of the auction and behavioural scoring during delivery, with the policy detail published at our invalid traffic policy. The serving path those checks sit inside is described in how CTV ad serving works end to end.

Signals that actually separate real inventory from fake

Structural checks first, because they are cheap and deterministic.

• IP against declared infrastructure. Does the request originate from IP space consistent with the publisher's or their CDN's stitching infrastructure, or from unrelated data centre space?
• app-ads.txt and sellers.json authorisation. Is the seller in this supply path actually authorised to represent this app? Does the declared path reconcile end to end?
• Field coherence. Does the declared device model plausibly support the declared player capabilities and content resolution? Incoherent combinations are a strong signal, and spoofing operations frequently get these details wrong.
• Bundle ID reputation and app age. Newly published apps generating immediate high volume deserve scrutiny they rarely receive.

Then behavioural signals, which catch what structure misses.

• Completion rate distribution, not average. Real inventory produces a distribution with variance. A placement where nearly every impression completes identically is producing a number rather than measuring one.
• Daypart shape. Human viewing has a curve — evening peaks, weekday and weekend differences, seasonal drift. Fabricated volume tends toward flatness.
• Beacon timing. Quartile beacons from a real player arrive at intervals consistent with actual playback duration. Fabricated beacon sequences frequently arrive too regularly, or with intervals that do not match the creative length.
• Frequency distribution across households. Real audiences produce a long-tailed distribution: many households seeing an ad once or twice, fewer seeing it many times. Suspicious inventory often produces implausibly uniform frequency, which also connects to household frequency capping.

You can inspect beacon behaviour on your own inventory directly with the SSAI beacon tester, and validate VAST responses with the VAST inspector.

What it actually looks like in a report

Abstract signals are hard to act on, so here are two placements side by side as they would appear in a delivery report. These are illustrative figures constructed to show the diagnostic contrast, not data from a specific campaign.

Placement A — legitimate premium CTV

• 2,400,000 impressions
• Completion rate 94.2%, ranging 91.8%–96.1% across dayparts
• 380,000 unique households, average frequency 6.3
• Frequency spread: 42% of households saw 1–2 ads, 31% saw 3–6, 27% saw 7 or more
• Hourly delivery peaks 8–11pm, troughs 3–6am, roughly a 12:1 ratio

Placement B — suspicious

• 2,100,000 impressions
• Completion rate 99.7%, ranging 99.5%–99.8% across dayparts
• 41,000 unique households, average frequency 51.2
• Frequency spread: 89% of households clustered between 40 and 60 impressions
• Hourly delivery essentially flat, roughly 1.3:1 peak to trough

On the metrics most dashboards surface by default — impressions and completion rate — Placement B is the stronger performer, and an optimiser will fund it accordingly.

Three things give it away, and none of them are on the default dashboard. The completion rate has almost no variance, which real viewing never produces. The household count is an order of magnitude too small for the impression volume, producing an average frequency no legitimate campaign would tolerate. And the frequency distribution is clustered rather than long-tailed, which is what happens when a fixed pool of fabricated identifiers is cycled rather than a real audience being reached.

The daypart flatness confirms it. People do not watch television at a constant rate through the night. Reporting that says they do is describing a process, not an audience. If your reporting cannot break out unique households and frequency distribution by placement, that gap is worth closing before your next flight — see CTV reporting and analytics.

The grey zone between fraud and low quality

Not everything that wastes CTV budget is fraud, and conflating the two leads to the wrong remedy.

There is a substantial category of inventory that is entirely legitimate in the technical sense — real app, real device, real human somewhere in the room — and still close to worthless. Screensaver and ambient channels that play unattended. Apps left running on a television nobody is watching. Auto-playing content in a background tab of a smart TV interface. Every impression is real. Attention is not.

This inventory passes every structural check. app-ads.txt is valid, the device is genuine, the SSAI request is authentic. It fails only on outcome, which is exactly why outcome measurement is the defence that catches both categories at once.

The remedy differs, though. Fraud calls for exclusion and, where contractual, clawback. Low-attention legitimate inventory calls for a pricing conversation — it has some value, considerably less than premium placement, and the honest response is to bid it lower rather than to ban it. Treating the two identically means either overpaying for ambient inventory or picking unnecessary fights with legitimate publishers.

What buyers should require

Five things, in rough order of impact.

Ask where filtering happens. Pre-bid, in-flight, or post-bid. If a partner only offers post-bid verification, you have an audit trail, not protection. This belongs in the same diligence pass as the programmatic TV buying checklist.

Require app-level transparency, not just domain-level. A report showing spend by supply partner is not enough. You need spend by app bundle ID, and you need to be able to exclude at that level.

Treat perfect completion rates as suspect. Set an internal review trigger on any placement sustaining above roughly 98% completion at meaningful volume. Some legitimate premium inventory genuinely runs very high, so this is a review trigger rather than an exclusion rule.

Check delivery shape against plausibility. Pull delivery by hour for a large placement. If it does not resemble how people actually watch television, ask why.

Reconcile against outcomes, not delivery. This is the most reliable defence available, because fraud can fabricate impressions but not incremental conversions. A placement with immaculate delivery metrics and no measurable outcome contribution is the clearest signal there is. Measurement approaches are covered in the attribution and measurement guide, and campaign-level reporting in reporting.

What publishers should do

Legitimate publishers carry real exposure here, and mostly through their partners rather than their own inventory.

Keep app-ads.txt accurate and current. Stale entries authorising partners you no longer work with are exactly what gets exploited. Audit quarterly.

Know your demand path. If you are running mediated demand, understand who is actually bidding. Fraudulent demand entering through a reseller displaces legitimate demand from your inventory and creates reconciliation disputes later.

Monitor your own render and beacon patterns. Anomalies in your delivery data are worth investigating even when they look favourable. An unexplained improvement in completion rate is not automatically good news.

Publish your position. Buyers increasingly ask about IVT policy during onboarding. Having a documented answer is a commercial advantage, not just a compliance artefact. Publisher-side controls are covered in publisher tools and FAST channel solutions.

Frequently asked questions

Is a 100% completion rate always fraud?

No, and treating it as automatic proof will cause you to exclude good inventory. Some premium CTV placements — particularly non-skippable pre-roll in strong content — legitimately run very high. What is suspicious is a completion rate that is both perfect and invariant across dayparts, content types, and pod positions, at scale. Real inventory varies. Treat it as a trigger to inspect the distribution rather than as a verdict.

Does SSAI cause fraud?

No. SSAI is legitimate infrastructure that solves real problems, including ad blocking resistance and playback continuity. What it does is remove the client-side signals that verification traditionally relied on, which raises the burden on request-level and behavioural verification. The technology is not the problem; the verification gap it opens is. Details on the serving mechanism are in our SSAI implementation.

Do app-ads.txt and sellers.json solve this?

They solve one part well: they establish which sellers are authorised to represent an app's inventory, which closes off the simplest resale fraud. They do not verify that any individual request came from a real device with a real viewer, and they do not help at all against a genuine app with a fabricated audience. Necessary, not sufficient.

How much CTV budget is typically affected?

Published estimates vary widely by methodology and by how well the inventory was protected, which is why a single industry figure is not very useful for planning. The more actionable question is what your own exposure looks like: pull delivery by app bundle ID for your last quarter, sort by completion rate, and inspect the top of that list. That analysis costs an afternoon and tells you more about your specific risk than any benchmark.

Can fraud affect outcome measurement as well as delivery?

Delivery metrics can be fabricated relatively easily. Incremental outcomes cannot, because they require a real human to take a real action. This is precisely why outcome-based measurement is the strongest defence: fraudulent inventory shows immaculate delivery and contributes nothing measurable downstream. If you are running holdout-based measurement, fraudulent placements show up as spend with no lift.

What should I do when I find a fraudulent placement mid-campaign?

Exclude at the app bundle level immediately rather than pausing the whole supply partner, since the partner is frequently carrying legitimate inventory alongside it. Document the delivery evidence — completion distribution, household count, frequency spread, daypart shape — before the reporting window rolls, because that evidence is what supports a credit request.

Then raise it with the supply partner directly. Reputable partners will issue a makegood or credit against documented IVT, and their willingness to do so tells you a great deal about whether to keep the path open. Finally, check whether the same bundle ID appears in other campaigns and other seats, because it usually does.

Should smaller advertisers worry about this?

Yes, and arguably more, because the mitigations that scale best — pre-bid filtering, app-level exclusion, outcome measurement with adequate statistical power — are easier for large buyers to run. The practical route for a smaller budget is to buy through supply paths where filtering happens upstream by default, rather than trying to build verification capability at a scale that cannot support it.