Standards
AdTech interoperability and technical standards
Document and assess advertising-system handoffs across OpenRTB, VAST, field mappings, reporting events and version changes.
Advertising systems interoperate when they exchange an ad opportunity, interpret the relevant data consistently, make their respective decisions and account for the outcome. Support for the same standard is a starting point. Each connection also needs an agreement about fields, values, versions, extensions and events.
Map the handoffs
Start with one buying route and format. Identify who creates the opportunity, who receives it, who makes the final ad decision and who records delivery. A web display route and a streaming video route may have different handoffs.
| Handoff | What a standard describes | What the partners must confirm |
|---|---|---|
| Bid request and response | The message format and structures used by the chosen protocol. | Fields sent, fields required for a decision and treatment of missing values. |
| Shared values | AdCOM lists objects and enumerations. | The taxonomy or list version understood on this connection. |
| Video ad response | VAST defines an XML format and expected player behaviour. | Features supported by the actual player, media requirements and tracking route. |
| Reporting | Each system records events at its own stage. | The event, inventory, period and reporting cut-off being compared. |
For each route, agree which request and response details are needed for a decision, which may be absent, and how missing values are handled. A message can follow a specification yet lack information a particular partner requires. Document the attributes the sender supplies and the receiver needs.
Record the connection's contract
For each route, record the standard release and each partner's implementation profile: transport and encoding, supported formats, required fields, extensions, taxonomies, accepted currencies, response deadline and error behaviour. Keep the sender's field meaning beside the receiver's interpretation.
Check currency in the payload rather than inferring it from an Australian campaign budget. Confirm the meaning and any defaults of currency fields with both partners before comparing prices with an AUD budget or report.
For any partner-specific fields or extensions, obtain the relevant schema and example values, and confirm how the receiver handles unfamiliar information. A field appearing in one sample does not establish that every route sends it.
OpenRTB 2.6’s dated release format identifies the release month: for example, 2.6-202211 denotes November 2022, and subsequent releases can use codes such as 2.6-202212 or 2.6-202301. The specification is updated approximately monthly for non-breaking improvements, which can include new fields, objects or enumerated values. Record the date code as well as the major version when assessing a connection.
Before accepting a release change, compare the exact fields, objects and enumerated values used by the route with the partner’s deployed parser. OpenRTB 2.x versions before 2.6 used a different convention: major versions indicated breaking changes, while minor versions indicated non-breaking changes. A version number without its applicable versioning policy can therefore leave the parties with different expectations.
Managing Connection Contracts Across AdTech Systems
- Document implementation profilesTransport, encoding, supported formats, required fields, extensions
- Confirm currency handlingCheck payload values, not inferred from AUD budgets
- Validate partner-specific fieldsObtain schema, example values, and receiver handling logic
- Establish change procedureAssign ownership, version control, rollback plan
Check what crosses each boundary
Use a small set of authorised cases covering a valid request, a missing optional field, an unsupported value, a no-bid response, a rejected bid and a selected ad. Define the expected outcome for each handoff before comparing available records.
Keep the event stages distinct. A bid response shows that a bidder replied; it does not establish that the bid entered an auction, won the final selection or produced an impression. Check which event records each system exposes and agree how they map to the route’s stages.
Reporting systems may expose measures for different events or stages. Treat measures from different products as examples, not counters to combine into one assumed route.
If records differ, align the placement, format, route, period and event definition, then find the first handoff where they separate. Use a shared identifier only where the systems actually expose one. Otherwise, compare compatible aggregates and state that individual tracing is unavailable.
Key Steps to Validate AdTech Handoffs
- Define authorised test casesCover valid request, missing optional field, unsupported value, no-bid, rejected bid, selected ad
- Confirm event stage mappingDistinguish bid response from auction win or impression delivery
- Align reporting definitionsMatch placement, format, route, period and event definition across systems
- Use shared identifiers only if exposedOtherwise compare compatible aggregates
Assess VAST release compatibility
A VAST version label does not by itself establish support for every feature in that release or its addenda. For example, VAST 4.2 added support for interactivity with SIMID, while the VAST CTV Addendum released in July 2024 includes ACIF support, ad registration and icons to support DSA. Record the exact version and addendum each partner supports, then confirm which relevant features work on the proposed route.
The IAB Tech Lab’s version history provides compatibility checkpoints: VAST 4.3 was released in December 2022, and VAST 4.2 in June 2019. The CTV Addendum for VAST 4.x was released in July 2024, with updates including support for higher-resolution creative on larger screens. These dates help distinguish a claimed standard version from the additional capabilities a partner has deployed.
VAST Version Compatibility and Addenda Support
Make shared values testable
AdCOM v1.0 is dated March 2022 and includes enumerations such as category taxonomies, device types, event types and event-tracking methods. For each value used in an OpenRTB connection, record the applicable list and version, then check that the sender’s value exists in the receiver’s interpretation. A matching field name is not enough if the parties use different enumerated values.
Include representative values in the connection’s test cases, especially where an enumerated value can affect how an object is interpreted. Record whether a value is accepted, mapped to another value or rejected, and agree how changes to the relevant list will be assessed.
AdCOM v1.0 Key Enumerations (March 2022)
- Category Taxonomies
- Standardised list of advertising categories
- Device Types
- Defined device classifications (e.g., mobile, desktop, connected TV)
- Event Types
- Standardised tracking events (e.g., start, complete, click)
- Event-Tracking Methods
- Methods used to record user interactions
Keep the agreement current
OpenRTB 2.6 uses date-coded releases for non-breaking updates and a new version number for breaking changes. A non-breaking update may still add a field or value unfamiliar to a deployed parser. Products and wrappers have their own release schedules.
Give each connection an owner, recorded versions and a change procedure. Before upgrading, compare release notes with the fields and events the route uses, confirm both partners' support, exercise the agreed cases and identify a recoverable prior configuration. Retain the result with the exact route and versions assessed.
In this guide
- Reading an OpenRTB field without confusing it with a targeting ruleUse site.pagecat to see what an OpenRTB field describes and why it does not prove a buyer's campaign targeting rule.
- Testing discrepancies between connected advertising systemsTrace an AdTech integration discrepancy by aligning event definitions, IDs, routes, dates and configuration versions.
- Planning version changes in an ad integrationMap release changes to fields, callbacks, partner support, acceptance cases and recovery conditions before an ad integration cutover.
- Maintaining a technical inventory of an advertising stackRecord each advertising-system connection, its versions, field contract, owners and observable events so changes and incidents can be traced.
