2.6-202506 Public Comment Feedback

[hillslatt]

Please comment on this issue with feedback on updates to the OpenRTB updates in Public Comment

• Addition of recording and airdate attributes to Object: Content
• Implementation Guidance on use of new attributes to better describe Live programs
• Addition of Table of Contents to Implementation Guidance

Public Comment closing 30-June (extended 1 week per community request)

[bmayd]

Addition of recording and airdate attributes to Object: Content

airdate is an integer value containing the unix timestamp of when the content was first broadcast. Couple thoughts:

• Presumably this refers to the scheduled start time, though that isn't explicitly called out and maybe ought to be.
• The UNIX timestamp is UTC and there is no timezone information provided, which seems like pretty useful signal to include (e.g. content that aired at 9pm ET or 6pm PT would both be reported as 1am UTC time). Might be helpful to either include a timezone field or (better) use the ISO 8601 formatting to represent times as strings.
• Instead of using -2 to represent all dates prior to January 1, 1970, use negative values to indicate specific prior dates; for example December 30th 1969 at midnight would be -86,401. If this change was made, the indicator of a live airing would need to be changed from -1 to zero, or -1 would have to be identified as an exception. Alternatively, using ISO 8601 would allow entry of the actual date.
• It would be helpful to include in the implementation guidance, and probably field definitions, something about the relationship between the airdate, recording and livestream fields. Presumably if airdate is -1 (or an alternative value indicating "content airing for the first time"), recording should have a value of 1 (real-time) and livestream should have a value of 1 (content is live).
• As an alternative to using -1 to indicate "content is airing for the first time," suggest just include the scheduled start time in the airdate field and use the recording and livestream fields to indicate the content is airing for the first time. Using the actual air time instead of -1 would give recipients useful information about proximity to the start of the content.

recording is defined as: 0 = pre-recorded content and 1 = real-time. Couple thoughts:

• The term "real-time" generally refers to very strict timing constraints in a technical context (like real-time bidding) and it might clearer to define it as "live" or "not pre-recorded".
• The definitions of the values (0 = pre-recorded content and 1 = real-time) are counter intuitive in a programming context where zero is generally defined as false and therefore "recording = 0" would mean it wasn't a recording. Someone not familiar with the spec who was reviewing the data would likely assume a value of zero for recording meant it was a live performance. As a case in point, when looking at the table of scenarios referenced below without knowing the definitions of the recording field values, it would be natural to assume a 1 indicated a recorded event. Suggest swapping the meanings of the values so zero is real-time and 1 is pre-recorded.
• It would be helpful to include in the implementation guidance, and probably field definitions, something about the relationship between the values of the recording and livestream fields. It isn't clear if livestream can have a value of one ("content is live") and recording can have a value of zero ("pre-recorded") which would indicate the content was a recording of a live event or if when livestream is one ("content is live"), recording must have a value of one ("real-time"). See similar comment above regarding relationship between these fields and airdate.

Implementation Guidance on use of new attributes to better describe Live programs

In section 7.15 - Additional Telemetry for Live Events of the implementation doc:

• There's a table of example scenarios which includes columns for recording and airdate, but there aren't definitions of either term provided. Although airdate is pretty self explanatory, it isn't obvious what recording indicates or what values 0 and 1 equate to and would be helpful to have them defined with a link to the definition.
• As noted above, it isn't clear what the relationship between livestream, recording and airdate is; including livestream in the table could help with that.

[ssorensen1979]

I want to second Brian May's comments above. The current counter-intuitive value definition for recording field will likely lead to the field being set incorrectly.

As a general comment, a lot of complexity is added by wanting to signal when someone is watching a rerun of something that was originally a live event and when the live event first aired, even though I don't think that is where most of the value related to live events is generated.

Many publishers will likely not have the necessary information available in their content management systems (or care whether they do), so actual adoption of these fields will likely be inconsistent and therefore hard to rely on.

--Simon (Freewheel)

[iabeurope-beis]

If airdate or any other attribute with date/time data ends up using ISO 8601 instead of a UNIX timestamp, it might be useful to specify the profile to avoid ambiguity:

• Basic vs. extended form: YYYYMMDDThhmm or YYYY-MM-DDThh:mm, most profiles (RFC 3339, W3C Date / Time) forbid the former.
• Hour range: 00-23 or 00-24, most profiles forbid the latter but it is technically allowed under ISO 8601.
• Unqualified form: Whether the date/time can be passed without the timezone. The RFC and W3C profiles do not allow it but it was suggested there might be use cases for the unqualified form.
• UTC: Either as Z or +00:00 (+0000 if the basic form is specified).

Agree with Brian's point on recording = 0 implying false.

