A supplier sends you a feed of ten thousand products. How many of them are already in your catalogue?

Short answer

You cannot know without matching, and matching is the work: suppliers send their own identifiers, spell the same manufacturer three ways, and describe attributes in units you do not use.

Keep product data explicit in the answer because that is the concept the interviewer is actually trying to test. A good product data explanation names the trade-off, the failure mode, and the evidence you would use before choosing. Use product data once more at the decision point so the answer reads as judgement rather than a detached example.

Keep product data explicit in the answer because that is the concept the interviewer is actually trying to test.

It is a matching problem, not an import

The instinct is a loader: read the file, upsert on something, done. That works for one supplier and collapses at the second, because the two describe overlapping products using nothing in common.

What you actually have is two catalogues and a question about which entries refer to the same physical item. That is entity resolution, and it has the shape every entity-resolution problem has — a confidence score, a threshold, and a band in the middle that a human has to look at.

Getting this framing right in an interview matters more than any specific technique, because it determines whether you build something that degrades gracefully or something that produces silent duplicates for a year.

Know which identifier you have

Not all identifiers are the same kind of thing, and conflating them is the usual first error.

Identifier	Whose	Unique where	Use
GTIN	Globally allocated, GS1	Everywhere	The only genuinely shared key
SKU	Yours	Inside your business	Your internal stock unit
Supplier code	Theirs	Inside their business	Joining back to their feed
MPN	The manufacturer's	Per manufacturer, loosely	A strong signal with the brand

The one to lean on is the GTIN, because it is allocated globally rather than locally and identifies a trade item consistently across organisations. It is also the one most often absent, wrong, or reused — a supplier who has recycled a code between products will match you to the wrong thing with high confidence, which is worse than not matching.

So even the good key needs sanity checks: a GTIN has a check digit, and one that fails it is a typo rather than an identifier. Matching two products with the same GTIN but wildly different titles or price bands is worth flagging rather than trusting.

Everything else — SKU, supplier code — is meaningless outside the organisation that issued it, and using a supplier's code as your product key means their renumbering becomes your migration.

When there is no GTIN

Most feeds in some categories have none, and then you score.

The useful signals, roughly in order of strength: brand plus manufacturer part number, which together are close to unique; a normalised title; the key category-specific attributes such as size, colour, capacity; and pack quantity, which is the one people forget and which distinguishes a single unit from a case of twelve.

Candidate pair
  incoming   "Anker PowerCore 10000 mAh Portable Charger, Black"
  existing   "Anker PowerCore 10,000mAh Power Bank - Black"

  brand match            exact            +0.30
  MPN                    absent both       0.00
  normalised title       0.86 similarity  +0.25
  capacity attribute     10000 == 10000   +0.20
  colour attribute       black == black   +0.10
  pack quantity          1 == 1           +0.05
                                          ------
  score                                     0.90   -> auto-link band

Normalisation before comparison does most of the work: case, punctuation, thousands separators, unit spellings, and the marketing words that vary between sellers. A title similarity computed on raw strings scores this pair far lower and sends it to a queue that did not need it.

The asymmetry that sets the thresholds

Two thresholds, three outcomes: auto-link above the upper one, create as new below the lower one, human review in between. Where you put them follows from the costs, and the costs are not symmetric.

A duplicate — the same product listed twice — splits inventory and reviews, looks unprofessional, and is fixable later by merging. Annoying, recoverable.

A wrong merge puts one product's price, images and stock against another's. A customer orders a 10,000 mAh charger and receives a 5,000. It is much harder to unpick, because orders, reviews and analytics have already been written against the merged identity.

So the bands are deliberately conservative: be reluctant to auto-link, tolerant of creating a duplicate, and accept a review queue in between. The width of that band is a staffing decision as much as a technical one — narrow it and errors enter the catalogue, widen it and the queue never empties.

Whatever you do, keep the merge reversible: record which source records contributed to a product, so an unmerge is a supported operation rather than an archaeology exercise.

Attributes are a separate problem

Identity is one job; making the product findable is another, and they get conflated.

A supplier sends "colour": "Jet Black", another sends "color": "black", a third puts it in the title. Capacity arrives as 10000mAh, 10 Ah, and 10,000 mAh. Dimensions arrive in centimetres and inches, sometimes unlabelled.

Normalising that into your own attribute model — a controlled vocabulary per category, canonical units, mapped synonyms — is what makes filtering work, and filtering is what makes the product findable. An item with the wrong attributes is not really for sale: nobody browsing by capacity will ever see it, and the loss is invisible because it produces no error and no support ticket.

This is also why product data quality is a revenue problem rather than a housekeeping one, and why the argument for spending on it is best made in those terms.

What to build first

The sequence that gets value soonest: normalise and validate identifiers, match on GTIN where present, score the remainder, put the middle band in a queue with the candidate pairs shown side by side, and instrument the outcome.

Then use the queue's own data to shrink it. The reasons reviewers give when they reject a match are a specification for the next scoring improvement, exactly as override reasons are in routing. A queue that stays the same size for six months is a queue nobody is learning from.

Suppliers do not share your identifiers and rarely share each other's. Treat the feed as two catalogues to be reconciled, and set the thresholds from the fact that a wrong merge costs far more than a duplicate.

---

© 2026 Preptima. Originally published at preptima.com.