The Smartlook WordPress plugin writes its project key, the post-type allowlist, and the consent-plugin bridge state to wp_options under smartlook_settings. Per-post opt-outs save into wp_postmeta as _smartlook_track, and any per-template overrides land under the same prefix. The default Smartlook settings screen exposes the global toggle and project key but no inventory of which pages have overrides.

SleekView reads both the options row and every post carrying a Smartlook postmeta key into one filterable grid. Project key, allowlisted post types, and per-page opt-outs become first-class columns. Editors filter to the posts that are excluded, sort by last edited to find recent override changes, and bulk-toggle _smartlook_track across a category in one motion.

Smartlook's own recordings, funnels, and events live in Smartlook's dashboard, which is the right place to read them. SleekView only handles the WordPress configuration: which pages opt in, which opt out, and which override happened when. That is what compliance reviews and tracking audits actually need.

Smartlook focuses on what happens after the session lands in their cloud (recordings, funnels, events) and the WordPress plugin handles only the front-end loader and a few per-post toggles. That split is sensible until a year of campaigns, compliance reviews, and template changes have buried dozens of override decisions in wp_postmeta that nobody remembers. The default plugin admin shows the global toggle but no inventory of what was overridden, by whom, or when.

SleekView treats the Smartlook options row and the _smartlook_track postmeta as one queryable surface. Compliance reviewers can verify billing and legal pages remain excluded without opening each one. Product ops can confirm onboarding funnels are still firing.

Implementation consultants stop relying on raw SQL to diagnose missing recordings. Smartlook's analytics stay where they belong. SleekView only makes the WordPress configuration legible at the scale the team actually operates.