Vendor Due Diligence
Part of AdTech interoperability and technical standards
Planning version changes in an ad integration
Map release changes to fields, callbacks, partner support, acceptance cases and recovery conditions before an ad integration cutover.
Plan a version change against the connection that runs today. Record what each party uses, what the new release changes, and which messages, callbacks or reports depend on it. A version number alone cannot show whether both systems will keep interpreting the same transaction in the same way.
Identify the changing layer
Separate the transaction standard, platform API, wrapper or SDK, and local field mapping; they can change on different schedules. IAB Tech Lab's OpenRTB 2.6 policy uses a date code for non-breaking updates and a new version number for breaking changes. A date-coded update can still add a field or value that an older deployed parser has not encountered.
Product releases can affect local code even when OpenRTB is unchanged: a wrapper release may remove or replace an event or an API that affected integrations consume. That is a wrapper migration detail, not a requirement for every bidder.
Google publishes separate deprecation and sunset schedules for its advertising APIs. Check the schedule for the exact product and API version in use.
Record the impact
| Item | Decision to document |
|---|---|
| Current and target versions | Standard release, product build, endpoint and proposed cutover date |
| Affected interface | Request, response, callback, report or export |
| Changed meaning | Fields, defaults, units, taxonomy values and extensions added, removed or reinterpreted |
| Partner readiness | Sender and receiver versions actually deployed and supported |
| Operational evidence | Errors, timeouts, relevant counters, alerts and support owner |
| Recovery | Prior deployable software and configuration, plus any limit on reverting |
Read release notes against the fields and events the connection actually consumes. Record a partner extension as its own dependency. Ask whether each side can handle old and new forms during a transition; a published non-breaking change does not prove that every deployed parser accepts it.
Pre-Cutover Verification Checklist for Ad Integration
- Document current and target versionsInclude standard release, build, endpoint, and proposed cutover date
- Map affected interfacesRequest, response, callback, report, or export impacted by change
- Track changed meaningsFields, defaults, units, taxonomy values, extensions added/removed/reinterpreted
- Confirm partner readinessBoth sender and receiver versions deployed and supported
- Collect operational evidenceErrors, timeouts, counters, alerts, support owner contact
- Verify recovery optionsPrior deployable software, configuration, and revert limits
Check the boundary before cutover
Prepare authorised examples for a normal request, a missing optional field, a new value, an unknown value, a no-bid response and a rejected response. Set the expected result for each, then compare old and proposed implementations where the environment permits. Check decisions and available counters as well as schema acceptance: a message can parse and still be interpreted differently.
If both forms must coexist, specify which party sends each form and when. Record the feature flag or routing rule that selects a version. A canary or parallel parser may help if the products support one, but the release decision must use the results actually recorded for this connection.
AdTech API Deprecation and Cutover Schedule
- Review release notes and deprecation schedules
- Check Google Ad Manager and Display Video API deprecation timelines
- Identify current and target versions
- Confirm OpenRTB 2.6 (date-coded) vs. new version or wrapper update
- Prepare test cases for coexistence
- Test normal request, missing field, new value, unknown value, no-bid, rejected response
- Validate both forms during transition
- Ensure parser compatibility with old and new formats
- Set cutover conditions and recovery plan
- Agree on acceptable release criteria and rollback path
Set the cutover and recovery conditions
Agree what constitutes an acceptable release: required messages are accepted, expected decisions are made, and required events remain observable. Set stop conditions for malformed messages, missing required fields, unexplained response loss or changed decisioning. Retain report definitions and the cutover time so later totals can be interpreted.
Reverting may require both software and configuration changes. It may also be unavailable if a partner has ended support for the old API version. Confirm the recovery route before moving traffic, and keep the migration evidence with the technical connection record.
Key Metrics for Successful Version Migration
- Expected decisions made
- Match between old and new implementations
- Events observable
- All critical callbacks triggered as expected
- Stop conditions monitored
- Malformed messages, missing fields, unexplained loss detected
