Glew syncs WooCommerce orders to its own warehouse using the REST API against wp_posts (post_type=shop_order) and wp_postmeta (or HPOS wp_wc_orders). The hosted product then runs cohort retention, RFM segmentation, and SKU-level reports that the stock WooCommerce admin cannot.

SleekView reads the same tables in place. Orders, refunds, customers from wp_users, and line items from wp_woocommerce_order_items join into one queryable surface inside WP Admin. RFM-style filters (recency, frequency, monetary value) become column expressions; cohort views group customers by first-order month against a chosen retention window.

Glew's hosted dashboard remains useful for cross-channel attribution and warehouse-grade aggregation, but most operators only ever ask the cohort and product questions SleekView answers locally. Edits route through wc_update_order so order status, notes, and refunds keep firing WooCommerce hooks while the team works directly from the analysis grid.

Cohort analysis is one of the things WooCommerce's stock admin genuinely does not do. The wp_posts (post_type=shop_order) table holds every fact you need, the wp_postmeta rows hold the customer and product detail, and wp_woocommerce_order_items holds the SKU level, but joining all three to compute recency, frequency, monetary value, or month-over-month retention is a SQL job. Glew solved that by streaming the data to a hosted warehouse and running the math there, which works well for cross-channel attribution but is overkill for most stores that just want to know which customers haven't bought in 90 days or which SKU keeps customers coming back.

SleekView treats the same WooCommerce tables as a queryable surface and computes RFM and cohort math inline. The data stays live because nothing is synced; HPOS is detected automatically; and edits route through wc_update_order so any inline action from the cohort view fires the same hooks WooCommerce expects. Growth analysts get the answers they used to wait for a warehouse to load.