WooCommerce Conditional Shipping and Payments (the Woo extension that hides or shows gateways and shipping methods based on cart conditions) stores rules in option rows and applies them at checkout. The outcome (which gateway and which shipping method actually shipped each order) is recorded on wc_orders as payment_method and the chosen shipping method per order line. Configuration is in one place, outcomes are scattered across order rows, and the question of which rule did what is invisible at the dashboard level.

SleekView Charts joins wc_orders with the conditional-rule meta so the rule-engine workspace gains a metrics layer. A Number counts orders subject to at least one active rule in the period. A Pie of payment_method shows the gateway mix after conditional hiding has done its job. A Bar of chosen shipping methods exposes which conditional-allowed methods are firing. An Area trends conditional-restricted-order volume so a new rule's reach is visible as a curve.

The plugin keeps owning the rule UI and the checkout enforcement. SleekView surfaces the resulting outcome data as a dashboard the operations team can actually scan.

The conditional layer in a Woo checkout is invisible by design. Customers never see the gateways or methods that were hidden, and the store team only sees the methods that survived. That makes rule effectiveness one of the least-measured surfaces in the entire store, despite the rules touching every order.

SleekView Charts treats the chosen gateway and the chosen shipping method as the outcome data the conditional engine produces. Rule-firing volume becomes a KPI, gateway mix becomes a Donut, method distribution becomes a Bar. The rule library is suddenly something a team can review on a calendar instead of trusting on faith.

Underperforming rules retire, region-specific rules confirm their reach, and the conditional engine earns the right to keep growing.