- Introduction to Data
- Track your video engagement and performance
- Make API requests
- Set up alerts
- Make your data actionable with metadata
- Track autoplaying videos
- Extend Data with custom metadata
- Track CDN for request metrics
- Show how many people are watching your videos
- Build a custom integration
- Understand metric definitions
- Export raw video view data
- Ensure privacy compliance
- Mux Data FAQs
Make your data actionable with metadata
Configure metadata with your SDK in order to search, filter and segment your video performance metrics.
In this guide:
High Priority Configurable Metadata
High Priority Configurable Metadata
Optional Configurable Metadata
Optional Configurable Metadata
Set Metadata with Session Data
Set Metadata with Session Data
Mux Data allows you to provide details about the video and environment that can't be detected automatically or if the video fails to load.
All metadata details except for
env_key are optional, however you'll see more helpful results as you include more.
- Video details (prepended by
video_) describe the current video that's playing and are all reset automatically when changing the video. This metadata might come from your internal CMS or video management system.
- Player details (prepended by
player_) describe the player configuration that's being used and should be set whenever monitoring is started on a new player. They do not reset when the video is changed.
- All other details will persist until explicitly changed.
In iOS and Android SDKs, names are converted to lowerCamelCase
getters. For example, to set the Video Stream Type field in iOS or Android, use
videoStreamType instead of
In the Objective-C SDKs, options are provided via the
MUXSDKCustomData objects. See the header directories for a complete list of names:
In the Java SDK, options are provided via the
CustomData objects. Use your IDE to inspect these objects' API.
Metadata is used in five different ways.
env_key is a required field, and ensures that your data goes into the correct environment.
Filter: some fields are available as filters and breakdowns in aggregate reports (as well as in the API and video view page).
View: some fields appear as attributes of a view on the individual video view page (as well as in the API).
API: some fields are only available via API or data export.
Metrics: some fields enable Mux to track additional metrics.
The following metadata fields are the most important fields that you should populate in order to get the basic functionality of Mux /Data.
viewer_user_id you should not use any value that is personally identifiable on its own (such as email address, username, etc). Instead, you should supply an anonymized viewer ID which you have stored within your own system.
|Environment||Unique ID||Required||Your env key from the Mux dashboard. Note this was previously named |
|Video ID||Text||Filter||Your internal ID for the video|
|Video Title||Text||Filter||Title of the video player (e.g.: 'Awesome Show: Pilot')|
|Viewer ID||Unique ID||Filter||An ID representing the viewer who is watching the stream. Use this to look up video views for an individual viewer. If no value is specified, a unique ID will be generated by the SDK. Note: You should not use any value that is personally identifiable on its own (such as email address, username, etc). Instead, you should supply an anonymized viewer ID which you have stored within your own system.|
The following metadata fields can be set manually and will be reported by Mux Data.
|Experiment Name||Text||Filter||You can use this field to separate views into different experiments, if you would like to filter by this dimension later. This should be a string value, but your account is limited to a total of 10 unique experiment names, so be sure that this value is not generated dynamically or randomly.|
|Page Type||Text||API||Provide the context of the page for more specific analysis. Values include |
|Player Initialization Time||Milliseconds since Epoch||Metrics||If you are explicitly loading your player in page (perhaps as a response to a user interaction), include the timestamp (milliseconds since Jan 1 1970) when you initialize the player (or for HTML5 video, when right before you add the element to the DOM) in order to accurately track page load time and player startup time.|
|Player Name||Text||Filter||You can provide a name for the player if you want to compare different configurations or types of players around your site or application. This is different from the player software (e.g. Video.js), which is tracked automatically by the SDK.|
|Player Version||Text||Filter||As you make changes to your player you can compare how new versions of your player perform. This is not the player software version (e.g. Video.js 5.0.0), which is tracked automatically by the SDK.|
|Sub Property ID||Text||Filter||A sub property is an optional way to group data within a property. For example, sub properties may be used by a video platform to group data by its own customers, or a media company might use them to distinguish between its many websites.|
|CDN||Text||Filter||The Content Delivery Network used to deliver the video. If using am SDK that supports CDN header extraction, this value will be auto-populated.|
|Content Type||Text||API||The type of content: 'short', 'movie', 'episode', 'clip', 'trailer', or 'event'|
|Duration||Milliseconds||View||The length of the video in milliseconds|
|Encoding Variant||Text||Filter||Allows you to compare different encoders or encoding settings. This could designate the encoder used (e.g. |
|Video Language||Text||API||The audio language of the video, assuming it's unchangeable after playing.|
|Producer||Text||API||The producer of the video title|
|Series||Text||Filter||The series of the video (e.g.: 'Season 1')|
|Video Stream Type||Text||Filter||The type of video stream (e.g: 'live' or 'on-demand')|
|Variant Name||Text||API||Allows you to monitor issues with the files of specific versions of the content, for example different audio translations or versions with hard-coded/burned-in subtitles.|
|Variant ID||Text||API||Your internal ID for a video variant|
|View Session ID||Unique ID||Filter||An ID that can be used to correlate the view with platform services upstream such as CDN or origin logs.|
|Custom Dimensions||Text||Filter||Customer-defined metadata|
The following metadata is populated automatically where the data is supported by the SDK. This data can be overridden by the SDK client implementation, if needed.
|Browser||Text||Filter||Browser used for the video view (Safari, Chrome, etc.) NB: |
|Browser Version||Version||Filter||Browser version (e.g. Chrome 66.0.3359.158) NB: |
|CDN||Text||Filter||CDN delivering the video, either detected by Mux (via response |
|Operating System||Text||Filter||Operating System (iOS, Windows, etc) NB: |
|Operating System Version||Version||Filter||Operating System version (e.g. OS X 10.6) NB: |
|Page URL||URL||View||Page URL|
|Autoplay||Boolean||Filter||Indicates whether the player was set to autoplay the video or not. This tracks whether the video has |
|Player Height||Integer||View||Height of the player as displayed, in logical pixels|
|Player Instance ID||Unique ID||View||Identifies the instance of the Player class that is created when a video is initialized|
|Player Language||Text||API||Player's text language|
|Poster||URL||API||The image shown as the pre-visualisation before play|
|Preload||Boolean||View||Specifies if the player was configured to load the video when the page loads.|
|Remote Played||Boolean||Filter||If the video is remote played to AirPlay as specified by the SDK.|
|Player Software||Text||Filter||Player Software being used to play the Video (e.g. Video.js, JW Player, etc.). Note this was previously named |
|Player Software Version||Text||Filter||Player Software Version (e.g. 2.45.5)|
|Source Height||Integer||View||Height of the source video being sent to the player, in pixels|
|Source Width||Integer||View||Width of the source video being as seen by the player|
|Player Width||Integer||View||Width of the player as displayed, in logical pixels|
|Source Type||Text||View||Format of the source, as determined by the player. E.g. 'dash', 'x-application/mpegUrl', 'mp4', etc.|
|Used Full Screen||Boolean||View||Indicates whether the viewer used full screen to watch the video.|
|Connection Type||Text||Filter||The type of connection used by the player, as reported by the client when available: |
|Device Brand||Text||Filter||Device Manufacturer (e.g. Apple, Microsoft)|
|Device Category||Text||Filter||The form factor of the device: |
|Device Model||Filter||View||Device Model (e.g. iPhone11,2)|
|Device Name||Filter||View||Device Name (e.g. iPhone 12)|
Metadata is normally set using code in the SDK configuration. However, some video metadata can also be set using Session Data key/value pairs in the HLS manifest. This method makes it easier to communicate values to the Mux player SDK without having to side-channel information to the client or change client-side code in order to configure metadata for a view.
Some common use cases where this is helpful are, for example, setting a view session id that comes from a backend system which can be used to associate a playback view with the requests that were made to a CDN or being able to easily capture which experiments a viewer is participating in without having to communicate that to the player.
HLS Session Data, which is represented in an HLS master playlist using the
EXT-X-SESSION-DATA tag, is a key/value pair that can be read by the player. When the master playlist is loaded into a video player integrated with a Mux Data SDK that supports extracting Session Data, the Session Data keys that use the
io.litix.data prefix will be included in the Mux Data view as dimension metadata the same as if you had configured the value from the SDK configuration code.
This feature is intended for developers using their own custom video delivery pipeline. HLS Session Data is set by Mux Video when videos are viewed; injecting your own HLS Session Data into Mux Video content is not currently supported.
The Session Data tags are interpreted as follows from the master playlist:
Tag: #EXT-X-SESSION-DATA Key: DATA-ID="io.litix.data.[dimension_name]" Value: VALUE="dimension value"
The dimension names available to be set from the master playlist:
The following is an example of Session Data tags in a master playlist:
#EXTM3U #EXT-X-VERSION:7 #EXT-X-INDEPENDENT-SEGMENTS #EXT-X-SESSION-DATA:DATA-ID="io.litix.data.experiment_name",VALUE="abr_test:true" #EXT-X-SESSION-DATA:DATA-ID="io.litix.data.view_session_id",VALUE="12345ABCD" #EXT-X-STREAM-INF:BANDWIDTH=2516370,AVERAGE-BANDWIDTH=2516370,CODECS="mp4a.40.2,avc1.640020",RESOLUTION=1280x720 ...
The Session Data tags contained in a master playlist would result in the
Experiment Name dimension set to
View Session ID dimension set to