Paid Memberships Pro keeps its operational data in two custom tables: pmpro_memberships_users stores one row per user-membership pair with status (active, expired, cancelled, admin_cancelled), level ID, start date, and end date, and pmpro_membership_orders stores every transaction with subscription_transaction_id linking renewals together. Membership levels themselves live in pmpro_membership_levels, and discount codes plus their usage live in pmpro_discount_codes and pmpro_discount_codes_uses.

PMPro's default admin gives Members and Orders separate screens, with reporting in a third tab. Joining a member to their lifetime-spend total or their last-order outcome means either jumping between screens or running custom queries through the Reports module. The PMPro Multiple Memberships add-on creates additional rows in pmpro_memberships_users — one per active membership per user — which complicates the default member view further because the same user appears multiple times.

SleekView reads both tables directly, joins on user_id, and aggregates orders per member for a single member-centric view with level, status, lifetime spend, last-order date, and join date as proper columns. Multiple-memberships installs render as one row per membership with the user_id grouping intact.

Paid Memberships Pro is popular because it does its core job well — member capture and access control — but its admin treats members and orders as two separate concerns. Operationally that's wrong: every retention question, every dunning workflow, and every cohort analysis needs both tables read together. Did this member's last order fail? Is their membership still active despite that? How much have they paid since signup? PMPro stores the data to answer all of those, but reaching it from the default admin means the Reports module, exports, and SQL.

SleekView's joined view collapses the two tables into one workspace where the row-level question is one filter away. Finance teams running monthly close, support handling chat queries, and growth teams building cohort retention analysis all benefit from the same simplification: one screen instead of three. For installs running PMPro Multiple Memberships or Recurring Subscriptions, the workspace adapts automatically — multiple-memberships rendered as one row per membership, recurring renewals grouped by subscription_transaction_id.