Skip to main content

Privacy and Data Handling

Benecaster is built for podcasters who care about doing right by their subscribers. That means being specific about what data the plugin touches, where it goes, and what controls you have over it.

This page documents every category of data Benecaster collects or processes — from subscriber feeds to optional telemetry — and the tools available to you for retention management and right-to-erasure.


Data Benecaster Collects

Free Follower Signups

When the [benecaster_follower_signup] shortcode is placed on a page, it presents a sign-up form to any website visitor — no account or payment required. Submitting the form:

  • Creates a WordPress user account for the submitted email address (if one does not already exist)
  • Generates a feed token and stores it in benecaster_tokens with token_type = 'follower'
  • Sends a welcome email to the submitted address containing their private RSS feed URL

Fields collected: Email address (required) and display name (optional — the form can be configured to omit the name field via show_name_field="false").

Idempotency: If the submitted email address already has a follower token for that show, the form shows the success message silently — no new user is created, no second welcome email is sent, and no indication of existing status is returned to the visitor. This is intentional to prevent email enumeration.

Personal data erasure: A follower’s data is erasable via the standard WordPress user erasure flow combined with TokenRepository::revoke_user_tokens(). The right-to-erasure tool in Settings → GDPR / Privacy covers follower token records alongside paying subscriber records.

Download Log

Every feed request from a subscriber is recorded in benecaster_download_log. Each row contains:

  • Episode reference
  • Show reference
  • Token reference
  • User (subscriber) reference
  • Membership tier at time of request
  • Hashed IP address (never plaintext — see below)
  • Byte range from the HTTP Range header, when present

IP hashing: Raw IP addresses are never stored. Before any log entry is written, the requesting IP is hashed using benecaster_ip_hash_salt. The plaintext IP exists in memory only for the duration of that single request.

If GeoIP enrichment is enabled (see below), the GeoIP lookup also runs before the hash, so the lookup and the hash happen in the same request and the plaintext IP is discarded immediately after both operations complete.

GeoIP Enrichment

When GeoIP is enabled in Settings → Tools → GeoIP Database, Benecaster enriches download log records and subscriber token records with geographic data derived from the requesting IP address.

What is captured and stored:

  • ISO alpha-2 country code (e.g., US, GB, DE)
  • ISO subdivision/region code (e.g., NY, ENG)

What is read from MaxMind and immediately discarded without storage:

  • City name
  • Postal code
  • Latitude
  • Longitude

The two codes are written to two places:

  • benecaster_download_logcountry_code and region_code columns on each download row.
  • benecaster_tokenscountry_code and region_code written once on the subscriber’s first valid feed poll (not updated on subsequent polls).

MaxMind database stays local: The GeoIP database file is downloaded to your server and all lookups run locally. No IP addresses are sent to MaxMind for individual lookups.

To configure GeoIP, see Settings Reference → Tools → GeoIP Database.

Telemetry to the License Server

When you opt in under Settings → Account → Telemetry, Benecaster periodically sends an anonymous usage payload to the Benecaster license server. Opting in is entirely voluntary — both flags default to off.

Base telemetry (benecaster_telemetry_opted_in), when on, includes:

Field What it is
Average episode duration Across all published episodes, in seconds
Total content hours Sum of all episode durations
Show age Days since your first published episode
Setup wizard completed Boolean flag
Web player play count Aggregate count, no subscriber identity
Revenue telemetry opt-in flag Whether you also have revenue telemetry on

Revenue telemetry (benecaster_revenue_telemetry_opted_in), when on, additionally includes:

Field What it is
Estimated MRR Bridge tier price × subscriber count, in cents

This is an estimate — no payment processor data, no transaction history, no subscriber identity is involved. It’s calculated from numbers Benecaster already has: how many active subscribers you have at each tier, and what pricing is configured for those tiers.

The revenue telemetry checkbox is disabled until the base telemetry checkbox is on. Turning off base telemetry automatically clears the revenue flag server-side.

