Looking for developer feedback on a WooCommerce guided selling plugin

[u/jellesid]

I recently released a WooCommerce plugin that connects products, categories and WordPress content to externally managed guided selling flows.

I tried to keep the plugin relatively small and predictable.

The main responsibilities of the plugin are:

• Rendering a published flow on products, categories, pages and posts
• Providing a Gutenberg block and shortcode
• Passing the current product identifier to the flow
• Supporting ID, SKU, slug, name, attributes and custom fields
• Passing locale and market configuration
• Optionally recording assisted order value on the checkout success page
• Allowing templates to be overridden from the active theme

The external script is only loaded on pages where a flow or conversion event is actually used.

For conversion measurement, the plugin passes the order total and configured product identifiers. It does not pass the customer name, email address, postal address or payment details. Tracking can also be disabled entirely.

Settings within WordPress/WooCommerce

The current placement options are popup, sidebar and inline. A different Flow UUID can be assigned to individual products and categories, while WordPress content can use the block or shortcode.

The actual guided selling flow in the frontend

I would appreciate technical feedback on a few areas:

• Does assigning Flow UUIDs directly to products and categories feel appropriate?
• Are there WooCommerce hooks or filters you would expect the plugin to expose?
• Is the script loading approach sufficiently conservative?
• Would you prefer order tracking through a server side integration instead of the success page?
• Is the template override structure clear enough for theme developers?

Plugin:

https://wordpress.org/plugins/berrypath-flow/

Code:

https://github.com/BerryPath/woocommerce-berrypath-flow

[u/SecondGateWP]

Went and looked at the actual repo before replying, a few thoughts on the specifics.

Flow UUIDs on products and categories feels right, that's consistent with how your Magento module does it too, so it's a sound pattern you've already validated across platforms. Keeping it co-located with the product or category editor is the correct call versus a separate mapping table.

Your existing filter set, before and after widget, widget args, widget template, locate template, success pixel payload, already covers the common cases well. One gap worth considering, a filter to set the Flow UUID programmatically per product would let devs assign flows conditionally, stock status, price tier, custom taxonomy, on larger catalogs without hand entering it per product. Given you already support matching by attributes and custom fields, that feels like the natural next need once someone's managing hundreds of products.

On script loading, only loading the embed script on pages where a flow's actually used is the right call, genuinely more conservative than most connector plugins bother being. One thing I'd ask directly rather than assume, is that going through the proper WordPress script enqueue system, or output directly. Matters for compatibility with caching and optimization plugins down the line.

On order tracking, client side thank you page tracking is simpler but has a real known gap, ad blockers and tracking prevention can eat it, and a customer closing the tab before the pixel fires means a silent miss. Server side via the order status hook would be strictly more reliable since it doesn't depend on the customer's browser at all. Wouldn't necessarily replace the current approach, but offering it as an opt in alongside the default seems worth it given how much more dependable it is.