BuddyPress Activity Social Share keeps its data inside the BuddyPress schema. The parent activity row sits in bp_activity with user_id, component, type, item_id, and date_recorded. The plugin then writes a per-network share count back into bp_activity_meta with keys like bp_activity_share_facebook, bp_activity_share_twitter, bp_activity_share_linkedin, and bp_activity_share_whatsapp, plus an aggregate bp_activity_share_count per activity.

SleekView Charts reads those tables as a regular chart source. Each card picks a meta key or column to group by (network, user, date, component) and aggregates with Count, Sum, Average, Maximum, or Minimum across the rows. Cards refresh against the live tables, so a share fired a minute ago appears on the next card refresh without any export step in between.

A typical setup combines a Number card for total shares this week, a Pie card for the per-network share split, an Area card for daily share activity, and a Bar card for the activities that pulled the most shares. Community managers finally see whether the share feature is actually moving the content out of BuddyPress or quietly sitting unused.

A share counter on each activity is invisible at scale. Five hundred posts each with a share button means five hundred numbers to scroll past, and the team has no way to know whether the feature is actually getting used. BuddyPress Activity Social Share stores per-network counts in bp_activity_meta against the parent activity row, so the data is sitting there ready to be aggregated.

SleekView Charts reads the same meta, joins it back to bp_activity for user, date, and component, and renders Number, Pie, Bar, and Area cards on one dashboard refreshed against the live data. The team finally sees the total share volume, the per-network split, the most-shared activities, and the daily trend in one view. The share feature stops being a quiet button and starts being something the community can manage like any other engagement signal.