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

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.

Today's Topic--Building top-down Faceted Navigation for Retail Catalogs: Nested queries in OpenSearch:

This post will serve as a focused deep dive into handling nested data in OpenSearch, a critical OpenSearch feature when you need to work with semi-structured documents like product catalogs, reviews, or behavioral events, that is associated with a category taxonomy.

Introduction

In retail, great product discovery depends on intuitive navigation. 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) plays a huge role here. It lets users filter across multiple product attributes and narrow things down quickly.

Take cosmetics, for example. Someone might search for a “baby pink lipstick,” 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 the exact match isn’t there.

To make this 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 Nesting Matters 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
      |
      |_SKU Attributes: 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 day, 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 article just posted here.