VASTlint

VAST macros / Ad and pod

[ADSERVINGID] VAST macro

Short answer: The AdServingId from the InLine ad, shared across the supply chain. Introduced in VAST 4.1.

What it means

Resolves to the text of the InLine AdServingId element: one identifier that every party can write into its own log for the same impression.

Example value

After the player substitutes the macro, [ADSERVINGID] becomes something like:

a1b2c3d4-e5f6-7890-abcd-ef1234567890

Before and after the player substitutes it

The first line is the URL in the tag. The second line is the request the player sends once it has a value.

https://t.example.com/i?asid=[ADSERVINGID]
https://t.example.com/i?asid=a1b2c3d4-e5f6-7890-abcd-ef1234567890

One id for the serving, copied by everyone

[ADSERVINGID] resolves to the text of the InLine AdServingId element. The element arrived in VAST 4.0. The macro arrived in VAST 4.1. The point of the element is that every company that touched the impression writes the same string into its own log, so a discrepancy is a comparison of one id rather than a guess across timestamps.

The value comes from the InLine. A wrapper does not mint a replacement. A wrapper pixel that fires before the player has fetched the InLine still contains the literal [ADSERVINGID], because the element does not exist yet. If you need the id on every hop, the early hop will be unsubstituted and the later hop, after the InLine, will carry the value. Those are not two servings.

When the two logs disagree

If the publisher log and the DSP log show different AdServingId values for what everyone believes is one impression, one side generated its own id. The macro cannot repair that. It only copies whatever text is in the element. A fresh UUID on each hop, written into AdServingId by the wrapper, destroys the comparison. Leave the InLine value alone as the chain proceeds.

[UNIVERSALADID] identifies the creative and stays stable across servings of that creative. [ADSERVINGID] changes with the serving. [TRANSACTIONID] is yet another id, for the transaction. A pixel that only has room for one of them should be explicit about which, because a frequency cap on the serving id resets every impression, and a discrepancy join on the creative id joins every serving of that creative into one bucket.

The element and the pixel

The player reads the element, then substitutes the macro in URLs that fire after that read.

A wrapper impression that fires before this InLine is fetched still contains the brackets.

<InLine>
  <AdServingId>a1b2c3d4-e5f6-7890-abcd-ef1234567890</AdServingId>
  <Impression><![CDATA[https://t.example.com/i?asid=[ADSERVINGID]]]></Impression>
</InLine>

VAST XML fragment only. This excerpt belongs inside a complete VAST document, so standalone validation will fail until it is wrapped in a full <VAST>response.

Where it is valid

Impression, tracking, error, and click URLs, once the player has the InLine. The element arrived in VAST 4.0. The macro arrived in VAST 4.1.

Macros are case-sensitive and substituted only inside URL fields. A macro written in the wrong case, or placed where it has no defined value, is sent to the server as literal text instead of a value.

Using it in a tag

<InLine>
  <AdServingId>a1b2c3d4-e5f6-7890-abcd-ef1234567890</AdServingId>
  <Impression><![CDATA[https://t.example.com/i?asid=[ADSERVINGID]]]></Impression>
</InLine>

VAST XML fragment only. This excerpt belongs inside a complete VAST document, so standalone validation will fail until it is wrapped in a full <VAST>response.

Related vastlint rules

Related macros

Validate your macros

vastlint flags unknown, mis-cased, deprecated, out-of-context, and unencoded macros in any tracking, click, error, impression, or media URL:

# CLI: exits non-zero on errors, ideal for pipelines
vastlint check creative.xml

Use the right tool for this failure

If you already have the resolved XML, run a pure spec check. If you only have a live tag URL, test that endpoint first. If the failure happens in the wrapper chain, inspect each hop.

Further reading