Analytics: Criteria
Dario Castro avatar
Written by Dario Castro
Updated over a week ago

Origin of consumption

The metrics are obtained from different platforms, which behave and report in different ways:

  • Players Full , those that are fully implemented or mediastream, these report user events, such as play, pause, seek, playing, content_end, among others.

  • External Audio Player , which inform the content request and the transferred data and consumption are obtained from them through logs, such as Itunes, Tunein, etc.

  • External Video Player , which only report the request for content, such as Chromecast, Roku. (it is not possible to obtain information on consumption)

  • External Player with cache , some platforms such as Spotify, generate the download of content previously and consumption is done from their servers, which does not allow obtaining a real metric of consumption per user, only the metric of when the platform performed download for storage. Other apps with similar behaviors are being reviewed, such as Google Podcast.

Start :

It corresponds to a request for content.

  1. Players Full , those records where the user actually performed an action on the player (play or autoplay) are counted, bots are excluded.

  2. External Audio Players , all requests are counted and validated against the logs.

  3. External Players Video , content requests are obtained, but it is not possible to obtain user consumption.

  4. Download , downloads are not counted as a start.

Audio Logs:

* Bots are excluded.

* Platform validation requests are excluded. (records less than 70,000 bytes)

* Requests with status 40X and HEAD are excluded.

* The bots have a user agent, which are recognized as bots, these records are the ones that are filtered.

Stream:

It corresponds to a Start with a few seconds of subsequent playback.

  1. Player Full , a start is considered valid after 5 seconds of playback.

  2. External Audio Player , a start is considered valid after 25 seconds of playback.

  3. External Video Player , it is not possible to identify a start as a stream, since it is not possible to obtain information from the content.

  4. Download , downloads are not considered as a stream.

Time:

It corresponds to the time consumed.

1. Player Full , is the sum of the times reported in all playing events.

2. External Audio Player , is the sum of the times calculated from the transferred data, information that is obtained from the logs.

3. External Video Player , it is not possible to get consumption.

4. Download , are not considered in the consumption times.

Download :

Corresponds to a download or subscription of a list or content. (Ondemand audio content only)

  1. Mediastream applications , those records marked with the “file_downloaded” event are considered a download.

  2. External Audio Player , a download is considered when the requested content reports a 200 on the servers.

  3. External Video Player , it is never considered as a download.

Audio Logs:

* Bots are excluded

* Validation requests are excluded. (records less than 70,000 bytes)

* HEAD and status requests other than 200 are excluded.

Device:

It corresponds to a single device,

  1. The standard provided by the IAB is used, where a device is the set of the user_agent + ip of the user who made the consumption.

  2. Both Starts and Downloads are considered in the device count.

  3. Users who have registration when entering the OTT, will use the device cookie with identifier.

Start / Download time window:

The concepts of start and download have a time window of 24 hours, this means that after this time, if the same playback identifier (playback_id) is consumed again, it will be counted again.

Information obtained from consumption: (Players Implemented)

Recorded Events:

  1. session_start : It is generated when the device session starts, in case you do not have one currently active. This can be generated by the balancer or another Mediastream entity that responds to HTTP content on mdstrm.com .

  2. player_loaded : It is generated when the player (web or sdk) has finished loading all its elements for the correct operation in a property (web page, app, other).

  3. playback_start : It is generated when the download of a content starts and a unique ID is associated to it that will identify all the rest of the playback of that particular content.

  4. Content_end : It is generated when the player reached the end of the content. The events generated up to this moment must be sent.

  5. Playing : Generated when the player is playing content.

  6. Play : It is generated when 1) the user clicks on play 2) the player does autoplay 3) the play method is used through the API.

  7. Pause : Generated when playback is stopped. The events generated up to this moment must be sent.

  8. Buffering : It is generated when the player that is playing the content is in the buffering process.

  9. Seek : It is generated when the player, either by user action or by programmatic action (API), the player, advances or rewinds the content.

  10. File_downloaded : It is reported when the user requests to download the complete asset (mp4, m4a, etc).

Unification of records

To avoid duplication of content requests, Stream-Metrics works with a unification algorithm that allows to distinguish consumptions of the same user where they are grouped according to the content criteria, user agent, ip and other factors such as the time window, to generate a single start or download.

Use of CDN logs - Audio:

