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 reads each blog's Drip options into one table. Account ID, opt-in default flag, snippet-type override, HPOS state and last option-modified date sit as real columns. Sort by opt-in default to scope a privacy review, filter to missing account IDs to find unconfigured stores, bulk-edit checkout text overrides across regional stores in one pass.

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 turns that audit into one table, so the privacy team filters the opt-in column in seconds and marketing ops scans the account-ID column without a tour through the network admin.