Notes on Methodology

Owned by Kemal Atayev
Last updated: Nov 18, 2019

All of the Checks are based on data from audited sites as well as data from PCs and Tablets unless specified otherwise (e.g. Check 10).


Sources of Metada (CCIDS vs CDMF)

At the moment all checks use the CDMF table and the data submitted by the broadcastes into it. The only piece of metada that does not get submitted into CDMF and originates from CCIDS is genre. However, at the moment genre metadata for Check 8 is based on PAS system.

Once CCIDS goes live we will switch the Compliance Reports from CDMF to CCIDS as the only source of metadata.

The titles of the checks, columns or other fields represent the source of metadata used and will also be changed once the switchover to CCIDS happens.


Detail Tab

The table in this tab is designed to provide the individual records with relevant data from Census Target and CDMF. (The only exception to this is Check 1 as it does not deal with Content IDs but rather TX log submissions.)


This table shows only the Content IDs that have issues that that particular Check is designed to identify. This means that not all of the Content IDs that are in the Total value in the ‘Summary by unique record count’ are in this table.

Example

In Check 7 ‘Duration Status’ Content IDs that fall into Valid Duration bucket will not be in the detail tab.


There are also 2 playtimes for each Content ID:

  • Playtime viewed – based on Census, representing device playtime
  • Playtime calibrated – based on ONE file, representing people playtime

In addition every Content ID has 2 entries – Live and OD (On Demand) with appropriate playtimes for each. It is possible for a Content ID not to have 1 of the above and hence appear only once. Also note that these apply when at Player and Broadcaster level. This means that the same Content ID (with 2 entries) can show up for the same Broadcaster on another Player.


Edge Case

Please note that there is a possibility that some Content IDs will have more than 2 entries when at the same Player and Broadcaster level. This can be caused when one of the metadata fields (present in that Check’s tab) is different e.g. BARB Standard Content Name, genre or duration. This deviation is caused when within the same week a broadcaster submits a CDMF record via XML with 2 (or possibly more) different metadata fields.

Throughout this manual this occurrence will be called ‘additional duplication’.


'Summary by unique record count' Table

It is important to note that the way this table summarises the records in the detail tab of the Detail Report is a result of the nature of detail tab described in the section above (3.3). The counts presented in this table are of unique Content IDs within each bucket (at Player + Broadcaster level). This means that in order to obtain the same number as in this table the list of Content IDs from detail table should be deduplicated for given bucket.

The Total in summary table is always the sum of counts of individual buckets of the Check.


'Summary by playtime' Table

This table provides breakdown, in percentages, of playtimes that are attached to the Content IDs in various buckets of the Checks.

  • Playtime viewed – based on Census, representing device playtime
  • Playtime calibrated – based on ONE file, representing people playtime


In addition this table is broken down by Activity – live and OD (On Demand).




EDGE CASES IN CHECKS

Due to complexities of data that Kantar collects, holds and integrates for Dovetail Fusion there is a probability that cases will arise that create anomolaous behaviour within the reports.

With each release of the reports we will monitor them and notify the broadcasters of occurrence of such cases.


Throughout this manual edge cases have been mentioned in the relevant locations. They will be put into the following boxes:

Edge Case



One example that could show up in many of the Checks is a blank broadcaster for a particular player. This happens when the Check can’t match BGID or OOGID of that Content ID to a broadcaster group in our master file.