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 and stores a feed token for them, recorded with a token type of 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").

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.

Listener Support Donations

Donations are recorded whichever mode you run — see Listener Support Overview for the difference between link mode and Stripe mode.

What is stored: the show, the amount and currency, the platform, a transaction reference, the donor’s email address and message when they provide them, and the date. In link mode these values are supplied by the donor when they return to your site; in Stripe mode they come from the completed payment.

Card details are never stored. In Stripe mode the payment runs through Stripe’s Payment Element and card data goes directly to Stripe — it does not pass through your WordPress database. In link mode no payment touches your site at all.

Donors are usually not WordPress users. Anyone can donate without an account, so donation records often have no user attached to them. The erasure request form described below works for them the same as for anyone else, by email address.

You have full access to your donor records. Because donations are stored in your own WordPress database, you can see each donor’s name, email, and message — there is no separate visibility control withholding it from you. Use it for sending a personal thank-you, the same way you would with any other record you hold.

Marketing Consent

Benecaster never sends marketing email itself, and asks nothing on a default install. A consent checkbox appears on the subscribe checkout and the follower signup form only when an add-on asks for one for that show. A donor who ticks the donor mailing-list opt-in also records a yes.

What is stored: one record per person per show — their answer (yes or no), the exact wording of the checkbox they were shown, which form they answered on (subscribe, a free tier on the subscribe form, follow or donation), whether their email address was confirmed, and the time, in UTC. A later answer replaces the earlier one for that show.

Confirmed and unconfirmed answers. The follower form, a guest checkout and the donation form all take an email address anyone could type. An answer given while signed in to that account is confirmed. One given while signed out is stored as unconfirmed until the person proves the address is theirs, by answering again while signed in or by clicking a button that states the answer:

• The follower confirmation email has two buttons. Confirm and follow only follows, and leaves the answer unconfirmed. Confirm and follow, and yes to: followed by the checkbox’s wording does both. This email only goes out on a show with Ask new followers to confirm their email turned on, under Subscriber Engagement.
• The Welcome email carries a Yes to: button for someone who signed up for a free tier while signed out and ticked the box.

An unconfirmed answer never replaces a confirmed one, and a signed-out follower submission doesn’t change an answer from a paid checkout or a donation, so nobody can untick the box with someone else’s address, or tick it for them.

On a subscribe checkout the answer is stored only once the membership exists: a declined card stores nothing.

Outbound Webhook Deliveries

If you send events to another service under Settings → Webhooks (see Outbound Webhooks), Benecaster keeps a log of each delivery so it can retry a failed one and show you Recent deliveries. Most events carry the subscriber’s email address in the request body, so these log entries are personal data. Every entry is deleted after 30 days, whatever its status, and sooner on an erasure request (see Right to Erasure below). What the receiving service does with the data is between you and that service.

Third-Party Scripts on Your Site

Two Benecaster features load a script from another company’s servers. Neither is loaded on a default install, and neither runs sitewide — but where they do run, the third party sees your visitor’s IP address, so both belong in your cookie and privacy disclosures.

Stripe.js — payments. Loaded when a page renders the subscribe form or the account and billing-portal pages. Stripe sets two cookies:

These are payment security cookies, not advertising cookies. Stripe uses them to recognise repeated card attempts from the same browser. They do not track your visitors across other websites and they are not used to profile or target anyone. A cookie audit that mislabels them tends to end in one of two bad outcomes: a privacy policy that describes tracking you do not do, or a podcaster ripping out payments over a misunderstanding.

Benecaster does not store either cookie and never reads them. They are set by Stripe, in your visitor’s browser, and Stripe is the data controller for them.

Where Stripe.js loads is narrower than people assume, which is useful when writing a cookie policy: the script is registered globally but only enqueued at render time, so it loads only on pages carrying [benecaster_subscribe] or the account and billing-portal pages. Never sitewide, never on episode or archive pages that do not carry one of those.

Cloudflare Turnstile — bot protection. Loaded only if you have enabled Bot Protection by saving both Cloudflare keys. On a default install, and on an install where only one key has been saved, nothing is requested from Cloudflare at all.

When it is enabled, Cloudflare receives the visitor’s IP address and their interaction with the challenge. Turnstile is designed to work without tracking cookies, which is much of why it was chosen, but the IP disclosure is real and you should account for it.

Where it loads depends on the donation style you use:

