Leaky Paywall stores subscriber state primarily as wp_usermeta keyed by _issuem_leaky_paywall_ (subscriber level, plan ID, payment gateway, payment status, payment date, plan expires, paid amount). Free-trial access counts are stored as transients per visitor and don't typically persist long-term. Restricted content rules live in wp_options under the plugin's settings group.

The default admin shows a subscribers screen with limited columns and a settings screen for restriction rules, both decoupled. Cross-cutting questions like which subscribers are in the renewal window for a given plan or which paid subscribers have payment status mismatches require either scripting or per-user clicking.

SleekView reads wp_users joined to wp_usermeta filtered by the Leaky Paywall meta key prefix and exposes every subscriber attribute as a column: level, plan, payment status, paid amount, payment date, expiry. Inline edits route through update_user_meta() so any hooks the plugin registers fire.

Publication paywalls live on retention, which means renewal-window planning, lapsed-subscriber win-backs, and per-level cohort analysis are bread-and-butter operations. Leaky Paywall stores all the data those operations need, but the default subscriber screen surfaces only the basics. The rest lives quietly in wp_usermeta under the _issuem_leaky_paywall_ prefix, accessible to scripts but not to ops teams.

SleekView turns those meta keys into proper columns. Revenue ops can see exactly which subscribers expire next month and which have payment status mismatches with the gateway. Marketing can segment subscribers by level for upsell campaigns.

Support can look up a subscriber's full state during a chat. The plugin's underlying storage model doesn't change. SleekView just gives the team the queryable workspace that subscriber operations actually need.