Only the WordPress-side data the Mautic Integration plugin already writes: identify and event rows from the local log, form-to-segment mappings from wp_postmeta and settings from wp_options. Mautic contacts, segments and campaign definitions are not duplicated into WordPress.

No. Contacts, segments and campaigns stay in the Mautic instance you host, which is exactly where automation should run. SleekView surfaces the WordPress half of the bridge: which event was sent, by which form, to which segment and from which page.

Yes. The plugin writes bridge mappings to each form plugin's standard postmeta location, and SleekView reads all of them. A mixed-form site produces one clean dataset with a source_plugin column for grouping.

Yes. The table reads the WP-side plugin storage, which is identical whether Mautic is self-hosted, on a managed Mautic host or running locally for development. Mautic's own reports remain authoritative on the Mautic side.

Yes. Save a view scoped to segment_id and the table narrows to a single segment. The view can be shared with the marketer or admin responsible for that segment so they open straight into the right slice.

No. SleekView queries options and postmeta on read, never on write. Identify calls and form bridges continue to run through the Mautic Integration runtime path with no added work, which keeps visitor-facing latency unchanged.

Some Mautic Integration plugin versions disable local event logging by default. SleekView shows an empty state on the event rows in that case, and the mapping columns over wp_options and wp_postmeta keep rendering so the view stays useful for audit work.

Yes. Each saved view is scoped by WordPress capability. The WP admin sees the tracking flag and bridge audit while the Mautic admin sees segment_id and event_name, with each role saving its own filter presets on the Mautic dataset.