• With the inline form style, the script loads when a page carrying that form is opened.
• With the button or icon styles — including the auto-injected prompt, which defaults to a button — the script loads only when a visitor clicks to open the donation modal. A listener who never clicks never contacts Cloudflare.

Benecaster does not receive or store anything from the challenge beyond a pass or fail on the donation attempt itself.

No consent banner, and no lazy-load switch. Benecaster does not ship either, for Stripe.js or for Turnstile, and neither is planned. If your jurisdiction requires consent before these load, that is handled by your own consent tooling — the plugin will not do it for you, and you should not assume otherwise from the narrow load conditions above.

Download Log

Download logging is opt-in, not automatic — it only records requests for a show (or episode) where you have turned on download tracking (Details → Show Flags, with a per-episode override on the Media tab). See Download Tracking for how to enable it. For a show or episode where tracking is off, no download-log entry is written at all. Where it’s on, each entry 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:

• The download log — a country and region code on each recorded download.
• The subscriber’s token record — a country and region code written once on their 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.

Sent on every check-in, whether or not you opt in. The daily license validation call carries a minimum payload regardless of your telemetry setting:

These counts are sent whether or not you opt in to telemetry, and the reason is worth knowing. Your plan limits how many active shows and subscribers you can run, and those limits are checked on the license server against the figures your site last reported. Gated behind telemetry opt-in, they would read zero for everyone who opted out — so the limits would not be relaxed for them, they simply would not be evaluated. Bare counts carry no personal data and nothing about who your subscribers are, so they are sent unconditionally rather than leaving your plan’s limits unenforceable.

✅ Your license key is not sent. It is not in the validation payload and not in the failure-alert payload. The request is authenticated by the per-show site token, which is the only credential the license server reads. Base telemetry (benecaster_telemetry_opted_in), when on, adds:

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

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.

Transcription add-on, when installed and active, adds a further block — base telemetry must also be on:

Nothing in this block includes transcript content. It reports how much was transcribed and how much editing followed, never what any transcript says.

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:

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
• Subscriber history (joined, cancelled and tier-change events) for those subscribers, which is anonymised rather than deleted, so your growth and churn counts don’t change
• Built-in membership payment records for those subscribers, which are anonymised rather than deleted: the amounts and dates stay as your financial record, and the link to the person is removed
• Their entries in Benecaster’s sales-tax records (see Right to Erasure below), which are removed outright
• Their entries in the outbound webhook delivery log, which are removed outright (every entry is also deleted after 30 days regardless)

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

Sent Email

Benecaster keeps a record of each email it sends, and a copy of the email itself — which can include a subscriber’s private feed URL or a sign-in link — so it can troubleshoot delivery and resend a message. These are kept for 180 days, then a daily job deletes them. Emails still waiting to be sent are never deleted. This window is separate from the subscriber retention window above; developers can change it with the benecaster_email_log_retention_days filter.

What Is Never Pruned

The unsubscribe log is explicitly excluded from retention purges. It records each opt-out and each opt back in, and how it was made: an email’s unsubscribe link, the one-click button in a mail client, or the listener’s own Email preferences on the account page. 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.

Episode purchases (the Episode Sales add-on) are excluded too, for a different reason: they’re access someone paid for outright, not aging subscriber activity. The nightly retention sweep never removes a purchase record — only a right-to-erasure request does, below. Don’t assume a quiet buyer’s purchases get tidied away with everything else.

Marketing-consent answers are kept too. The record is your proof that consent was given, and a listener who has gone quiet has not withdrawn it. Only a right-to-erasure request removes it.

Analytics Data Retention

Analytics records — subscriber events, daily aggregates, and the 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.

Donor Data Retention

Donation records have their own window, set under Settings → Listener Support → Donor data retention. The default is to keep donations forever, and that default is deliberate: donations are financial records, and most podcasters need them for their accounts long after the subscriber data around them has aged out.

Set a window in days and a nightly sweep purges donation rows older than it. Consider your bookkeeping and tax obligations before turning this on — the deletion is permanent, and this is the one retention setting where the shortest window is unlikely to be the right one.

Billing Addresses

Benecaster does not store your subscribers’ billing addresses.

