Shareaholic stores its app configuration and per-location share button settings in wp_options under shareaholic_settings and related shareaholic_* keys, with per-post overrides written as postmeta on individual wp_posts rows. The plugin's hosted dashboard handles analytics off-site, but the local WordPress install carries the configuration footprint without an admin grid to inspect it.

SleekView reads the shareaholic_* options together with per-post override meta and presents one row per post with effective app, location, and button set columns alongside standard post columns. The Source column flags whether each post inherits the global config or has a per-post override, which is the audit surface relaunches and migrations need.

Shareaholic Pro's analytics live in the hosted Shareaholic service rather than in a local table, so SleekView is honest about its scope: the local configuration and per-post overrides are queryable as a table; off-site analytics still live in the Shareaholic dashboard.

Shareaholic's hosted analytics handle the 'what's being shared' question well, which is why the local WordPress install does not need to duplicate that data. What the local install does need is a queryable view of its own configuration footprint: which posts run which buttons, in which locations, from which source (global default or per-post override). Without that view, coverage audits are guesswork, governance answers are anecdotal, and relaunches inherit years of accumulated per-post overrides nobody can review.

SleekView builds the coverage grid by joining shareaholic_settings with every per-post override meta in the database, presenting one row per post with effective configuration and source. Editors audit relaunches in an afternoon, governance answers cookie-policy questions from a CSV, and maintenance teams bulk-normalise overrides that no longer match policy. The plugin keeps owning configuration; the hosted dashboard keeps owning analytics; the grid owns the local coverage view.