video.plcmt in OpenRTB: values, versions, and what buyers filter on

The nine values

The values come from AdCOM's List: Plcmt Subtypes - Video, not from OpenRTB itself, which is why they can change without an OpenRTB release. Values 1 through 4 arrived with the field; 5 through 9 were added by AdCOM 1.0-202607 for the CTV Ad Portfolio formats.

The list defines no vendor-specific range, so unlike api or battr there is no 500-and-above escape hatch. A value outside 1 through 9 is simply invalid, and a buyer that does not recognise it treats the impression as unclassified.

When plcmt actually existed

Ask three integrations when plcmt arrived and you get two answers, because the specification's release notes and its text disagreed for six months.

This is why every secondary source, this site included, dates the change to 2.6-202303: it is quoting the specification correctly. The 202303 document simply never said it. AdCOM took the same date, annotating its legacy Placement Subtypes list "deprecated as of the 2.6-202303 release". So both dates are defensible, and which one is correct depends on which artifact you validate against. RTBlint validates against the specification text, snapshot by snapshot, so 2.6-202309 is the first version where a payload carrying plcmt passes without a finding. Sent against an earlier snapshot, the validator says the field is not defined for that version rather than silently accepting it, which is the behaviour that catches a bidder pinned to a snapshot older than the field it is reading.

The practical answer for a seller: if a partner disputes whether plcmt is valid for the version you agreed at integration time, the disagreement is real and it is theirs to resolve, not a bug in your request. Name the snapshot in the conversation.

Fields that answer a different question

Four fields on the Video object look like they overlap with plcmt. They do not, and the mistakes come from treating them as interchangeable.

The linearity confusion is worth calling out because the spec itself addresses it: the field describes the expected VAST response, not whether a placement is instream or outstream. A request declaring linearity 1 tells a buyer nothing about whether the video content exists.

What a validator reports, and why

What no validator can tell you is whether the value is the right one. A request that says "plcmt": 1 for a muted autoplay player beside an article is valid OpenRTB and misdescribed inventory. That distinction is the reason buyers audit plcmt distributions against measured player behaviour rather than trusting the field.

A minimal instream request

{
  "id": "auc-1",
  "imp": [
    {
      "id": "1",
      "video": {
        "mimes": ["video/mp4"],
        "plcmt": 1,
        "placement": 1,
        "linearity": 1,
        "startdelay": 0,
        "w": 1920,
        "h": 1080,
        "protocols": [2, 3, 5, 6]
      }
    }
  ],
  "site": { "id": "s-1", "domain": "example.com" }
}

Both placement fields are present on purpose. Drop placement when your partners confirm they read plcmt, not before. Paste this into the tester and change the version selector to watch the finding change with the snapshot.

FAQ

Related

• placement vs plcmt: the migration, value by value
• The Video object: every field, grouped by what it controls
• Enum reference: the full AdCOM definitions for all nine values
• CTV and ad pods, where plcmt 5 through 9 land
• Three years of plcmt: the state of the migration