Proposal: VAST for dynamic ad insertion (that doesn't break timestamps) #556
Replies: 1 comment 4 replies
-
|
I really like the idea of looking at a way to get transcripts to work with DAI. VAST is already used by the podcast industry when stitching ads together, so its use is rather elegant here. I guess two questions:
Not so long ago, RedCircle’s Mike Kadin was on the Podcasting 2.0 podcast ep 133 with I seem to remember a pretty good solution for it. Here it is… Yeah. So I think, going back to what you said before, right, each individual download where the listener hits play is unique to that specific listener at that time, right for that episode, right. And that is unique to them. But the transcript URL and the chapter URL is at the feed level right? Now, like I said, before, we do like store or cache, a configuration that says like, we serve this IP address and user agent, this audio file at this time, so that if they come back five minutes later and download the second half of it, everything remains in sync, right? So we do have some concept, it's temporary and time of like, you know, if you asked me like, What did i What did I stitch together? In this episode from this IP address five minutes ago? I can answer that question. Right. So theoretically, right, then, like, if you asked me for a transcript, I can use that same configuration and stitch the transcript together, right? Same thing for the chapters, right. So I think the only thing that's missing with our current setup is just kind of like a specification that details how those URLs for the transcript and the chapters should be requested. They have to be from the client, they have to be close within time for when the download was requested. And they have to be, you know, from the same IP address, same user agent, everything else is same. So we can identify that and say, Alright, that's the same thing that just downloaded this podcast five minutes ago, now I can give you the transcript. If they download the transcript on the server side, that's not going to work. It's going to come from the server's IP, if they download the transcripts, like when the RSS feed updates, but then the listener downloads the podcast two days later, those are going to be out of sync, right. So like, either that's one option is to just kind of specify what the client's behavior should be with respect to downloading those things. Right? That's one option. I don't like it as much, but that's an easier option. Dave Jones Mike Kadin Dave Jones Mike Kadin Dave Jones Mike Kadin Dave Jones Mike Kadin Dave Jones Mike Kadin Dave Jones Mike Kadin Dave Jones Mike Kadin Dave Jones Mike Kadin |
Beta Was this translation helpful? Give feedback.
-
This is sort of what I attempted to address with my last two points: Like the value block, it's a voluntary system based on trust and incentives. You could block someone who violates trust with the block tag, although the block tag is also based on trust (it's easy to get around). I would add that a transcript-based search engine is actually a legitimate example of an ad-free podcast app. It doesn't itself "play" the audio or the ads, it only finds search results and links you to other players at specific timestamps. At the end of the day, it is always going to be a trust model (much like I was thinking recently that in order to drive this point home, I should publish an open source library for detecting ad insertion points for legitimate apps that depend on these. If bad actors also want to depend on these, that would still not be a reason to undermine the legitimate use cases. However, it would be much better if hosting companies supported these legitimate client use cases properly. As it stands, legitimate apps that are sensitive to timestamp changes would have no option other than to skip over the ads in order to stick only to those regions that we have valid transcripts and timestamps for. If the hosting companies provided an option for VAST-compliant apps, it would no longer be necessary for all such apps to skip the ads.
Section 1.1.3 of VAST 4.0 mentions server-side stitching as a fallback option. Although I was unable to find details on how the client/server shake hands on which approach to use. If none were specified, we could implement something like this: The client includes a header in the GET request to indicate that it is VAST compliant. If that header is not present in the request, the server serves a stitched audio file with the ads dynamically inserted on the server side. So the default behaviour would be the current behaviour.
Unfortunately that approach doesn't actually solve the use case of timestamp-based transcript search engines. Remember that a search engine doesn't actually play the audio or the ads, it merely presents search results and links you to other players to play the search result at the indexed timestamp. So the timestamps will always be invalidated by an approach that gives you a different response from the same GET request. What troubles me about this from an HTTP perspective is that it's not idempotent. So while in theory, you could add a response header to a GET response that tells you which transcript corresponds to the audio you're getting this time, the whole thing is not idempotent, and it means that the GET response that search engine receives will be useless when trying to serve up search results. The other idea mentioned was having a unique URL for each version of the dynamically stitched file. This would be an example of a traditional use of HTTP, since a GET request for each URL would be idempotent. However, the dynamic part of it would just be pushed to another server-side step and idempotency would be broken there. For example, the URL listed in the feed might be dynamically changed, or it might be a redirect that dynamically redirects to a different audio file each time. In either case, the search engine will not be able to download and index a moving target. |
Beta Was this translation helpful? Give feedback.
-
|
I think the idea of using either the ULID or an HTTP header is that it is idempotent - if you send the same ULID or the same HTTP header to the transcript engine, you should get the same transcript back again that corresponds to the audio. For DAI-delivered audio, the desire is that a listener continues to get relevant ads, but that the transcript deals with the fact that I might hear an initial 30" preroll while other listeners might get a 60" preroll. So, I'm not sure where a transcript search engine fits here. It'll always be transcribing the version of the audio which is given to the search engine. That may well be different to the version of the audio that a typical listener gets. We probably don't want to break that. |
Beta Was this translation helpful? Give feedback.
-
Subsequent requests are idempotent, but the initial request is not. That's what prevents a timestamp-based transcript search engine from providing other listeners a timestamped link to a podcast episode, and it's also what prevents social podcast apps from sharing timestamped links with other listeners. The lack of idempotency on the initial request is what prevents these types of beneficial use cases.
Exactly. Ads are intended for the listener's consumption and not for the search engine's consumption, but that is exactly my point. Individual listeners are not the only consumers here. Apps also consume the timestamps and share them with other listeners. Now there is another very simple solution here, which is that the search engine does not index any podcast that uses dynamic ad insertion, and apps do not permit clip sharing for any podcast that uses dynamic ad insertion. However, I would think that podcasters themselves would really want these things in order to boost the discoverability and virality of their podcasts. So it really comes down to the question of whether apps take advantage of this and skip ads. Well, we can already skip ads, can't we? Users can press the skip-forward button, and there are also automated ways to detect and skip ads. Another interesting point here is that if we allow an app to declare that they are VAST-compliant, it would actually be possible for an app to implement ads in such a way that you could not skip the ads, or where you need to listen to at least X seconds of the ad before you can skip it. VAST-compliant apps could also take advantage of the ability to click and follow the ad link to whatever promotion deal it is. VAST apps can also handle the case where if a user does click on the seek bar to skip over an ad point, the ad will still be forcefully inserted before jumping to that seek point (see the YouTube player for an idea of how all of these user experiences work). So there are benefits as well to the advertiser that might be overlooked. With the proposal as it is, the default behaviour would be to operate the way it currently does with sever-side stitching, but provide a handshake for VAST-compliant apps to provide a richer client-side experience and support all of these interesting use cases that involve sharing timestamps with other listeners. |
Beta Was this translation helpful? Give feedback.
-
If only you had shared a timestamped link to the relevant part of this 2 hour long episode: link If ever there were a use case for timestamp sharing, here it is. |
Beta Was this translation helpful? Give feedback.
-
Background
Dynamic ad insertion results in a well-known problem for Podcasting 2.0: it invalidates the timestamps in transcript and chapter files. A common approach to dynamic ad insertion is to serve the stitched audio file and the corresponding stitched transcript and chapters files at the same time, so that a transcripts or chapters file is only valid for the audio file that was downloaded at the same time.
However, this approach does not work with timestamp-based search engines which download and index transcript files during the crawl stage, and then serve search results at some later point in time when those timestamps will no longer match with the audio. More generally, this approach presents a problem for any Podcasting 2.0 application that needs to do one-time processing of transcript or chapter files, typically in cases where that processing is large scale or intensive.
Proposal
The VAST specification: https://www.iab.com/wp-content/uploads/2015/06/VASTv3_0.pdf
VAST is a standard for client-side ad insertion, providing cues for ad insertion points, and an endpoint for dynamically fetching the ad to insert. The response from the ad server is an XML document that specifies the type of ad, one or more media files that constitute the ad to be inserted, and other elements that are specific to video ads (such as instructions on what to do when the user clicks on the ad). We can use just the subset that is relevant to audio ads, which includes the insertion times, the ad durations, and the media files associated with the ad, which we can use to include 1) the audio file for the ad, and 2) the transcript file for the ad.
VAST has open source implementations for different client side platforms lending themselves well to adaptation to Podcasting 2.0:
The key benefit of VAST is that it preserves timestamps regardless of what ad duration is inserted.
Companies currently offering dynamic ad insertion on the server side may naturally be cautious about whether they can trust apps to implement this. However:
Beta Was this translation helpful? Give feedback.
All reactions