Wiki · Concept · Last reviewed June 25, 2026

AdCOM

AdCOM, the Advertising Common Object Model, is IAB Tech Lab's shared vocabulary for describing ads, placements, context, and enumerated values used around programmatic advertising protocols.

Category: Concept / Ad Tech Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AdCOM, OpenRTB, adtech, bidstream, agentic advertising, privacy

Definition

AdCOM is not an auction protocol. It is IAB Tech Lab's Advertising Common Object Model: a reusable vocabulary for ad-market concepts around protocols such as OpenRTB. OpenRTB handles requests, bids, deals, prices, notices, and auction mechanics; AdCOM supplies shared concepts such as ads, placements, users, devices, sites, publishers, content, creative attributes, and enumerated values. A bidder may see an integer in a bid request, but the meaning of that integer often comes from an AdCOM list.

IAB Tech Lab's overview separates AdCOM into two practical parts. One is the object model associated with OpenRTB 3.0, a version IAB says was not widely adopted. The other is the set of enumerated lists used by OpenRTB 2.x attributes; IAB says that part has broad adoption because common values can be referenced compactly and updated modularly. The official GitHub releases list AdCOM 1.0-202606, published June 11, 2026, as the latest release reviewed for this entry.

Mechanism

The AdCOM v1.0 specification groups its object model into media, placement, and context objects. Media objects describe the ad, including creative metadata, rendering details, restrictions, tracking, and audit information. Placement objects describe what kinds of ads and behaviors are allowed in a slot. Context objects describe the environment around the impression: site, app, digital out-of-home, publisher, content, user, device, location, data segments, and regulation-related objects.

AdCOM also defines enumerated lists. The official specification includes lists for agent types, API frameworks, audit status codes, category taxonomies, connection types, content contexts, creative attributes, device types, placement types, event tracking methods, location types, media ratings, playback methods, and related ad-market values. These lists make bidstream fields easier for systems to parse, compare, and validate.

The OpenRTB overview notes that OpenRTB 2.6 uses AdCOM 1.0 lists for faster updates, while OpenRTB 3.0 introduced companion AdCOM specifications. In practice, AdCOM is the shared dictionary for field meanings, while OpenRTB remains one major transport and auction layer.

Agent Context

AdCOM has a direct agent context because machine buyers, seller agents, fraud systems, brand-safety systems, creative reviewers, and compliance tools operate on structured descriptors. A buying agent can treat placement type, content category, device context, creative attributes, and audit status as features. A seller-side system can use the same vocabulary to declare acceptable media, sizes, and behaviors.

IAB Tech Lab's 2026 AAMP materials make the connection explicit: its agentic advertising work references existing standards, and its agentic protocols include object models and primitives based on Tech Lab standards such as AdCOM. Standardized schemas can reduce ambiguity for agents, but they can also let a questionable data flow scale faster because every participant can parse it.

Governance Use

A governed deployment should record the AdCOM version or release tag, the transaction layer that invokes it, the lists used, the fields sent, any vendor-specific extensions, the interpretation applied by bidders or policy engines, and the retrieval time. The AdCOM specification treats the model as extensible, so an audit must distinguish official values from local extensions and stale mappings.

For AI and automated advertising systems, governance should bind AdCOM fields to use limits. A placement descriptor may be acceptable for rendering and pricing while being unacceptable for sensitive inference, audience enrichment, or downstream model training. A creative-attribute code may help block unsafe ads, but it does not prove the creative was reviewed correctly.

Limits

AdCOM does not prove that a person consented, that a seller is authorized, that a category is accurate, that a bidder deleted losing-bid data, or that a model used the field lawfully. It gives systems a shared vocabulary. Privacy, consent, minimization, security, competition, and deletion questions need separate evidence.

The most important limit is semantic compression. A compact code can make traffic smaller and integrations cleaner, but it can also hide the living situation behind the code. A page, app, show, device, location, or creative is reduced to a machine-readable value that may travel farther than the person understands.

Source Discipline

Claims about AdCOM should identify the exact source: the IAB Tech Lab overview page, the AdCOM v1.0 specification, the GitHub repository, the release tag, or the transaction specification that references AdCOM. Claims about adoption should distinguish IAB's statement about OpenRTB 2.x enumerated lists from the less-adopted OpenRTB 3.0 object-model architecture. Claims about a real exchange, bidder, publisher, or agent require implementation evidence beyond the standard itself.

Spiralist Reading

Spiralism reads AdCOM as grammar below the auction. OpenRTB is the sentence that says an impression is for sale; AdCOM supplies many of the nouns and adjectives that make the sentence computable. That grammar can support interoperability and safety review. It can also make people, contexts, and creative judgments more portable inside attention markets. The discipline is to ask which values deserve to exist, who assigns them, who can correct them, and what automated systems are allowed to infer from them.

Sources

Return to Wiki