Wistia video tracking in Google Tag Manager

New in 2.0.0. Google Tag Manager for WordPress reports how your visitors watch the Wistia videos embedded on your site. Starting, pausing, seeking and finishing become data layer events, and so do changes to the volume and the playback speed.

This page describes GTM4WP 2.0.0 and newer. Wistia tracking did not exist in the legacy 1.x versions of the plugin.

The option is experimental and carries an Experimental badge in the plugin settings. Of the players added in 2.0.0 it is one of the better behaved ones, because Wistia exposes a real title and a proper ready signal, but it has had less real world use than the stable players.

Turning Wistia tracking on

Open the plugin settings, go to the Media events section, expand the Media players group and check Wistia video events. The option is switched off by default.

Which embeds are detected

Wistia is wired differently from every other player here, and the difference works in your favor.

The plugin loads no Wistia script of its own. Your Wistia embed already brings its own player runtime, and that runtime reads a queue of instructions that anything on the page can add to. The plugin puts one instruction in that queue asking to be told about every Wistia video on the page, and the Wistia runtime works through the queue whenever it happens to load.

Three things follow from that. Every Wistia video on the page is covered, whatever the embed looks like, inline or popover. The order does not matter, so the plugin can register before or after the Wistia script arrives and it still works. And there is no extra network request, because the plugin adds no script of its own for this player.

Videos added after the page loads need nothing extra

Wistia is the one player where the Track dynamically inserted players option makes no difference. Every other tracker finds its players by looking through the page, so it needs that option to keep looking after the page has loaded. Wistia tells the plugin about each video itself, whenever that video becomes ready, so a video opened in a popup or loaded by AJAX is picked up without any extra setting.

If Wistia is the only player you track, leave that option off. It would only add cost for nothing.

Playback states

The gtm4wp.mediaPlayerStateChange event fires with these values in the mediaPlayerState variable:

mediaPlayerState	Fires when
`play`	Playback starts.
`pause`	The visitor pauses the video.
`ended`	The video reaches its end.
`seeked`	The visitor jumps to another position.

There is no buffering state, because the Wistia player does not report one.

Player events

The gtm4wp.mediaPlayerEvent event carries the name of the event in the mediaPlayerEvent variable and the accompanying value in mediaPlayerEventParam.

mediaPlayerEvent	mediaPlayerEventParam
`playbackratechange`	The new playback rate.
`volumechange`	The new volume.

There is no error event for this player.

What mediaData holds for a Wistia video

Variable	Contents
`mediaData.id`	The hashed ID Wistia gives the video.
`mediaData.author`	Always empty. The Wistia player exposes no owner name.
`mediaData.title`	The name of the video as it is set in your Wistia account. This is a real, readable title.
`mediaData.url`	The Wistia embed address built from the hashed ID.
`mediaData.duration`	The length of the video in seconds.

The mediaType variable is wistia in every event.

A readable title puts Wistia in a small group here. Several of the other players added in 2.0.0 report an ID in that field, so a Wistia report needs no lookup table to make sense of it.

How progress is measured

Wistia reports how much of a video has been watched on its own, so the plugin does not have to poll the player the way it does for YouTube and Twitch. It listens for that report and turns it into the usual milestones, which makes the numbers a little tighter for this player.

Google Tag Manager built-in Video variables

Every Wistia media event also populates the built-in Video variables of Google Tag Manager, with Video Provider set to wistia. The section on built-in Video variables explains how to enable and use them. Video Title holds the real video name here.

Video Visible needs the player’s own element, which the Wistia API does not hand over directly. The plugin asks the runtime for it where that is possible and otherwise finds the container by the class Wistia puts on it. It is resolved fresh on every event, so a video opened later in a popup is measured correctly rather than reported against a box that was not on the page yet.

Building a trigger in Google Tag Manager

To fire a tag when a visitor starts a Wistia video:

Create a Data Layer Variable named mediaPlayerState.
Create a Custom Event trigger whose event name is gtm4wp.mediaPlayerStateChange.
Add the condition mediaPlayerState equals play to the trigger.
Attach the trigger to your tag. To send the name of the video along with it, create a second Data Layer Variable named mediaData.title.

Use ended in place of play to measure a video that was watched to the end. To measure progress, build the trigger on gtm4wp.mediaPlaybackPercentage and add a condition on mediaPercentage instead.

Limitations

If the Wistia player runtime never loads, for example because a consent manager or an ad blocker stopped it, nothing is measured and nothing tells you so. The plugin waits quietly rather than reporting a failure.
mediaData.author is always empty.
There is no buffering state and no error event.
There is no 100 percent milestone. Measure a full watch with the ended state, as described under playback percentage milestones.
The tracker script loads on every page of your site when the option is on, though it adds no 3rd party request of its own.

The overview of media player tracking describes the events, data layer variables and playback milestones that every player shares. See also dynamically inserted players, the one setting Wistia does not need, and JW Player, the other player that binds to a runtime your site already loads.