[Thank God It’s Search]: Building Faceted Navigation for Retail Catalogs: Part1 - Nested field types in OpenSearch

4 minute read
Content level: Intermediate
1

This post will serve as a focused deep dive into handling nested data in OpenSearch, a critical skill for anyone working with semi-structured documents like product catalogs, reviews, or behavioral events.

Welcome to Thank God It’s Search series—your Friday fix of OpenSearch learnings, feature drops, and real-world solutions. I will keep it short, sharp, and search-focused—so you can end your week a little more knowledge on Search than you started.

I'm kicking off a 5-part series that will dive into building aggregations effectively. We'll use a retail catalog as our example to explore best practices and key considerations for implementing aggregations in your workload!

Today's Topic--Building Faceted Navigation for Retail Catalogs: Nested field types in OpenSearch

In retail catalogs, effective product discovery is crucial for customer satisfaction and sales conversion. Building hierarchical navigation is essential as it allows customers to intuitively explore complex product catalogs with multiple attributes like categories, brands, colors and sizes. This structured approach helps customers quickly narrow down their search and find relevant products, even when dealing with large inventories spanning multiple categories and variants.

This post will serve as a focused deep dive into handling nested data in OpenSearch, a critical feature when building hierarchical navigation for retail catalogs with multiple attributes like category, subcategory and assorted sku variants. This structured approach helps implement effective product discovery and guided search capabilities.

Introduction

Customers are often exploring complex catalogs—products with multiple variants like color, flavor, or stock availability—and they expect accurate, flexible, and relevant results. Faceted navigation (aka guided search aka hierarchical navigation) plays a huge role here. It lets users filter across multiple product attributes and narrow things down quickly without having to even search.

For example, someone might search for a “baby pink lipstick,” in a cosmetic retail website, but end up with no results because different brands label shades creatively—like “rose romance,” “pink satin,” or “almost bare.” Keyword search alone falls short. But with faceted search, we can surface multiple, similar alternatives, normalize differences across brands, and keep customers browsing—even when search fails to scale.

To make the navigation work with detailed, layered catalogs, OpenSearch gives us nested field types. These let us filter accurately across both product-level and SKU-level attributes. That’s important because OpenSearch flattens object arrays by default, treating multi-valued fields as arrays leading to incorrect results. Nested fields fix that by treating each object in the array as its own mini-document—so filtering stays clean and scoped.

Why nested field types matter in OpenSearch!

Consider a document listing two patients:

{

"id":"1",

"patients": [

  {"name": "John", "age": 56, "smoker": true},

  {"name": "Mary", "age": 85, "smoker": false}

]

}

A query searching for age > 75 AND smoker = true wrongly returns this document ("id":"1") due to how non-nested arrays are handled. Nested fields solve this by encapsulating each object, ensuring accurate document matches and counts when multiple filters are applied simultaneously.

Real-World Use Case

A cosmetics retailer migrating to Amazon OpenSearch Service wanted to improve guided navigation. Their goal: allow customers to filter across both product and variant levels (e.g., lipstick color, flavor, store availability) at multiple levels. Their catalog was deeply nested—products like lipsticks and glosses had unique SKUs with their own attributes.

Here’s a simplified catalog hierarchy:

Category: Makeup
 |
 |_  Subcategory: Lipstick
      |_Axiology: Vegan, Cruelty-Free
      |_Skin Type: Dry, Oily
      |_SKU Attributes: [multi-valued] ID, Flavor, AvailableInStore, Color

To build this in OpenSearch, you need to follow the below steps.

  • Define the index with nested fields, particularly for skuinfo.
  • Ingest sample product data with attributes spread across both product and SKU levels.
  • Query using nested paths, enabling multi-select filtering (e.g., all lipsticks in "Hot Pink" or with “Raspberry” flavor).
  • Aggregate back to product-level metadata (e.g., show brands or categories of SKUs that are available in “Hot Pink”).

Whats Next? In the next post, you will learn to build exactly that ! Using a synthetic cosmetic dataset, you will learn to implement a top-down and bottom-up faceted navigation using the OpenSearch "nested" and "reverse_nested" queries. Check out the next set of articles posted here

👉 Implementing top-down faceted navigation approach

👉 Building bottom-up faceted navigation

👉 Improving search experience with multi-select filters

👉 Finally ending our 5-part series with Best practices for optimizing aggregation performance!

See you next Friday with another search solution in the Thank God It's Search series! Until then, happy searching! 🔍