YITH WooCommerce Product Add-Ons writes block configurations into product postmeta and serialises the customer's selection into wc_order_itemmeta on every line that uses an add-on. The default WooCommerce order screen renders those selections as plain strings under each order line, which is fine for support per order and useless for any cross-store question about which blocks customers actually engage with.

SleekView reads wc_orders joined with wc_order_items and wc_order_itemmeta, parses the YITH add-on meta keys and exposes add-on label, selected option, add-on price and order status as columns. Filter to engraving-block selections in the last 30 days to triage personalisation throughput. Sort by add-on price to surface high-margin options. Group by product to see which catalog pages convert on add-ons.

The plugin keeps owning the add-on UX, cart logic and price calculation. The table view owns the audit surface, so the per-line selections YITH already records become a queryable cohort instead of a string buried under an order.

Product add-ons quietly add a meaningful percentage to AOV on personalisation-heavy stores, but WooCommerce renders every selection as plain text under an order line and YITH itself doesn't ship a cross-order audit. The data is already there: every block label, every selected option and every add-on price lives in wc_order_itemmeta as soon as the order is placed. SleekView reads those meta keys as real columns so add-on selections become a queryable table with order status, product and date_paid attached.

Filters stack into a single query so the engraving fulfilment queue, the high-margin add-on cohort and the unused-options pruning list become one-click views. The plugin keeps owning the add-on UX, while the team running personalisation gets the per-row surface the data always implied.