SSAI/SGAI Ad Tracking for HLS and DASH

[haudiobe]

Hi Hali, Zachary and Thomas,

We are reaching out because we would like to discuss with you the work that we have with the UK Broadcast industry to simplify Ad Tracking. We believe that our work is a good complement to the version 2 of the Ad Creative Signaling in DASH and HLS standard. Hence, we are keen to discuss with you how we can build a proposal for it.

In two sentences, our proposal relies on a callback API which requires the player to regularly send its playhead position and playback events. The API end-point can then fire all the tracking beacons and/or provide the Advertising Information about the streams to the device. I am attaching the presentation that we made in order to discuss our proposal at an SVTA Meeting.

I am unsure if our proposal is better suited for the SVTA Advertising WG or the DASH-IF Live and Ad Insertion Call. So I wanted to see if maybe we could have a talk with you first, to discuss our proposal and any documents/presentations that you would need from us. Would you be available next week? Maybe we could have a call on Tuesday the 3rd of September at 16UTC or on Wednesday the 4th before/after the Advertising WG Call?

Thank you for your help,

Regards,

Olivier Cortambert Head of Solutions Architecture

Yospace - The Dynamic Ad Insertion Company SVTA - SSAI Tracking.pdf

[haudiobe]

DASH-IF WG 2024/03/09:

Please provide comments

• do we want to work in DASH-IF WG?
• If so, who is interested to support the work?
• Proposal for the exact scope are also welcome

[technogeek00]

Notes from presentation in 9/6 Live/Ad call

• Main goal: Make it simple to send all beacons related to inserted advertisements
• Existing mechanisms for SSAI sending beacons is either sent without understanding of client playout or require specific SDK implementation which can be hard / heavy across devices
• Proposal is to introduce a new standardized mechanic / API within player implementations that reports active player position and state to a service endpoint which is then able to fire tracking beacons on behalf of the client
  • Only expectation of manifest/playlist is a signal to activate this mode, potentially supply the endpoint to track against
  • Service expected to maintain state / understanding of the stream shape so that does not have to be actively communicated
• Couple of potential solve points called out in call:
  • Rufael highlighted the DVB extension work on DASH Callback and the ongoing work to establish global callbacks outside of periods
  • @wilaw pointed out the similarities being described relative to the CMCDv2 direct endpoint call mechanics which can be activated on player state change as well as interval

Personal thoughts

• This doesn't appear to have manifest / playlist specific needs, it would be more specifically player related
• Pursuing a new player / api mechanic could be done here or in the players and playback wg
• However, the CMCD v2 may work exactly as needed for this solution and driving towards greater adoption there and reusing may be generally easier to accomplish

[haudiobe]

TF group Sep 27, 2024

• Olivier reports that he is in touch with Will to add this to CMCDv2
• The new key would be the playhead position, a common way to report this is needed
  • would be the currentTime of the video element of the browser
  • may need a further definition using some MPD level information
  • @dsilhavy can we have a look how dash.js would do this.
  • we should also make sure that this is also compatible with HLS. Can you define it independent of the manifest.
• We wait for feedback from CMCDv2
• Callback API not to be specified on Period level, but on MPD level
  • rufael reports that with the presentationTimeOffset may use this.
  • Alex should have a look