WP Subscribers is one of the rare opt-in plugins that doesn't outsource the list to an ESP. Subscribers go into a plugin-prefixed custom table, registered-user opt-ins are tracked through wp_usermeta, and lead-magnet download events end up in the same prefix. The two stores answer different questions but describe the same person, so the plugin's native admin shows them as separate reports. SleekView unions them on email and presents a complete subscriber row.

The columns that matter for newsletter operators are source form, lead magnet, confirmation state, and join date. Source form tells you whether the subscriber came from the sidebar, the footer, or a lightbox; lead magnet ties the opt-in to the offer that drove it. Sort by joined-date among pending rows and you have the cohort that opted in but never confirmed, which is exactly the audience for a re-engagement send or a cleanup pass. The native UI surfaces these values, but only one report at a time.

For GDPR data-subject responses, the unioned row is the artifact: source, lead magnet, confirmation, send history, all keyed on a single email. SleekView produces it without writing custom SQL. The duplicate-detection column flags the cases where the same email exists in both the public table and the registered-user usermeta, with a precedence rule (registered usually wins) so a merge action is unambiguous. Bulk-confirm and CSV export with active filters preserved round out the daily-use surface.

Self-hosted opt-in plugins solve a real problem (no ESP fees, no list-syncing, no third-party privacy footprint) but they introduce a subtler one: the operator becomes the database administrator. A list managed inside an ESP comes with native tools for source attribution, confirmation cohorts, lead-magnet performance, and duplicate management. WP Subscribers does store the data needed to answer all those questions, but the storage is split between a plugin-prefixed table and wp_usermeta, and the native admin shows them separately.

The result is that newsletter operators end up writing one-off SQL or living with reports that don't quite line up. The pending-confirmation cohort is the most concrete example: the plugin will tell you how many pending rows exist, but answering "who opted in three weeks ago and never confirmed" requires joining the join-date column with the confirmation column and sorting. That's exactly the kind of question SleekView turns into a saved view.

Pair it with the duplicate-across-stores detector and the GDPR data-subject export, and the operational floor under the self-hosted approach finally matches the ESP comparison.