VAST macros / Identity and privacy
[LIMITADTRACKING] VAST macro
Short answer: Whether the user has enabled limit ad tracking (1) or not (0). Introduced in VAST 4.1.
What it means
A 0/1 flag reporting the device limit-ad-tracking setting. When 1, the [IFA] is typically zeroed or withheld and personalised targeting must be suppressed.
Example value
After the player substitutes the macro, [LIMITADTRACKING] becomes something like:
1Before 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?ifa=[IFA]&lat=[LIMITADTRACKING]
https://t.example.com/i?ifa=00000000-0000-0000-0000-000000000000&lat=1A 0 or a 1, from the device
[LIMITADTRACKING] resolves to 0 or 1, the device limit-ad-tracking setting. VAST 4.1 added it, next to [IFA] and [IFATYPE]. 0 means the identifier may be used. 1 means the user has limited tracking, and [IFA] should be empty or the all-zero identifier. A real advertising id sitting beside lat=1 means the two macros were filled by different layers, and the id should not be treated as available.
There is no third value. A log line that still contains [LIMITADTRACKING] was not substituted: the case is wrong, the player is older than 4.1, or the token was encoded before the player could see it. Do not store the brackets as a distinct privacy state.
What it is not
[GDPR] says whether GDPR applies to the request. [GDPRCONSENT] is the consent string. [LIMITADTRACKING] is the device switch, including the connected-TV platform switch the player is supposed to copy. A European web impression can have GDPR=1 and LIMITADTRACKING=0. A CTV impression can have LIMITADTRACKING=1 and no consent string at all. Dropping one into the column of the other misstates both.
The flag does not name the device. Frequency capping and attribution still need [IFA] and [IFATYPE] on the same URL. When the flag is 1, those fields are withheld on purpose. A cap that falls back to the IP address at that point is a policy choice the macro does not make.
The URL after a real substitution
When the switch is on, the identifier is the zero id or an empty parameter, and the flag is 1. When the switch is off, the flag is 0 and [IFA] carries the platform id named by [IFATYPE]: idfa, aaid, rida, tifa, or another token from that list.
Where it is valid
Impression, tracking, and click URLs alongside [IFA]. Introduced in VAST 4.1, so a 2.0 or 3.0 player leaves the token as written.
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
<Impression><![CDATA[https://t.example.com/i?ifa=[IFA]&lat=[LIMITADTRACKING]]]></Impression>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
- VAST-2.0-macro-unknown: URL contains a [MACRO] that is not a recognised IAB VAST macro
- VAST-2.0-macro-lowercase: Recognised macro is not uppercase — players match macro names case-sensitively
Related macros
- [IFA]: The device advertising identifier (IDFA, AAID, or CTV ad ID) for the request.
- [IFATYPE]: The type of advertising identifier carried in [IFA] (e.g. idfa, aaid, rida).
- [GDPR]: Binary flag for whether GDPR applies to this request (1) or not (0).
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.xmlUse 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.