AI Assistant is here! - Make the leap to conversational eCommerce

Attribute-based filtering

A mechanism that allows users to narrow down results by selecting specific values from catalog attributes, such as color, brand, material, or price range.


Definition

Definition

Attribute-based filtering is the mechanism that makes any kind of product filter work: matching a user's selection against a structured field in the catalog, then returning only the products where that field's value matches. When someone checks "blue" or "under $50," the system isn't scanning product descriptions for the word blue. It's querying an indexed attribute (color) for a specific value, the same way a database query filters rows by a column value.

This is the layer underneath what shoppers see as filters, facets, or navigation menus. Those are the interface. Attribute-based filtering is the logic connecting a UI click to a smaller result set.

A few things determine how well it works in practice:

  • Attribute quality. If product data has inconsistent values (some items tagged "Blue," others "blue," others "Navy Blue"), the filter either misses products or creates near-duplicate options in the UI.
  • Filter logic. Selecting two values in the same attribute usually works as OR (color: blue OR red), while selecting values across different attributes usually works as AND (color: blue AND brand: Nike). Getting this wrong produces empty result sets or filters that feel broken.
  • Single vs. multi-select. Some attributes make sense as single-choice (in stock or not), others need multi-select (sizes, colors), and the interface has to reflect that or users end up with results that don't match their intent.

Attribute-based filtering is a prerequisite for faceted navigation, not a replacement for it. Faceted navigation adds the dynamic layer on top: live counts per option, hiding filters that would return zero results, letting several facets combine at once. Without solid attribute-based filtering underneath, none of that dynamic behavior is possible.

What it's used for

What it's used for

Filtering only works as well as the data behind it. A store can have a polished-looking filter panel and still return wrong or empty results if the attribute data is messy, missing brand values on half the catalog, or sizes stored as "M," "Medium," and "MED" for the same item.

Getting this right has a direct effect on findability. In a catalog of any real size, text search alone can't cover every way a shopper describes what they want. Someone looking for "waterproof hiking boots size 10" is really running an attribute query in their head. If the catalog attributes support that, the store can return exact matches. If they don't, the shopper either gets irrelevant results or has to fall back on scrolling through everything.

It also affects merchandising and reporting. If attributes are structured consistently, a store can pull real numbers on what shoppers filter by most, which price ranges get selected, which brands never get picked. That data is only usable if the underlying attributes were clean to begin with.

How Doofinder applies it

Doofinder indexes product attributes directly from the store's product feed (Shopify, PrestaShop, WooCommerce, or a custom feed), mapping fields like color, size, brand, material, and price into structured, filterable data at index time, not read on the fly from product descriptions.

Store owners can define which attributes become filters or facets from the admin panel, and Doofinder applies basic normalization to reduce mismatches, like grouping close variants of the same attribute value so "Blue" and "blue" don't appear as two separate filter options.

Because attribute data and search share the same index, a filter selection and a text query can be combined in a single request. A shopper who searches "jacket" and then filters by "waterproof" isn't running two separate lookups. It's one query against the same structured data.

Example

Case study

Example

An outdoor gear store imports its catalog from a supplier feed where the "waterproof" attribute is recorded three different ways across different product batches: "Yes," "Waterproof," and "IPX7." Before cleanup, a shopper filtering by "waterproof" only sees the products tagged exactly "Yes," missing two-thirds of the boots that actually meet that criteria.

After normalizing the attribute values into one consistent field, the same filter now returns the full set. The store also notices, from filter usage data, that "waterproof" is selected in 40% of boot searches, information it didn't have when the attribute was split across three inconsistent values. That leads the merchandising team to feature waterproof boots more prominently on the category page.

References

Sources