When a show collects tax on the built-in membership system, subscribers enter a billing address in a Stripe address form on your signup page — tax has to be calculated from somewhere. The address passes through your site’s server on its way to Stripe, so the tax can be shown before they pay, and is not saved or logged there. It stays with Stripe, and appears on the Stripe invoice your subscriber receives, which carries your business details because you are the merchant. The same goes for an address a subscriber updates later from their account page.

This is deliberate. A home address is more precise than anything else Benecaster keeps — elsewhere the plugin reads a subscriber’s city, postal code and coordinates during a GeoIP lookup and discards all three, retaining only country and region. Keeping addresses would also mean keeping them for years, since tax rules require invoices to be retained long after a subscription ends.

What this means for your privacy policy: you still need to account for the address, because it is collected in the course of your transaction — but you are describing data held by your payment processor, not by your website. Your existing disclosure about Stripe as a payment processor may already cover it. Worth a look rather than an assumption.

See Tax and VAT on Podcast Subscriptions.

---

Right to Erasure

The Erasure Request Form

Put [benecaster_erasure_request] on your privacy page. Anyone can use it, whether they are a subscriber, a follower or a donor: they type an address, and WordPress emails its own Confirm Action: Erase Personal Data link to it. Once they confirm, the request waits under Tools → Erase Personal Data until you complete it. Nothing is erased before then, so the billing check below and other plugins’ data get a human look.

The page shows the same thing for every well-formed address, so the form can’t be used to test who is on your list. It is limited to 3 requests per address and 5 per visitor an hour, and it uses Turnstile when both Listener Support keys are saved. Signed-in members also get an Erase my data section on their account page.

Deleting Data Yourself

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 Delete subscriber data. The button turns red and reads Confirm delete; nothing has been deleted yet.
4. Click Confirm delete. The result lists what was removed, category by category.

The cascade covers: tokens, download log, email log, the person’s stored and queued emails (including any still waiting to be sent, so nothing more goes to them), migration patron records, their entries in Benecaster’s sales-tax records, their entries in the outbound webhook delivery log, and their marketing-consent answers. The subscriber’s history (joined, cancelled and tier-change events) is anonymised rather than deleted: the events stay so your counts don’t change, and the link to the person is removed. The result lists it as Subscriber history rows anonymised: N. Episode preview links you sent to that address keep working, but the name and email they were sent to are removed; the result’s last line is Preview links anonymised: N, shown even when it is 0. Their built-in membership payment records are treated the same way: each payment, its amount and its date stay as your financial record, and the link to the person is removed. Unlike the automatic prune, a manual right-to-erasure request also deletes the subscriber’s entry in the unsubscribe log — the indefinite-retention exception applies only to automated pruning.

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

Nothing is deleted while the person is still being billed. If they hold a built-in membership that Stripe can still charge (active, in a free trial, past due, paused, or set to cancel at the end of the current billing period), if a membership plugin still counts them as an active member of a show, or if a show’s membership plugin is deactivated so there is no way to ask it, the screen deletes nothing. Instead it shows a red box headed Nothing was deleted: this person is still being billed., with one line per show giving the reason and what to do, ending …then delete their data again. Cancel the membership, then delete their data again. These are the same checks Erase Personal Data runs, described below. An email address with no WordPress account on the site has nothing to bill and is deleted as usual. The nightly retention sweep is not affected by this check.

WordPress’s Built-In Export and Erase Tools

Benecaster also registers with WordPress’s own privacy tools, so Tools → Export Personal Data and Tools → Erase Personal Data work for subscribers without you using the dedicated screen above.

Export Personal Data returns everything Benecaster holds tied to the requested email: tokens, subscriber history, membership and subscription records, badges, donations, sent emails, unsubscribe records, and download history — plus a Benecaster Purchased Episodes section (Episode Sales add-on): the show, what it gave access to, the date granted, and the expiry, including purchases that have since expired. Lifetime access shows Never rather than a date.

If the person has answered a marketing-consent checkbox, the export includes a Benecaster Marketing Consent section, one entry per show: the show, their answer, the wording they were shown, where they answered (Subscribe form, Subscribe form, free tier, Follow form or Donation form), whether their email address was confirmed, and when the answer was recorded.

If any outbound webhook deliveries about the person are still in the log, the export includes a Benecaster Webhook Deliveries section: the event, its delivery status and the date for each. The body that was sent is not included; it holds only the person’s own email and identifiers already listed elsewhere in the export.

