How I Used AI to Classify Over 30,000 Products (Without Writing a Single Line of Code)

I designed an AI pipeline to clean and classify 30,000 e-commerce products — without writing a single line of code. Here's the design logic behind it.

Jason K Hanani

8/12/20264 min read

black blue and yellow textile
black blue and yellow textile

I cleaned 30,000 e-commerce products in seconds. Classifying a 200-product sample with AI took under 10 minutes.

Not manually. Not by hiring someone. By designing a pipeline that split the work correctly — AI-generated code for the mechanical stuff, AI for the parts that actually need judgment. I didn't write a single line myself.

Here's exactly how it works.

The dataset was a mess

I used a public ASOS product catalog — 30,845 rows, 9 columns — sourced from Kaggle. It looked clean at first glance. It wasn't.

  • 18 fully null rows

  • 873 duplicate SKUs

  • A category field that contained product names, not categories

  • Color values in three different cases — "Black", "BLACK", "black" — treated as separate values

  • Size fields that mixed size labels with stock status: "UK 14 - Out of stock"

  • Product descriptions stored as a stringified blob that needed parsing before anything could be extracted from them

This isn't a contrived example. This is what real catalog data looks like when it's been touched by multiple systems, multiple teams, and multiple years of shortcuts.

The most important decision: what AI should and shouldn't do

Most AI demos use AI for everything. That's the wrong move.

Normalizing "BLACK" to "Black" doesn't need a language model. Neither does deduplicating SKUs, parsing a price string, or splitting a size field. These are mechanical transformations. Code handles them faster, cheaper, and with zero risk of hallucination.

What code can't do is read this:

"Coats & Jackets by New Look. Low-key layering. Notch collar. Button placket. Tie waist. Regular fit."

...and reliably decide: is this Apparel > Jackets & Coats? Or Apparel > Suits? Or something else entirely?

That requires semantic understanding. That's where AI belongs. So I split the pipeline into two stages.

Stage 1 — Pure code. Drop nulls. Deduplicate. Normalize color casing. Parse prices (including "Now £22.50" sale formats). Split size strings into available sizes and a stock flag. Parse the description blob into five structured fields. No API calls. No cost. Runs on 30,000 rows in seconds.

Stage 2 — AI enrichment. Extract material and fit type from the description. Assign category and subcategory from a fixed taxonomy. Return a confidence score for every classification. The AI does the semantic work. The code validates the output — if the AI returns a category that isn't on the approved list, it gets flagged no matter how confident the model was.

The AI doesn't get the final say. The validation layer does.

Why I defined the taxonomy before anything else

This step matters more than the code.

Without a fixed taxonomy, you get "Casual Tops," "Casual Top," and "Top (Casual)" as three separate values for the same product type. The AI isn't wrong — it's unconstrained. Unconstrained AI output isn't catalog data. It's noise.

I defined 10 top-level categories and roughly 90 subcategories before the AI touched a single product.

One edge case that required real thought: the difference between Sports Lifestyle and Sports Performance. An adidas Originals track jacket is sports-inspired but built for everyday wear. A proper running top is functional gear. They look similar. They belong in different subcategories. The AI can tell the difference — but only if the taxonomy gives it the right buckets.

That's a human decision. It has to happen before the AI gets involved.

The confidence routing layer

Here's the part most pipelines skip.

Every classification comes back with a confidence score between 0 and 1. The pipeline routes each product into one of three buckets based on that score:

  • Auto-approved (≥ 0.80, taxonomy valid) → goes straight to the clean output

  • Human review queue (0.50–0.79) → flagged with a plain-language reason, sorted lowest confidence first

  • Rejected (< 0.50) → excluded from the clean output, logged separately

The human review queue is the most valuable output in the whole pipeline.

It's not a failure state. It's the system being honest about where it's uncertain. A human reviewer working through that queue is doing exactly the right work — focused on the genuinely ambiguous cases, not manually reviewing 30,000 rows to find them.

The real point

I've applied this same design logic in production.

At ZALORA, I helped deploy an AI chatbot into seller support workflows. It hit 68% ticket deflection at steady state. That number held because we were disciplined about what the bot could answer autonomously versus what it had to escalate. Unconstrained, it would have deflected more — and made more errors. The routing logic was what made it trustworthy.

Same principle here.

The confidence routing, the taxonomy validation, the human review queue — these aren't just technical features. They're the answer to one question every operations or product person should ask before deploying AI into any workflow:

What happens when it's wrong?

If you don't have a clear answer, you don't have a system. You have a demo.

What's next

The next version of this is a simple web tool — paste a product name and description, get back a category, subcategory, material, fit type, and confidence score in real time.

No CSV. No setup. Something a catalog manager could use to spot-check a product before it goes live.

I'll post it here when it's ready.

If you're dealing with messy catalog data or thinking about where AI actually belongs in your ops workflows — this is the kind of problem I work on. Feel free to reach out.

Dataset: ASOS E-Commerce Dataset — 30,845 products by TrainingDataPro, via Kaggle.

Jason Kester Hanani

Operations & Product Professional

contact@jasonkhanani.com