The Hyperise plugin for WordPress is a thin bridge to the Hyperise SaaS. The cloud handles personalization image generation, visitor identification and CRM integrations. WordPress stores the account ID, API token and tracking domain in wp_options, registers shortcodes that render personalized assets, and writes block attributes to wp_postmeta when the Hyperise block is used.

The plugin's settings screen confirms the account connection and exposes a few feature toggles. It does not list which posts embed which Hyperise asset, which tag is referenced most, or when each embedded page was last touched. The data is in wp_posts, wp_postmeta and wp_options, but a content lead wanting to retire a sunset asset still ends up running database queries by hand.

SleekView reads each embed as one row. Asset ID, asset type, parent page URL, hyperise_tag and last edit sit next to author and post status. Filter to a specific tag to find every page referencing it, sort by last modified to surface stalled campaigns, bulk-edit to repoint embeds before retiring an asset on the Hyperise side.

Hyperise is fundamentally a SaaS tool with a thin WordPress shim, but the WP side carries the personalization that visitors actually see. A tag wired to an archived asset renders nothing. A page that lost its embed during an editor mistake delivers a generic experience to a buyer the team assumed was being addressed by name.

The default plugin admin focuses on connecting the account, not on listing every embed across the site. SleekView turns the parsed shortcodes and block attributes into one table, so a content lead can sort, filter and repoint in minutes instead of running ad-hoc database queries. The data is already in wp_postmeta, post_content and wp_options, the table surface makes it operational.