WooCommerce Blocks is now the canonical front-end for WooCommerce: the Cart block, Checkout block, Product Collection block, and a long list of filter and product blocks render the storefront on most modern installs. Each completed order still lands in wp_wc_orders on HPOS or wp_posts on legacy, with cart and checkout context stored in wp_wc_orders_meta and post_content_filtered.

SleekView Charts reads those orders and pivots the order-meta keys that the block-based checkout writes: source URL, created_via flag, customer note, and shipping method. Each becomes a groupBy column or a filter chip, so a chart can split orders by which page or template the checkout block rendered on, or by whether the customer arrived from a Product Collection block or a Product Search block.

The Blocks plugin also stores block usage inside the post_content of every page that uses it. A chart that counts pages containing wp:woocommerce/checkout or wp:woocommerce/cart shows exactly how many templates depend on the new blocks, which is useful for migration audits and theme decisions.

WooCommerce Blocks ships the new cart and checkout experience and a deep set of product and filter blocks, but the admin still leans on the older Analytics tab for reporting. That tab aggregates revenue and orders by date, not by which block produced the order or which page rendered the block. SleekView Charts reads the order tables WooCommerce already writes and exposes the meta keys the new checkout populates, so block-driven traffic gets its own segment instead of merging into the totals.

Block usage across the page tree turns into a chart too, which makes migration audits and theme decisions concrete instead of anecdotal. The Blocks plugin keeps owning the front end; SleekView just charts what it produces.