If the person has bought buy-ups (the extras you sell beside a membership), the export includes a section headed Benecaster Extras, the name subscribers see for buy-ups: the show, the buy-up’s name (under Extra), its status, its period dates, whether it is set to cancel at the end of the period, and when it was cancelled. Stripe’s IDs are not included.

If you have stored or queued emails to the person, the export includes a Benecaster Stored Emails section: the show, the email type, the subject, its status, and when it was queued, scheduled and sent. The body and headers are never included, because an email can hold a private feed URL or a sign-in link.

If you have sent the person an episode preview link, the export includes a Benecaster Episode Previews section: the episode, the name it was sent to, its status, when it was sent and expires, how many times it was viewed and when it was last viewed.

If the person has paid for a built-in membership, the export also includes a Benecaster Membership Payments section, one entry per payment: the show, the tier, the amount paid with its currency, the amount refunded (blank when nothing was refunded), and the date it was paid, in your site’s own timezone. Stripe’s own IDs for the payment are not included.

The Benecaster Emails section lists one entry per email Benecaster logged for that address, with its show, type, subject, Status and Date. Its description reads “Emails we sent you, and emails we did not send and why — usually because you had opted out. Opt-outs are recorded so they can be honoured.” The statuses are:

• queued — waiting its turn to be sent.
• sent — handed to your site’s mail system. A message that bounces later still reads sent, because Benecaster never hears about it.
• failed — could not be sent after three attempts. The mail server’s error message is not included: it is about your server, not the person, and can carry server details.
• suppressed — never sent. These entries have a Why it was not sent row, in words: You had opted out of all emails from this show., You had opted out of announcements and updates from this show., You had opted out of new-episode emails from this show., or The site stopped this email. It was not because of an opt-out of yours. when an add-on or custom code on your site refused it.

The Date is when the email was sent or, for a suppressed one, when it was refused. Emails logged before Benecaster recorded these statuses all read sent, whatever happened to them.

If the person has been notified of a tier or buy-up price change, the export also includes a Benecaster Price Changes section — one entry per change they were notified of, including a change since withdrawn or superseded by a later one. Each entry shows: which tier or buy-up changed, the old and new price, when they were notified, the date they’d first be charged the new price, whether a reminder was sent (a date, or “No”), and the outcome in plain words — moved to the new price; not yet applied; left on the current price (with the reason: their membership had ended, moved tier, was paused, or had a payment problem); not applied because the subscriber switched to a different billing period before the change took effect; not applied because the subscriber cancelled their switch to this billing period; not moved because the update failed; or not applied because the show withdrew or replaced the change — plus the date they were moved and any error details. Dates are shown in the site’s own timezone. Only people matched to a WordPress account are included; a price change sent to someone without an account has nothing to match against.

If the person was imported from another podcast platform through the Migration Wizard, the export also includes a Benecaster Platform Migration section — one entry per show they were imported for: the show, the previous platform, their email and name as imported, the tier they held there, and the date they joined there. That join date is shown exactly as it was imported, never converted or shifted to your site’s timezone — it describes an event on the other platform, not on yours. The entry also shows their migration status and the invitation, completion, and grace-period-end dates, in your site’s own timezone. Someone matched only by email — imported before they ever created a WordPress account — is included the same as a matched account. The payment-setup link they were sent and any private notes you left on the import are never exported.

Before any of the erasure below runs, Benecaster checks whether the person still has a membership that can be billed. If they hold a built-in membership subscription that Stripe can still charge — active, in a free trial, past due, paused, or set to cancel at the end of the current billing period — the whole request is refused and nothing is erased. The same happens if a bridge plugin (MemberPress, WooCommerce Subscriptions, Paid Memberships Pro, or Restrict Content Pro) still counts them as an active member of a show, or if a show’s configured membership plugin is deactivated, since there’d then be no way to ask it. Each plugin’s own idea of “active” decides this: a WooCommerce subscription on hold after a failed payment, a MemberPress renewal being retried, and an RCP membership that’s expired but still being retried do not block erasure, while a fixed-term PMP level does.

When a request is refused this way, WordPress shows Personal data was found for this user but was not erased, with one line per show telling you what to do — cancel the Stripe subscription (settle a past-due balance first, or cancel immediately rather than waiting out a subscription already set to cancel at period end), or cancel or reactivate the relevant membership plugin. Once that’s done, run the same request again. Until then the request stays at Confirmed (or Pending, for a forced erasure), and WordPress’s “your request has been completed” email is never sent — telling the person why is on you, since WordPress doesn’t send a refusal email either. None of this blocks a hand-granted or comped membership with no Stripe subscription behind it, an ended membership, or someone with no WordPress account at all, and it doesn’t stop any other plugin’s own eraser from running.

