How Products Are Mapped to Fitment Data

This page explains how the indexer decides which vehicles a product fits: how the product is identified by brand and part number, where each of those components is pulled from and in what order, how each data source matches them, and how to fix the most common mapping issues.

Note

All fitment mapping happens during indexing. Any change to product data or fitment sources takes effect only after a full re-index, which can be triggered by the "Force re-index" button at the "Convermax site search index" section of our app home page.

Fitment status

Every indexed product ends up with one of the following values in the Fitment field:

Value	Meaning
Vehicle Specific	The product was matched to a list of vehicles and is only shown when one of them is selected.
Universal Fit	The product fits any vehicle and is always shown regardless of the selected vehicle.
Non-Vehicle Products	The product is not related to vehicles at all (apparel, gift cards, tools). The YMM widget ignores it.
No Fitment Data	No source returned any fitments for the product. Depending on store settings, such products are usually hidden when a vehicle is selected.

The two-component matching key: Brand + MPN

Automotive fitment catalogs identify a part by a two-component key:

1. Brand — the brand as registered in the AutoCare (AAIA) Brand Table: either the AutoCare Brand Name (which must match exactly, case-insensitive) or the AutoCare Brand Code — the 4-letter code assigned to every brand (for example, BBHK).
2. MPN — the manufacturer part number, which again must match the part number in the catalog. Matching is exact and case-insensitive; most sources additionally try a normalized form with dashes, dots, commas, slashes, and spaces stripped, but there is no fuzzy matching.

Both components must resolve for catalog lookups to work: if the part number comes out empty, catalog lookups are skipped for the product entirely, and if the brand doesn't match the catalog, most sources return nothing (they never fall back to searching all brands — see the per-source table below for the exceptions).

In practice, stores follow one of two approaches:

• Standard identifiers. The product's brand field holds the AutoCare Brand Name and SKUs are plain MPNs or BrandCode+MPN. Fitment mapping works out of the box.
• Own naming conventions. SKUs or brand names follow the store's internal scheme — usually historical, or because other systems (ERP, feeds, marketplaces) depend on them and renaming isn't an option. Such stores need to provide the original brand and MPN separately: through the overrides described below, set up together with our team.

Where the MPN component comes from

By default, the part number for lookups is the product SKU — the SKU of the first variant that has one. When variant-level fitments are enabled for the store, each variant is looked up by its own SKU instead, and vehicle selection then works per variant. The product handle is used as a fallback key by custom fitment data files when the product has no SKU at all.

The value should be the plain MPN, not BrandCode+MPN. That said, part numbers with an embedded AutoCare brand code are recognized — see Brand code in the part number.

Overriding non-standard SKUs

When your SKUs don't match the catalog part numbers (store-specific prefixes/suffixes, internal numbering), put the real MPN into the convermax.part_number product metafield: whenever it is present, its value replaces the SKU in fitment lookups. Create the metafield from the app's Metafields tab (Shopify Admin → Apps → Convermax → Settings → Metafields) like the other standard metafields, fill in the catalog MPN on the products that need it, and force a re-index. A variant-level convermax.part_number metafield is supported too — ask us to set it up. Note that when variant-level fitments are enabled, multi-variant products are still matched per variant by each variant's own SKU; the metafield applies to the product-level lookup.

Per store, we can also switch the part-number source to a different field — for example Shopify's standard MPN metafield (shopify--facts.mpn) or a feed app's metafield such as mm-google-shopping.mpn — or apply SKU transformations (stripping brand prefixes or store suffixes). These are configured by our team; contact [email protected].

Where the Brand component comes from

The brand for lookups comes from the product's brand field:

• The Shopify product Vendor field — the primary source. It has to match the AutoCare Brand Name used by the catalog (case-insensitive, otherwise exact).
• Merged vendors. If the product's vendor is listed in an automated collection built from a "Product vendor is equal to" rule, and that collection has the convermax.merge_vendors metafield, the collection title replaces the Vendor before any fitment lookups. See Merge multiple vendors to one for the setup.

Per store, our team can also configure overrides: renaming known brand spellings to the catalog names, or reading the brand from a different field. And independently of the brand field, a brand code embedded in the part number is recognized by most sources and works even when the brand spelling doesn't match anything — see the next section.

Brand code in the part number

SKUs and part numbers in the following formats are automatically split into a brand code and an MPN, provided the 4-letter prefix is a valid AutoCare brand code written in uniform case — all uppercase or all lowercase; a mixed-case prefix is never split:

• BBHK-12345
• BBHK_12345
• BBHK|12345
• BBHK12345 (only when the rest of the value contains digits)

The extracted code is then used as the brand component of the key, which makes the lookup independent of how the brand field is spelled. This is the most reliable way to key products, and it is the standard convention for manually exported ACES files ({BrandCode}_{PartNumber} SKUs).

