Why have my listen counts gone down?

Pinecast decides whether a listen is from a bot at the moment the listen is recorded. We keep adding rules for new bots, crawlers and scrapers, and a new rule applies to listens recorded after it goes live. The most recent large update was in September 2026. If your numbers stepped down around then, listens from bots that used to count no longer do.

Past listens are not re-checked automatically. To have your older listens re-checked with the current rules, contact support: open Support in the header and choose Send a message to support (or Email support@pinecast.com).

Unlike other hosts, we keep an individual record of each listen (rather than aggregate totals) along with metadata about that event. That is what lets us re-check older listens. A lower number is disappointing, but we overwhelmingly prefer to give you the most accurate view of your listenership that we possibly can.

What does a re-check do?

When you ask for a re-check, we run the current bot rules over your listens from the last nine months for any of your podcasts. Some rules may not be applied, as we do not store raw IP addresses for listeners. This applies to clip listens as well as episodes. It does not apply to listens on Spotify.

How do I know that this was done correctly?

Nightly snapshots of our analytics data is stored in the event that changes have been made incorrectly. Streaming log data of all listen events is separately stored for a fixed period of time, allowing us to rollback bad changes.

Additionally, no analytics data is deleted as part of a re-check: flagged listens are kept but excluded from charts and aggregates. We are able to easily un-flag events as necessary.

All changes to analytics data are performed in an auditable two-step process. The first step simulates the operation being performed, allowing the effects to be observed for a sample of flagged events. The second step commits the effects of the operation to the database.

How do you detect unclassified bots?

Our techniques vary and evolve over time. Some common approaches:

• We look for request fingerprints that span many podcasts. It's extremely unlikely for a genuine listener to subscribe to a very large number of Pinecast podcasts.

• Requests that appear to be made by extremely old software (e.g., pre-2010) or software that couldn't possibly listen to a podcast is often a sign of a bot.

• Requests from a single IP address made so quickly that it's almost impossible for the listens to be genuine are often flagged.

• Identical requests made from a single ASN or small IP address range that have identical fingerprints are often bots.

• Requests made from data-center and low-cost server-hosting IP address ranges are likely bots.

• Requests made using generic HTTP clients without specifying a custom User Agent string are almost always bots.

• Requests whose user agent names a known crawler, AI scraper or dataset collector.

When a potential bot is detected, it is reviewed and a rule is written that filters it from new listens. As soon as the rule is live, it applies to every listen recorded after that.

When does this happen?

New rules apply to new listens as soon as they go live. We review our bot rules from time to time, with no fixed schedule. Past listens are re-checked only when you ask (see above).