Title doesn’t make a whole lot of sense as I didn’t want to put everything there when I’m going to explain what I need below. Follow along.
As I’m writing the chapter on measuring your podcast, I’m trying to explain feed requests. Now, feed requests are any request made to your feed from anything. Anything is quite broad, so let me narrow it down. Anything could be:
- A person who added your feed to their feed reader. That’s a feed request.
- A person who opens your feed in their feed reader. That’s a feed request.
- A person who plugs in your feed into their browser. That’s a feed request.
- A podcatcher updating its directory with new details from your feed. That’s a feed request.
- Any errors or failed attempts (sort of like a 404 error when a webpage can’t be found). That’s a feed request.
- Any others?
Now, when a feed request is made, is a download registered in my stats because the audio file is enclosed in the feed? Or, would that more accurately be considered a download request?
My thinking is yes, if an audio or video file is enclosed in your RSS feed, then if there’s a request made for your feed, it’s also considered a download request, but not an actual download. If that’s the case, how does this then skew your podcast statistics?
Let me know if I’m on the right track. The most intelligent response will make it into my book with full attribution.
Tags:
feeds,
RSS,
podcasting,
technology,
Interesting question et al.
If you sign-up with Feedburner, they will provide specific stats on downloads, i.e: When the actual file was requested from the enclosure (obviously from within the .xml feed file).
With their ‘Pro’ package enclosure usage can be derived.
With Google Analytics you can see the most common content used.
Re: Feed requests, on one of our podcasters: http://www.smoothgroovers.com, we get 48,000 requests for the feed per month. In terms of actual episode listening online, approx 300. In addition, according to Feedburner requests, 10? We don’t know how exactly how many we get from i-tunes and I believe the popularity bar in i-tunes listing may be based on search information.
In summary, monitoring from a variety of podcatcher sites has to be the answer.
Another interesting statistic is most rated. For example, again referring to the Smoothgroovers on Podfeed, they are number 2 and what is quite annoying is the way some people who don’t like jazz intentionally attempt to manipulate the awarded rank.
For example, suggesting, ‘Jazz does not deserve to be top’. What these people don’t realise is that by voting for the podcast they have sustained the ranking. Being most voted does not mean being most popular.
Anyway, I love Jazz!
Leesa;
I’m hyper-express emailing a white paper on podcast stats to you that I wrote when I was a member of Techpodcasts.com. Todd Cochrane, Douglas Welch, Kevin Devin and I spent quite a bit of time determining what constitutes a “real” podcast download. Kevin wrote a script called Podstats that makes a numerical determination of the number of downloads that a site gets over a period of time. It was — and may still be — the way advertising revenue was shared amongst techpodcast.com affiliate members.
I should caution that Doug Kaye does not think downloads represent an accurate representation of the number of listeners. While he is right, it is still more accurate than relying on limited sample broadcast diaries which are used in radio. We discussed this in a post on my site a couple of years ago; http://www.bradfordgibson.net/node/132.
Just because a feed is requested, doesn’t mean the enclosures inside it are! That’s important to keep in mind. Another thing…some applications make multiple requests to a file in order to download it (such as any application that uses Microsoft BITS, like IE7 does). That can significantly skew your numbers.
Bloody hell, based on all your feedback, I just realized how much I still need to do. I’ll contact the guys over at Feedburner, Libsyn and Radiotail. Thanks for the suggestions everyone and John, thanks for tackling my questions. I’m glad you were able to make sense out of my nonsense 🙂
This is a question for Rick Klau of Feedburner or Greg Galant of Radiotail.
likewise, feedburner’s forum.
feed requests (aka, hits on the xml page) can’t be accurately turned into subscriber requests. they need to be cross-referenced with IP addresses to ensure that duplicates aren’t recounted.
Here’s as far as my knowledge goes:
1. Is not necessarily a feed request, it depends on how the client handles the adding of the feed. If the client starts the add process based on seeing the file name feed or the extension .xml it may not have to make a request.
2. Opening the feed in a browser is a request
3. If you mean adding a feed as a live bookmark in Firefox it will request it once it’s added and every time you start the browser when connected and it has a refresh which can be set by the server (and probably the client but I haven’t looked for that in the preferences). Please chime in if you’ve done that, I don’t open FF on my cell modem anymore b/c I have to wait for 2 meg in feeds to come down before I can browse.
4. A directory would grab the feed to analyze it.
5. Errors will depend on which side had the error, a client error may never get to the server and not show up. It’s also possible that a server error would not be recorded.
6. It’s important to note that most newsreaders will be requesting the feed every time they start (unless set otherwise). From what I understand requests for the feed are not a very useful metric, downloads of the media files are far more useful in determining who’s getting the content.
The audio file is not actually in the feed, only the location of it, so you will not show a download request until the feed is downloaded and the user requests the file. If your newsreader chaches the file for you than you will have a download, but downloading the feed will not register a download request unless the client checks the feed and then downloads the file.
The other issue that clouds all of this is that clients may make multiple requests for single files before the download commences. As a result your download requests will always be significantly overstated compared to actual downloads. Bandwidth is a better measure of the number of downloads, but then this becomes skewed by partial downloads.
Just to mess with your brain a little more, there’s also the issue of IP addresses. Think of this as the “ID Number” of the machine requesting the download. Unique IP’s is a number that is very good, but this stat is understated because some ISPs funnel all requests through single machines (ie – all AOL downloads appear to come from a narrow range of IP addresses). Libsyn has a formula that they apply that takes into account your unique IPs and then does some guestimating (probably based on bandwidth and total requests) and draws a line in the sand.
If you look in the Libsyn forums under stats there’s more there than you’ll probably want to know.
This also raises some other issues that show how fragile a feed can be when it gets redirected too many times, hopefully this will shake out as more standards form.
Libsyn’s forum has always been a good place for these sorts of answers. They have some experts there who can tell you what it all means as far as they are concerned.