The Drip for WooCommerce plugin is intentionally thin on the WordPress side. The Drip cloud owns customers, events and revenue reporting. WordPress only stores a handful of options: drip_account_id, drip_default_checkbox, snippet attributes set via the drip_set_snippet_* filters, and any checkout-text overrides. No custom tables, no per-product flag store, no cached customer data.

That thinness is a feature on a single store and a problem at scale. On a multisite network with regional stores, an agency portfolio or staging environments, each blog has its own option row, and the default Drip settings page never rolls up. A question like "which stores still ship with opt-in default on" requires opening every store's settings page individually and writing the answer down by hand.

SleekView Charts reads each blog's Drip options and aggregates the network into a chartable dataset. A Number card anchors total stores with a configured account ID. A Pie splits stores by opt-in default state. A Bar ranks stores by snippet-attribute customizations. An Area trends Drip-settings edits over time to expose when the integration was last reviewed.

Drip's plugin is small and well-behaved by design. It does not duplicate customer data into WordPress, it does not cache events, it does not invent its own admin UI for things WooCommerce already does. That restraint is correct, the Drip cloud is where revenue reporting and abandoned-cart automations run.

The cost is that the WP-side configuration becomes invisible. The only way to see whether opt-in default is on across 20 stores in a network is to open 20 settings pages by hand. SleekView Charts turns that audit into a single dashboard, so the privacy team reads the coverage Pie in seconds and marketing ops reads the account-ID KPI without a tour through the network admin.

The 1.0.4 opt-in regression is the canonical example, the same shape catches every future drift.