Representing minute data

Minute data represents an average audience (and associated TVR / Share / PUT / HUT) for a given minute of time.

Minute data can be aggregated up - and is often transmitted as 5-minute or 15-minute averages to reduce data volumes.

Minute data rarely concerns itself with the content and as such usually treats time periods with intervals the same as those without. It is primarily used for benchmarking and providing averages over time.

Although common, the unit of a minute is not a requirement of representing viewing over a time period so we have taken a more general approach in the schemas and used “day-parts” to allow common represenation of any minute data or agregated date over a fixed period of time.

A day-part has a start time and either a duration or an end time. End times are usually presented as exclusive i.e. the time of the day-part starts at the start time but ends fractionally prior to the end time.

A day-part can be defined as being a minute long, and starting at each minute - this would form the classical minute data that is often the most granular provided by the data bureaus. It could also be defined to cover a popular viewing period - e.g. prime-time might be defined as between 19:00:00 and 21:30:00 each day.

Although all day-parts can be defined at a minimum by using any two of the attributes three available attributes (start time, duration and end time), it is possible that the day-part is only referred to by an identifier - for this reason the schema does not dictate the requirement to provide these particular fields.

If consecutive data is always provided it may be enough to simply infer that the data starts at the beginning of one of the parameters provided in the criteria and that there are enough rows provided to cover the complete time range suggested. We would always recommend explicitly providing attributes to make the data easier to consumer over reducing the space used. Compression of JSON or XML files will satisfy most requirements to keep the datafile sizes to a minimum.

<dayPart 
  channel="A channel name" 
  date="2019-01-01" 
  startTime="06:00:00" 
  durationInSeconds="60">
  <figure 
    demo="Adults" 
    audience="300000" 
    ttv="12400000" 
    universe="98200000"/>
  <figure 
    demo="Women" 
    audience="200000" 
    ttv="11400000" 
    universe="97200000"/>
</dayPart>
{
  "channel": "A channel name",
  "date": "2019-01-01",
  "startTime": "06:00:00",
  "durationInSeconds": 60,
  "figures": [
    {
      "demo": "Adults",
      "audience": 300000,
      "ttv": 1240000,
      "universe": 98200
    },
    {
      "demo": "Women",
      "audience": 20000,
      "ttv": 1140000,
      "universe": 97200
    }
  ]
}

The example above provides the minimum required to sensibly represent a minute of viewing.

When providing figures a decision should be made about whether the consumer will be calculating their own percentages or whether they should be provided. Providing audience, total TV and universe allows the consumer to calculate share, TVR, HUT/PUT at will without any loss of precision.

By representing all minute data as day-parts the interpretation of data is made easier without compromising the ability to represent all likely requirements.

Because universes are usually only calculated on a monthly basis it may be more compact to transmit these in their own structure.

<dayPart 
  date="2019-01-01" 
  <figure 
    demo="Adults" 
    universe="98200000"/>
  <figure 
    demo="Women" 
    universe="97200000"/>
</dayPart>
{
  "date": "2019-01-01",
  "figures": [
    {
      "demo": "Adults",
      "universe": 98200
    },
    {
      "demo": "Women",
      "universe": 97200
    }
  ]
}

The disadvantage is that it becomes harder for the consumer to build their own applications as they will now have to retrieve the appropriate universe figures to combine with minute/transmission/interval data to calculate a TVR.

Equally it might be decided to transmit total tv as it's own dataset and require the consumer to use it to calculate shares. Transmitting separately is most appropriate when there are large volumes of data being transmitted and data bandwidth is limited.

<dayPart 
  date="2019-01-01" 
  startTime="06:00:00" 
  durationInSeconds="60"
  <figure 
    demo="Adults" 
    ttv="12400000"/>
  <figure 
    demo="Women" 
    ttv="11400000"/>
</dayPart>
{
  "date": "2019-01-01",
  "startTime": "06:00:00",
  "durationInSeconds": 60,
  "figures": [
    {
      "demo": "Adults",
      "ttv": 1240000
    },
    {
      "demo": "Women",
      "ttv": 1140000
    }
  ]
}