The reason the whole request is refused, rather than just the parts that would otherwise stay: erasing feed tokens and detaching a subscription from the account while Stripe keeps billing would leave the person paying for something they can no longer access and can no longer cancel themselves from their account page.

Erase Personal Data does not treat every category the same way, because some of it is also the podcaster’s own financial or feed-delivery record:

Episode purchases don’t appear on the podcaster-facing Settings → Your Data export in Benecaster itself — that sheet belongs to the Episode Sales add-on, which has the product names and prices this page doesn’t.

Anonymised means the identifying link (the WordPress user, and any denormalized name or email) is stripped from the row, while the row itself, its timestamps, and its non-identifying counters or state stay in place — this is how a donation or a download count survives an erasure request rather than being removed outright.

Deleting a Subscriber’s WordPress Account

Deleting someone’s WordPress account (Users → Delete, or wp user delete) is treated as a request to remove them. Benecaster does three things, in this order:

1. Cancels their built-in membership billing. Any Stripe subscription that can still charge them is cancelled immediately, with no refund and no cancellation email. If you want to refund them, do it in Stripe.
2. Switches off their feed. Every Benecaster feed link the person had, on every show, stops working, free follower links included.
3. Removes their data as Delete a subscriber’s data does above, episode purchases included, and also anonymises five kinds of record that Erase Personal Data anonymises too: their built-in membership subscriptions, their buy-ups (any still running is ended), their badges, their price-change records (including any payment error text) and their Listener Support donations (name, email and message cleared; amount and date kept). Nothing is left pointing at an account that no longer exists.

Delete a subscriber’s data and the nightly retention sweep leave those five linked to the person on purpose: both keep the WordPress account, so the records still have someone to belong to. Delete a subscriber’s data does clear the name and email from episode preview links sent to the person, as both erasure routes do.

Unlike Erase Personal Data, an active membership does not block this, because WordPress does not wait: the account is deleted either way, so Benecaster cancels the billing instead of refusing.

If Stripe cannot be reached, the account is still deleted and the subscription is left running. A critical notice in your notification bell names the show and the Stripe subscription: A deleted WordPress account had a paid membership on [show], and Benecaster could not cancel its Stripe subscription ([subscription ID]). Cancel it in your Stripe Dashboard, or Stripe will keep charging the card. Cancel it there.

A membership plugin keeps charge of its own billing. Restrict Content Pro and WooCommerce Subscriptions cancel the person’s subscription themselves when the account is deleted. Paid Memberships Pro cancels only if you tick its cancel option on the Delete Users screen, so tick it, or PMPro keeps charging someone whose feed has stopped. See Paid Memberships Pro Setup.

Donors Without an Account

A donor who gave without ever creating an account asks the same way as anyone else, through the erasure request form. When you complete the request under Tools → Erase Personal Data, every donation record for that address is anonymised: their name, email and any message are cleared, while the amount, currency and date are kept as your financial record. Their donations’ entries in the subscriber history are unlinked from any WordPress account too, keeping the amount, currency and date.

Because the confirmation link goes to the address being erased, nobody can anonymise someone else’s donation history by guessing at their email.

Developers: the benecaster_donor_data_erased action fires whenever donation records are anonymised: when an administrator completes a request under Tools → Erase Personal Data, and when a WordPress account is deleted. It carries the email and the number of rows anonymised, so you can mirror the change into a CRM or mailing list. It fires with a count of 0 too, so check the count before acting on it. See Clean up external records when a donor requests data erasure.

---

Erasing Your Own Data From Benecaster.com

Everything above is about your subscribers’ data, on your WordPress site. Your own account data on benecaster.com — your license, your invoices, your support history — is a separate request, made by contacting us.

An erasure of your benecaster.com account does not delete everything, and we would rather you know why before you ask.

The right to erasure does not override a legal obligation to keep records, so the financial rows stay — kept whole rather than anonymised, because an invoice that cannot say whose it is is not an invoice. We will tell you exactly what was retained when we action your request. Full detail is in the Privacy Policy.

---

Analytics Dashboard and the Feed Request Log

