Redirect Speed of Analytics Prefix Services
An analytics server logs each request from a listening app and redirects it to the actual audio file where it can get downloaded and eventually played.
If it takes one second for the analytic prefix server to redirect to the actual audio file, your listener needs to wait one second longer than without it. (If the audio file is not pre-loaded nor cached.)
Does it matter? On the web, a one second longer wait time means the world in regards to drop-off rates, for podcasts it does not matter the world, but it matters at least a little bit – in my opinion.
When creating Podkite’s analytics prefix, we focused on two things:
- no (or as little as possible) downtime by design
- the fastest redirection speed in the market
For the mini benchmark, I used the same test audio file (not that it matters much).
Here are the averages and 10 response times in milliseconds:
Podkite (59ms average) | Podtrac (130ms average) | Chartable (270ms average) | Podsights (507ms average) |
47 | 144 | 317 | 588 |
37 | 124 | 371 | 479 |
151 | 124 | 133 | 495 |
46 | 131 | 133 | 536 |
46 | 123 | 137 | 474 |
85 | 123 | 132 | 497 |
38 | 134 | 138 | 490 |
48 | 134 | 136 | 492 |
37 | 134 | 939 | 519 |
Again, does it matter? A little bit. Especially if you chain multiple prefixes.
Is the Podkite analytics prefix fast enough? That’s what we actually wanted to ensure and the answer is clearly yes.