[Change] § 5.4: Keep creative inspection and previews from sending production tracking #42

What kind of change?

Change a normative requirement (MUST / SHOULD / MAY)

Which section?

5.4: Creative requirements

Current text

Section 5.4 defines creative delivery, supplied assets and approval. The third_party_tags description is "Accepted wrapper types and VAST versions". It does not distinguish requests made to inspect a creative from notifications that report delivery of that creative.

Proposed text

Add the following subsection after the § 5.4 field table:

Creative inspection and previews

For this section, inspection means evaluating a creative outside live campaign delivery, including discovery, composition, submission checks and previews. A production notification is an event report intended for a campaign's live measurement or delivery diagnostics.

An implementation performing inspection MUST NOT send production impression, playback, click, viewability, verification or ad-error notifications. This includes requesting an event URL solely to check its availability, regardless of the HTTP method used.

An implementation MAY retrieve creative documents, follow VAST wrappers and inspect referenced media as needed for its checks. Permission to retrieve these resources does not extend to firing their event URLs. Retrieval can itself be logged by the resource owner; this requirement does not imply that inspection produces no server activity.

A preview that executes creative or verification code MUST prevent that code from sending production notifications. Synthetic events MAY be sent to test endpoints, or through a test mode that the receiving service documents as excluding those events from production measurement and delivery diagnostics. An inspector's own test flag is insufficient unless the receiving service supports it.

Inspection failures MUST be returned through the inspection result or a separate diagnostic channel. They MUST NOT be reported by firing a production VAST <Error> or verificationNotExecuted URL.

A skipped or blocked check MUST NOT be reported as passed. This section does not waive any required checks.

These requirements apply to inspection only. During live delivery, implementations remain subject to the tracking and error-reporting requirements of the applicable execution standard.

Why

Consider an agent previewing a supplied VAST tag before committing to a line item. It loads the tag into a player to check playback. The player fires the tag's impression and start beacons. A second check encounters a wrapper failure and fires its error beacon. The endpoints receive real event reports even though these were inspection attempts.

VAST distinguishes resource retrieval from event reporting. Its tracking section explains that requests to tracking resources contribute to event counts, and that they belong at the corresponding playback event. Its error-reporting section describes player failures during ad serving. Reusing a player for previews therefore needs an explicit boundary around its production notifications. The same problem can occur when a display preview loads an embedded tracking pixel.

This is a source-review scenario, not a report of a defect observed in an OpenProposal implementation.

VAST 4.3, §§ 2.3.4 and 2.3.6 provides the underlying event semantics. Issue #32 concerns which creative checks run at submission. This change concerns what those checks and previews are permitted to send, regardless of which checks are implemented.

Knock-on effects

• No new fields, mutability markers or enum values. The field indexes in Appendices A and B stay unchanged.
• No requirement to add document fetching or previews. Implementations that offer them must keep their event traffic separate from live delivery.
• Add a short note alongside the § 6.3 CTV example explaining that inspecting its VAST creative must not fire production tracking.
• VAST and OpenRTB execution semantics stay unchanged. The proposal does not define a measurement methodology, attribution rule or settlement process.
• No additional buyer-seller round trip is required. An optional inspection can be omitted with the limitation reported. A required check needs a way to run without production notifications before it can pass.

Would this break an implementation already built to this draft?

Yes, for an implementation that sends production notifications during inspection. The payload shape is unchanged.

Alternatives you considered and rejected

Rely entirely on VAST's playback rules. Those rules describe a player serving an ad; OpenProposal also has agents checking and previewing creatives before delivery. The inspection boundary should be explicit where those checks happen.

Require a universal test query parameter. A parameter only works if the receiving service recognizes it and separates the resulting events. This proposal permits existing test modes without inventing a new one.

You are commenting as

Standards body / working group participant

Member of the IAB Tech Lab Agentic Taskforce, commenting in a personal capacity.

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This contains no confidential or commercially sensitive information.