Wiki · Concept · Last reviewed July 10, 2026

AdCOM

AdCOM, the Advertising Common Object Model, is IAB Tech Lab's shared vocabulary for describing ads, placements, content, users, devices, creative attributes, and enumerated values used around programmatic advertising protocols. It makes bidstream semantics portable; it does not prove consent, lawful basis, seller authorization, or downstream deletion.

Definition

AdCOM is not an auction protocol, consent framework, ad-transparency law, or proof that an advertising data flow is legitimate. 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, audit status, regulation signals, and enumerated values.

The practical point is semantic interoperability. A bidder may see a compact integer in a bid request, but the meaning of that integer often comes from an AdCOM list. That keeps traffic smaller and integrations more consistent, but it also makes the mapping between a human context and a machine-readable code a governance object.

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.

Snapshot

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 2.6 specification says OpenRTB uses AdCOM 1.0 for enumerations so new values can be added without requiring a new OpenRTB version. The OpenRTB 2.x repository similarly describes AdCOM as the companion specification for common objects and values and states that, as of OpenRTB 2.6, all OpenRTB 2.6 enumerated lists are kept in AdCOM for faster iteration. In practice, AdCOM is the shared dictionary for field meanings, while OpenRTB remains one major transport and auction layer.

Current Context

As reviewed on July 10, 2026, the official AdCOM repository says the main branch contains the most recent release, release branches preserve prior releases, and the develop branch is work in progress. The current release page lists AdCOM 1.0-202606 as the latest release, dated June 11, 2026, with additions of realtime and firstbroadcast attributes in the Content object and an updated description for content.livestream.

AdCOM is also being pulled into agentic-advertising work. IAB Tech Lab's AAMP page describes Agentic Advertising Management Protocols as an umbrella initiative built around agentic foundations, agentic protocols, and trust and transparency. It says the agentic-protocol layer includes object models and primitives based on existing taxonomies and Tech Lab standards such as AdCOM, and specifically names an Agentic Ad Object derived from AdCOM.

The privacy context remains separate from the standard. The UK Information Commissioner's 2019 RTB report flagged transparency, consent, special-category-data, supply-chain, and data-protection-impact-assessment concerns around RTB. In January 2025, the U.S. Federal Trade Commission finalized a Mobilewalla order that bans that company from collecting consumer data from online real-time bidding advertising exchanges for purposes other than participating in those auctions. Those sources do not amend AdCOM, but they show why a parseable bidstream value still needs legal, retention, and recipient evidence.

EU platform rules add another boundary. The European Commission's Digital Services Act materials say ads must be clearly labelled, platforms must provide information about who placed an ad and why the recipient sees it, very large online platforms must maintain public ad repositories, and platforms can no longer show ads based on sensitive data such as sexual orientation, religion, or race. AdCOM can help machines describe inventory and creatives; it does not satisfy those transparency duties by itself.

Agent Context

AdCOM has a direct agent context because machine buyers, seller agents, fraud systems, brand-safety systems, creative reviewers, compliance tools, and media-planning agents 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.

The safety question is not whether agents can parse the schema. It is whether the schema gives them authority they should not have. A media-buying agent that can optimize on placement and content values may also infer sensitive context, route budget toward manipulative creative, or reuse bidstream fields for model training unless the deployment binds fields to permitted purposes and retention limits.

Standardized schemas can reduce ambiguity for agents, but they can also let a questionable data flow scale faster because every participant can parse it. Agentic advertising therefore needs the same evidence discipline as other delegated systems: identity, scope, version, data provenance, approvals, recipient logs, and limits on automated inference.

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, deprecated values, stale mappings, and exchange-specific conventions.

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. A regulation object may carry a signal, but it does not prove that consent, notice, or deletion duties were satisfied.

The minimum evidence record should include the release tag, list name, field path, transmitted value, human-readable meaning, source timestamp, actor assigning the value, recipient category, legal basis or policy rule relied on, retention rule, downstream-model-use rule, and any dispute or correction path. This record connects AdCOM to AI Audit Trails, AI Data Provenance, AI Data Retention, and Data Minimization.

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, that a creative passed human review, 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 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.

Another limit is version drift. The same code can be interpreted against different release snapshots if a bidder, exchange, compliance tool, or agent uses a stale list. A governance review should therefore ask not only whether a field was syntactically valid, but which AdCOM release supplied its meaning at the time of the transaction.

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, the OpenRTB specification, 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.

Claims about legal duties should use regulator, statute, court, or official agency sources. The ICO and FTC sources cited here concern RTB and named enforcement or regulatory issues, not AdCOM conformance. The DSA source concerns EU platform advertising transparency duties. Do not collapse those into a claim that AdCOM itself grants compliance.

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.

Open Questions

Sources


Return to Wiki