Novashare Pro stores share counts as postmeta (novashare_share_count_facebook, novashare_share_count_pinterest, novashare_share_count_total) and logs click events to its own wp_novashare_clicks table with post_id, network, location, and timestamp columns. The plugin's settings page configures buttons; its built-in stats panel shows aggregates. There is no row-level grid that joins both data sources to wp_posts.

SleekView reads the novashare_* meta keys and the wp_novashare_clicks table together, surfacing each post with cached counts, click totals, and per-network columns alongside title, author, and post type. The Cache freshness column reads novashare_share_count_updated so editorial knows whether a number is current.

Inline edits on the editorial side (review status, refresh-by date, owner) live as SleekView-managed meta keys that never collide with the novashare_* namespace. The plugin owns its keys; SleekView owns its annotations alongside.

Novashare Pro is unusual in that it captures both cached share counts and live click events. The first is what other plugins call 'share data' and it lives in wp_postmeta as novashare_* keys. The second is what other plugins skip entirely and it lives in wp_novashare_clicks with row-level granularity.

The plugin's own stats panel surfaces aggregates of both, which is fine for the executive overview and not enough for editorial or reporting work that needs to slice by author, post type, or date. SleekView turns both data sources into one queryable grid: per-network share columns from postmeta, 30-day click totals from the clicks table, and a freshness flag for the cache. Editorial sees cached counts vs actual clicks in the same row, which is the comparison that separates 'shared but not clicked' from 'clicked but not shared' and points to entirely different follow-up actions.

Marketing exports the cohort, growth keeps tabs on placements, and the plugin's own panel keeps doing the executive summary. The grid is where the rows live.