Listen to the brief:

Fitment is one of the harder problems in parts commerce because product relevance depends on more than the query. A customer may search for an exhaust system, piston, filter, or steering component, but whether that product is actually useful depends on the vehicle or equipment it is intended for.

At Fyresite, we have spent the last several years building a Shopify-first fitment system for automotive, powersports, marine, and other parts merchants. The system integrates with Algolia for search and discovery and is designed to keep fitment data manageable within Shopify while making it available across the storefront, product pages, cart, customer accounts, and newer interfaces such as conversational assistants.

The core problem turned out not to be search. It was data modeling. We presented on this topic at Algolia DevBit 2026. You can watch the original presentation below, or keep reading to learn more.

Fitment does not have a universal schema

Year / Make / Model is the format most people associate with automotive fitment, but in practice it is only one possible schema.

A standard catalog may use Year / Make / Model. Engine-specific products may use Year / Make / Engine. Trim-level fitment may introduce Submodel, while marine catalogs may use attributes such as Manufacturer, Model, and Horsepower. The relationships can also differ: one SKU may correspond to one vehicle, while another may be compatible with many different vehicles.

That means a rigid schema is difficult to apply across merchants. It also means fitment cannot be treated as a fixed set of product attributes if the same system needs to support multiple verticals and catalog structures.

Our model therefore starts with a variable set of fitment dimensions. The important requirement is not that every merchant use the same attributes, but that each valid combination of attributes remains intact.

Why flat product attributes are not enough

One of the first problems we encountered was reliability.

Suppose a product has separate lists for Year, Make, and Model. If the lists contain 2018, Ford, Honda, F-150, and Civic, then each individual value may be valid for that SKU. The problem is that nothing in a flat representation preserves which Year, Make, and Model values belong together.

A filtering system can therefore construct combinations that were never present in the original fitment data. The example from our DevBit presentation was a 2018 Honda F-150. Every value exists on the product, so a naive filter can evaluate the combination as valid even though the vehicle does not exist.

This is manageable when the relationship is one-to-one because the product itself acts as the common reference. It breaks down when one SKU fits many applications.

The solution we adopted was to stop treating fitment values as unrelated attributes.

Modeling fitment as entities

In our system, one fitment entity represents one valid combination of fitment variables. A 2018 Ford F-150 is therefore an entity rather than three independent values.

If another combination is valid, it gets another entity. If a combination is invalid, no entity exists for it. This preserves the relationship between the individual dimensions and prevents the search layer from generating combinations simply because their component values happen to appear on the same SKU.

The entity can then be indexed independently, much like a product or collection, and associated with the Shopify resources that need it.

This approach also keeps the model flexible. A fitment entity might contain Year, Make, and Model for one merchant, while another might use Make, Year, and Engine. The same underlying architecture works as long as each entity describes a complete, valid application.

Using fitment entities across Shopify

Once fitment is modeled independently, it becomes useful outside search.

A fitment entity can be associated with products to drive search filtering and product-page compatibility checks. It can also be used to scaffold Shopify collections, attach vehicles to customer accounts for a “My Garage” feature, segment customers by vehicle, or associate editorial content with a specific application.

We think of the entity as a throughline because the same identifier can be reused across multiple parts of the system rather than reconstructing fitment from independent fields each time.

This matters operationally. If the storefront, product page, customer account, and cart each implement their own interpretation of fitment, discrepancies become difficult to avoid. Using a common entity model gives those systems the same reference point.

Our first implementation: Speed of Air

One of our earlier implementations was for Speed of Air Technologies, a manufacturer of high-efficiency pistons. At the time of our DevBit presentation, the site had roughly 400 SKUs and around 700 fitment entities based on Make, Model, Year, and Engine. Products used one-to-many fitment relationships, which made it a useful test case for the entity model.

This implementation predated our work with Algolia and used Shopify's native search and discovery tooling. It demonstrated that the data model worked, but also exposed scaling constraints around native filters. In the implementation we showed, Shopify's filtering model imposed limits on the number of filter groups and filter values, which becomes relevant quickly with automotive catalogs.

The user flow was conventional. A shopper selected a vehicle through a stepped form, with each choice constraining the available values in the next field. In the demo, we selected a 2007 Chevrolet Corvette V8. The selection produced a filtered product listing page, and impossible combinations were unavailable because the options were derived from valid entities rather than arbitrary combinations of product attributes.

When we opened a product detail page, the same vehicle appeared in the compatible-vehicles section. The important part was not the UI itself, but that the same fitment entity could be carried from initial selection into the PDP instead of recalculating compatibility independently.

That implementation established the model. The next step was to apply it to a substantially larger catalog and use Algolia as the discovery layer.

Scaling the model with Algolia

Diesel Power Products is a larger and more varied implementation. At the time of the presentation, its catalog included approximately 26,500 SKUs, 1,600 collections, and 350 fitment entities, with a mixture of one-to-one, one-to-many, and universal products.

The merchant also illustrates why fitment dimensions need to be configurable. Rather than relying on Year / Make / Model, its primary model is Make / Year / Engine. In diesel applications, an engine generation and vehicle body can change on different schedules, so Engine is often a more useful matching dimension than Model.

For this implementation, we index the catalog and fitment data in Algolia so the same relationships can be used for filtering and search. Algolia also have a native search connection for Shopify. This matters particularly in large collections. Sean's demo (see the video recording at the end of this blog) showed cases where a collection could contain hundreds or close to a thousand possible results before fitment was applied.

