2.6-202604 Public Comment Feedback

[hillslatt]

The Programmatic Supply Chain Working Group and Commit Group have gone through 3 rounds of Public Comment related to Livestream Signaling, captured in Issues 143, 157, and 162. This document reflects a final proposal from the Programmatic Supply Chain Commit Group, having considered and incorporated feedback from the preceding rounds of Public Comment.

Programming Liveness

• Addition of realtime, and firstbroadcast attributes in OpenRTB Object: Content and AdCOM Object: Content
• Updated attribute description of content.livestream
• Associated Implementation Guidance

Substitution Macros

• Updated description of ${AUCTION_PRICE}
• New ${AUCTION_DISCOUNT_PCT} and ${AUCTION_DISCOUNT_CPM}
• Associated Implementation Guidance

Public Comment will close May 28, 2026

[tonyhhung-lab]

We have mixed feedback from publishers about their ability to calculate the 3 states of livestream, realtime and firstbroadcast across every single live entity in their CMS and to send it on ad requests. I wonder if there is an easier option here where we consolidate firstbroadcast and realtime.

If what we are solving for is really:

1. allow SSPs/DSPs to understand when live traffic spikes happen
2. allow better differentiation of scheduled FAST inventory from scheduled live events/tentpoles (sports, entertainment, etc.)

Can we just drop the realtime signal and have firstbroadcast = 1 when it is first broadcast in real time or in the local market (i.e. primetime)?

This allows all of the following events to be marked as firstbroadcast and is easy for publishers to understand/calculate without having to separate content IDs and/or airing IDs and looking against airing dates.

1. World Cup game that is live
2. World Cup game that is broadcasted for the first time in primetime in local market

Another key point that went under the radar, and perhaps we can mention this in implementation guidance. The change of livestream definition from "VOD vs. livestream" to "scheduled vs not scheduled" will also include some larger reclassification of a large amount of livestream inventory (esp in gaming livestreams) that will be be reclassified to having livestream=0 and firstbroadcast/realtime=1. Since we are using the same signal here, publishers with applicable inventory being reclassified need to be informed and switch over to the new signals..

[jarredwilichinsky-ship-it]

Have any programmers signed up to sponsor this spec?

[nealrichter]

Tony Hung (Google) notes a reasonable question. No alternative given. Tony: are you willing to work up specific examples?

My guidance would be to move forward and we can discover issues in expression of certain cases of STV programs as they come. It's incombant on implementers to surface example idiosyncrasies or edge cases as they come up.

[nealrichter]

Jarred: these are optional fields that programs can adopt with their SSP/AdServer partners. The intent is to allow increased expression in OpenRTB implementations. We are working on an implementation of the same fields in the Deal API's AdCom object structure, to allow outside of RTB signaling within a DealID. Can you help us with that thinking?

[robhazan]

Know I'm coming in late, but my 2 cents on Tony and Jarred's questions/comments:

realtime and firstbroadcast are going to be provisional attributes. Since we can't find a perfect compromise that makes everyone happy and we don't have enough voices piping up to comment on how they'd use the fields, the thinking is that we start more expressive/flexible rather than less, and let's see how these things get used. If nobody uses firstbroadcast or realtime we can remove them from the spec in a year's time. @jarredwilichinsky-ship-it - if you just want to use realtime and not firstbroadcast for all integration purposes, that's perfectly reasonable. But I don't think we should limit others who may want to use that expressiveness.

All of these fields to some degree rely on implementation agreements between buyers and sellers. DSPs need to know when to activate pacing that's relevant for live events. If some buyer and/or some seller doesn't want to use realtime or firstbroadcast to signal that, or only wants to use 1 of those 2 fields for all scenarios, then they can agree on that for their integration.

Another thing to keep in mind is that these attributes are not only for use on a per-bid-request basis. The content object (and these liveness attributes within it) is also referenced by the LEAP Forecasting API and will likely be included in the Deal API, as well. So even if the granular level of expressiveness is not easy for pubs to provide in bid requests, it may be feasible/appropriate to provide in supply scheduling/forecasting and deals-related communications.

[robhazan]

@tonyhhung-lab - does the end consumer initiate a gaming livestream and use progressive download to watch it? Or is it initiated by the gamer or gaming league and streamed using livestreaming technology?

If it's the latter, I'd say the current definition works (i.e. it's livestream=1 because the user didn't watch on-demand playback asynchronously, but rather watched the stream in realtime synchronously).