Blog · CTV

Fraudulent CTV bundle IDs mimic each platform's ID grammar. OpenRTB validates shape, not spoof.

On August 18, a vendor published a mechanics report on the 50 highest-traffic fraudulent Connected TV bundle IDs in its weekly Ad Fraud Indicators of Compromise database. The headline percentages are not a market-wide fraud rate. They describe how those 50 IDs behave: 80 percent of fraudulent Roku bundles spoof a recognizable brand name, 67 percent of fraudulent Fire TV bundles follow native ASIN and .amz suffix conventions, 74 percent of fraudulent Samsung bundles mimic numeric store IDs, and 100 percent of fraudulent Apple TV bundles in the sample also appear on three or more other platforms. Twenty-four of the fifty highest-traffic fraudulent bundle IDs showed up on Amazon Fire TV. The argument is not that CTV is 80 percent fraudulent. It is that spoofers learn each store's ID grammar and write bid requests that look native to automated validators.

What the sample actually measures

The report ranks bundle IDs by traffic among entries flagged in an open IOC feed updated weekly from buy-side and supply-path observation. That is a curated worst-of list, not a random sample of CTV impressions. The percentages describe patterns within those fifty rows: which spoofing tactic dominates on which operating system, how often the same bundle string travels across platforms, and how many of the top-traffic fraudulent IDs concentrate on Fire TV versus Roku or Samsung.

Flagged bundle IDs, in the vendor's taxonomy, show signs of spoofing known apps, malformed or missing app-store mappings, or platform mismatches. That last category includes mobile bundle IDs appearing in CTV bid streams: a request that claims living-room inventory while carrying a phone app identifier. Impression-level invalid traffic filters may still fire on bot-like behavior downstream. They do not, by themselves, answer whether the bundle field matched the device class, store, and publisher authorization chain before the auction cleared.

Contrast that with delisting risk, which is a different failure mode we covered separately: a bundle that was legitimate and is no longer on a store shelf but still bids. This report is about active spoofing and ID manipulation while the auction is open, not shelf status alone.

Platform mimicry is the mechanism

OpenRTB treats app.bundle as an opaque store identifier. Validators check that the field exists, that it is a string, that it is not empty. They rarely check whether the string's shape matches the platform implied by device.os, device.make, or the exchange's CTV taxonomy. Fraud operators exploit that gap by copying each ecosystem's native conventions.

On Roku, brand spoofing dominates the fraudulent sample: 80 percent of flagged Roku bundle IDs spoof a specific, recognizable brand, more than on any other platform by percentage. The string reads like a channel a buyer already trusts. On Amazon Fire TV, 67 percent of flagged IDs follow native conventions, including ASIN-style codes and .amz or .amzn suffixes. On Samsung Smart TV, 74 percent mimic the platform's numeric ID format. Each pattern is designed to pass a human glance and a shallow regex.

Multi-platform proliferation is the other signal. Every fraudulent Apple TV bundle ID in the sample also appeared on three or more other platforms, the strongest overlap pattern in the dataset. On Roku, 60 percent of fraudulent bundle IDs were found on three or more other platforms. Real apps sometimes ship on multiple stores under related IDs. Fraudulent IDs reuse the same claim everywhere because the cost of copying a string is zero and each additional exchange is another auction that never compares notes.

// Same bundle string, incompatible stories
Request A (claims Roku):
  device.os = "Roku OS"
  app.bundle = "41468"              // numeric, Roku-native shape

Request B (claims Fire TV, same traffic source):
  device.os = "Fire OS"
  app.bundle = "B08XYZ1234.amzn"    // ASIN mimicry

Request C (claims CTV, mobile bundle):
  device.os = "tvOS"
  app.bundle = "com.example.game"   // phone game ID in CTV stream

// Schema: three valid app objects
// Policy: at most one can be true

Exposure concentration matters for buyers who treat Fire TV as safer because CPMs look stable. Twenty-four of the fifty highest-traffic fraudulent bundle IDs in the sample were identified on Amazon Fire TV. That is not a platform indictment. It is a reminder that high traffic on a spoofed ID flows through whichever exchanges accept the claim without cross-checking store metadata.

Why format validation is not enough

Supply-path tooling already checks app-ads.txt against schain nodes, sellers.json, and MFA lists. Those checks assume the bundle identifies an app the authorization file was written for. Spoofing breaks the assumption without breaking the file format: a bundle that mimics a major brand may still resolve to a developer domain nobody recognizes, or to a missing mapping the bidder never fetches.

Blocklists keyed on bundle plus platform close part of the gap by excluding known-bad pairs before pricing. They are reactive. Mimicry is generative. New IDs appear faster than any weekly top-fifty feed rotates, especially when the spoof copies legitimate formatting.

The durable check is consistency across fields, not string shape alone:

  • Does app.bundle match the store format for the declared device.os and device class?
  • Does the same bundle appear on multiple platforms in your logs with incompatible device claims in the same week?
  • Does app.storeurl resolve to a live listing whose bundle matches the request?
  • Does the first payment hop in schain appear in app-ads.txt for that exact bundle, not a lookalike string?

Mobile bundle IDs in CTV streams are the blunt case. A phone game identifier in a request labeled tvOS or Roku OS is not a subtle spoof. It is a category error that should fail before app-ads.txt is consulted. Many integrations never emit that comparison because each field validated independently passes.

What to do

  • Log bundle, platform, and device class together. Spoof detection starts when you can pivot on app.bundle across exchanges and see incompatible device.os values in the same hour.
  • Reject cross-platform duplicates with conflicting device claims. If the same bundle bids as Roku and Fire TV and Apple TV, at least two requests are lying.
  • Fetch store metadata on ingress for high-CPM CTV paths. A numeric Samsung-shaped ID should resolve to Samsung's catalog API or your vendor equivalent before the request reaches open auction.
  • Layer IOC feeds under consistency rules, not instead of them. Weekly top-fifty lists catch known high-traffic bad IDs. Mimicry checks catch the next ASIN-shaped string before it hits the list.
  • Validate bid request shape in CI. Paste production CTV requests into the bid request tester and gate app.bundle presence and type per the OpenRTB validation guide. RTBlint checks malformed or inconsistent payloads. It does not detect fraud or label a bundle spoofed. It catches missing bundle fields and structural drift that prevent your own consistency rules from running at all.

The honest limit

The percentages in the August report describe tactics within a vendor-maintained IOC sample, not a census of programmatic CTV. They are still useful because they name the spoofing strategies your validators must anticipate: brand mimicry, native format mimicry, and cross-platform copy-paste. No single field in OpenRTB v2.x attests that a bundle is canonical for the platform. Until store attestations ride in the bid request, the work stays on the buyer and seller to compare claims against each other and against live metadata.

Sources

Field names are from OpenRTB as published by IAB Tech Lab. The analysis is our own. RTBlint is independent and not affiliated with IAB, IAB Tech Lab, or Pixalate.