Download Tracking (Optional)
Download tracking tells you not just that a subscriber polled their feed, but that they actually downloaded an episode — which episode, when, and from which podcast app.
Without it, your Benecaster dashboard shows feed activity: last seen, how often they check in, whether their token is healthy. With it enabled, each episode in your dashboard gets a download count, a per-subscriber download history, and a breakdown by podcast app. That’s the difference between knowing someone is subscribed and knowing they listened.
Enabling Download Tracking
Download tracking has two levels, and no global on/off switch — there is no site-wide “download proxy” setting anywhere in Benecaster.
Show level (the default for every episode on that show). Open the show’s settings, go to Details → Show Flags, and toggle Enable download tracking. Every episode on the show inherits this setting unless you override it individually.
Episode level (overrides the show default for that one episode). Open the episode, go to the Media tab, and set the download tracking field to Inherit from show (the default — follows the show-level toggle), Force on, or Force off. Use the override when one episode should behave differently from the rest of the show — a single promoted episode you want data on even though tracking is off show-wide, or one episode you want excluded even though tracking is on.
No other configuration is needed at either level — Benecaster handles everything automatically once tracking is on for an episode.
Per-show, with a per-episode override, is deliberate. The proxy is the one part of Benecaster that meaningfully increases load on your server, so being able to turn it on for one show, one season, or a handful of episodes lets you get the numbers you actually want without paying for the ones you do not.
To disable it, turn off the show-level toggle, or set the episode override to Force off. Disabling stops new download records from being created; existing data stays in the database until the retention window passes or you clear it.
The Downloads by Tier panel in Analytics appears once at least one episode has the proxy enabled. Until then it shows a prompt to enable it rather than an empty chart.
What Gets Recorded
When a subscriber downloads an episode, Benecaster logs:
- Which subscriber (by token)
- Which episode
- When the download happened
- Which podcast app made the request
This data powers the download count column in your episode list, the download history on each subscriber’s detail panel, and — if you have the Analytics Dashboard add-on — the per-episode and per-app breakdowns in your analytics charts.
Downloads Can Be Refused, and Refusals Are Not Recorded
A download is refused when the show is not entitled to serve it — a cancelled or expired licence, a payment failure that ran its full 30 days, or a show that is disconnected. The subscriber’s download URL returns an error reading “This show is no longer available for download.” Followers are the exception and keep downloading, because a follower’s feed only ever carried your public episodes.
⚠ A refused download is not logged, so you cannot see refused attempts in your download stats. Only completed downloads are recorded, and that is deliberate: every field in the log — the tier, the audio variant, the byte range — describes a download that finished. A refusal has none of them, so a logged refusal would be counted as a genuine download, and a lapsed show’s numbers would go up at exactly the moment they should collapse.
What this looks like in your charts: a lapsed show’s downloads fall to zero, apart from followers. There is no way to tell “nobody tried” from “everybody was refused” — so read a flatline during a licence problem as the licence problem, not as an audience that left.
What It Costs You
Download tracking has no setup complexity, but it does add load to your WordPress site. Here’s why: when a subscriber’s app downloads an episode, the request briefly passes through your WordPress installation — Benecaster logs it, then immediately redirects the app to the actual audio file hosted wherever you keep it. Your server never serves the audio itself.
That redirect is a WordPress request. On a small show with a modest subscriber base, it’s negligible. On a show with hundreds of active subscribers releasing multiple episodes per week, you could see thousands of extra PHP executions weekly.
Two things to watch as your show grows:
Hosting load. Entry-level shared hosting (Bluehost, SiteGround Shared, DreamHost Shared, and similar) may struggle with this additional request volume — particularly around episode release days when many subscribers sync at once. If your site feels sluggish after enabling download tracking, or your host’s control panel starts showing elevated resource usage, the proxy is the likely cause. Managed WordPress hosting (Kinsta, WP Engine, Flywheel) handles it comfortably at most show sizes.
Database size. Benecaster stores a record for each download. On a large, active show with tracking enabled for months, this can grow to tens of thousands of rows. This is generally fine — the data is indexed — but it’s worth knowing it accumulates over time.
Clearing Download Data
If you want to reclaim database space or start fresh, go to Benecaster → Settings → Tools → Clear download analytics data. This permanently removes all stored download records. It doesn’t affect subscriber records, tokens, episode data, or anything else.
You can also configure how long records are retained before automatic pruning — see Feed Request Log Retention for details.
The download log is handled differently from the other analytics tables in that retention setting, and it’s the one where “Forever” is safe. Every night, download rows older than 30 days are automatically summarized into a permanent, much smaller table of daily counts (by episode, tier, and podcast app) and the original detailed rows are removed. Your episode and subscriber download counts stay accurate — they read from the summary once rows age past 30 days — but the raw table itself never grows without bound. Subscriber events and daily snapshots, the other two tables under that same retention setting, are not summarized this way and do grow with whatever window you choose there.
If You Notice Problems
Download tracking is one of the first things to check when something feels off with your site’s performance or database size. Specifically, look here if:
- Your hosting dashboard shows higher-than-expected PHP request counts or CPU usage, especially around episode release days
- Your database is growing faster than you’d expect given your subscriber count
- WordPress admin pages are noticeably slower on busy days
- Your host has flagged resource overuse
In any of these cases: check which shows have download tracking on (Details → Show Flags) and whether any episodes carry a Force on override. Turning off the show-level toggle, or setting the busiest episode’s override to Force off, immediately stops new requests for it flowing through the proxy, and a handful of recent, heavily-downloaded episodes is usually where the volume is coming from. You can confirm it’s the source by checking how quickly your database is growing — rapid growth correlates with high download volume when tracking is on.
If you’re on shared hosting and seeing consistent issues, the practical options are: disable tracking, switch to managed WordPress hosting, or reduce the retention window so the table stays smaller over time.
For Developers
Each download fires the benecaster_download_redirected action immediately before the 302 redirect is issued — you can use it to log to an external analytics service, enrich download records, or trigger workflows based on download activity. See the hook reference for parameters and examples.