VAST tracking events / Linear
unmute VAST tracking event
Short answer: Fires when ad audio is restored after mute.
When it fires
Ad audio was unmuted. Count it against mute, not against start. A burst of unmute with no mute usually means the player fired the wrong name.
Unmute records the volume coming back
unmute fires when ad audio is restored after it was off. Read it next to mute. A start that is heard the whole way produces neither. A start that begins silent and is turned up produces unmute only, which is common on mobile players that begin muted.
The name has been valid on Linear since VAST 2.0. It was not removed in 4.0. A 4.x document that still says unmute is correct. Do not rename it to a vendor's private event.
A player that fires the wrong one
Some players emit unmute at the start of every ad that is audible. The count then matches start, and mute stays at zero. That pattern is a player bug. The tag cannot fix it by adding a second unmute URL. Confirm with one known tag in the tester, where you can see the event log, before you rewrite the template.
Muted starts on mobile and CTV
Mobile players often begin playback muted and wait for a gesture. The first audio event is then unmute, with no mute before it, and it can arrive well after start. A dashboard that requires mute before unmute will drop those rows. Count unmute on its own for that inventory.
A connected-TV ad that is audible for the whole spot produces neither mute nor unmute. Building a heard-rate as unmute divided by start reports zero on the inventory that was heard the entire time. Heard-rate needs a player that tells you the starting volume. This event only records a change.
When the column stays empty
unmute is in the VAST 2.0 set, and the current version still includes it. An empty column on a current player is not a version mismatch.
Each wrapper hop may include its own unmute 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+ |
|---|---|---|---|
| Yes | 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="unmute">
<![CDATA[https://track.example.com/unmute]]>
</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-4.1-tracking-event-value: Tracking event attribute not in the valid set for this VAST version
Related events
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.