How to Match a Product Catalog to CPSC Recalls
Catalog recall screening is an entity-resolution problem. The important work happens between a merchant’s imperfect item data and the scope language in an official notice.
Start with the strongest identifiers
Normalize UPC values without inventing digits, and compare them exactly. Next compare normalized brand and model as a pair. Use product titles and descriptions only to produce candidates when stronger identifiers are missing.
- Exact: normalized UPC equals an official notice UPC.
- Likely: both normalized brand and normalized model agree.
- Possible: partial identity or text similarity needs review.
- None: no scoped-source match as of the returned timestamp.
Why false positives happen
Recall scope can depend on a date range, lot, retailer, color, component or manufacturing location. A shared brand name or product family is not enough. Model names can also be reused across years.
A useful API returns its match basis and unresolved identity fields. This lets the receiving workflow quarantine a candidate for review instead of silently converting similarity into a block decision.
Why monitoring creates recurring value
A one-time catalog scan becomes stale. A catalog watch should compare active items against newly synchronized notices and send a webhook only for a new match, a higher match level or a relevant notice update.
Resolved candidates should remain in history. Deleting old matches removes the audit trail and makes it harder to explain why an item was previously reviewed.
Frequently asked questions
Can product title text produce an exact match?
No. Text similarity can create a possible candidate, but exact is reserved for a normalized UPC match.
What fields should a catalog provide?
Provide product name and as many of brand, model and UPC as are available. Missing identity should remain visible in the result.
How often should active items be rescanned?
LookTwice rescans active catalog items daily and only notifies on material match events.