Product matching
Records matched across catalogues, feeds or channels against agreed rules, with near-matches surfaced for review rather than resolved silently.
Product Data Matching & IDQ Auditing
Find the duplicates before your customers do
What this covers
Item data quality problems are structural, not clerical. Duplicates arrive through acquisitions, supplier feeds and hurried launches. Identifiers get reused. A parent-child relationship gets built the wrong way round and nobody notices because the pages still render.
StaffCloud audits the catalogue against written matching rules — what constitutes the same product, how identifiers are treated, what tolerance applies to near-matches — and produces a defect list a person can act on, rather than a similarity score.
The rules are the negotiable part and they are agreed first. Whether a different pack size counts as the same product depends entirely on what you are using the match for, so it is a decision, not a default.
What the team does
Deduplication audit
Duplicate and near-duplicate SKUs identified, grouped, and returned as a list with the evidence for each — because a merge is a commercial decision, not a data one.
Identifier review
GTIN, UPC, EAN and MPN checked for validity, reuse and collision, which is where a surprising share of catalogue chaos originates.
Variation and family integrity
Parent-child relationships and their theme attributes verified, so families group as one product instead of scattering into singles.
IDQ scoring against your rules
Completeness, validity and consistency measured against the rules you signed off, reported by defect type rather than as a single number.
Remediation support
The fixes applied where you want them applied, with the merge and retire decisions left with you.
How the engagement runs
-
01
Rule definition
What counts as a match, what counts as a duplicate, and what tolerance applies — agreed and written down before anything is compared.
-
02
Baseline audit
The catalogue run against the rules to produce a defect list by type, so the size and shape of the problem are known.
-
03
Review and decisions
Groups reviewed with you: what merges, what retires, what is legitimately two products. We do not make those calls unilaterally.
-
04
Remediation and monitoring
Agreed fixes applied, then re-run on a cadence so the duplicate rate is watched rather than discovered again in a year.
What a clean identity layer buys
Duplicates do not announce themselves. They show up as split stock, split reviews, and an order picked from the wrong record.
- Stock and sales consolidated onto one record per product
- Identifier problems found before a channel rejects the feed
- A duplicate rate that is measured rather than assumed
Platforms and tools we work in
The pod works inside your stack. These are the systems this team uses day to day — if yours is not listed, we will learn it.
- SQLMatching, deduplication and reconciliation
- Excel / Google SheetsReview sets and decision tracking
- AkeneoPIM-side identity and governance
- Seller CentralMarketplace catalogue and variation checks
- Your ERPSource records and identifier extracts
Questions buyers ask
The things worth knowing before the first call.
Not sure this is the right scope?
Describe the workload in a sentence and we will point you at the right team — or tell you honestly if it is not something we should take on.
Ask usNo. StaffCloud identifies duplicates, groups them and shows you the evidence, but the decision to merge or retire a record stays with you.
That decision affects stock, sales history and sometimes accounting, and an automatic merge is how a catalogue loses data it cannot get back. You keep control of the irreversible step; we do the work of finding what needs deciding.
By the rules you sign off at the start. Identifier match, attribute match, title similarity and tolerance for pack-size differences are all adjustable, and the right settings depend on what the match is being used for.
Agreeing them up front means the output is reviewable: you can look at any matched pair and see which rule put them together, rather than trusting a score you cannot interrogate.
That is common, and it becomes a finding in its own right. Where GTINs have been reused, invented or left blank, StaffCloud leans the match on attributes instead and reports the identifier problem separately.
It usually needs fixing before any channel feed will behave properly, so surfacing it early saves you discovering it later through rejected uploads and duplicate listings.
Yes. Cross-catalogue matching is the same discipline applied to a different source, and our team runs it against rules you agree in the same way.
It is also what sits underneath price monitoring: the match has to be right before any price comparison means anything. Matching first is what stops a monitoring report confidently comparing two different products.
Scale and confidence. The AI service under AI Solutions is built for very large catalogues, where a model makes the first pass and people review the uncertain cases.
This service is people-led against explicit rules, which is the right choice when the rules are subtle or the volume is moderate. We will tell you which fits your catalogue rather than defaulting to the one that sounds more advanced.
It depends on how fast your catalogue grows and how many feeds write into it. Ranges that ingest supplier feeds usually need a standing cadence; a stable own-brand range can go much longer between passes.
StaffCloud will recommend a frequency based on what the first audit finds, so you are paying for the checks your catalogue actually needs rather than a fixed schedule that suits us.