Drip stores subscribers, events, and workflows in its hosted ecommerce CRM. The WordPress plugin is the connector. API credentials, the Drip account_id, and identify/event mappings live in wp_options under keys like drip_settings, and per-form mappings live on form postmeta. When logging is enabled, the plugin records each push (identify or event) in a small log table or rolling option record.

The default admin screens cover connection and per-form mapping. They do not give a queryable view over what shipped. "Which signups pushed today, which event names fired, which got the right tags, which failed" is not a one-click table. Per-event mapping audits after a campaign change require opening forms one at a time.

SleekView reads the connector's options and event log. Signups and ecommerce events become rows with action (identify/event), Drip tags, event name, status, and API response. Mapping overview joins every form to its Drip destination. Bulk retry calls the plugin's own push function so behaviour matches a normal trigger.

Drip competes on ecommerce-grade automation that depends on a clean event stream. Placed Order, Started Checkout, Viewed Product: when those events fire reliably, post-purchase, abandoned-cart, and replenishment flows do their job. When they misfire, the symptoms show up in conversion dashboards a week later, not in alerts.

The WordPress connector is the source of truth for those events on the WordPress side, but its default admin is built for setup, not surveillance. A few options, a per-trigger configuration screen, and the assumption that operators will spot drift themselves. SleekView reads the connector's option and log records into a real table, so identify versus event, applied tags, and per-event-name failure rates all become a saved view rather than an export.

Ecommerce ops, lifecycle marketers, admins, and support each get the slice they need to keep the bridge between WooCommerce and Drip operationally honest.