The logs allow validating and obtaining information from external sources such as the data transferred and the status of the request,

  1. Data Transferred: It is used to obtain the consumption time.

  2. Status: It is used to determine if a request corresponds to a Start or a Download.

  • Ondemand : Status 206, HLS Status 200

  • Live and Give : Status 200

Identification of origins:

Stream-Metrics uses the concept of "Property", which can be assigned in each implementation, the purpose is to identify where the content is consumed.

Any platform that does not report this attribute will be identified as Others. Mediastream players, by default, are identified as “Mediastream-player” (audio and video are distinguished separately). In web players, the property-name can be configured directly on the platform in the Players section.

CDN criteria:

Concepts:

  1. Traffic : Corresponds to the total transferred data.

  2. Hits : Corresponds to the requests that found the cached content

  3. Misses : Corresponds to requests that did not find the cached content.

  4. Hit Ratio : Relationship between those who made the requests that made the hit and the total number of requests.

  5. Request : All requests that request content, regardless of their status.

  6. Error : All requests that responded with 5xx.

  7. Global pop Traffic : Traffic (GB) by points of presence.

  8. Cache Status : Graph that displays the state of the edge cache vs. time.

  9. Response Status: Graph that displays the responses of the request, grouped by 2xx, 3xx, 4xx and 5xx.

HTTP response status codes:

  1. Informational responses (100–199),

  2. Satisfactory responses (200–299),

  3. Redirects (300–399),

  4. Client errors (400–499),

  5. and server errors (500–599).

Filters:

  1. Date.

  2. Filter by distribution area.

Examples (Audio):

Fully implemented platforms:

Accounting:

External platforms (Audio):

Accounting:

Considerations for external players cases:

  1. Some third-party platforms download the content before consuming it, marking these as a download and not as a start .

  2. The counted times are obtained from the transferred data reported by the servers, this value is usually higher than the actual consumption, since the platforms request the content in the future that the user may or may not consume.

Glossary :

  1. Content id : Content identifier

  2. Referrer : domain from which the consumption is being made. (web only)

  3. User agent : Identifier that corresponds to the set of the device, version of the device, browser and its version or application that the user is using at the time of consumption.

  4. Playback : A consumption request generated by a user, to a content in a certain time. This request is identified by the playback_id attribute which is unique throughout the playback. This identifier can change if the user closes the player or refreshes the site where the player is located.

  5. Give : Type of content that corresponds to the recording of a live, allowing you to advance or go back in your timeline.

  6. Live / Ondemand : Types of content.

  7. Category : Content categorization system.

  8. Property : Player identifier.

  9. Referrer : Domain where the consumption was made.

  10. Retention : Sections of the content viewed.

  11. Engagement : Of the content sections viewed, this graph represents the most viewed.

  12. Distributor : Entity configured in platform as distributor of the content. By filtering through this field, all the records consumed from the platforms of the selected distributor will be displayed.

  13. Producer : Entity configured in platform as content generator.

  14. Show : Content structure that represents a program, has associated seasons, episodes, producer and broadcaster.

  15. Pre-Load : Initial load that takes place before the user requests the content.

IAB Audio Podcast Standards:

  1. Autoplay: The use of autoplay is not recommended.

  2. File Request: For a full download, we recommend requesting the entire file in one go. For a progressive download, we suggest requesting the file in slices (byte range). This way, you can distinguish between a full download and a progressive download.

  3. Do not modify the enclosure URL when requesting media; we advise against adding additional parameters.

  4. Do not cache podcast episodes on your servers. It is always recommended to download the most recent episode from the enclosure URL for each application user who wishes to listen.

  5. Use the GUID, rather than the episode URL, title, publication date, etc., to identify new episodes in the RSS feed that should be automatically downloaded to the user's device. The GUID is designed to persist through changes in hosting environment, titles, etc.

  6. Implement an "automatic download unsubscribe" behavior (e.g., stop auto downloads after 5 episodes of non-listening).

  7. Do not automatically download all episodes (e.g., back catalog episodes) by default. This creates unnecessary load on publishers' servers and consumes users' bandwidth. It is advisable to avoid this practice.

MediaStream players and SDKs already adhere to these standards.


If you have any related question, feel free to write to us.

Att: Mediastream team

Did this answer your question?