What is never included in telemetry: subscriber names, emails, IP addresses, episode titles, feed URLs, or any content from your episodes.

Web Player Play Beacon

When the [benecaster_player] shortcode renders on a page, it registers plays via a lightweight unauthenticated beacon: POST /benecaster/v1/analytics/player-play.

This endpoint:

  • Increments a per-episode play counter
  • Increments a site-wide aggregate play counter
  • Does not capture subscriber identity
  • Does not store IP addresses (not even hashed)
  • Does not log episode titles — the episode is referenced by internal ID only

Plays counted this way are the “Web player play count” field included in base telemetry, if you’ve opted in.

Transcription Service Add-On Telemetry

When the Transcription Service add-on is active and base telemetry is enabled, six additional fields are included in the telemetry payload:

Field What it is
transcription_provider Provider slug only (e.g., openai, assemblyai) — never your API key
transcription_minutes_api_30d API-transcribed minutes in the last 30 days
transcription_episodes_30d Episodes transcribed in the last 30 days
import_method_distribution Counts of how transcripts arrived: api / file / paste / rss_feed, over 30 days
transcript_edit_rate_distribution Five buckets: never_opened / opened_no_edits / 0–5% edited / 5–20% edited / 20%+ edited
has_custom_prompt Boolean — whether you’ve set a custom transcription prompt

What is never included: transcript text, episode titles, episode IDs, or any content from your audio or transcripts.


Subscriber Data Retention

Configurable Retention Window

You control how long Benecaster retains subscriber personal data via Settings → GDPR / Privacy → Subscriber Data Retention. The default is 90 days after a subscription ends.

Covered by the retention window:

  • Token records for deactivated subscribers
  • Download log rows linked to those subscribers
  • Email log rows
  • Migration patron records from Patreon/Supercast imports

A nightly cron (benecaster_gdpr_prune, 02:00) automatically purges records older than the window.

What Is Never Pruned

benecaster_unsubscribe_log is explicitly excluded from retention purges. This table records that an unsubscribe event occurred. It is retained indefinitely for regulatory compliance — you need to be able to demonstrate that you honored an unsubscribe request, even after the subscriber’s other records are gone.

Analytics Data Retention

Analytics tables (benecaster_subscriber_events, benecaster_analytics_daily, benecaster_download_log) have a separate retention window configured in Settings → Tools → Analytics Data. The default is Forever. This is distinct from subscriber data retention — analytics data may not contain subscriber identity at all (daily aggregates, for example, contain no subscriber references). See Settings Reference → Analytics Data for details on the pruning flow.


Right to Erasure

To delete all data Benecaster holds about a specific subscriber:

  1. Go to Settings → GDPR / Privacy → Delete a subscriber’s data.
  2. Enter the subscriber’s email address.
  3. Click Find subscriber — Benecaster shows you a cascade summary listing every table and row count that will be deleted.
  4. Review the summary and click Confirm deletion.

The cascade covers: tokens, download log, email log, and migration patron records. Unlike the automatic prune, a manual right-to-erasure request also deletes the subscriber’s entry in benecaster_unsubscribe_log — the indefinite-retention exception applies only to automated pruning.

Deletion is immediate and irreversible. There is no recovery path.


Your Responsibilities

Benecaster provides tooling to help you comply with privacy regulations — configurable retention, manual erasure, GeoIP controls, and telemetry opt-ins. But the plugin cannot guarantee compliance on your behalf. You are responsible for:

  • Your site’s privacy policy accurately describing how subscriber data is collected and used.
  • Responding to subscriber data requests (access, correction, erasure) within the timeframes required by applicable law.
  • Configuring retention windows that match your legal obligations in the jurisdictions where your subscribers live.
  • If you are subject to CCPA: understanding your obligations as a “business” under the California Consumer Privacy Act and whether the data Benecaster processes falls within its scope.

If you’re uncertain about your obligations, consult a legal professional familiar with data protection law.