In its own dedicated tables for popup definitions, per-popup stats and locally captured subscribers. SleekView reads these directly without going through plugin abstractions, which keeps queries fast and lets you compose cohorts the default admin cannot render.

Yes. The view joins to the popup-definition table on popup_id so the column shows a readable popup name instead of an integer. The join is a config option in the agent UI, not custom SQL.

Yes. SleekView writes through the plugin's data layer where exposed, so any registered actions on subscriber updates fire normally. ESP integrations downstream of those actions behave the same as if you had edited from the Supsystic admin.

Source-page tracking depends on what your install records. If the data is present in any subscriber field, SleekView pivots it into a column. If the install does not capture source pages, no view can invent that data.

No. SleekView is a queryable view of what is already in your WordPress database. ESP integrations still happen through Supsystic's standard sync. SleekView is the audit, cohort and export layer over the local store, not the live capture or send path.

Yes. Inline edit lets you blank out email, name and consent fields directly. Combine with a saved filter for 'right-to-be-forgotten requests this month' and the workflow collapses into a single screen.

Group the subscriber view by email. Rows that match across multiple popups surface together with a popup-list column showing every popup that captured them. Useful before pushing to an ESP that does not tolerate duplicates.

Yes, on a per-site basis. Each site keeps its own Supsystic tables and SleekView builds views against the local rows. Cross-site rollups need a network-level data join, which is a separate setup.