RTBlintAlpha

Docs

AdCOM 1.0 object reference

AdCOM, the Advertising Common Object Model, is IAB Tech Lab's transaction-neutral object layer: the definitions of what an ad is, where it can run, and the context around it. OpenRTB 3.0 delegates all of its domain objects to AdCOM, and OpenRTB 2.6 moved its enumerated lists there. This page maps every object group.

The three object groups

AdCOM splits its model by question. Media objects answer what the ad is. Placement objects answer where and how it can render. Context objects answer everything around the transaction: property, device, user, and regulation. A protocol like OpenRTB 3.0 composes these into transactions; AdCOM itself defines no auction mechanics.

Media objects: the ad

  • Ad: the root creative object. Carries the advertiser domain (adomain), categories and their taxonomy (cat, cattax), language, attributes, an audit trail, and exactly one of the media subtypes below.
  • Display: banner and rich display creatives, including DisplayPlacement-matching dimensions, markup or a structured Banner/Native payload, and API frameworks.
  • Video and Audio: time-based creatives, referencing the markup (typically VAST for video) plus duration, mime types, and delivery attributes.
  • Audit: the creative review state a supply platform tracks: status, feedback, corrected fields, and review timestamps.

Placement objects: where it renders

  • Placement: the root supply-side object. Declares the tag id, secure requirement, supported API frameworks, and exactly one of the subtype objects.
  • DisplayPlacement: display slots, with DisplayFormat sizes, position, and native asset requirements via NativeFormat.
  • VideoPlacement and AudioPlacement: time-based slots: placement subtype (the list behind OpenRTB's plcmt values), durations, skippability, playback methods, and companion support via Companion.

The AdCOM video placement subtypes list is the one OpenRTB 2.6-202303 adopted for imp.video.plcmt; the values and their migration from the legacy placement field are covered in placement vs plcmt.

Context objects: everything around the transaction

  • DistributionChannel: the abstract property, concretely a Site, App, or Dooh object, each carrying a Publisher and optional Content (with Producer, channel, and network detail).
  • Device: hardware, OS, connection, and identifiers, with Geo for location and provenance.
  • User: the audience side: ids, consent, and Data/Segment pairs for third-party audience data.
  • Regs: regulatory flags (COPPA, GDPR applicability), and Restrictions: the categories, advertiser domains, and attributes the seller blocks for the transaction.

Where is the Impression object?

AdCOM deliberately has none. The impression is a transactional concept, so it stays in the transaction protocol: OpenRTB 2.x models it as imp, and OpenRTB 3.0 replaces it with Item, the unit of sale inside the request. An Item carries commercial terms (quantity, floor, deal references) and points at an AdCOM Placement through its spec field. So the 2.x imp.video becomes, in 3.0 terms, an Item whose spec holds a Placement with a VideoPlacement. The full mapping is in OpenRTB 2.6 vs 3.0.

AdCOM and the enum lists

Since OpenRTB 2.6, the enumerated lists (creative attributes, placement subtypes, playback methods, connection types, and the rest) live in AdCOM rather than the OpenRTB document, so both 2.6 and 3.0 share one set of definitions. The enum reference maps the lists as OpenRTB uses them, including the vendor-specific 500+ ranges.

RTBlint validates OpenRTB 3.0's transport layer in full and currently treats the AdCOM objects under item.spec and bid.media as opaque; see the 3.0 version page for what that covers. For background on why AdCOM exists at all, read What is AdCOM.