With the Analytics Dashboard add-on, the feed request log’s revoked-link checks are shown per person to your site’s administrators. Its win-back page lists each cancelled subscriber still checking their feed by WordPress name and email, with their last check-in, check-ins a day and app, and its Export CSV writes those names and emails to a file you download. Nothing new is recorded or kept, and nothing leaves your site. The add-on’s Your Data sheets hold only counts.

Backups and Exports

Backups and exports hold personal data. That includes the Email Editor’s Email Opt-Out List sheet, which holds subscribers’ email addresses. By default they sit in wp-content/uploads/benecaster/, inside the web root, with unguessable file names. Where your host gives you a writable folder outside the web root, name it with the BENECASTER_PRIVATE_DIR constant and new files go there; see Backup and Security Best Practices. Uninstalling with data removal on, and Reset Plugin Data, remove the benecaster/ folder there too.

Suggested Privacy Policy Text

Benecaster contributes suggested paragraphs to your site’s privacy policy, one per feature you actually have active — download logging, Listener Support donations (link or Stripe mode), built-in membership, free follower signup, and email logging. A fresh install with everything off contributes nothing.

Find it at Settings → Privacy → Policy Guide (WordPress core’s own privacy policy tool). This text is a starting point, not a finished policy — it is suggested text, and you still own your privacy policy and must review it. Benecaster does not write your privacy policy for you; it drafts the parts that describe what Benecaster itself does, so you don’t start from a blank page for those sections.

Developers: an add-on can append or remove its own {heading, content} entries before the combined text reaches WordPress via the benecaster_privacy_policy_sections filter.

Email Communications

Once your site has sent a subscriber an email, the suggested text includes an Email Communications paragraph:

“When we send you an email — such as a welcome message, a receipt or a renewal reminder — we keep a record of it: the type of email, when it was sent or why it was not, and its delivery status, along with a copy of the email itself. We use these to troubleshoot delivery problems, resend a message you did not receive, and honour unsubscribe requests. We delete them after 180 days, and sooner if you ask us to erase your data.”

The number of days follows your site’s email retention period (see Sent Email above), so the policy never promises a shorter window than your site keeps. If a developer sets the period below one day with the filter, which keeps sent email until it is erased, the last sentence reads “We keep them until you ask us to erase your data.” instead.

Paid Subscriptions

If built-in membership is active on your site, the suggested text includes a Paid Subscriptions paragraph:

“We store your subscription status, tier, and billing history. If the price of your subscription changes, we also record that we told you about it, when, whether we sent a reminder, and what happened to your subscription as a result. If you ask us to erase your data, we keep that record but remove anything that identifies you, so our record of the price change stays complete. We can only erase your data once your subscription has ended. While it is active, paused, in a free trial or has a payment outstanding, we need that data to provide the subscription you are paying for, so please cancel it first and then ask again.”

The last two sentences describe the refusal behavior above in plain language for your subscribers, and the middle two describe how a price-change notice survives an erasure request without identifying anyone — see Price Change Considerations for more on that record.

This paragraph is suggested text you can edit like any other paragraph on the Policy Guide screen, and it only appears for a show billed through built-in membership. A show gated by a bridge plugin (MemberPress, WooCommerce Subscriptions, PMP, RCP) doesn’t get it — that plugin already discloses its own billing data and its own erasure limits, and Benecaster doesn’t duplicate them.

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.
• Accounting for the billing address your subscribers give at checkout if you take payment through the built-in membership system. Benecaster does not store it — Stripe does — but it is still collected in the course of your transaction. See Billing Addresses above.
• Disclosing the third-party scripts your site loads and the cookies they set — Stripe’s __stripe_mid and __stripe_sid on your payment pages, and Cloudflare Turnstile on your donation form if you have enabled Bot Protection. Benecaster neither sets nor reads them, but they run on your domain and your visitors meet them there. See Third-Party Scripts on Your Site above.
• Obtaining consent for those scripts if your jurisdiction requires it. Benecaster ships no consent banner and no lazy-load option for either.
• Meeting anti-spam requirements (such as CAN-SPAM) for the emails your site sends — including a valid business or postal address where the law requires one. Set it once per show under Settings → [Show] → Emails → Business address (or on the Details step of the setup wizard when you create the show), and Benecaster adds it as its own line in the footer of every email that show sends. Leave it blank and no address line is shown — the plugin does not add one for you.
• 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.