RTBlintAlpha

Blog · Standards

Redefining Media Types: eight new claims, and the bidstream fields they land on

· RTBlint

IAB released the Redefining Media Types Standard for public comment on July 9, 2026, with IAB Tech Lab setting the technical standards for adoption. Comment closes August 8. Most of the coverage read it as a planning-and-reporting document, which the first half of it is. The second half is not. It defines eight binary attributes that apply to an individual impression, and the stated plan is to encode them directly into OpenRTB bid requests. Seven of the eight already have somewhere to live in the spec, and that is the problem worth two weeks of your attention.

What the standard is

RMT classifies video advertising environments on two layers. The first sorts inventory into macro buckets grounded in how a person is actually watching: Lean Back Viewing, Personal Screen Viewing, and Passive and Communal Viewing. The second applies impression-level attributes that let a single impression be described precisely across platforms and devices. The scope covers connected TV, online video, social video, FAST, video podcasting, and retail video.

The motivation is stated plainly in the release: legacy classification terms were built to describe distribution technology and business models rather than the viewing experience a consumer actually has. "CTV" describes a delivery path. "Online video" describes a browser. Neither tells a buyer whether the ad played full screen with sound on in a living room, or muted in a feed on a phone, and those two impressions are not the same product at the same price.

RMT follows Campaign Data Standards 1.0 from May 14, 2026. Where that work addressed reconciliation between planning tools and finance systems, this one addresses what a given video impression actually is, independent of which platform reports it. The framework is designed to feed the Project Eidos taxonomy and to inform the OpenRTB and AdCOM specifications rather than sit beside them as a standalone document.

The eight attributes, and where each one already lives

The second layer is the operational half: sound state, skip-enabled versus completion-required, full-screen presentation, addressability, availability of signals, measurability, device, and ad format. Read that list as a protocol engineer and it is not new vocabulary. It is a list of assertions the bid request is already supposed to be making. Here is the mapping as the spec stands today.

RMT attribute            OpenRTB 2.6 field(s)                     State today
--------------------------------------------------------------------------------
Sound state              video.playbackmethod (1,2,5,6)           Field exists
Skip vs completion       video.skip, skipmin, skipafter           Field exists
Full-screen              video.pos = 7, w/h vs device.w/h         Weak proxy
Addressability           device.ifa, device.lmt, user.eids        Field exists
Signal availability      regs.gpp, source.schain, user.ext        Inferred only
Measurability            video.api = 7 (OMID), imp.metric         Capability, not proof
Device                   device.devicetype, app/site/dooh         Field exists
Ad format                video.plcmt, video.linearity, mtype      Field exists

Four of those are clean. playbackmethod encodes sound state directly: 1 and 5 start with sound on, 2 and 6 start with sound off by default. devicetype separates a connected TV (3) from a set top box (7) from a phone (4). skip with skipmin and skipafter encodes the skip contract. plcmt carries format, and the CTV Ad Portfolio signaling finalized on July 22 just extended its range past the original four subtypes.

The other four are where RMT is asking for something the protocol does not currently give it.

The four that do not have a real field

Full-screen presentation. There is pos, whose value 7 means full screen, but pos is a display-era placement-position field that most video sellers leave unset, and the CTV portfolio work has just loaded another ten values onto it for overlay and squeezeback geometry. Deriving "this played full screen" from video.w and video.h against device.w and device.h works when all four are populated honestly, which on CTV is not the common case.

Addressability and signal availability are today inferred from absence. A buyer decides an impression is addressable because device.ifa is present and device.lmt is not 1, or because user.eids has an entry. That is inference over a field that may be missing for a dozen unrelated reasons: a stripped bidstream, a consent state, a truncating adapter, a seller that never populated it. Turning inference into a declared boolean moves the failure from "I could not tell" to "you told me wrong."

Measurability is the one to watch. Today the closest signal is video.api containing 7, which declares OMID 1.0 support. That is a statement about what the player can do, not about whether the delivered impression was measured. A declared measurability bit invites the same conflation, and measurability claims are exactly the kind that get repeated downstream into reporting without anyone re-deriving them.

We have already run this experiment. It was called plcmt.

In 2022 the IAB deprecated video.placement and introduced video.plcmt with tighter definitions, precisely because the old field had drifted into meaning whatever each seller wanted it to mean. It was a good taxonomy, correctly motivated, published with a migration path and a deadline.

Three years later, as we covered in the plcmt migration retrospective, plenty of traffic still carries both fields with values that contradict each other, and plenty carries neither. Nothing rejected the bad data. Unknown fields are ignored by design, a wrong enum value inside a valid range is indistinguishable from a right one, and there is no error code for a version or semantic mismatch. The taxonomy was fine. The enforcement layer did not exist.

RMT is a better-designed taxonomy than plcmt, and it will land on the same enforcement layer. If playbackmethod is unpopulated on 30 percent of your video inventory today, then a sound-state classification built on it is unpopulated on 30 percent of your inventory the day it ships, and the classification will be reported as though it were known.

What to do before August 8

The comment window is the leverage. Two useful things to do with it, and one to do regardless of whether you comment.

  • Measure your own fill rate on the seven mapped fields. Take a day of real bid requests and count how many populate video.playbackmethod, video.skip, video.plcmt, device.devicetype, video.api, video.pos, and device.ifa. That percentage is the ceiling on how accurately RMT can classify your inventory, and it is a concrete number to submit as feedback rather than an opinion.
  • Comment on the attributes your data cannot answer as a binary. Measurability and signal availability are the two most likely to be filled in optimistically by whichever system has the least information. A definition that says how the bit is derived, and from which field, is worth more than the bit.
  • Fix the enum drift now, not after the taxonomy ships. RTBlint flags out-of-range enum values as openrtb.value.invalid, fields that do not exist in your declared version as openrtb.field.not_yet_available, and skip pairings that contradict themselves as openrtb.field.requires_skippable_video. Those are the failures that a classification layer will silently inherit. The CI guide covers gating on them.

To check a single request against the current snapshot, paste it into the bid request tester. For the field-by-field background on the taxonomy this one sits next to, see placement versus plcmt and the rule catalog.

The part worth saying plainly

RMT is good work and it addresses a real problem: the industry classifies video by delivery pipe and then argues about what the numbers mean. Grounding the definitions in the viewing experience is the right correction, and doing it in a way that feeds OpenRTB and AdCOM rather than sitting in a PDF is the right implementation choice.

The risk is not in the standard. It is that a classification layer is only ever as good as the fields underneath it, and those fields have no runtime that rejects a wrong answer. A new taxonomy on unvalidated inputs produces confident, precise, wrong reports, which is worse than the ambiguity it replaced, because ambiguity at least announces itself. The fix is unglamorous and available today: validate the seven fields you already have before the eighth arrives.

Sources

The OpenRTB specification is published by IAB Technology Laboratory under a Creative Commons Attribution 3.0 License. Field names and enumerated values referenced here are drawn from it; the analysis is our own. RTBlint is independent and not affiliated with IAB or IAB Tech Lab.