Fuzzy Search for Product Codes and SKUs: Typo Rules Without Dangerous Matches

Overview

Product codes are not ordinary text. A name such as “wireless keyboard” can often tolerate broad text similarity or semantic search. An identifier such as PX-7A19, 10-4402-B, or RZK800-L carries structured meaning in every character. One changed digit may identify a different voltage, size, revision, or compatible component.

The safest design treats fuzzy search for SKUs as a constrained retrieval problem rather than a simple similarity problem:

1. Normalize the query and indexed code in a predictable way.
2. Parse the identifier into meaningful parts where the catalog format allows it.
3. Generate candidates using exact and narrowly approximate rules.
4. Rank candidates with stronger weight on prefixes, numeric segments, and exact code evidence.
5. Apply safety rules that suppress or label ambiguous near-matches.

This approach is different from using one global Levenshtein threshold. A distance of one may be reasonable for a long descriptive code, yet unsafe for a two-digit size or a single revision character. For broader background, see the comparison of Levenshtein, Jaro-Winkler, and trigram similarity.

What to track

1. The identifier’s character pattern

Before selecting an algorithm, document the formats in your catalog. Record whether each code contains a fixed prefix, separators, letters, digits, check characters, revision markers, or meaningful suffixes. A useful pattern inventory looks like this:

2. Normalization changes and collisions

Create a normalization pipeline, but preserve the original value for display and auditing. Common steps include trimming whitespace, converting case consistently, converting known separator variants to one representation, and optionally removing separators for a secondary search field. Do not silently remove characters that distinguish code families.

For example, store both 10-4402-B and a normalized form such as 104402B. Test whether normalization creates collisions. If AB-12 and A-B12 become identical, the index needs a collision flag or a stronger structured representation.

3. Confusion pairs

Maintain a catalog-specific list of likely input errors. Common visual or keyboard confusions include O/0, I/1, S/5, and B/8, but these should not automatically be interchangeable. A substitution rule is safer when it applies only at an allowed position and when the resulting candidate is otherwise unambiguous.

4. Safety and relevance metrics

Track more than whether a query returns a result. Useful measures include exact-match rate, successful correction rate, zero-result rate, click-through on the first result, reformulation rate, and the share of queries where a near-match was judged misleading. Review these by code family, not only as a catalog-wide average. A rule can improve short alphanumeric codes while harming long model numbers.

Cadence and checkpoints

A SKU search implementation needs an operating rhythm because catalogs, naming conventions, and user error patterns change. A monthly or quarterly review is usually more useful than occasional tuning after a serious incident.

At every release

• Run normalization tests against representative codes, including separators, case changes, leading zeros, and unexpected whitespace.
• Check that exact matches outrank all approximate matches.
• Verify that unavailable, discontinued, and replacement items are labeled distinctly rather than blended together.
• Test dangerous pairs such as adjacent sizes, voltage variants, regional versions, and revision suffixes.

Monthly

• Sample zero-result queries and classify them as typos, obsolete codes, unsupported formats, or genuine misses.
• Review the top approximate matches for queries containing digits.
• Measure how often users reformulate after selecting or viewing a fuzzy result.
• Add confirmed confusion pairs to a versioned test set rather than changing a rule informally.

Quarterly or after catalog changes

• Rebuild the character-pattern inventory when a supplier, product family, or ERP export changes.
• Recheck collision rates after new normalization rules.
• Review thresholds separately for each code family and field length.
• Compare search behavior before and after an index, tokenizer, or query-engine change.

If your implementation uses PostgreSQL or Elasticsearch, keep platform-specific behavior documented alongside the application rules. The database or search engine can generate candidates, but application-level safety checks may still be needed. The guide to PostgreSQL versus Elasticsearch fuzzy search can help frame that choice.

How to interpret changes

A higher match rate is not automatically an improvement. For product codes, false positives can be more damaging than zero results because a confident-looking wrong item may be ordered, installed, or added to an inventory record.

Use a labeled test set with at least four categories:

1. Safe corrections: a likely typo should return the intended code.
2. Exact queries: the exact item must remain first and unchanged.
3. Dangerous near-matches: similar codes representing different products must not be silently merged.
4. Unknown inputs: unrelated or malformed strings should produce no result, a low-confidence state, or a request for clarification.

For an alphanumeric code, compare segments rather than relying only on whole-string similarity. One practical scoring model is:

score = exact_prefix_bonus
      + exact_numeric_segment_bonus
      + exact_suffix_bonus
      + character_similarity
      - separator_penalty
      - protected_position_penalty

The exact weights should come from your test set. Protect positions that encode size, voltage, revision, or compatibility. For example, permit a one-character correction in a descriptive middle segment while requiring an exact match for a revision suffix.

A query-handling checklist can prevent broad fuzzy behavior from leaking into every search:

• Is the query long enough for approximate matching to be meaningful?
• Does it contain digits, and if so, which positions may change?
• Did normalization remove or alter a meaningful separator?
• Is there one clearly superior candidate, or several nearly tied candidates?
• Should the interface ask the user to choose instead of presenting one automatic correction?

For multiple close candidates, show the original code, the matched code, and the distinguishing attribute. Avoid replacing the user’s query with an unmarked “did you mean” correction when the result could change product compatibility.

When to revisit

Revisit the implementation on a monthly or quarterly schedule, and immediately after any event that changes identifier structure. That includes a new supplier, an ERP migration, a catalog import, a revised separator convention, new regional codes, or the introduction of serialized inventory.

Also revisit the rules when support teams report recurring failed searches, when duplicate detection begins grouping distinct products, or when search analytics show a rise in reformulations around one code family. These signals often indicate a format-specific problem rather than a need for a more permissive global threshold.

Use this short review sequence:

1. Export recent exact, zero-result, and approximate-match queries.
2. Label a sample for safe correction, unsafe correction, and unresolved input.
3. Compare results by pattern, length, and numeric content.
4. Update the normalization and confusion-pair tests first.
5. Change one matching rule at a time and rerun the dangerous near-match set.
6. Record the decision, threshold, affected code family, and next review date.

The goal is not to make every imperfect query return something. The goal is to make likely corrections easy while making dangerous ambiguity visible. Treat SKU fuzzy matching as a controlled search feature, measure it against real catalog risks, and keep the test set current as your product-code formats evolve.