Ecommerce product discovery case study, simplifying a large catalogue for a UAE ecommerce store

Home / Case studies / Ecommerce product discovery case study

Ecommerce product discovery decides whether a large catalogue sells or simply sits there. This ecommerce product discovery case study covers a project for a UAE ecommerce retailer whose product range had grown faster than the structure holding it. Visitors arrived, searched, opened three or four categories and left without reaching a product that suited them. The store was not short of products. It was short of a route through them.

Custom ecommerce development gave us the room to fix that properly. Tomsher rebuilt the store as a custom ecommerce platform on the MERN stack and treated ecommerce catalogue optimisation, product attributes, product filtering and site search as one connected system rather than four separate features. The client is not named here, and all screenshots are anonymised.

Ecommerce product discovery project at a glance

The challenge, a large product catalogue website customers could not work through

A large product catalogue website creates problems that only appear at scale. The retailer had added products steadily for years, and each addition made sense on its own. Together they produced six issues.

• Ecommerce category structure built around internal logic. Sections were named the way the business described its stock, not the way customers asked for it, so shoppers could not tell which category held the product they wanted.
• Products in the wrong place, or in several places. Similar items sat under different parents, which made ecommerce website navigation feel inconsistent and comparison impossible.
• Inconsistent ecommerce product attributes. The same specification was recorded differently across products, with mixed units, spellings and formats, so nothing could be filtered or compared reliably.
• Site search that matched the wrong things. A product name typed slightly differently returned nothing, part numbers did not match, and results ignored availability.
• Deep category pages with no ecommerce product filtering. Long product lists with almost no filters left customers scrolling through pages of items rather than narrowing to a few.
• Weak mobile ecommerce navigation. Filters were hard to reach on a phone, selected filters were not visible, and returning from a product page lost the customer's place in the list.

The commercial effect was predictable. Customers who knew exactly what they wanted managed. Everyone else gave up, and the sales team fielded phone calls answering questions the website should have answered.

How Tomsher assessed ecommerce product discovery

Product discovery optimisation started with the catalogue rather than the design, because a new layout over unreliable data produces the same problems in a better font. Five assessment methods shaped the build.

• A full catalogue export and audit. Every product, category assignment and attribute, examined for missing values, duplicates, inconsistent units and unused fields. Just over 41% of products were missing at least one attribute their category needed.
• Ecommerce category structure review. Mapping the existing hierarchy and counting products per branch. Two categories held more than 900 products each with no way to narrow them, while nine held fewer than 15.
• Search log analysis. Reviewing 90 days of queries, what customers typed, which searches returned nothing, and which terms the catalogue recorded under a different word.
• Task-based testing. Nine participants were asked to find specific products on the existing site, on desktop and on a phone, with hesitation, backtracking and abandonment recorded.
• Input from the sales team. The questions customers asked by phone showed which information the site was missing and which product distinctions actually mattered to buyers.

The audit produced the two documents the rest of the project ran on: a before and after category map, and an attribute sheet defining every field, its allowed values and its unit.

Ecommerce catalogue optimisation, restructuring categories around customer needs

Ecommerce category structure is the first filter a customer uses, so it was rebuilt around how buyers describe what they want rather than how the warehouse organises stock. The 14 main categories became 11, and the 62 subcategories were reworked into 48.

• Plain category labels, taken from the words customers typed into search, with internal terminology kept in the admin only.
• A controlled hierarchy, deep enough to narrow a large range meaningfully but shallow enough that a customer reaches a usable list within two or three clicks.
• One primary home for every product, with cross-listing handled through attributes and filters instead of duplicate placements, so a product no longer competes with itself.
• Balanced branches, splitting the two oversized categories and merging the thin ones into their nearest relevant parent.
• Clear routes downward, with subcategory links and popular filters surfaced on category pages, so a broad entry point leads somewhere specific.

Every changed category URL was mapped to its new destination and given a permanent redirect before launch, so existing rankings and links carried across rather than being abandoned. In total 104 URLs were mapped and tested on staging.

Ecommerce product filtering built on consistent product attributes

Ecommerce product filtering is only as good as the ecommerce product attributes behind it, which is why attribute standardisation came before the filter panel. Working from the attribute sheet, the team defined the fields each category needed, set allowed values for every one, standardised units, and cleaned around 8,400 product records to match.

On the custom MERN platform this was modelled directly in MongoDB, with attributes stored as structured, validated fields rather than free text inside a description, and enforced through the admin so a new product cannot be saved with an unusable value. Attribute completeness across the catalogue moved from 59% to 97% during the project.