Dimitris

[robhazan]

@bmayd @ssorensen1979 @iabeurope-beis - created #152 to address your feedback. Please have a look. CC @hillslatt

[robhazan]

@bmayd @ssorensen1979 @iabeurope-beis @hillslatt PING!

[amitshetty]

1. One more vote on Brian's comment on the consistent use of 0/1 and 0== false :)

2. airdate attribute - I discussed with a few others, and the general opinion was that they didn't see the value. I’d argue that the level of interest in the content being considered is all that really matters. The user is looking at it, so it is of interest to them… Not sure it is worth the effort to track and communicate the exact air date. Will buyers assign different values to different airdates?
   But, open to discussing and understanding it if there is significant buy side interest in it.

3. That said, the -1 value for airdate was a good idea (maybe using a different attribute that represents "first time aired" or maybe adding one more value on recorded?). The example that resonated with people was re delayed live events. If an event at the Olympics is being streamed on a delay due to time zone concerns, but it IS the first time that event is being streamed, it might be more valuable compared to any recordings of the event played later.

4. btw, I also heard confusion about how "livestream" is being used for recorded content and for episodic content, but there wasn't any major pushback. People understood the difficulty in describing all the different concepts. Not to throw a wrench or cause more confusion, but does "linear" (in the sense of Linear TV) help here? (linear as in scheduled watch, but not live). So the 2 attributes would be "linear" and "recorded" instead of "livestream" and "recorded".

-Amit (Fox)

[ahewitt-Magnite]

Feedback from Magnite:

We support the addition of recording and airdate to better distinguish real-time vs. pre-recorded content, especially for forecasting and targeting use cases. However after speaking with several customers, we anticipate challenges in implementation for distributor pubs/media owners that rely on third-party programming sources. Specifically, many distributors do not currently ingest or expose this metadata, and upstream data feeds from programming partners may not support structured flags for "real-time" or original airdate today. For these sellers, supporting these fields would require a not insignificant amount of technical work as well as possibly opening up contracts or even signing up a net-new vendor who could verify these signals. These sellers are overall supportive of the effort, but we just expect that some may not want to or may not be able to quickly implement the solution proposal.

We would encourage the working group to provide optional implementation guidance (or fallbacks) for cases where recording or airdate cannot be reliably sourced—e.g., defaulting to recording:0 and omitting airdate if the value is unknown. It might also be worth adding clarification around whether the burden of accuracy lies with the content originator or the distributor.

[bmayd]

@robhazan Apologize for the slow response.
Changes look good, but I've been thinking about the livestream and recorded attribute definitions and wondering if the current fields, as defined, provide a complete enough signal. I'm assuming an advertiser will be interested in knowing:

1. Is this a live event?
2. Is it being broadcast as its happening?
3. Is it being broadcast for the first time?
4. Is the broadcast linear or on-demand?

I think the current proposal may be conflating the 1st and 2nd in an effort to signal "liveness" by coupling livestream and recording and that decoupling them would enable signaling of pre-recorded live events.

If that makes sense (and matters to advertisers), I suggest defining:

• livestream as 0: on-demand, 1: linear (perhaps name the field linear instead of livestream with 0: no, on-demand, 1: yes, linear)
• recorded as 0: no, broadcast live, 1: yes, pre-recorded.

Add:

• 'capturedlive' defined as 0: no, 1: yes.
• 'firstbroadcast' defined as 0: no, 1: yes.

For a live event happening now (e.g. sports or SNL) linear broadcast, the values would be: livestream: 1, recorded: 0, capturedlive: 1, firstbroadcast: 1.

For a live event time delayed (e.g. EU Olympics in US or US national evening news on west coast) first linear broadcast, the values would be: livestream: 1, recorded: 1, capturedlive: 1, firstbroadcast: 1.

For a live event time delayed (e.g. EU Olympics in US or national evening news on west coast) on-demand broadcast, the values would be: livestream: 0, recorded: 1, capturedlive: 1, firstbroadcast: 0.

For episodic content (e.g. sitcom or movie), first airing, linear broadcast, the values would be: livestream: 1, recorded: 1, capturedlive: 0, firstbroadcast: 1.

For episodic content (e.g. sitcom or movie), on-demand broadcast, the values would be: livestream: 0, recorded: 1, capturedlive: 0, firstbroadcast: 0.

I think if livestream was 0 (on-demand) recorded would have to be 1 (pre-recorded) and firstbroadcast would have to be 0 (not first) or undefined.

airdate would keep the current definition: first broadcast or otherwise published.

Per the @ahewitt-Magnite comment above, I think it would be good to include "unknown" signals for each of the attributes as well rather than providing defaults which may be incorrect and misleading.