How to fix miscategorized SKUs across a large catalog

Before you can fix anything you need a precise, testable definition, because "wrong category" hides at least four distinct failure modes and each one is fixed differently:

• Flatly wrong — a cordless drill filed under hand tools. Rare but high-impact; usually a data-entry or bad-mapping error.
• Too shallow — a yoga mat sitting in Sports & Outdoors instead of Sports & Outdoors > Exercise & Fitness > Yoga > Yoga Mats. Technically "correct" at the top, invisible at the bottom, and it inherits none of the facets (material, thickness) that the deep node would expose.
• Ambiguously placed — products that legitimately could sit in two nodes (a "desk lamp" vs. "task lighting"), where you've been inconsistent across similar SKUs.
• Channel-mismatched — correct in your internal taxonomy, wrong against Google's product taxonomy, Amazon's browse nodes, or a specific distributor's tree.

Write these down as your taxonomy of errors. Most teams discover that "miscategorized" in their catalog is overwhelmingly too shallow and channel-mismatched, not flatly wrong — which changes the whole remediation strategy, because shallow and mismatched are mapping problems, not correction problems.

You cannot prioritize what you haven't measured, and "the catalog is a mess" is not a number a stakeholder will fund. Run a diagnostic pass that produces a defect rate and a ranked worklist:

1. Leaf-depth distribution. Histogram every SKU by how deep its category path goes. A catalog where 40% of SKUs sit at depth 1–2 in a taxonomy that runs 4–5 deep has a shallowness problem you can size in one chart.
2. Sibling outlier detection. Within each category node, compare key attributes (title tokens, brand, GPC/UNSPSC code, supplier class) across the SKUs that share it. A node full of "valves" with three "safety glasses" in it flags the outliers automatically.
3. Attribute–category contradiction. If a SKU has voltage and amperage populated but lives under Plumbing, the attributes contradict the category. These cross-field conflicts are some of the highest-precision miscategorization signals you have.
4. Behavioral signals. Pull on-site search and browse analytics. Products with impressions but near-zero filtered-view appearances, or high "viewed from search, never from category" ratios, are frequently mis-shelved.
5. Channel rejection logs. Google Merchant Center disapprovals, Amazon category suppressions, and marketplace mapping errors are a free, already-labeled list of wrong categories — mine them first.

The output is a single ranked table: SKU, current node, suspected correct node, error type, confidence, and revenue/traffic weight. That table is your project plan.

A very common, very expensive mistake is to start re-classifying SKUs against a taxonomy that is itself broken — duplicate nodes, overlapping leaves, missing branches. You'll spend weeks placing products into categories you'll later merge or delete. Stabilize the tree first:

