Bonkers stats every other day for a week now

For extra flavour, the jumps are so ridiculous during these last few days, I get a daily listen count that is 10x to 50x my weekly listens. That’s just can’t be right or organic, I’m not running any ads and I can only wish I were that successful. I can’t bring those numbers to advertisers with a straight face. They’ll think I’m trying to defraud them, with historical stats being what they are.

This reminds me off that month-long period in May/June 2021 during which I had the same issue and it proved to be a bug on your end.

[ Please do not bump. ]

Hi there,

Is it just one particular episode or all of the episodes? Do you have your episodes distributed on any other pages beside the website or anything?

I noticed on https://www.halftone.fm/category/blog/, the player you have within one of the blog posts preloads the latest episode without pressing play, this is counting a listen with every single page load for that particular episode.

Request URL:
https://www.halftone.fm/wp-content/uploads/2023/10/Showrunners-78.mp3
Request Method:
GET
Status Code:
206 Partial Content

I see all other pages seem to use the Castos Player which no longer preloads the episode on a page view (that may have been the issue you’re referring to in 2021).

So for that, just be sure that any media players that are delivering your files do not preload the episode file in the event your episodes are being served from other sites.

That said, do you see a trend when the episode total jumps? Is it from a particular source or kind of all spread out among sources? Is it all podcasts seeing these spikes or just one podcast?

This has been affecting any and all shows and episodes. Not always all of them on the same day/at the same time, but most of them, most of the days.

I get a couple of quiet days every now and then but the issue resumes seemingly at random (so it’s not happening on certain days and repeating circumstances on the production side), meaning it’s not that I publish a new episode on a certain feed and that’s the feed that happens to go haywire that day.

No, my episodes are not being distributed through other sites, just the regular podcast services, whose stats remain realistic.

As for the page you highlighted, it doesn’t get many visits, certainly not enough to explain what I’m seeing, even if it autoloads. But I removed that embedded player, just to be on the safe side.

Hi @yaponvezos,

It’s possible that this behavior is the result of a bot that periodically crawls your site.

Have you examined the listening sources for the standard time frame and compared them to the peak days? Is there a variation, and if so, which source has the highest numbers during these peaks? Is it the ‘Audio player,’ ‘Other,’ or something else?

Maybe it could give you some ideas regarding what’s happening.

Best regards,
Serhiy.

They seem to be counted in “Other”. But that is always the case. Plus, when these spikes happen, they’re evenly distributed between feeds and episodes, so if I check episode stats and all the extra downloads count as Other, I’m not going to see some huge and obviously nonsensical number in Other for any particular episode.

It’s not as clear as back in 2021 when all the spikes were counted in Audio Player, which is pretty specific. Your Other category never was specific enough.

I will try to check the bot activity but my firewall doesn’t make that easy. I am sure the extra traffic doesn’t originate from suspect parts of the globe though, I keep my firewall pretty aggressive as it is.

@yaponvezos You can try checking the referrers (sources) in the peak periods directly in the database. Can you use phpMyAdmin or any other database tool? The referrer is stored in the wp_ssp_stats table, column referrer.

• This reply was modified 1 year ago by Serhiy Zakharchenko.

Hi

Experiencing exactly the same issue. From my perspective, it appears like a bot or a new “service” is represented as downloading all episodes in the catalogue in one go. Our daily stats are typically in the neighborhood of a multiple of the number of episodes in our archives plus the number of actual downloads on that day.

Downloads get represented under “other” in the listening sources.

Appears that the “downloads” tracked by the plugin are bogus if I compare the numbers to other services like Chartable or Podtrac.

Thanks for looking into this.

@zahardoc just checked my database. All the hits in question have an empty “referrer” field.

@paspen18

You can try tracking the referrer by adding the following string to php/classes/class-ssp-stats-hit.php file, track_hit() function (line 145, before $episode_id = $episode->ID):

if ( ! $referrer ) {
  $referrer = $user_agent;
}

@zahardoc

Thanks for that. Added it to the file as described.

Hope the next release of the plug-in will address the issue directly.

@zahardoc

Fix worked out fine so far.

However today, there is another “bonkers” day. Checked the DB and the “hits” are now coming through with referrer “itms” (500+ all within a couple of seconds). Appears “itms” is what Apple calls the iTunes crawler service.

Not sure if Apple changed anything on how they are crawling rss and how that is, or should be, reflected in the stats plugin.

Experiencing similar traffic spikes here. Most of the unexplained traffic is coming from a single IP address in my case (34.223.22.0), which seems to belong to an Amazon datacenter in Portland. Haven’t manually added that user agent fallback for referrer yet. Will do that today to see what comes back there.

Just a quick followup here. User agent is coming back as “itms”, but I’d be surprised if it’s actually Apple, given the Amazon IP address. The user agent coming back from the actual Apple IP address is “iTMS”, and it’s much less spammy.

Has there been any progress on this? The “bonkers” stats are worse than ever after a quiet time and pretty much make the plugin obsolete.

Assuming you guys are working hard on an upgrade, seeing that the last update to the plugin was 9 months ago now (version 1.5.2).

Same here. After a (relatively) quiet period, the issue came back with a vengeance these last few days so I can’t trust any of the stats.