Why an automated product match is never treated as a fact

The same product is named differently across retail chains: a different way of writing the volume, a different word order in the title, sometimes a different manufacturer code. To build competitor-price analytics, every such pair first has to be recognized as "the same product".

Fuzzy string matching (RapidFuzz) does the first pass — it quickly narrows a huge set of possible pairs down to a few dozen likely candidates with a similarity score.

A string-similarity score knows nothing about packaging, volume, or a regional product variant. "Product 0.5 L" and "Product 0.5 L, winter formula" will score as a close match, but for price analytics they are different products. Trusting the score and auto-confirming above a threshold would let some of these mismatches into the reports — and distort exactly the numbers the system exists to produce.

The mistake is not a one-off: a wrong match, once stored, keeps distorting reports on every subsequent price update until someone notices and fixes it manually — after the fact.

Automatic confirmation is disabled entirely, regardless of how high the score is. Every candidate stays in a queue for an operator to confirm, and only a manually confirmed pair reaches the working reports. The algorithm is responsible for keeping that queue short and ranked by likelihood — not for the final call.

So manual review does not become a bottleneck as the retail network grows, a confirmed match applies at the competitor level as a whole, not per individual store or region: one operator decision clears the pair for every location of that competitor at once.

Automation speed is not worth more here than the accuracy of the data pricing decisions rely on. A slower, verifiable pipeline is a deliberate choice, not a temporary limitation waiting on a "smarter algorithm".