Not every source supports brand codes: WPS and Turn 14 match by their own brand names only (Turn 14 uses its own 3-letter part prefixes, which we map to AutoCare codes), and SSF ignores the brand component and matches by part number alone.

Where fitment data comes from

Product-level overrides come first. A product explicitly marked as Universal Fit or Non-Vehicle Products gets that status immediately, and nothing else is consulted — not even the Fitment Editor:

• the fits_Universal tag, or
• the convermax.fitment_type metafield set to Universal Fit or Non-Vehicle Products.

Fitment Editor data is a layer, not a source in the ladder. Fitments added, changed, or excluded through our Fitment Editor are loaded for every product. If the editor sets the product's fitment type (Universal Fit or Non-Vehicle Products), the sources below are skipped entirely; otherwise the editor rows are merged on top of whatever the sources below return — see Fitment Editor changes.

External sources are checked in order — the first source that returns any fitments wins, and the remaining sources are skipped. If you need data from several sources combined (for example, catalog fitments plus your own additions), we can enable merge mode for your store — contact us.

1. The convermax.fitment product metafield. Fitments entered directly on the product as a YAML list (skipped here when it already serves as the editor storage). See Add Custom Fitment Data with Metafields.
2. Custom fitment data files. Spreadsheets or ACES XML files from Google Drive, FTP/SFTP, or Amazon S3. See About Custom Fitment Data Sources.
3. Product tags. Fitments in the fits_Years`Make`Model`Submodel tag format, parsed when tag-based fitments are enabled for the store. See Add Custom Fitment Data with Tags.
4. Catalog integrations, looked up by the Brand + MPN key, in this order: PDM Automotive, SEMA Data (SDC), SureDone, ASAP Network, WPS, Turn 14 Distribution, SSF. See Fitment Data Integrations.

When no source returned anything (after the editor merge), the fallbacks run:

• Matching by product specs. For stores configured with spec-based matching, products can be matched to vehicles by shared attributes — for example, wheels by bolt pattern.
• Collection-level defaults. A product in a collection marked as universal (the universal template suffix, or the collection metafield convermax.fitment_type = Universal Fit) becomes Universal Fit; a product in a collection with convermax.fitment_type = Non-Vehicle Products becomes Non-Vehicle Products.

Otherwise the product is indexed with No Fitment Data. And if every fitment row returned by a source is marked Universal (for example, the "Universal" column in a spreadsheet), the product becomes Universal Fit.

How each source matches the key

All sources match whole values case-insensitively; none of them do fuzzy matching.

Source	Brand component	MPN component
Fitment Editor	Records pinned to a product match by product ID alone. SKU-level records match every product with that SKU; if the record also stores a brand, the product's brand must match too	The product SKU (not needed for product-ID records)
Custom fitment data files	Not used for the key-column lookup; the brand fallback requires an exact AutoCare Brand Name	The key column (SKU by default), exact. The brand-code split and the brand fallback match only rows carrying brand-code + part-number columns — ACES rows, or spreadsheets that include them
ACES XML files	AutoCare Brand Name or Brand Code	Part number, exact (punctuation matters)
PDM Automotive	PDM brand name, its AutoCare name, a per-store alias, or the Brand Code	Part number, exact only (punctuation matters)
SEMA Data (SDC)	Only brands your SEMA account is approved for; AutoCare Brand Name or Brand Code	Part number, exact and normalized
SureDone	Brand name; if nothing matches, retried by part number alone across all brands	Any of the listing's identifiers (marketplace SKUs, MPN)
ASAP Network	Only brands your ASAP account is approved for; brand name, its synonyms, or the Brand Code	SKU or manufacturer SKU
WPS	Exact WPS brand name only — no brand-code fallback	WPS SKU or supplier product ID
Turn 14 Distribution	Turn 14 brand name (common alternative spellings are mapped, case-sensitively)	Manufacturer part number (also tried with spaces stripped) or Turn 14's part number
SSF	Not used — matches across all brands	Part number, exact and normalized

Fitment Editor changes

Fitment Editor data is merged with the winning external source rather than being just another source:

• Vehicles added in the editor are added to the external fitments.
• Vehicles excluded in the editor are removed from the external fitments.
• A product can also be flagged in the editor to discard all external fitments, keeping only the editor data.
• If the editor sets the product's fitment type (Universal Fit or Non-Vehicle Products), that overrides all other fitment sources (the product-level overrides above still win).

Note

Editor changes are an overlay on top of the data you receive from your sources. They are never written back to the original ACES or CSV files, and there is currently no easy way to sync them into connected spreadsheets — the source data stays as delivered, with the editor corrections applied on top during each re-index.

Resolving brand-name mismatches and misspellings

The store's brand field often doesn't match the AutoCare Brand Name exactly — NGK Spark Plugs vs NGK, Yukon Gear vs Yukon Gear and Axle, aFe vs Advanced Flow Engineering. Since brand matching is exact (there is no fuzzy matching), such mismatches make catalog lookups return nothing for the whole brand. Several mechanisms resolve them:

• The AutoCare brand table. We maintain a global mapping of AutoCare Brand Codes to Brand Names. It powers the brand-code-in-part-number recognition: when the part number carries a valid 4-letter code, the brand is resolved through the table regardless of the brand-field spelling. The authoritative table is published by the Auto Care Association; subscribers can browse and download it at autocarevip.com, and brand codes are also visible in data sources like SEMA Data or PDM if you have an account there.
• Catalog alias tables. Each catalog carries its own known alternative spellings: Turn 14 and SEMA Data have canonical-name tables, ASAP has brand synonym groups, and PDM brand records match by the PDM name, the AutoCare name, and store-specific aliases. When you report a misspelled brand, we usually fix it by adding an alias there.

• Merged vendors. The convermax.merge_vendors collection metafield lets you rename or merge vendors yourself — the replacement name is what fitment lookups use.

• Per-store rules. We can configure brand renames for your store (for example, mapping all your feed's spellings to catalog names), or switch the brand source to a different field.

If a whole brand has no fitments, the first things to check are the exact AutoCare Brand Name spelling and whether your SKUs carry a brand-code prefix the catalog doesn't expect (or vice versa).

Optional vehicle mapping and filtering

By default, fitment rows are indexed as the source provides them; only year ranges (2017-2020, 2017+, 2017,2019) are expanded into individual years. On top of that, several optional layers can be configured per store:

• Vehicle mapping (vehicle_mapping) — renames Make/Model/Submodel values before indexing, fixing misspellings and unifying spellings across sources. See Fitment mapping and synonyms and Troubleshooting misspelled makes or models.
• Vehicle filter (vehicle_filter) — a spreadsheet of vehicles acting as a whitelist (default) or blacklist: fitments outside the whitelist (or matching the blacklist) are dropped. See How to use vehicle filter.
• Turn 14 app vehicle filter — for stores using the Turn 14 Distribution app by DataHere2There, the vehicle filters configured in that app can be applied to the fitment data.
• VCdb validation — fitments can additionally be validated against the AutoCare VCdb vehicle database.

None of these are active unless set up for the store.

Wheels and tires

Wheel and tire products go through a separate pipeline: instead of (or in addition to) per-vehicle fitment rows, they get size attributes (diameter, width, bolt pattern, etc.) from wheel/tire data sources or product attributes.

See Wheels & Tires Data Integrations and Using Metafields for Wheel and Tire Product Attributes.

Verifying a product with the Fitment Editor

The Fitment Editor shows the fitment data a product currently resolves to, so you can verify what customers will get before or after a re-index, override wrong data, add missing vehicles, or exclude incorrect ones. For mass changes, see Fitment Editor Commands.

You will find it as the Fitment Editor block on the product page in your Shopify admin.

Common mapping issues and how to fix them

Symptom	Likely cause	How to fix
Product shows No Fitment Data although the catalog has fitments for it	The product SKU is empty, or doesn't match the catalog part number (extra prefix/suffix, different formatting)	Fill in the SKU, or provide the exact catalog MPN via the override
A whole brand shows No Fitment Data	The product's brand doesn't match the AutoCare Brand Name (AEM vs AEM Induction, typos)	Align the brand field with the AutoCare Brand Name, use brand-code-prefixed SKUs, or ask us to add a brand alias
SKUs carry a brand prefix the catalog doesn't have	The catalog stores plain MPNs while your SKUs look like BRAND-12345 with a non-AutoCare prefix	Provide the plain MPN via the override, or ask us to configure prefix stripping for your store
A universal product asks for a vehicle or is hidden after vehicle selection	The product has no fitment data and nothing marks it as universal	Mark the product universal via the product-level overrides, or mark its whole collection/category
Fitments from a custom file are not applied	The key column doesn't match the product SKU; the file/folder isn't shared with our accounts; the store wasn't re-indexed	Make sure the key column matches the SKUs exactly, check folder sharing, then force a re-index
Fitments entered on the product are not applied	Wrong format (field order, separators), or an unexpected field name	Check the format in the product-level source guide linked above; contact us if you use a different field
Some vehicles from the data are missing on the storefront	A configured vehicle filter drops them, Make/Model spellings differ between sources, or an invalid year range	Check the store's vehicle filter, fix the spelling or ask us to add a vehicle mapping; check the year format (2017, 2017-2020, 2017+)
Product shows fitments from the wrong source	A higher-priority source returned data (for example, stale fitments left on the product override the catalog)	Clear the stale higher-priority data, or ask us to enable merge mode if you want sources combined
Excluded vehicles still show up / editor changes missing	Editor exclusions apply on top of external data during indexing	Force a re-index; if the problem persists, contact us
Changes to product data or fitment files have no effect	The store hasn't been re-indexed since the change	Use the "Force re-index" button in the app

If a product still maps incorrectly after checking the above, contact [email protected] with the product URL and its SKU — we can trace exactly which source produced (or failed to produce) its fitments.