Blog · Video

Three years of plcmt: the state of the placement migration

April 15, 2026 · rtblint

OpenRTB 2.6-202303 deprecated video.placement in favor of video.plcmt back in April 2023. Three years later, the two fields are still riding together in most video bid requests we see. That is not a failure to migrate so much as the migration's actual shape: a slow, partner-by-partner reclassification of inventory that, for a meaningful share of supply, does not reprice favorably.

What changed, briefly

video.placement used a five-value list (1 In-Stream, 2 In-Banner, 3 In-Article, 4 In-Feed, 5 Interstitial/Slider/Floating) that described where a player sat on the page and nothing about whether the user asked for the video or whether the sound was on. video.plcmt, added in the same 2.6-202303 dated snapshot, uses a different four-value list (1 Instream, 2 Accompanying Content, 3 Interstitial, 4 No Content/Standalone) built around the MRC's tightened definition of instream: sound-on by default at player start, or explicit user intent to watch, with the video as the focus of the visit. The two enums do not map one to one, which is the entire reason this migration has taken three years instead of one release cycle. We cover the full value tables and the field-by-field mapping in placement vs plcmt in OpenRTB video; this piece is about where the industry actually stands on adopting it.

Why it was contentious: reclassifying means repricing

The old list let muted, autoplay video players embedded next to editorial content claim placement=1 In-Stream, the same code used for genuine pre-roll on requested content. Trade press coverage of the rollout put accompanying-content supply, video that plays alongside text rather than being the reason for the visit, at roughly 30% of online video volume that had been sold under the old In-Stream label. Under plcmt, that inventory reclassifies as plcmt=2 Accompanying Content, not plcmt=1 Instream, because it fails the sound-on and user-intent test.

That reclassification has a price attached. When Google began requiring video.plcmt on AdX bid requests in April 2024, publishers testing the new classification against buyer demand reported video revenue drops ranging from 20% to 63% depending on how much of their inventory was autoplay-heavy, with roughly 15% average declines reported across several SSPs. That is the real reason plcmt adoption has been slow and uneven: it is not a technical migration, it is an honest, partner-by-partner disclosure that some previously premium-priced inventory is not what it was sold as.

Why dual-sending is still the norm

The IAB's own implementation guide never asked publishers to cut over. Section 7.10 of the OpenRTB 2.6 implementation guide ("Updated Video Signals"), subsection 7.10.2, spells out the transition pattern directly: a publisher that wants to support both should send the legacy value for In-Stream on the legacy placement attribute and the updated Instream value on plcmt, in the same video object. Three years in, that is still what most of the supply side does, because the demand side has not finished migrating off the old field.

Trade coverage from August 2024 put six of the top ten DSPs as not yet reading plcmt at all, with Google, The Trade Desk, and Basis Technologies among the adopters at that point. Prebid.js only made gathering plcmt a requirement alongside placement in its version 9 release, and stopped letting its ORTB converter infer placement from ad unit context rather than an explicit value. Individual adapter issues from that release cycle show the lag in the wild: publishers reported ad servers and adapters that still only read video.placement and had no plcmt support yet, meaning dropping the legacy field on those integrations would have gone straight to a silent classification failure. There is no forcing function here besides confirming, demand partner by demand partner, that the new field is actually being read before you stop sending the old one.

What buyers key on now

The demand-side posture has hardened since the early skepticism. DV360 has required video.plcmt on AdX bid requests since April 2024, and Prebid.js adapter documentation and issue trackers describe plcmt as a value adapters are expected to gather and pass through, not an optional extra alongside placement. SSPs that adopted the new field early describe it as necessary for buyers to price instream, accompanying, and standalone video differently rather than lumping it all into one instream rate card. The practical upshot for a supply-side integration in mid-2026: assume any buyer running current DV360 or Trade Desk video strategies is reading plcmt and pricing off it, and assume any buyer still integrated against an older adapter or a legacy ad server connection is reading placement and nothing else.

What is not publicly documented

We could not find a published, industry-wide figure for what share of current video bid requests carry plcmt alone, placement alone, or both. Vendor blog posts and trade coverage describe adoption in terms of named DSPs and SSPs, not volume percentages, and the one hard number available (six of the top ten DSPs not reading plcmt as of August 2024) is almost two years stale by the time of this writing. Treat any specific dual-sending percentage you see quoted elsewhere as an estimate, not a measured industry figure, unless the source names how it counted.

What to check this week

rtblint flags the legacy field at its exact path: imp.video.placement trips openrtb.field.deprecated against the 2.6-202303 and later dated snapshots, so you can see at a glance whether a given request is still placement-only, plcmt-only, or sending both. Paste a sample video request into the bid request tester, or run rtblint validate request.json with the CLI in CI to catch requests missing plcmt entirely before a buyer's classification logic does it for you. If you have not re-audited your own inventory against the sound-on and user-intent test since the 2.6-202303 release, that is the actual outstanding work three years later, not picking a cutover date for placement.