Have still been reflecting on the whole Dave Winer – Mitch Ratcliffe podcasting conversation (yes, I know, the topic is past its expiry date, but I’m still interested). I’m revising my confidence that MP3 will replaced by a better-monetizable format from ‘almost certain’ to ‘probable,’ since I managed to come up with some possible solutions – and I know from experience that if I’ve come up with a solution ten other people are already working on it. I still think MP3 is a poor format to work with, but it just might be possible to hack something out.
First – there’s nothing in the MP3 file that can ping back to a remote webserver. If there’s going to be pinging, the MP3 file can’t do it. However, the MP3 player can. An MP3 player could therefore send the contents of the ID3 tags to whatever server it’s set up to send to, allowing for accurate counting of listens. An online MP3 player could simply record the ID3 tags to its own server.
Problem: to count accurately, this would require every MP3 player out there to be modified.
Possible solution: capture enough of the market and also accurately estimate your share in the market, allowing for automated ‘reach’ estimates similar to those done by comScore (or Alexa, or Google, or anyone with a lot of toolbar installs) for websites. It’d still have to be one hell of a large percentage of usage to capture the long tail – you couldn’t measure listenership for new, handful-of-listener podcasts. But theoretically it’s possible.
Problem: what URL are the various MP3 players going to ping? Are all parties ever going to agree on a common repository? Microsoft’s not going to modify their Media Player to send Apple or Google data (and vice versa…)
Possible solution: the ID3v2 tag – which contains the text for song titles, artists, etc. – is extensible. There’s a field in there for a user-defined URL. The individual MP3 file could therefore contain the ping back URL of the issuer, and the MP3 player could then send a ping to that URL. There could be a host of aggregators and audience verifiers, and the creator of the MP3 file could just pick one to code up.
Problem: Just because we can count the number of listens to an advertisement doesn’t mean we can track its effectiveness. How do we measure whether our ads are converting, an essential part of online ad spend?
Possible solution(s): 1-800 pay-per-call schemes, single use URLs, and promotional codes will sort of work today, but ideally – and to avoid ping fraud bumping up the number of ad listens – the advertising model has to be moved from cost-per-impression to cost-per-click and then to cost-per-action. To do this, the listener needs to be able to move directly from the advertisement to the advertiser’s site in real time. Which means there needs to be a URL embedded in the MP3 player. Which means we need to add more cruft to the ID3 tag and further modify MP3 players to display clickable URLs at certain points during the MP3. When listening to an advertisement, the relevant URL for that advertisement could appear in the browser (and could be retrieved easily by a user through the MP3 player’s interface later). Of course the URL would lead to a click-through gateway that’d do the tracking for the advertiser. As a side-effect, the podcasters themselves could use the same scheme to add their own URLs to their shows – when mentioning a website, the URL to that website could appear right on the screen of the MP3 player.
Adding URLs to an audio file has been something I’ve been thinking about for ages now – while Jeff Jarvis and Mike Arrington‘s comments jogged my memory a bit, I remember chatting with Evan Eckard about this in early spring. Given infinite time and an infinite supply of people who can code…
Problem: What’s all this about clicking – my MP3 player isn’t hooked up to the Internet!
Probable solution: Give it a couple of years, and your MP3 player will be, as long as you’re within range of a cellular network. Right around the time the podcasting advertising models are beginning to mature and go mainstream. Come to think of it, when your MP3 player is also your phone, you could conceivably rig up a cell phone MP3 player that could read which keys were pressed while you were listening to a podcast, and redirect the audio to another call, informed by the phone’s GPS capabilities. “The Yardley Show is sponsored by Guinness. For a listing of pubs in your area that serve Guinness, press 1.” Wait, not advanced enough – let’s add in voice recognition. “The Yardley Show is sponsored by Guinness. For a listing of pubs in your area, say ‘I need a drink’ now.”
Lots of commerical possibilities. But because this would require modifying both MP3s (easy, do it yourself, start today) and all MP3 players (harder, requires broad consensus, first one to do it looks like Don Quixote), it’d take some luck to make it happen. Definitely not a business plan for the faint-hearted! If I was a gambling man I’d still put my money on formats like Audible’s.
{ 1 comment… read it below or add one }
Great post. I agree wholeheartedly. This paragraph caught my attention:
“1-800 pay-per-call schemes, single use URLs, and promotional codes will sort of work today, but ideally – and to avoid ping fraud bumping up the number of ad listens – the advertising model has to be moved from cost-per-impression to cost-per-click and then to cost-per-action.”
So let’s say a service like Fruitcast, which currently only tracks downloads, wanted to provide better metrics for advertisers. Would a 1-800 pay-per-call system work? Or is this just as easy to fake as the download bot you spoke of yesterday? By cost per action, you presumably mean tracking when a sale is made – this would no doubt work more smoothly (perhaps with a unique URL or promotional code for tracking) because podcasters aren’t going to buy a product/service just to improve their metrics.