The Poptin WordPress plugin is a thin connector. It stores the Poptin account ID, the inclusion rules (which post types load the tag, which URLs are excluded) and the consent gating flag in wp_options. When the audit option is enabled, each front-end load that emitted the Poptin script writes a row to a small emission log with timestamp, post type, template and status.

The default plugin admin renders the account field, a connect button and a few inclusion toggles. Useful for setup. Limited for the recurring question marketers, ops and legal ask: which post types are firing the script today, did a deploy drop a hook, is consent gating set correctly across environments. Each answer sits in the option store and emission log already, behind a screen that was not designed to aggregate.

SleekView reads the Poptin plugin option and the emission log directly. The rules view surfaces post type, exclusion pattern and consent flag as row-level columns. The emission log lands in its own view with timestamp, post type, template and status, sortable and filterable. Filter to one post type, save the view as a recurring coverage audit. Same plugin storage, presented as the workspace the data deserves.

Poptin owns the popup composer, the trigger rules and the conversion analytics on the SaaS side, where they belong. The WordPress plugin holds the embed surface: account ID, inclusion rules, consent flag, whether the footer hook still fires after a theme rebuild. Treating that surface as a toggle screen leaves coverage audits as a manual chore that quietly stops happening.

Treating it as a sortable, filterable table makes a coverage review a one-minute job. Marketing sees the post types actually emitting. Legal sees the consent flag at a glance.

Ops catches a dropped hook the same week instead of waiting for the Poptin impression curve to flatten. Same option store and audit log the plugin already maintains, surfaced as the workspace the data deserves.