Avnzor — Product Taxonomy Rebuild

Avnzor — Product Taxonomy Rebuild

A GCC health & beauty retailer whose product structure had stopped matching its business — and the intake system that keeps the fix from decaying.

A GCC health & beauty retailer whose product structure had stopped matching its business — and the intake system that keeps the fix from decaying.

A GCC health & beauty retailer whose product structure had stopped matching its business — and the intake system that keeps the fix from decaying.

Avnzor taxonomy rebuild — revenue density inversion across catalog categories

Shopify
Algolia
Shopify Admin API
catalog & search analytics

Avnzor's category tree still described a beauty store while the revenue had moved to nutrition — and with roughly one visitor in twenty using search, almost all product discovery ran through it. A five-pass audit set the catalog against the business and produced the constraints for a tree capped at three levels. But a one-off cleanup would not hold: a single import re-broke the catalog weeks later. So what shipped was an intake path — a daily tripwire, a classifier that proposes a category, and a queue where merchandising approves. Categorisation stopped being a project and became a queue somebody works.

Series

Avnzor — Part 2 of 5 · The catalog

Role

Information architecture & UX strategy

Year

Q3 2026

Industry

E-commerce · Information architecture · GCC market

Stack

Shopify · Algolia · Shopify Admin API · catalog & search analytics

Finding 01 — the catalog ranked by product count, then re-ranked by revenue per product, inverting completely
Finding 01 — the catalog ranked by product count, then re-ranked by revenue per product, inverting completely

Every storefront inherits its taxonomy from whatever the business was when the catalog was first loaded. Avnzor’s had never been revisited — so it still described a beauty store, while the revenue had quietly moved to nutrition.


The Constraint

The category tree was the least maintained system in the store and the one carrying the most weight. Roughly one visitor in twenty used search; the rest browsed, which meant almost all product discovery ran through a menu nobody owned.

Underneath it sat more than a thousand product types nested several levels deep. 589 of those types held three products or fewer — shelves with nothing on them. Duplicate labels split single concepts across multiple branches, so the same idea lived in several places at once and none of them completely.


Avnzor's category tree still described a beauty store while the revenue had moved to nutrition — and with roughly one visitor in twenty using search, almost all product discovery ran through it. A five-pass audit set the catalog against the business and produced the constraints for a tree capped at three levels. But a one-off cleanup would not hold: a single import re-broke the catalog weeks later. So what shipped was an intake path — a daily tripwire, a classifier that proposes a category, and a queue where merchandising approves. Categorisation stopped being a project and became a queue somebody works.

Finding 02 — before and after taxonomy structure
Finding 02 — before and after taxonomy structure

The System I Introduced

Rather than redraw the tree from intuition, I measured the catalog against the business in five passes — shelf space against revenue, structure against depth, search demand against actual sales, query language against index language, and browse against search. Each pass produced one finding, and each finding constrained the shape of the new tree.

Shelf space ran opposite to earning power. There were 17× more Makeup SKUs than Sports Nutrition SKUs, and each Sports Nutrition SKU earned 80× what a Makeup SKU did.


The System I Introduced

Rather than redraw the tree from intuition, I measured the catalog against the business in five passes — shelf space against revenue, structure against depth, search demand against actual sales, query language against index language, and browse against search. Each pass produced one finding, and each finding constrained the shape of the new tree.

Shelf space ran opposite to earning power. There were 17× more Makeup SKUs than Sports Nutrition SKUs, and each Sports Nutrition SKU earned 80× what a Makeup SKU did.


Evidence That Shaped the System

The restructure caps depth at three and organizes around how the catalog actually earns: Sports Nutrition and Supplements get real branch structure — Protein split by whey, isolate and plant; Performance split by creatine, pre-workout and amino — while the long tail of near-empty product types stops being navigation and becomes filtering.

That gap is the whole argument in one chart. Demand and revenue were being generated by two different halves of the store, and the taxonomy was organized around the half that searched rather than the half that bought.

اوردیناری returned nothing while The Ordinary sat in the catalog with dozens of products. میکب returned nothing against 4,350 makeup products. اشوقندا returned nothing against a stocked Herbals shelf. The fix is a synonym layer between query and index — no catalog rewrite required, and no dependency on the taxonomy work landing first.


Finding 03 — most searched brands versus best selling brands, with no overlap
Finding 03 — most searched brands versus best selling brands, with no overlap
Finding 04 — Arabic and Persian queries returning zero results for products the catalog already held
Finding 04 — Arabic and Persian queries returning zero results for products the catalog already held
Finding 05 — 72% of store sessions were browsing rather than searching
Finding 05 — 72% of store sessions were browsing rather than searching

The System Proposed

Status: Audit and target tree delivered. The live collection migration has not shipped — everything below is the recommendation, not a measured outcome.

The audit produced a structure and a sequence: restructure the tree around revenue density, cap depth at three, retire the empty product types into filters, and ship the trilingual synonym layer independently of the taxonomy migration so the zero-result queries stop failing immediately.

  • 1,000+ → 3 — Product types → max tree depth

  • ~95% — Catalog reachable after restructure

  • 589 — Product types holding 3 products or fewer

  • 80× — Revenue per product · Sports Nutrition vs Makeup

  • 0 of 5 — Top-searched brands that were also top sellers

  • ~5% — Visitors who used search


What’s Next

Migrating the live collections onto the new tree, then measuring the same five signals again — the browse/search split is the one to watch, since a taxonomy that works should move discovery toward the menu rather than away from it.

The System Proposed

Status: Audit and target tree delivered. The live collection migration has not shipped — everything below is the recommendation, not a measured outcome.

The audit produced a structure and a sequence: restructure the tree around revenue density, cap depth at three, retire the empty product types into filters, and ship the trilingual synonym layer independently of the taxonomy migration so the zero-result queries stop failing immediately.

  • 1,000+ → 3 — Product types → max tree depth

  • ~95% — Catalog reachable after restructure

  • 589 — Product types holding 3 products or fewer

  • 80× — Revenue per product · Sports Nutrition vs Makeup

  • 0 of 5 — Top-searched brands that were also top sellers

  • ~5% — Visitors who used search


What’s Next

Migrating the live collections onto the new tree, then measuring the same five signals again — the browse/search split is the one to watch, since a taxonomy that works should move discovery toward the menu rather than away from it.

More Projects

Creating Since 2010

Currently looking for product design and design engineering roles in the Washington, DC area. If you’re building something where the design system and the code are the same problem — I’d like to hear about it.

© Molham.Works 2026

Creating Since 2010

Currently looking for product design and design engineering roles in the Washington, DC area. If you’re building something where the design system and the code are the same problem — I’d like to hear about it.

© Molham.Works 2026

Creating Since 2010

Currently looking for product design and design engineering roles in the Washington, DC area. If you’re building something where the design system and the code are the same problem — I’d like to hear about it.

© Molham.Works 2026