No. The GetResponse cloud dashboard still owns deliverability, opens, and clicks since the sends happen there. SleekView Charts adds the WordPress-side dashboard for submissions, campaign distribution, and signup velocity, the synthesis the default admin does not assemble.

Yes. Even when contacts move to GetResponse on submit, the plugin logs the submission attempt locally with form ID, campaign ID, and timestamp. SleekView reads those local rows to render every chart in the dashboard without an API call.

Yes. If the webform captures placement as a hidden field or referrer URL, SleekView can group submissions by that column. Compare footer, popup, and inline-form performance on a single Bar card.

Yes. Dashboard-level filters apply to every chart card. Filter by a single GetResponse campaign_id and every card scopes to that list, so per-campaign dashboards become one-click switches instead of per-card reconfiguration.

Yes. Aggregations run on indexed columns and avoid full table scans. Hundreds of thousands of submission rows render charts in seconds because the Charts engine uses pagination and indexed joins rather than scanning meta.

Yes. Each chart card exposes its underlying row set, which exports to CSV with active filters applied. The export feeds board reports, attribution tooling, and ad platforms without spreadsheet round-trips.

Yes. Each subsite has its own GetResponse Forms data and SleekView Charts reads the current subsite by default. Network-wide dashboards can be configured explicitly when reporting spans multiple subsites.

It still works. The plugin records the account or API token reference on each form, and SleekView can group by it. Multi-brand setups get one dashboard per account or a combined dashboard with brand on a Pie card.