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 (opens in a new tab).