Job mapping-supplier-categories-to-store-categories · revised 11 October 2026
Map a supplier's category names onto your store categories, with no silent defaults
Every category value in a named supplier feed maps to exactly one of your store categories, or lands in a visible unmapped list. Nothing falls silently into a default category.
You might be seeing
- Many imported products sit in a default or catch-all category
- A supplier category rename moves products out of a category they used to appear in
No passwords, keys, card details or admin invites needed to start.
What usually happened
The importer matches supplier category text to store categories by loose text matching or hard-coded cases, so new, renamed or hierarchical supplier categories fall into a default or the wrong category without any record of why. Nobody can say which supplier values are mapped, which are not and who decided.
Who it’s for: Merchant or merchandising manager who imports a supplier catalogue into a store and finds products in the wrong category or in a catch-all one.
Usually starts when: A new supplier catalogue arrives with its own category names, or an existing supplier renames categories, and products appear under Uncategorised or under the wrong collection.
The result: Every distinct category value in a named supplier file maps through a table you can read to exactly one store category, or to a visible unmapped list awaiting your decision. The importer applies the table the same way each run, and a changed or new supplier value is reported, never defaulted.
Check whether this job fits
Answer these without sending feeds, code or logins. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
List the distinct values
In a copy of a supplier sample, sort the category column and remove duplicates, or ask your developer to print the distinct values.
Look for: Near-identical spellings, path separators such as > or /, trailing spaces and different capitalisation. Each distinct text is a separate value the importer must treat consistently.
What you get
- The mapping table in a format you can edit, with every supplier value in the sample
- A change to the importer with its tests
- A report of unmapped and changed values for the sample run
- Steps to revert the change
Included
- One supplier feed layout and one target store category tree, up to 200 distinct supplier category values
- Extract the distinct category values and any category path structure from your redacted sample
- Build an owner-editable mapping table with one target per value, a reason column and an explicit unmapped state
- Change the importer to read the table, apply it exactly (not by loose matching), and write unmapped values to a list instead of a default category
- Add tests with synthetic rows covering mapped, unmapped, renamed and many-to-one cases
Not included
- Deciding which store category is commercially right for a product; your merchandising owner approves each mapping
- Re-categorising products already in your store
- Redesigning your store category tree
- Mapping to a shopping platform's own category list, unless you add it in writing
- More than 200 distinct supplier values, which are quoted separately
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every distinct category value in the agreed sample file appears exactly once in the mapping table with one target category or the explicit unmapped state.
Evidence: The distinct-value list from the file and the table side by side, with counts matching.
A synthetic file containing a mapped value, a new unseen value, a renamed value and two supplier values mapped to one store category imports so that each product lands in its table target, and the new and renamed values appear in the unmapped list with no product placed in a default category.
Evidence: Test run output with each product's resulting category and the unmapped list.
Running the same file twice gives identical categories and an identical unmapped list.
Evidence: Both outputs compared.
The importer's existing tests still pass with the change applied.
Evidence: Full test run output attached to the change.
Sign-off. Your approver signs off the mapping table row by row, and you accept the test results in writing. Payment follows sign-off; applying the change live stays with your maintainer.
If it fails. If the agreed tests do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- The importer or import rules can be shared through an agreed route and run locally on synthetic data
- You have a redacted sample file showing the supplier's category values, and a person who can approve each mapping
- Your target category list is available as text
We stop and tell you if
- Nobody on your side can approve mappings, so the table would be guesswork
- The import happens inside a hosted tool whose rules cannot be changed or exported
- The supplier gives no stable category field, only free text in descriptions
What could go wrong
Before you merge, closing the change leaves the importer as it was. After merge, your maintainer can revert the named commit. The job does not re-categorise products already stored, so reverting affects only future imports.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A plausible but wrong mapping is applied to many products at once. | Each row carries a reason and needs your approver's yes; products with unapproved values go to the unmapped list. |
| A supplier renames a category later and products silently change place. | Changed or new values are reported as unmapped; they are never defaulted or fuzzily matched. |
| Case or spacing differences split one category into two rows. | The agreed comparison rule for case and spaces is written down and tested with synthetic values. |
Your named approver confirms every mapping row. An independent reviewer checks that no value falls into a default, that matching is exact and that the report accounts for every distinct value. Your maintainer reviews and applies the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the supplier layout, target tree, approver and unmapped rule in writing
- Extract distinct supplier values and path structure from the redacted sample
- Draft the mapping table with proposed targets and reasons, and send it to your approver
- Change the importer to apply the approved table exactly and to list unmapped values
- Run synthetic rows covering mapped, unmapped, renamed and many-to-one cases and the existing tests
- Independent review, then hand over the table, change, report and revert steps for your maintainer to review and apply
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and any needed permissions are in place. Hosting, supplier and platform charges are excluded unless the written quote includes them. An enquiry creates no charge or booking.
Need to keep it working?
Discuss a standing check that reports new or changed supplier category values every run.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Do the mapping yourself in a spreadsheet with one row per supplier value and a target column, then ask your developer to load it. The table is the valuable part; the importer change is small.
- Ask the supplier whether it publishes a category identifier or a mapping to a standard taxonomy, which is more stable than names.
Questions
Will you decide which category each product belongs in?
No. We propose a mapping and your named approver decides each row. The importer then applies exactly what was approved.
What if the supplier renames a category next month?
The new name is reported as unmapped and nothing is placed in a default category. You then decide where it goes. A standing import check can watch for this.
Can the table also map to Google's category IDs?
Only if you add that to the written scope. The table can hold a second target column, but Google's taxonomy has its own rules that must be checked.
Send an enquiry
Send us
- The list of distinct category values from a redacted sample, as text
- Your target category names, as text
- What currently happens to products that do not match. No supplier credentials, customer data or code in the first enquiry
Later, once you agree
- The importer code or import rules through an agreed company-controlled route
- A named person who approves each mapping row
- A redacted sample file for the tests
You keep the importer, your store and the decisions about which category each supplier value belongs in. We prepare the table and the change on a copy with synthetic rows; your merchandising owner approves the mapping and your maintainer applies the change.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “mapping-supplier-categories-to-store-categories” as the subject.