No. It complements them. Complianz reports tell you the trend: opt-in rate over time, region distribution, banner variant performance. SleekView lets you inspect the rows that make up the trend. The two together give privacy and legal teams the full picture: aggregate trend in the reports, specific row-level evidence in the view. Neither replaces the other.

No. SleekView is admin-only and queries on demand. The Complianz banner, scan, and consent capture on the front end are untouched. The view only runs database queries when an admin or privacy officer opens the screen, and SleekView paginates server-side so even consent logs with millions of rows render quickly through database indexes.

We discourage it. Consent records should be append-only for the audit trail to remain credible. SleekView is read-only on these tables by default, which is the correct posture for a regulatory audit surface. If a record is genuinely incorrect, the right path is to add a corrective record, not edit the original. The view supports that workflow naturally.

Yes. Any wp_cmplz_ table is fair game, including the cookie scan results, service definitions, and the document audit tables that Premium adds. A view that joins consent records to the cookie definitions in force at the time can answer questions about which specific cookies a visitor consented to, which is exactly the level of detail many audits demand.

Yes. Each subsite has its own wp_cmplz_ tables, since Complianz installs per site, and each subsite gets its own SleekView. A network admin can switch between subsites to audit each site independently. The per-site data isolation matches the legal reality that consent under one site's policy is not interchangeable with consent under another site's policy.

SleekView runs entirely on your server. No data leaves WordPress. The view does not send consent records to any third party, does not call out to an external API, and does not log to any service outside your hosting environment. This matches Complianz's own self-hosted posture and keeps the consent data within the same trust boundary the original capture happens in.

The plugin has a configurable retention setting. SleekView reflects whatever is in the wp_cmplz_statistics table at the time the view loads. If your retention policy requires a specific minimum, configure that in Complianz settings, and SleekView surfaces the resulting history depth. Reducing retention prunes older rows from view as well, since the view reads from the live table.

Yes. The policy version is captured per consent record, so a saved view filtered by policy version isolates consent under each iteration of the policy. This is essential when a policy update is followed by a re-prompting wave: the before-and-after rows answer the regulator's question about whether consent under the old policy still applies, and SleekView makes the comparison straightforward.