VAST tracking events / Linear
progress VAST tracking event
Short answer: Fires at a declared offset. The only tracking event that takes a parameter. Introduced in VAST 3.0.
When it fires
Playback reached the offset attribute. Offset must be HH:MM:SS or n%. A bare number of seconds is invalid. An offset past Duration can never fire, which looks like a dead tracker.
progress is the only event with a parameter
progress fires when playback reaches the offset attribute. VAST 3.0 added it. VAST 2.0 players do not call it. offset accepts HH:MM:SS or a percentage such as 25% or 75%. A bare number of seconds matches neither form, and the event cannot be scheduled.
An offset past Duration can never fire. offset="00:00:45" on a 30-second Duration is a dead URL that looks, in a report, like every other dead URL. Compare the offset to Duration before you blame the endpoint.
Several progress elements are normal
A creative may carry more than one progress tracker, each with its own offset. They are separate beacons. 00:00:15 and 75% on a 30-second spot are 15 seconds and 22.5 seconds. Quartiles still fire on their own schedule. progress does not replace firstQuartile. A vendor listening only for quartiles will ignore a progress URL the player did call.
Put progress on Linear. An overlay does not have this playhead. For a NonLinear unit, overlayViewDuration is the duration signal, from VAST 4.0.
Offsets the player cannot schedule
Both of these fail for a different reason. The first is not a timestamp or a percentage. The second is later than a 30-second Duration.
offset="15" is not a legal form. 00:00:45 never arrives on a 30-second Duration.
<Tracking event="progress" offset="15"><![CDATA[https://track.example.com/15]]></Tracking>
<Tracking event="progress" offset="00:00:45"><![CDATA[https://track.example.com/45]]></Tracking>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.
When the column stays empty
progress is absent from VAST 2.0. A player that only implements those versions will not request it. The version table on this page is the set that includes it.
Each wrapper hop may include its own progress URL. The player requests every one of them when the event happens, so a chain of four hops produces four calls for one playback. An http URL on an https page is dropped by the browser before the ad server sees a miss. The event name can be right and the scheme can still zero the column.
Where it is valid
| 2.0 | 3.0 | 4.0 | 4.1+ |
|---|---|---|---|
| No | Yes | Yes | Yes |
Legal containers: Linear. An event in the wrong container is not a player error. It is a URL nobody calls.
Using it in a tag
Put it in a Linear TrackingEvents block. It is not valid on the other creative types, and a player does not fire a tracker in the wrong container.
<Linear>
<TrackingEvents>
<Tracking event="progress" offset="00:00:15">
<![CDATA[https://track.example.com/progress]]>
</Tracking>
</TrackingEvents>
</Linear>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-3.0-progress-offset: <Tracking event="progress"> requires an offset attribute
- VAST-3.0-progress-offset-format: Tracking progress offset does not match required format
- VAST-4.1-tracking-event-value: Tracking event attribute not in the valid set for this VAST version
Related events
- start: Fires when linear playback actually begins, first frame rendered.
- firstQuartile: Fires when linear playback reaches 25 percent of Duration.
- complete: Fires when linear playback reaches the end of Duration.
Check the XML, then confirm the beacons fire
Validate the event names and containers on the document. Test a live URL when the XML is clean and reporting is still empty.