RTBlintAlpha

Blog · CTV

Console-native FAST sells authenticated gaming identity. The OpenRTB request still reads like generic CTV unless the path declares it.

· RTBlint

On August 31, Sony Pictures Television launched Live TV on PS5 in the United States: more than 100 free, ad-supported channels reachable from the console Media tab without a separate app download. TechTimes reported the ad stack as Publica for server-side insertion and PubMatic for programmatic supply. That is a familiar FAST headline until you notice what sits underneath every impression: a mandatory PlayStation Network sign-in that already tracks games played, purchases, and session time. The auction still clears through the same OpenRTB pipes as household FAST on a stick. The identity layer underneath is not the same, and nothing in a default CTV bid request tells you which one you bought.

Two FAST surfaces on one console, two identity models

FAST is growing quickly. TechTimes cited the sector at $12.28 billion in 2025 rising to $14.88 billion in 2026, a 21.2% annual rate. Most of that inventory still arrives in programmatic systems as connected TV: large screen, video placement, app bundle, device identifier. That description is accurate for a Roku stick or a Samsung TV Plus session where the platform knows a household IP and viewing history at the device level.

Live TV on PS5 is structurally different. Every console requires a PlayStation Network account. Opening the service links that account to a Sony Pictures CORE profile. Behavioral signals Sony already collects as platform operation, which games were played, what was purchased, how long sessions ran, can flow into ad delivery when a user watches the NFL Channel or a Crunchyroll exclusive. TechTimes contrasted that with third-party FAST apps installed on the same hardware: those apps can read device-level identifiers, not the authenticated PlayStation Network behavioral profile tied to the signed-in individual.

Sony's own launch materials describe the advertising environment as premium and integrated directly into the console experience, with Publica and PubMatic named as core ad technology partners. PubMatic is the programmatic marketplace layer. Publica handles SSAI on Sony's side before the stream reaches the player. For a buyer, that means the impression may be stitched server-side and sold through RTB, but the seller story is not generic living-room CTV. It is authenticated console inventory with first-party gaming context. The bid request your bidder receives may not say that explicitly.

What the scale numbers actually measure

TechTimes reported PlayStation Network at 125 million monthly active users as of March 2026, with a peak of 132 million in December 2025. Fewer than 50 million of those users pay for PlayStation Plus, leaving roughly 75 million active accounts generating limited direct subscription revenue. Live TV on PS5 is framed as a way to monetize that installed base through advertising rather than through another upsell.

Those figures are platform population counts, not programmatic fill rates or reachable bidstream volume. They tell you how large the authenticated denominator could be in the United States at launch, not how many impressions PubMatic will expose per day or what share will clear in open exchange versus private marketplace deals. A buyer who hears"125 million users" and maps that directly to reachable CTV reach is making a category error: MAU is account inventory, not ad-request inventory.

The same article noted that Tubi, the largest pure-play FAST service, saw only 5% of its viewership on live linear channels in early 2025, with most consumption on demand. Sony's launch bundles substantial on-demand programming alongside live channels. For supply-path planning, that split matters: live SSAI pods and on-demand ad breaks may traverse different insertion paths and may surface different OpenRTB objects even when the brand label is the same Live TV product. Treating the service as one homogeneous CTV app in your taxonomy hides that operational split.

Why devicetype=3 is not the argument

Console FAST still presents as connected TV in most trafficking workflows. The screen is a television. The player is native to the OS. Buyers who filter on device.devicetype: 3 will include this inventory, and that filter is not wrong on surface class grounds. The disagreement is about what identity rides along with the request, not whether the device enum says TV.

Household FAST platforms infer audience from IP, device graph, and viewing patterns at the device or household level. Authenticated console FAST can attach individual-level gaming and commerce behavior to the same session because the user signed in before the first channel tuned. TechTimes quoted Sony executives describing a gaming-heavy audience that is"not likely showing up in other connected TV environments often." Whether you accept that positioning or not, the buy-side question is operational: does the bid request declare authenticated first-party enrichment, or does it look like any other CTV app bundle with an IFA?

Privacy settings add another layer buyers must not confuse with absence of data. TechTimes reported that users can disable "Personalized Advertising" under Settings > Users and Accounts > Privacy, which limits use of individual PlayStation Network profile data for targeting while ads still serve. A request that arrives without enriched segments may reflect user choice, not a clean device-class signal. Pricing and measurement models that assume gaming-intent targeting on every impression will drift when opt-out rates climb.