With that in place, faceted navigation became category-specific rather than generic. Each category now shows between four and nine facets that matter to its buyers, such as size or dimensions, material, compatibility, brand, capacity and availability, instead of one global filter list that half fits everything. The filter panel shows counts so customers can see how many products a choice leaves, combinations return results rather than empty pages, and availability works as a filter so nobody narrows down to items that cannot be shipped.

Filter URLs were handled deliberately, not left to chance. Google's guidance on faceted navigation warns that filter URLs can consume crawl capacity and slow the discovery of real content, so the build uses a consistent parameter format and controls which filtered views are open to crawling, while keeping category and product pages fully linked and crawlable.

Ecommerce site search optimisation for a large catalogue

Ecommerce site search optimisation mattered here because search is where customers who know what they want go first. On this store, 34% of sessions used search before launch, and those sessions were the ones failing most often. Building on a custom platform meant search behaviour could be tuned to this catalogue rather than accepted as a default.

• Matching on product names and part numbers, so a SKU or model code returns the product directly.
• Tolerance for typing, handling misspellings, spacing differences and partial words.
• Synonyms from real search logs, starting with 260 mappings that connect the words customers use to the words the catalogue uses.
• Autocomplete suggesting products and categories as the customer types.
• Filters on search results, so a broad query can be narrowed the same way a category can.
• Useful no-result pages, offering close matches, popular products in the likely category and a route to contact the team rather than a dead end.

Search queries are logged and reviewed monthly, so the synonym list and the catalogue keep improving after launch instead of freezing on launch day.

Product specification management, making comparison easier

Product specification management is what turns a shortlist into a purchase. Customers rarely choose a product in isolation. They choose between two or three, and the site has to make the difference visible.

• Consistent specification tables, with the same fields in the same order across every product in a category, and units stated once.
• Variants presented clearly, so the difference between options is obvious on the page instead of buried in the product name.
• Useful product cards, carrying the two or three attributes that decide the purchase in that category, plus availability, so customers can shortlist from the list page.
• Side-by-side comparison of up to four products in the categories where buyers weigh specifications against each other.
• Honest availability, shown at variant level and drawn from the same data the filters use.

Mobile ecommerce navigation improvements

Mobile ecommerce navigation carried 71% of this store's traffic, and a filter panel designed for a desktop sidebar usually fails on a phone. The mobile experience was rebuilt around four points.

1. Filters within reach, opened from a fixed control that stays visible while scrolling a long product list.
2. Selected filters always visible, shown as removable chips so customers know why a list is short.
3. Sorting as a first-class control, not hidden inside the filter panel.
4. Position preserved, so returning from a product page puts the customer back where they were in the list, with filters intact.

The React front end made this practical, because filtering and pagination update the list without a full page reload while the URL still reflects the current view, so a filtered list can be shared or reopened.

Why custom ecommerce development on the MERN stack

Custom ecommerce development shaped what product discovery could do on a catalogue of this size. Five parts of the MERN stack decision mattered most.

• MongoDB holds products with the attributes each category genuinely needs, rather than forcing every product into one rigid field set, with indexes built for the filter and search patterns this store actually uses.
• Node.js and Express expose catalogue, filter, search and availability as APIs, so the website, the admin tools and any future app or integration read the same logic.
• React gives fast category and search pages where filters apply without reloading the page.
• Full control of the data model, which is what allowed attribute validation, category-specific facets and product comparison to be built the way the catalogue required.
• Room to integrate, with the same APIs available for stock, pricing and order flows from back-office systems.

A template-based store can run a shop well. A catalogue of several thousand products with category-specific attributes tends to outgrow one, and the effort then goes into working around the platform instead of improving the customer experience. For businesses in that position, our ecommerce website development in Dubai team builds the data model first and the interface on top of it, and for account-based and wholesale requirements the same approach extends into B2B and B2C portal development.

Results of the ecommerce product discovery project

The measurement plan was agreed before launch, with a baseline recorded from the old site. The figures below compare the 60 days before launch with the 60 days after, and the task measures come from moderated testing with nine participants before and ten after.

Traffic and promotional activity were broadly comparable across the two periods, and no paid campaigns were added during the second period. Even so, discovery changes are one factor among several, so these figures should be read as the direction of travel rather than as proof that every point of movement came from the redesign.

Some limits are honest ones. Ecommerce product discovery improvements make a catalogue usable; they do not fix pricing, delivery times or product photography, and the store continues to work on those. Search quality also depends on maintenance, so the synonym list and attribute values are reviewed as new products are added.

Discuss a similar ecommerce website project

Ecommerce catalogue optimisation usually starts with a review rather than a rebuild proposal. Send us your store and we will look at the category structure, product attributes, filters, site search behaviour and mobile browsing, then come back with what is costing you sales and the order we would fix it in. If custom ecommerce development is the right answer, that review becomes the starting point for the data model.