Public subscribers go into a custom table (typically wp_subscribe2) with email, IP, time and confirm code. Registered users opt in via the s2_subscribed usermeta key, with related keys for excluded categories, format and frequency. SleekView reads both directly so the merged view is a faithful representation of who is actually subscribed.

Yes. Build a view that unions both sources keyed on email, with a precedence column showing which side wins (registered usually does because that user has richer preference data). The deduped result is what most teams want before exporting to an ESP, since hosted ESPs treat email as the unique key by default.

Yes. SleekView writes through Subscribe2's existing functions where they exist (confirm, delete, subscribe, unsubscribe). Direct table writes only happen for fields the plugin treats as plain data with no associated hooks. That separation keeps custom integrations on top of Subscribe2 working when an audit edit fires.

Subscribe2 stores excluded categories in usermeta with a known key. SleekView surfaces it as a column you can edit; the plugin reads usermeta on send, so the next digest respects the new exclusions. Bulk-editing exclusions across many users at once is one of the most useful operations the merged view enables.

Yes. The format and frequency are stored in usermeta. Add them as columns to your view, sort by frequency, and you will see who is on which schedule. Most sites have a per-post crowd and a digest crowd; the column makes that mix visible and editable in bulk.

That token is rendered by the plugin at request time; it does not store data. SleekView focuses on subscriber rows, not on the public form HTML. To audit where the token is used in posts, the agent UI can scan post_content for the literal token string and return a separate report.

Subscribe2 HTML stores the same kinds of data in the same tables, plus a few extra usermeta keys for HTML-specific preferences. SleekView reads both shapes; if a usermeta key is present, it appears as a column. Sites that have not upgraded see a smaller column set, which is the expected behavior.

WordPress deletes that user's usermeta on account deletion, including s2_subscribed, so the registered-side row disappears. If the same email also exists in wp_subscribe2 as a public subscriber, that row remains. SleekView's merged view reflects this honestly: the user vanishes from the registered side and stays on the public side until explicitly purged.