Engagement vs. Stream Hours Engagement vs. Stream Hours
  1. Zype
  2. Analytics
  3. The Zype Analytics Dashboard

Engagement vs. Stream Hours

The purpose of this article is to provide more insight into the types of audience viewing analytics that Zype offers, including highlighting tracking methodologies and differences between the two measurements.

Zype supports two methods of tracking and reporting on audience viewing:

  • Engagement - a client-side measurement of viewing behavior that offers reporting on video plays and duration watched using tracking beacons that have been integrated into Zype’s web player and templated app players.
  • Stream Hours - a server-side measurement of hours of content streamed by viewers, calculated using the number of bytes delivered to your audience over a given period of time as well as the renditions and bitrates streamed during that delivery.

How are engagement analytics measured?

Zype’s engagement analytics require use of our web video player or templated app players for video playback.

Each of Zype’s players have been integrated with special tracking beacons that fire an event each time a viewer clicks to play, seek, or pause a video. Each of these events include metadata regarding the viewer and the video being played, allowing Zype to associate these play events with specific videos in your library and consumers in your Zype audience database.

Once a viewer initiates playback of a video, the tracking beacons also poll the players every few seconds for changes in the player state. During each of these polling events, the tracking beacons send additional data to Zype’s analytics server regarding the play head position (where the playback bar sits) to ensure consistent updates to tracking how much content the viewer has watched in that session.

Tracking is stopped when a video reaches end of playback, the viewer clicks the pause button, or closes a webpage / video details view in an app, or exits out of an app or browser session entirely.

Which reports in Zype feature engagement analytics data?

The following reports and metrics feature engagement analytics data:

  • Most Requested & Most Watched - in these reports, the “Time Watched” and “Plays” metrics are based on Zype’s engagement analytics
  • Video Engagement - in this report, the “Plays,” “Average Play,” and “Time Watched” metrics are based on Zype’s engagement analytics

When do engagement analytics not work?

Tracking for engagement analytics are only supported in Zype’s web player or templated apps. In situations where customers build custom apps or use 3rd party players that don’t include Zype’s tracking beacons, engagement analytics data will not be collected.

Engagement analytics also will not be collected in situations where content is syndicated to 3rd party partners or aggregators. In situations where partners are ingesting your content for playback in their own apps or platforms, no engagement analytics data will be captured.

Additionally, engagement analytics will not be captured in situations such as offline playback, typically offered in mobile applications, where viewers can download videos and play them back without having an active internet connection. In these situations, tracking playback through client-side engagement analytics will be inconsistent and likely not function as expected.

How are stream hours calculated?

Stream hours analytics require using Zype for video delivery (i.e., using Zype as your content delivery network). Specifically, stream hours reporting is only supported for Zype Hosted VODs and Zype Live video sources.

To provide info on how stream hours are calculated, first we should review how videos are encoded. When videos are uploaded into Zype for VOD delivery, or RTMP sources are sent to Zype for Zype Live delivery, the video source is encoded by Zype into multiple renditions and bitrates in order to provide optimal playback experience to your audience.

For streaming use cases, videos are typically encoded to a format called HLS, where a master video manifest can point to multiple child manifests, where each child manifest represents a playable rendition of the same video that has been encoded to a specific bitrate and size in a ratio that has been optimized for delivery speed and playback quality. For example, a single video may be encoded to the following bitrate and rendition sizes:

1080p @ 5 MBPS

720p @ 2.5 MBPS

480p @ 1.2 MBPS

288p @ 0.6 MBPS

During the encoding process, each of these renditions is broken up into 10 second “chunks” or segments -- think of this as chopping up a video into 10 second increments, and then stitching those increments together with a string, or manifest.

When a video is requested by a video player, the player first retrieves the master manifest for that video file. The player will parse the manifest to determine which renditions are available for playback, along with each rendition’s respective bitrate. While each player may have small differences, typically most players will attempt to start playback using the highest quality rendition supported by the viewer’s bandwidth using a technology called ABR (Adaptive Bitrate) streaming.

During the resulting playback, the player will download 10 second chunks of data from the manifest that it is currently playing. Each chunk represents a small number of bytes, dependent on the rendition size and bitrate of the manifest that is being played.

Zype’s stream hours analytics calculates the duration of content that is streamed by the player based on which specific manifest rendition and bitrate is used for each downloaded chunk. In this way, whether viewers are playing a lower 480p rendition or higher 1080p rendition, the calculation of duration streamed by the player remains consistent in our stream hours analytics reporting.

Which reports in Zype feature stream hours analytics data?

The following reports and metrics feature engagement analytics data:

When do stream hours analytics not work?

Tracking for stream hours is only supported if distributing Zype or Zype Live video sources. In situations where customers bring their own delivery, for example using self-hosted or 3rd party hosted content sources (e.g., Vimeo Pro, YouTube, etc.), stream hours reporting will not work.

In scenarios where content is syndicated to 3rd party partners, if the partner’s player initiates downloads of all available renditions during playback, then stream hours calculations may be increased to reflect multiple renditions being downloaded and streamed simultaneously.

Likewise, if a partner’s player attempts to pre-fetch streaming content segments ahead of playback, stream hours calculations may be increased as more chunks are downloaded and delivered to the player ahead of the viewer’s actual playback position.

On the other hand, if a 3rd party content partner acquires a source stream, but then re-encodes and handles viewer delivery using their own CDN, then stream hours analytics will not be tracked beyond the initial download of the source stream.

Why do I see differences between engagement analytics “Hours Watched” and server-side Stream Hours reports?

Since engagement analytics and stream hours analytics are captured in vastly different ways and are dependent on different playback conditions, it’s common to see variances in reporting data.

Common reasons for seeing reporting differences in engagement data and stream hours data include:

  • Situations where custom players are being used for playback in different web or native applications
  • Situations where content is being syndicated or distributed to partners where you don’t have control over playback

Was this article helpful?

0 out of 0 found this helpful

Articles in this section