// Third-party FAST app on PS5 (device-level path)
"device": { "devicetype": 3, "ifa": "…", "ip": "…" },
"app": { "bundle": "com.pluto…", "name": "Pluto TV" }
// Seller sees device/session; no platform gaming profile in-band

// Console-native FAST (authenticated path — illustrative)
"device": { "devicetype": 3, "ifa": "…", "ip": "…" },
"app": { "bundle": "…", "name": "Live TV on PS5" },
"user": {
  "ext": {
    "eids": [ /* first-party or partner IDs when declared */ ]
  }
}
// Same devicetype; different addressability contract if eids populate

The illustrative block is not a guaranteed wire format from PubMatic or Publica. It shows the inspection problem. Two requests can pass the same CTV lint rules, share devicetype: 3, and still differ on whether user.ext.eids, publisher first-party segments, or supply-chain metadata document authenticated enrichment. Buyers who only QA device class and video placement will not catch that gap until reach or frequency reports disagree with the brief.

Who can observe what across the hops

Sony operates the authenticated session and the content bundle. Publica performs SSAI before playback. PubMatic connects inventory to programmatic demand. Each hop can see a different slice of identity depending on contract, privacy setting, and what the SSP forwards. The exchange normalizes the object. The DSP applies filters and bid models. Neither side automatically knows that the impression originated from a mandatory sign-in flow unless fields or deal metadata say so.

Supply-chain completeness matters here for a different reason than fraud. A buyer authorized to purchase Sony first-party segments needs to see consistent schain and seller declarations that match the integration they contracted for. Incomplete chains (schain.complete != 1) produce no-bids that look like thin demand when the real issue is authorization metadata. That pattern is familiar on open CTV; console-native inventory does not exempt it.

Compare with the device-class split documented in our open programmatic CTV spend map post: open exchange CTV money divides across TV OS and mobile app bundles while campaigns still traffic one label. Console-native authenticated FAST adds a perpendicular split on the same hardware: native service versus sideloaded FAST apps. Both can clear as CTV in the bidder UI. Only one carries platform account behavior into the ad decision unless your filters distinguish them.

What to check before you reclassify the line item

  • Separate native console FAST from sideloaded FAST in deal taxonomy. Bundle and app name should identify Live TV on PS5 (or future console-native FAST) as distinct from third-party FAST apps on the same device class.
  • Inspect whether authenticated enrichment is declared in-band. Look for populated user.ext.eids, publisher first-party segment fields, or PMP metadata that documents account-level targeting versus device-only delivery. Absence is not proof the seller lacks data; it is proof your bidder cannot see it.
  • Map privacy opt-out to expected segment density. Personalized advertising toggles on console settings change what can be used for targeting while ads still serve. Do not benchmark gaming-intent performance without knowing opt-out prevalence on the supply you bought.
  • Split live linear SSAI from on-demand breaks in sampling. Channel guides and library titles may not share identical insertion or request shapes. Validate samples from both paths if your deal covers the full product.
  • Read nbr before widening CTV filters. Unsupported device and incomplete supply chain codes often trace to metadata mismatches, not missing demand. See the no-bid reason code guide.
  • Paste live requests into the bid request tester. Confirm devicetype, app.bundle, video placement, and identity extensions match the contract you think you are buying in the OpenRTB tester.

The honest limit

We do not have impression-level OpenRTB samples from PubMatic's Live TV on PS5 integration in this post. TechTimes and Sony's launch materials establish the ad-tech partners, the authenticated account requirement, and the contrast with third-party FAST apps on the same console. We are not going to invent fill rates, CPMs, or segment penetration percentages.

What is defensible is narrower. Console-native FAST can sell authenticated first-party identity while clearing through the same programmatic CTV pipes buyers already use. Standard device-class filters cannot tell native authenticated inventory from sideloaded device-level FAST on the same hardware. Until deal metadata and request fields declare that difference, buyers will mix reach models, frequency caps, and incrementality readouts that assume the wrong identity layer. That mismatch shows up in the request before anyone prices it.

Sources

RTBlint is independent and not affiliated with Sony, Integral Ad Science, PubMatic, or IAB. Figures below come from TechTimes reporting and Sony launch materials unless noted.