• Establish one golden internal taxonomy as your source of truth, ideally aligned to a standard (GS1 GPC, UNSPSC, eClass, or your industry's equivalent) so it maps cleanly outward later.
• De-duplicate and disambiguate leaves. Merge Lighting > Lamps and Lamps > Lighting. Every leaf node needs a one-sentence inclusion rule and a couple of explicit exclusions so two analysts (or two models) make the same call.
• Build explicit crosswalks from your golden tree to each channel's taxonomy — Google product categories, Amazon browse nodes, each major customer's internal scheme. Maintain these as versioned mapping tables, not tribal knowledge. When Google reshuffles its taxonomy (it does, periodically), you update one crosswalk, not a hundred thousand SKUs.
• Decide the tie-break rules for genuinely dual-natured products up front, and apply them consistently. Consistency beats theoretical perfection here.

This step is governance, not data work, and it's the highest-leverage hour you'll spend. A clean taxonomy with documented rules makes the bulk classification that follows dramatically more accurate.

There is no single right tool — there's a portfolio, and mature catalogs use all of these in layers, cheapest-and-most-certain first:

• Deterministic rules / lookups — When a supplier class, a GTIN-to-category map, or an exact attribute pattern uniquely determines the node, use a rule. It's free, auditable, and 100% repeatable. Push as much volume through rules as you can; it's your highest-confidence tier.
• Classical ML classifier — Train on your already-correct SKUs (title, description, attributes → leaf node). Good for high-volume, repetitive catalogs with stable categories. Needs labeled data and retraining as the tree evolves, and it gives you a probability you can threshold on.
• LLM-based classification — A model that reads what a product actually is (messy title, spec sheet, supplier copy) and matches it to the deepest correct node, with a rationale. This is the strongest option for the too-shallow and ambiguous cases that defeat rules, and for mapping into unfamiliar channel trees. Constrain it to your taxonomy (don't let it invent nodes), require a confidence score and a cited reason, and route low-confidence calls to review.
• Human review — Not for the whole catalog — for the long tail of genuinely ambiguous, low-confidence, or high-revenue SKUs the automated tiers flag. Humans are expensive and inconsistent at volume, which is the original cause of the mess, so spend them only where judgment genuinely can't be encoded.

The tradeoff: rules are cheap and brittle, ML is scalable but needs labels and drifts, LLMs handle judgment and novelty but cost more per SKU and need guardrails, humans are accurate-ish but don't scale. Layer them so each SKU is handled by the cheapest method that can be confident about it.

Don't reclassify the whole catalog in a single transaction. Sequence it so you bank value early and contain risk:

1. Wave 1 — high-confidence, high-impact. The flatly-wrong and obvious-shallow SKUs that also carry traffic or revenue. These are the ones where a rule or a high-confidence model call agrees with a cross-field signal. Big wins, low risk.
2. Wave 2 — systematic shallowness. Whole branches that default to a shallow node. Often fixable with a single mapping rule applied across thousands of SKUs at once.
3. Wave 3 — channel re-mapping. Re-run the channel crosswalks so the now-correct internal node propagates to Google, Amazon, and customer trees. Clear the rejection/suppression backlog here.
4. Wave 4 — the ambiguous long tail. Human-in-the-loop review of everything that stayed low-confidence.

For each wave, stage the change, diff it against current values, sample-audit before you commit, and keep the previous category in a category_previous field so any wave is reversible. Track a defect rate per wave so you can show the trend line moving.

A reclassification that's confidently wrong is worse than the original, because it looks fixed. Gate every wave with validation:

• Sample audit. Pull a stratified random sample (by error type and confidence band) and have a human grade it. Hold to a published precision bar — e.g., "95% correct at the leaf before this wave ships."
• Consistency checks. After the change, re-run sibling-outlier and attribute–category-contradiction detection. The number of contradictions should drop, not move sideways.
• No-orphan check. Confirm every reassigned SKU lands on a live, indexable leaf that exposes the right facets — not a node that's hidden or facet-less.
• Post-fix behavioral lift. This is the real scorecard. Watch filtered-view impressions, category-page entrances, on-site search recall, and channel approval rates for the affected SKUs over the following weeks. Correct categorization should show up as products appearing in browse paths they were absent from before. If the numbers don't move, your "correct" node may still be wrong or too shallow.

Measurement closes the loop: it tells you whether the project actually bought you discoverability or just rearranged labels.

The cleanup only sticks if the corrected category lands in your source of truth — the PIM, ERP, or master catalog — and flows outward from there. Patch a category directly in a Google feed or an Amazon listing and you've created a fork: the next full sync from your PIM overwrites your fix with the original wrong value, and you're back where you started next quarter.

The durable pattern is one-directional: corrected internal node written to the PIM, channel-specific nodes derived from it through the versioned crosswalks, feeds regenerated from that. Your PIM stores the data; the categorization work — gathering, classifying to the deepest correct node per channel, and writing it back — is the layer that sits alongside it. That's exactly the kind of high-volume, rules-plus-judgment work Anglera does at catalog scale: read what each SKU actually is, place it in the most specific accurate node for every channel, and write it to your source of truth so the fix propagates everywhere and survives the next sync.

If you fix the catalog and change nothing about how SKUs enter it, you've bought a temporary reprieve. Re-accumulation is guaranteed because the original causes — manual entry, supplier feeds with their own (wrong) categories, new channels with new trees, taxonomy updates — are all still running.

Build the guardrail in:

• Classify at intake. Every new or changed SKU gets auto-categorized and confidence-scored before it goes live. New SKUs are the cheapest to get right and the most expensive to fix later.
• Quarantine low-confidence. SKUs the classifier isn't sure about don't ship to channels until reviewed.
• Re-validate on taxonomy change. When a channel reshuffles its tree, re-run the affected crosswalk and re-classify only the impacted branch.
• Monitor the defect rate continuously. The same diagnostics from step two, run on a schedule, turn miscategorization from a periodic fire drill into a metric with a baseline and an alert threshold.

The difference between a catalog that's clean once and one that stays clean is whether categorization lives in the ingestion pipeline or in a recurring spreadsheet emergency.