No. Impressions, conversions and contact analytics stay in Poptin where the popup was composed. SleekView Charts reads only the WP-side plugin storage: settings, inclusion rules and any emission audit log. Anything the plugin writes locally is fair game for a card, nothing more.

The account ID and inclusion rules live in wp_options. If the plugin's emission audit is enabled, log rows are persisted in an option array or custom table depending on the version. SleekView reads each storage path and pivots it into named columns for the chart cards.

Yes. Each dashboard respects a post_type filter, so a per-post-type audit dashboard scopes every card to one slug and surfaces emission count, template mix and time trend for that slice. Useful when a campaign was scoped to a single content area.

Settings and rule cards work regardless because they read from wp_options directly. Emission cards require the plugin's audit log to be enabled or a lightweight hook that SleekView samples on the wp_footer action. Without either source, the emission cards show a friendly empty state.

No. Chart queries hit the option store and emission log on read, never on write. Front-end rendering continues to emit the Poptin script through the plugin's own runtime path with no added work, which keeps page-load latency unchanged.

Yes. On a multisite or a staging-plus-production setup, the inclusion rules and the consent flag are values in the Poptin settings option. SleekView's multisite rollup shows them as columns on every site, so drift surfaces as an obvious split in the chart.

SleekView's settings and rule cards keep rendering from wp_options. The emission cards fall back to an empty state with a clear note about enabling the audit, so the dashboard stays useful while ops decides whether to flip the audit on.

Yes. Each saved chart dashboard is scoped by WordPress capability. Marketers see the coverage cards while legal sees the consent flag cards, with each role saving its own filter presets on top of the same Poptin dataset.