Mux.com
GuidesAPI ReferenceChangelog

Monitor THEOplayer (Web)

This guide walks through integration with THEOplayer to collect video performance metrics with Mux Data.

In this guide:

1

Install theoplayer-mux

1

Install theoplayer-mux

Install theoplayer-mux from our CDN.

2

Initialize Mux Data

2

Initialize Mux Data

Attach your THEOplayer instance to the theoplayer-mux monitor.

3

Make your data actionable

3

Make your data actionable

Use metadata fields to make the data collected by Mux actionable and useful.

4

Changing the video

4

Changing the video

If your implementation changes the video without changing the video player, let mux know to start tracking a new view.

5

Advanced options

5

Advanced options

Depending on the details of your implementation, you may want to leverage some of the advanced options of theoplayer-mux.

Release Notes

Release Notes

1Install theoplayer-mux

Include the Mux JavaScript SDK on every page of your web app that includes video.

<!-- Include theoplayer-mux after the core THEOplayer javascript files -->
<script type="text/javascript" src="https://cdn.theoplayer.com/latest/~yourlicense~/theoplayer.loader.js"></script>
<script src="https://src.litix.io/theoplayer/4/theoplayer-mux.js"></script>

2Initialize Mux Data

Get your ENV_KEY from the Mux environments dashboard.

Env Key is different than your API token

ENV_KEY is a client-side key used for Mux Data monitoring. These are not to be confused with API tokens which are created in the admin settings dashboard and meant to access the Mux API from a trusted server.

Call new THEOplayer.Player like you normally would. Call initTHEOplayerMux with a reference to the player instance and the Mux SDK options.

<div id="my-player" class='video-js theoplayer-skin theo-seekbar-above-controls'></div>
<script>
  const playerInitTime = Date.now();
  const playerWrapper = document.querySelector('#my-player');

  // Get a reference to your player, and pass it to the init function
  const player = new THEOplayer.Player(playerWrapper, {
    // Insert player configuration here
  });

  player.src = 'https://muxed.s3.amazonaws.com/leds.mp4';

  initTHEOplayerMux(player, {
    debug: false,
    data: {
      env_key: 'ENV_KEY', // required
      // Metadata
      player_name: '', // ex: 'My Main Player'
      player_init_time: playerInitTime // ex: 1451606400000
      // ... and other metadata
    }
  });
</script>

3Make your data actionable

The only required field in the options that you pass into theoplayer-mux is env_key. But without some metadata the metrics in your dashboard will lack the necessary information to take meaningful actions. Metadata allows you to search and filter on important fields in order to diagnose issues and optimize the playback experience for your end users.

Pass in metadata under the data on initialization.

// player here is the instance of THEOplayer.Player
initTHEOplayerMux(player, {
  debug: false,
  data: {
    env_key: 'ENV_KEY', // required
    // Site Metadata
    viewer_user_id: '', // ex: '12345'
    experiment_name: '', // ex: 'player_test_A'
    sub_property_id: '', // ex: 'cus-1'
    // Player Metadata
    player_name: '', // ex: 'My Main Player'
    player_version: '', // ex: '1.0.0'
    player_init_time: '', // ex: 1451606400000
    // Video Metadata
    video_id: '', // ex: 'abcd123'
    video_title: '', // ex: 'My Great Video'
    video_series: '', // ex: 'Weekly Great Videos'
    video_duration: '', // in milliseconds, ex: 120000
    video_stream_type: '', // 'live' or 'on-demand'
    video_cdn: '' // ex: 'Fastly', 'Akamai'
  }
});

For more information, view Make your data actionable.

4Changing the video

There are two cases where the underlying tracking of the video view need to be reset:

  1. New source: When you load a new source URL into an existing player.
  2. New program: When the program within a singular stream changes (such as a program change within a continuous live stream).

Note: You do not need to change the video info when changing to a different source of the same video content (e.g. different resolution or video format).

New source

For THEOplayer, you do not need to emit the videochange event when the player source property of the player is updated. The sourcechange event that is fired when you update the source property of the player is handled automatically. However, you still need to pass the updated video metadata under metadata.mux, as shown in the example below.

When this is done, it removes all previous video data and resets all metrics for the video view. Note: the previous method using changeMuxVideo has been deprecated, but will continue to work for 2.x versions of this plugin.

player.source = {
  sources: {
    // ...your source
  },
  metadata: {
    mux: {
      video_id: 'new-ID',
      video_title: 'New title',
      // ... other metadata
    }
  }
}

New Program

In some cases, you may have the program change within a stream, and you may want to track each program as a view on its own. An example of this is a live stream that streams multiple programs back to back, with no interruptions.

In this case, you emit a programchange event, including the updated metadata for the new program within the continuous stream. This will remove all previous video data and reset all metrics for the video view, creating a new video view. See Metadata for the list of video details you can provide. You can include any metadata when changing the video but you should only need to update the values that start with video.

Note: The programchange event is intended to be used only while the player is currently not paused. If you emit this event while the player is paused, the resulting view will not track video startup time correctly, and may also have incorrect watch time. Do not emit this event while the player is paused.

// player is the instance received in the `onCreate` callback
player.mux.emit('programchange', {
  video_id: 'abc345',
  video_title: 'My Other Great Video',
  video_series: 'Weekly Great Videos',
  // ...
});

