Guides

placement vs plcmt in OpenRTB video

video.placement was deprecated in the OpenRTB 2.6-202303 update in favor of video.plcmt. They are different fields with different enums: placement uses the old five-value list (1 In-Stream through 5 Interstitial/Slider/Floating), plcmt uses a new four-value list (1 Instream, 2 Accompanying Content, 3 Interstitial, 4 No Content/Standalone). The values do not map one to one. During migration, send both.

Two fields, two lists

Both fields live on the Video object of the bid request and both draw their values from AdCOM 1.0, where all 2.6 enums are maintained. placement points to List: Placement Subtypes - Video, which AdCOM now marks deprecated as of the 2.6-202303 release. plcmt points to List: Plcmt Subtypes - Video, written to match the updated IAB Digital Video Guidelines. The spec entry for placement now reads simply: deprecated as of OpenRTB 2.6-202303, use plcmt instead.

Old list: placement (deprecated)

Value	Name	Definition
`1`	In-Stream	Played before, during or after the streaming video content that the consumer has requested (pre-roll, mid-roll, post-roll).
`2`	In-Banner	Exists within a web banner that uses the banner space to deliver a video experience. Relies on display inventory on the page for delivery.
`3`	In-Article	Loads and plays dynamically between paragraphs of editorial content, existing as a standalone branded message.
`4`	In-Feed	Found in content, social, or product feeds.
`5`	Interstitial/Slider/Floating	Covers the entire or a portion of screen area, but is always on screen while displayed (cannot be scrolled out of view).

New list: plcmt

Value	Name	Definition
`1`	Instream	Pre-roll, mid-roll, and post-roll ads played with streaming video content the consumer requested. Must be sound-on by default at player start, or have explicit user intent to watch. The video must be the focus of the visit and the only in-view player capable of audio while playing.
`2`	Accompanying Content	Pre-roll, mid-roll, and post-roll ads with streaming video content, where the player loads before, between, or after paragraphs of text or graphical content and starts playback only on entering the viewport. May convert to a floating or sticky player when scrolled off the page.
`3`	Interstitial	Video ads played without video content. Must be the primary focus of the page during playback, take up the majority of the viewport, and cannot be scrolled out of view.
`4`	No Content/Standalone	Video ads played without streaming video content, in placements such as slideshows, native feeds, in-content, or sticky and floating units.

Why the change happened

The old list described where a player sat on the page. It said nothing about whether the user asked for the video or whether the sound was on, and over time a large share of muted autoplay outstream inventory was sold as placement=1 In-Stream. The updated IAB Digital Video Guidelines, following the MRC's tightened definition of instream, made user intent and audio the test: under the new list, Instream (plcmt=1) requires sound-on by default at player start or explicit intent to watch, with the video as the focus of the visit. Everything that fails that test is now Accompanying Content, Interstitial, or No Content/Standalone. The point is transparency in monetization: buyers paying instream CPMs get inventory that meets the instream definition.

That is also why the two enums cannot be converted mechanically. Old In-Stream splits into new Instream or Accompanying Content depending on audio and focus. The IAB implementation guide's own examples show placement=1 paired with plcmt=1 for true instream, and placement=3 In-Article paired with plcmt=4 No Content/Standalone. Classify each placement against the new definitions; do not write a lookup table.

Migration guidance

The IAB's transition pattern is to send both fields, each with the correct value from its own list:

{
  "imp": [{
    "id": "1",
    "video": {
      "mimes": ["video/mp4"],
      "placement": 1,
      "plcmt": 1
    }
  }]
}

Audit each video placement against the new definitions: is sound on by default, did the user request the content, is the player the focus of the visit?
Set plcmt from the new list on every video request. For CTV, full-episode and live streams are plcmt=1.
Keep sending placement with its legacy value while demand partners still read it. Buyers on the updated definitions read plcmt; legacy DSPs read placement.
Drop placement once your partners confirm they key on plcmt. New integrations should not read placement at all.

Downgrading previously "instream" inventory to plcmt=2 is not a penalty: honest signals keep the supply biddable by buyers who now filter on the new field. The CTV page covers how plcmt interacts with pod bidding fields, and the 2.5 vs 2.6 guide puts the change in context of the other dated updates.

FAQ

Do I send both placement and plcmt?

Yes, during the transition. The IAB implementation guide shows exactly this pattern: keep the legacy value in video.placement for buyers still reading the old list, and set video.plcmt from the new list. Buyers on updated definitions read plcmt; once your demand partners confirm they do, you can drop placement.

What is plcmt 2 (Accompanying Content)?

Video with streaming content that plays alongside text or graphical content rather than being the reason for the visit. It starts playback only on entering the viewport and may convert to a floating or sticky player. Much inventory that claimed placement=1 In-Stream under the old list, such as muted autoplay players in articles, belongs in plcmt=2 under the new definitions.

Is plcmt required in OpenRTB 2.6?

The spec does not mark it required. In practice video buyers increasingly key pricing and eligibility on plcmt because it separates true sound-on instream from accompanying and standalone video, so omitting it costs money on CTV and instream web supply.

Validate it

Paste a video bid request into the bid request tester and rtblint flags the deprecated field at its exact path, for example imp.0.video.placement, via its deprecated and moved field checks (openrtb.field.deprecated, openrtb.field.moved), and checks plcmt against the documented AdCOM values. The CLI runs the same rules in CI: rtblint validate request.json.