Algolia's own auto-parts architecture follows a similar principle: vehicle context needs to work alongside query intent and product data, rather than existing as a separate filtering step. Its current fitment solution is designed to combine those signals in the search layer and to support both vehicle-specific and universal products.

Three interfaces over the same fitment model

One of the more useful aspects of the Diesel Power Products implementation is that the customer does not have to reach a product through one fixed journey.

In the DevBit demo, we showed three ways to reach the same product while relying on the same fitment data underneath.

The first was a traditional guided flow. The shopper selected a Make, Year, and Engine, moved into a relevant subcollection, viewed filtered results, opened a product, and added it to the cart. Once a vehicle was selected, the storefront displayed that the results were being filtered for the active fitment, and the PDP confirmed that the selected part fit the vehicle.

We also validate fitment again at the cart level. That additional check is useful because the cart cannot assume the customer followed the expected path. A product may have been added before a vehicle was selected, accessed through a direct URL, or added during a different part of the session. Revalidating against the active fitment reduces reliance on the earlier navigation state.

The second flow used search directly. Instead of selecting the vehicle first, Sean searched for 2010 Duramax AFB exhaust. Algolia synonym handling mapped the terminology appropriately and returned the same product, while the storefront still confirmed compatibility with the selected vehicle. Fyresite uses a mixture of manually configured and AI-generated synonyms, including both one-way and two-way relationships depending on the case.

This is particularly relevant in parts commerce because users often search using domain terminology rather than catalog terminology. They may use an engine family, abbreviation, manufacturer shorthand, OEM number, or another term that does not exactly match the product record. Fitment and query interpretation therefore need to work together rather than sequentially.

The third path used a conversational assistant connected to the same Algolia indexes and fitment data. The assistant retrieved compatible products, added a selected item to the cart, and created a checkout link. It could also answer a direct fitment question for the same vehicle.

The engineering point here is not the reduction in clicks by itself. It is that the guided UI, search box, and conversational interface can all query the same underlying compatibility model.

Separating fitment logic from interface logic

The presentation summarized the three journeys as roughly eight clicks for guided fitment, four through search, and one through chat. All three terminate at the same checkout state with fitment confirmed.

We do not expect every user to prefer the shortest path. Some customers need a structured selector, while experienced buyers may prefer search, and other users may prefer a conversational workflow.

What matters architecturally is that none of those interfaces should implement its own independent fitment logic.

The interface determines how the user expresses intent. The fitment layer determines whether a product is compatible. Algolia provides a search and retrieval layer that can serve those different interfaces against the same indexed data.

That separation makes it easier to add new interfaces without creating another version of the compatibility model.

Accounting for universal products

A strict vehicle filter creates another practical problem: universal products.

Some products should appear for a category or query even though they are not explicitly tied to one vehicle entity. Diesel Power Products uses a mixed model containing both vehicle-specific and universal products, so filtering cannot simply discard every record without an exact fitment association.

This means fitment-aware ranking needs to distinguish between several states. A product may have an explicit compatibility relationship with the selected vehicle, may be universal and relevant to the category, or may be incompatible.

Those states are different from a simple boolean filter and should be represented accordingly in the index and ranking logic.

Algolia's auto-parts implementation also accounts for universal products alongside vehicle-specific results. This is important because an overly strict fitment filter can be just as problematic as an overly permissive one.

Product enrichment still matters

Fitment determines whether a part is compatible, but compatibility alone is not enough to rank search results well.

During the Q&A portion of our presentation at DevBit, we were asked how many attributes were present on a typical product record in the Diesel Power Products implementation. The answer was around 30. Much of that data comes from working with experienced merchant teams to identify useful product attributes, terminology, and synonym relationships within their specific category.

That distinction is important when designing the index. Fitment attributes answer one class of question: can this product be used with this vehicle? Product attributes, inventory signals, merchandising rules, and textual relevance answer another: which of the compatible products is the most useful result for this query?

Search quality depends on both.

Carrying fitment into the order

The same entity model can also extend beyond discovery.

In the DevBit discussion, we described attaching fitment information to products as they are added to the cart. This becomes useful for B2B or multi-vehicle orders, where different line items may correspond to different vehicles. The fitment context can remain associated with each line item and continue through downstream order and fulfillment workflows.

This is one reason we prefer to model fitment explicitly rather than infer it from the customer's most recent filter state. Once the fitment relationship has an identity of its own, it can be persisted and passed between systems.

What we learned

The main lesson from these implementations is that fitment should be modeled independently from the UI used to select it.

A stepped Year / Make / Model selector, a search query, and an AI assistant are different ways of expressing intent. They should not create different definitions of compatibility. The same fitment entities should be available to all of them.

For us, that means keeping Shopify as the operational environment for the merchant, representing valid applications as discrete fitment entities, and indexing the relationships in Algolia for low-latency retrieval and search.

That architecture has also made it easier to extend the system. Search was one use case. Product-page validation, cart checks, customer segmentation, fitment-specific content, and conversational purchasing all build on the same model rather than adding parallel versions of the data.

The implementation details vary significantly between merchants, which is why we stopped trying to define fitment as a fixed Year / Make / Model schema. The more useful abstraction is simpler: model each valid compatibility relationship explicitly, preserve that relationship in the search index, and make it available wherever the application needs to answer the question, “Does this part fit?”