5Advanced options

Disable cookies

By default, Mux plugins for HTML5-based players use a cookie to track playback across subsequent page views. This cookie includes information about the tracking of the viewer, such as an anonymized viewer ID that Mux generates for each user. None of this information is personally-identifiable, but you can disable the use of this cookie if desired. For instance, if your site or application is targeted towards children under 13, you should disable the use of cookies.

This is done by setting disableCookies: true in the options passed to the Mux plugin.

// player here is the instance of THEOplayer.Player
initTHEOplayerMux(player, {
  debug: false,
  disableCookies: true,
  data: {
    env_key: "ENV_KEY",
    // ...
});

Over-ride 'do not track' behavior

By default, theoplayer-mux does not respect Do Not Track when set within browsers. This can be enabled in the options passed to Mux, via a setting named respectDoNotTrack. The default for this is false. If you would like to change this behavior, pass respectDoNotTrack: true.

// player is the instance of THEOplayer.Player
initTHEOplayerMux(player, {
  debug: false,
  respectDoNotTrack: true,
  data: {
    env_key: "ENV_KEY",
    // ...
});

Customize error tracking behavior

Errors are fatal

Errors tracked by mux are considered fatal meaning that they are the result of playback failures. If errors are non-fatal they should not be captured.

By default, theoplayer-mux will track errors emitted from the video element as fatal errors. If a fatal error happens outside of the context of the player, you can emit a custom error to the mux monitor.

// player is the instance of THEOplayer.Player
player.mux.emit('error', {
  player_error_code: 100,
  player_error_message: 'Description of error'
});

When triggering an error event, it is important to provide values for player_error_code and player_error_message. The player_error_message should provide a detailed description of the error as it happened. The player_error_code must be an integer, and should provide a category of the error. If the errors match up with the HTML Media Element Error, you can use the same codes as the corresponding HTML errors. However, for custom errors, you should choose a number greater than or equal to 100.

In general you should not send a distinct code for each possible error message, but rather group similar errors under the same code. For instance, if your library has two different conditions for network errors, both should have the same player_error_code but different messages

Error translator

If your player emits error events that are not fatal to playback or the errors are unclear and/or do not have helpful information in the default error message and codes you might find it helpful to use an error translator or disable automatic error tracking all together.

function errorTranslator (error) {
  return {
    player_error_code: translateCode(error.player_error_code),
    player_error_message: translateMessage(error.player_error_message),
  };
}

// player is the instance of THEOplayer.Player
initTHEOplayerMux(player, {
  debug: false,
  errorTranslator,
  data: {
    env_key: "ENV_KEY",
    // ...
  }
});

If you return false from your errorTranslator function then the error will not be tracked. Do this for non-fatal errors that you want to ignore. If your errorTranslator function itself raises an error, then it will be silenced and the player's original error will be used.

Disable automatic error tracking

In the case that you want full control over what errors are counted as fatal or not, you may want to consider turning off Mux's automatic error tracking completely. This can be done by passing automaticErrorTracking: false in the configuration object.

// player is the instance of THEOplayer.Player
initTHEOplayerMux(player, {
  debug: false,
  automaticErrorTracking: false,
  data: {
    env_key: "ENV_KEY",
    // ...
  }
});

Ads tracking with theoplayer-mux

Mux has been tested with and supports THEOplayer's Ads integration. Simply configure the ads as you would with THEOplayer normally, and Mux will track ads automatically. No additional configuration is needed.

Other THEOplayer ad integrations, such as Google IMA, may work out of the box but have not currently been tested. Please contact us with any questions.

Release Notes

Current release

v4.8.0

  • Allow for passing in the THEOplayer instance instead of using the instance on window

Previous releases

v4.7.5

  • Update mux-embed to v4.9.2

v4.7.4

  • Update mux-embed to v4.9.1

v4.7.3

  • Update mux-embed to v4.9.0

v4.7.2

  • Update mux-embed to v4.8.0

v4.7.1

  • Update mux-embed to v4.7.0

v4.7.0

  • Introducing HLS Session Data support

  • Update mux-embed to v4.6.2

v4.6.1

  • Update mux-embed to v4.6.1

v4.6.0

  • Bump mux-embed to 4.6.0

v4.5.1

  • Update mux-embed to v4.4.4
  • Stops emitting a requestcompleted event for every manifest request

v4.5.0

  • Update mux-embed to v4.4.2

v4.4.0

  • Add support for bandwidth metrics

v4.3.1

  • Fix an issue where normal events were being fired as ad events

v4.3.0

  • Update mux-embed to v4.4.0
  • Support latency metrics when using HLS

v4.2.0

  • Update mux-embed to v4.2.0
  • Fix an issue where views that resulted from programchange may not have been tracked correctly
  • Fix an issue where if destroy was called multiple times, it would raise an exception

v4.1.1

  • Fix an issue where bitrate reported for HLS streams would be double the expected value

v4.1.0

  • Update mux-embed to v4.1.1
  • Add support for custom dimensions
  • Fix an issue where player_remote_played may not be tracked correctly

v4.0.0

  • Update mux-embed to v4.0.0
  • Support server-side device detection

v3.1.0

  • Add renditionchange tracking event

v3.0.1

  • Inject metadata for certain edge case startup sequences

v3.0.0

  • Update mux-embed to 3.0.0