logo
Why We Rebuilt SKU Matching From Scratch in BPS Cloud

Why We Rebuilt SKU Matching From Scratch in BPS Cloud

Most WooCommerce bulk-edit tools match products by name, or by whatever looks closest to a guess. Names change. They get typo'd. Two products in the same catalog can share the same name entirely. None of that makes a name an identifier — but it's what a lot of bulk-edit tools quietly key off anyway, because it usually works well enough that the failures don't get noticed until a store owner is staring at a duplicate product wondering how it got there.

We built BPS Cloud's matching logic to never do that.

The matching order

Every row in a sync runs through the same strict order, no exceptions:

  • An explicit product id, if the row already has one.
  • A stored row-link from a previous sync — BPS Cloud remembers which sheet row maps to which product.
  • An exact sku match — nothing looser than exact.

If a SKU matches more than one product, that row doesn't get a best guess. It gets a clear per-row error, and nothing is written. A wrong sync that fails loudly is recoverable. A wrong sync that succeeds silently is how a catalog ends up with duplicate products nobody can explain.

Why this had to be a design decision, not an afterthought

It would be easy to treat this as a minor implementation detail — matching logic, one function, done. In practice it's the single decision that determines whether a bulk-edit tool is trustworthy at real catalog volume. A tool that's right 99% of the time and silent about the other 1% is worse than one that's right 95% of the time and tells you exactly which rows to check. The failures you can see are the ones you can fix.

Google Sheet products tab with sync_status and sync_message columns showing a real result for every product row

Every row gets a real sync_status and sync_message — never just an overall "done."

The bug that proved it: sale_price_rejected

This isn't a theoretical concern. During Google Workspace Marketplace testing, we found a real WooCommerce quirk: under certain conditions, WooCommerce will silently reject a sale_price update — for example when the new sale price isn't actually lower than the regular price — and still return success. From the outside, the sync looks fine. The price just never changed.

A tool that trusts WooCommerce's response would report that row as ok and move on. BPS Cloud doesn't trust the response — it checks what WooCommerce actually stored against what you sent. When they don't match, that row is flagged sale_price_rejected with a message that says exactly that, instead of a false "ok" that leaves you assuming a price change went through when it didn't.

That's the same philosophy applied one level deeper: it's not enough to avoid guessing on which product a row matches. You also have to verify the write actually happened the way you think it did. A sync tool that can't tell you both of those things accurately isn't really telling you the sync worked — it's telling you the request didn't error, which is a different and much weaker claim.

No silent failures, on any row, ever

That's the whole design principle behind BPS Cloud, and it's the reason the matching order above exists in the first place. A duplicate product, a price that silently didn't update, a sync that reports success on a row it never actually touched — these are all the same category of problem: a tool being confidently wrong instead of visibly uncertain. Confidently wrong is the expensive failure mode, because you don't find out until you're already searching your own store trying to figure out what happened.

BPS Cloud is free to install from the Google Workspace Marketplace. If you're curious how the matching order plays out in an actual bulk-edit workflow, see our step-by-step guide to bulk-editing WooCommerce products from Google Sheets.

Prefer the WordPress plugin? See the Bulk Product Sync plugin page for pricing and details.