Skip to main content
Your Analytics tab, your retention curve, your Custom Metrics: none of them read the page events described in Video Events, Timed Events, User Events, or Pixel Events. Those pages document a JavaScript API you subscribe to on your own page. This page documents a different system entirely: the beacon the player sends to TrackPlay in the background, which is what every report you read is built from. You do not call anything on this page. The player sends these events on its own. Read this page to understand what a metric is counting, not to integrate against it.

​
Three systems, one player

The three systems share almost no event names. play on the page-events system and video-play on the analytics system fire from the same click, but they are two separate dispatches with two separate payloads. Do not expect one to tell you about the other.
The public player API is not documented here. If you are building a custom control surface against window.TrackPlay, treat that as a separate integration with its own event names, not an extension of the events on this page.

​
How delivery works

The player never sends one event at a time. It queues events and flushes the queue in one of three ways:
  1. Synchronous, on the spot. cta-clicked and checkout-click flush the queue immediately, before the function returns. Both usually precede a navigation (a click through to your cart), so the beacon has to leave before the page does.
  2. Fast flush, within 2 seconds. page-view, video-play, video-unmute, video-continue, video-restart, video-error, video-autoplay, and video-autoplay-sound queue, then flush on a 2-second timer. Fast enough to treat as immediate, not fast enough to block the click.
  3. Batched, up to 10 seconds. Everything else queues and flushes on a running 10-second interval, or sooner if the viewer leaves the page first.
page-exit and page-reload are a special case of the third tier: the exit handler flushes the whole queue the moment it fires, so nothing queued in the final 10 seconds is lost when the tab closes.
This is at-least-once delivery over navigator.sendBeacon, with a fetch(..., { keepalive: true }) fallback if the browser refuses the beacon (quota or payload size). A beacon can be lost if both fail. It is never intentionally duplicated, but a retried request is not de-duplicated server-side either.

​
Fields on every event

Every event below carries this envelope in addition to its own fields.
​
string (uuid)
The viewer’s device, stable for a year.
​
string (uuid)
The current watch session. Rotates after 30 minutes of inactivity or a 12-hour cap.
​
string (uuid)
Your workspace.
​
string (uuid)
The video.
​
number
Current playback position, in seconds, at the moment the event fired.
​
number
Milliseconds since the visit started.
​
string
The viewer’s viewport orientation, portrait or landscape.
​
string
Delivery mode: standalone or runtime (shared-runtime embed).
​
string
Set only when the container is running a split test. split_test_variation_id rides alongside it. Absent otherwise.
Attribution fields (page_url, referrer_domain, UTM and click-id data, custom_data) ride on every event too, captured once when the tracker loads and stamped onto everything after. They are not repeated in the per-event tables below.

​
Playback events

The lifecycle of a single view: load, play, watch, pause, leave.
video-pause is being lost on most videos right now. Recent player builds attach a pause_reason field to every pause. The current ingest schema does not recognize that field, and an unrecognized field on a known event fails the whole event rather than the one field, because partial rows are never stored.This lands per video, not all at once, because each video carries the player build it was last compiled with. A video compiled before the change still records pauses normally. A video compiled since then records none. Pause volume began dropping on 4 August 2026 and has fallen by roughly 95%, and it will keep falling as more videos are recompiled.Treat any pause-derived number as an undercount until this is fixed, and do not compare a pause figure across that date. Play, resume, seek and the rest of the stream are unaffected, as is the page-level paused event in Video Events, which is a separate dispatch.

​
Engagement events

Interaction with the player controls, the page around it, and signals that someone is probing rather than watching.
turbo-variant and headline-chosen are both variant-assignment signals, but only headline-chosen lives here. turbo-variant is under Experiment events because it carries an A/B arm assignment, not a click.

​
Conversion events

The signals that connect a session to intent, and eventually to a sale.
A custom event is not a conversion. event_value is reported on its own and never feeds revenue, ROAS, EPC, or RPV.

​
Experiment events

Variant assignment inside the player. This is not the same system as a split test, which assigns a variant before the player ever loads.

​
Quality events

video-error is the only event in this group, and it carries the most payload of any event on this page.
​
string
required
A short label for the error class.
​
string
required
The error message.
​
string
One of fatal, error, warning, info.
​
string
One of encoding, network, drm, browser, recovered, unknown.
​
boolean
Whether playback stopped. A recoverable HLS error that resolves itself is reported as not fatal, even if the underlying error code looks severe.
​
boolean
Whether the player’s own recovery logic resolved the error.
​
string
The quality level active when the error happened.
​
number
The HTTP status of the failed request, when the error is network-related.
​
string
Buffer health at the moment of the error.
​
string
Extra HLS diagnostic context, when available.
video-error is deduplicated client-side: the same distinct combination of type, detail, fatal, and recovered is sent once per page view, not once per occurrence. A flapping network connection will not flood your reports with the same error.
This event is sent immediately, on the fast-flush tier, not batched with the rest of the Quality data.

​
Event names that will not appear in your reports

Two different failure modes produce a name that looks real but never shows up in your data. Knowing which one you are looking at saves you a support ticket.
These names exist in TrackPlay’s own configuration but no code path in the current player ever sends them. If you see one referenced anywhere outside this page, treat it as inactive: video-end, video-oof, video-resume-screen, video-fullscreen, video-loaded-webm. There is no dedicated “video finished” event. Completion is computed from the watch-time data on video-time, not from a single end-of-video signal.
The player sends these, but the current release does not forward them into your reports, either because the browser-side event list does not recognize the name or because the ingest service does not: captions-change (a caption-language switch), exit-intent-triggered (the internal trigger behind the exit-intent page event, which itself still fires normally), video-unmute-button (the manual unmute button, distinct from the video-unmute event above, which does work), video-completed (fired when a video is marked complete, at 95% watch time or on end), and the AI Dubbing language, subtitle, and audio-fallback events. If you are running AI Dubbing, do not expect language-switch or subtitle-toggle data in your reports yet.