Amazon caching Flash Briefing files...is intent the fix?

Podlove Publisher Analytics
1

Hi All,

I love Podlove so much! Such an amazing piece of software.

I have a question, but it might be a little long, because I want to explain everything.

I create Alexa Flash Briefings (“micro-podcasts” for Amazon Echo devices) and have about 200 clients that I set up with hosting on Libsyn and Podbean. Their analytics worked fine until late October, when Amazon started caching the files on their servers without notice. Suddenly, each of my clients started complaining their stats had dropped tremendously, like from 150 plays per day to 10 plays per day. When I checked their analytics in the Amazon Developers Console, the numbers still looked normal, so the traffic dropped, it just couldn’t be recorded by Libsyn or Podbean. I eventually found out that Amazon had begun caching Flash Briefing files on their own servers. I’ve been looking for a good analytics solution for my clients ever since, but with no luck.

At the same time this was happening, I was setting up my own audio hosting solution specifically for Alexa Flash Briefings on Amazon servers using Podlove, Auphonic, S3 storage and Cloudfront CDN. I noticed that my Flash Briefing’s Podlove stats are exactly correct, as are the analytics of the 4 other clients I offered test accounts to.

So here’s the question: Is the way that Podlove measures plays through Intents vs. Downloads the reason it’s working, or has Amazon just not sucked my account into their caching mechanism yet?

If I could suddenly go to my 200 clients and say “Migrate to Alexa Guy Hosting and the analytics will be correct again,” that would give a HUGE jumpstart to my hosting business. But if it’s not the reason, we could all be faced in 3-4 months with the same problem when Amazon starts caching these files.

Any clearance on how Intents work, including how they might be recording the click vs. the download would be appreciated.

Thanks in advance!
Jeff

2

I’m don’t know how Flash Briefings work on a technical level, but I can tell you how Publisher Tracking works.

First, there’s https://docs.podlove.org/podlove-publisher/guides/download-analytics.html providing some insight if you haven’t seen that yet.

But to get to the issue: The way tracking works here is that instead of a direkt link to the file, the Publisher provides a tracking link in the RSS Feed. If Amazon takes that link, follows it, takes the file and then caches/serves it from their own servers, there’s nothing anyone can do to track beyond that.

However if for some reason they keep the original tracking URL intact and just replace the final file… I don’t know, it doesn’t seem likely.

Apart from the explanation the best advice I can give is wait and observe for a while. I can’t provide a definitve answer.

3

Thanks for the quick reply, Eric!

I actually figured out a way to test it. I have some clients whose Alexa feeds are run through Feedpress, so I can check with one of theirs (with their permission), by duplicating a day or two of their files onto my service and change out the feed in Feedpress to my server. If the stats are right during that period, it will work. If they’re not, it won’t.

1 Like