Executive Summary
When AI search underdelivers on a parts catalog, the engine is usually not the problem; the catalog underneath it is.
Product data sits in an orphan zone between merchandising, IT, and the supplier and standards feeds that pour in through ACES, PIES, or TecDoc. Although every team is affected, nobody owns it end-to-end. As a result, product data issues never show up as a discrete problem. Instead, the issues show up in multiple signals that all indicate you are underperforming by slightly more than you should. In this post, we will dig into common catalog issues and the right way to address them, detailing the following:
- Six dimensions set the ceiling. Fitment, attributes, descriptions, taxonomy, relationships, and assets decide what every capability above them can achieve.
- The engine is often not the bottleneck. Search and recommendations underperform because of the data they were given to reason about. Incomplete fitment also drives returns up, because a part the catalog cannot properly match to a vehicle is a part the buyer sends back.
- Every new AI capability amplifies the core catalog issues. A weak foundation returns a fraction of each new tool’s promise, again and again.
- Cleanup is a discipline, not a project. A one-off pass erodes as soon as new products and supplier files arrive without the same standards. The retailer that builds catalog discipline now earns compounding returns across every capability the platform ships next, and that advantage is not bought in an afternoon.
Catalog Ownership: The Gap Every Team Works Around
Sit in on a quarterly review at almost any parts retailer, and you will hear a version of the same conversation:
- The CDO wants to know why the new AI search has underdelivered, providing only a fraction of the lift expected from the vendor demo.
- The CMO wants to know why personalized recommendations barely moved order value.
- The merchandising team wants to know why filter usage is falling while the catalog keeps growing.
Someone asks whether the platform is the problem. IT defends the platform. Marketing defends the campaigns. Merchandising defends the catalog.
The Problem is Simple: Nobody Owns the Product Data.
Product data quality determines whether an aftermarket catalog can be found, matched to a vehicle, and acted on by search, recommendations, and AI. The problem is, product data is not just one thing. In reality, product data actually has six dimensions, and together these six dimensions set the ceiling on every capability built on top of them.
Understanding what those six dimensions are, and what they look like when they fail, is the first step toward fixing the problem nobody names.
Six Dimensions of Product Data That Set the Ceiling on a Parts Catalog
1. Fitment Completeness
Fitment data is the information that connects a part to the vehicles it fits: the make, model, year, engine, and variant data that ACES and TecDoc exist to standardize.
When fitment is thin or missing, a part that should match a buyer’s vehicle never appears in the search results. A brake pad that fits dozens of models but carries no application data shows up for none of them. The buyer searches, finds nothing, and goes to a competitor whose catalog carries the same part with complete fitment. The same gap also causes returns: when fitment data is incomplete, the platform cannot confidently confirm whether a part fits a specific vehicle, and the buyer who orders the wrong one sends it back.
2. Attribute Consistency
Attributes are the filterable properties that help a buyer narrow the catalog: friction type, pad width, mounting style.
When the same property arrives from four suppliers described four different ways, the filter breaks. Friction material shows up as low-metallic, Low Metallic, low metal, and low_met, and the buyer sees four options for what should be one. Any model trying to generalize across the catalog sees fragmentation it cannot reconcile.
3. Description Quality
The aftermarket has a specific trap here. Product Information Exchange Standard (PIES) data exists to exchange product data between trading partners, but the descriptions suppliers provide through PIES feeds are often republished with little or no differentiation—the same sentence often appears word-for-word on five competitor sites.
Re-using PIES data word-for-word has drastic implications for search relevance, SEO, and AI readability.
There is a 30-second check: search a distinctive sentence from one of your product descriptions in quotes and see if the results include your competitors. If they do, you are all publishing the same feed. The fix is to write unique, structured descriptions on top of the supplier data, not to republish it unchanged.
4. Categorization and Taxonomy
Brake discs and rotors are the same thing. If your catalog lists them as two categories, you have split one stream of demand in half and taught every category-aware model two half-truths.
The same happens whenever a category exists under two names, or a part sits in several overlapping ones.
5. Product Relationships and Job Bundles
A front brake job is rarely one part; it needs pads, discs, and a wear sensor. Whether your catalog knows that, and populates the rest of the job systematically rather than at random, is what product relationships decide.
Good product bundles draw on several sources at once: compatibility data, repair-job logic, supersessions, transaction patterns, and merchandiser judgment. When relationships are random, the recommendation engine trained on them produces random suggestions, and buyers learn to ignore them. The customer buying front pads gets offered a roof bar because nothing in the data says the discs and the wear sensor belong to the same job.
6. Image and Asset Hygiene
Assets get onboarded whenever the supplier sends them, which is why a catalog often has six eras of photography in it at once—inconsistent backgrounds and a mix of aspect ratios and resolutions. Further, some SKUs may lack image assets altogether. When image quality varies part by part depending on when each was onboarded, the browsing experience degrades and visual search features cannot work reliably. A missing image is a product the buyer scrolls past.
Here is what poor product data looks like on a single record:
One catalog record can fail in six different ways.
SKU record
Front brake pad set
Part number Verified against the supplier feed
Fitment No vehicle applications attached
Description Identical to four other records
no vehicle application
The part fits specific vehicles, and the record names none of them, so vehicle search never retrieves it.
attributes conflict
Pad width appears twice with two different values. Filters and models cannot tell which one is true.
description duplicated
The supplier’s text is republished word for word, here and wherever else the same feed landed.
categories overlap
Assigned to three categories that partly contain each other, so category logic splits its demand.
no job bundle
No link to the discs, wear sensors, or fluid the same job needs, so nothing useful gets recommended.
asset mismatch
One image, in the wrong ratio, shot against a different background from the rest of the range.
What do these six dimensions look like side by side? The table below shows the same brake pad record with weak data and with well-engineered data.
| Dimension | Weak catalog record | Well-engineered record |
|---|---|---|
| Fitment | No application data. The pad exists in the catalog but is not linked to any vehicle. Invisible to vehicle search. | ACES/TecDoc fitment covering all compatible makes, models, years, and engine variants. Appears in every relevant vehicle search. |
| Attributes | Friction type is listed as “low metal.” Width field blank. No OEM cross-reference. | Friction type normalized to “Low-metallic” across the catalog. Width, height, and thickness populated. OEM part numbers indexed and searchable. |
| Description | Supplier PIES boilerplate republished unchanged. Same text on three competitor sites. | Unique description with application context, friction characteristics, and terms trade buyers actually search. |
| Taxonomy | Assigned to both “Brake pads” and “Braking,” splitting demand across two category pages. | Single canonical category. No overlapping assignments. |
| Relationships | No related products. The recommendation engine has no ground truth to learn from. | Linked to matching discs, wear sensor, and caliper hardware via repair-job logic. Bundle-ready. |
| Assets | Low-resolution image with inconsistent background, shot at onboarding 4 years ago. | Standardized background, consistent aspect ratio, current product image. |
The first record is invisible to vehicle search, unfilterable by any buyer trying to narrow by specification, and unlearnable by any model trying to recommend it. The second is findable, filterable, and useful to every system above it. The gap between these two records is not a technology problem; it is an engineering discipline applied to the catalog itself. Left unfixed, the consequences of that gap compound across every channel the catalog touches.
How Weak Catalog Data Suppresses Search, Inflates Returns, and Starves AI
Search returns less than it should. Search is one of the highest-intent paths on an aftermarket site, and when it fails, the instinct is to blame the search engine. The actual cause is usually the data the engine has to work with: parts without the fitment that would surface them, descriptions without the terms buyers actually use, categories that fragment what should be unified. The recognition moment is a trade buyer typing “anti roll bar link” and finding nothing, because every record says “stabilizer link.” How that failure decomposes layer by layer is its own article.
OEM part number search fails silently. Trade buyers frequently search by the OEM reference printed on the part they are replacing. When OEM cross-references are missing from the catalog, those searches return nothing. The buyer does not see a wrong result; they see no result. That is a lost order, but because it looks like the search engine failed, the platform team may never realize the root cause was a missing data field, not a missing algorithm.
Incomplete fitment drives returns up. When the catalog cannot confidently confirm whether a part fits a specific vehicle, two things happen: either the buyer abandons the purchase because the product page does not show a fitment match, or they order anyway and receive a part that does not fit.
Returns in the aftermarket are expensive. The buyer does not blame their own research; they blame the retailer that let them order a part that did not fit, and the trust lost in that transaction is harder to recover than the cost of the return itself.
Recommendations feel random. A recommendation model learns from catalog relationships and user behavior. If the relationships are poorly structured, the model has no ground truth to learn from, and its suggestions feel random because, in effect, they are: the customer buying front pads is offered a roof bar because nothing in the data says the discs and the wear sensor belong to the same job.
Most merchants who fail to realize expected ROI from AI will blame the AI when the problem isn’t AI’s fault at all. The model may be working as designed, but the relationships it was given are noise.
Every new AI capability amplifies the core issues. The number of AI tools available to commerce is rising, and each has potential value to aftermarket retailers, but each depends on the quality of the underlying product data. Merchants who adopt agentic commerce, visual search, generative descriptions, or conversational shopping with a weak data foundation will watch each new capability underdeliver and be mystified. That is why the same capability can perform very differently across two retailers using the same AI vendor.
This performance gap between you and your competitors (the ones succeeding with AI) will widen each year as more capabilities stack on the data layer.
The solution is well-engineered product data and recognizing that product data engineering is a compounding contribution (something you will keep doing) rather than a one-off cleanup.
What Changed at GSF Car Parts
Our work with GSF Car Parts clearly illustrates what happens when a retailer decides to fix its product data foundation and its search capabilities together.
GSF Car Parts is a UK parts retailer that today runs its operations using a headless Adobe Commerce implementation. Net Solutions worked with GSF Car Parts to rebuild the product-data pipeline alongside the search and merchandising experience for its customers. After the rebuild, product-data imports fell from as long as 16 hours to 17 minutes and zero-result searches fell from 2.16% to 0.73%. Further, fitment-built bundles now carry an average order value roughly 57% higher than a typical order.
17 min
0.73%
57% higher
Our work with GSF Car Parts demonstrates the combined effect of better product data, fresher pipelines, and innovative commerce capabilities designed for aftermarket buying. GSF Car Parts did not isolate the data layer as the sole cause for underperformance, but instead recognized that a clean data layer was the precondition that made every other investment perform. Modern reference-data and catalog APIs raise the ceiling further, because changes can be processed incrementally instead of rebuilding the whole catalog each time.
The GSF rebuild illustrates what the fix looks like at scale, but the question most teams ask next is not whether it works; it is whether the improvement holds or if the catalog will quietly erode again within six months. That question depends on whether the fix was treated as a project or engineered as a discipline.
Five Disciplines That Keep Catalog Quality From Eroding
The common instinct is to hire a data-cleanup vendor for 12 weeks, clean the catalog once, and declare victory. This approach is doomed to fail because quality starts to erode as soon as new products, supplier files, and manual edits enter without the same standards. What holds is a discipline engineered into how the catalog lives, and that has five parts:
1. Measure Before You Remediate
Score the catalog first, so you fix the highest-impact gaps rather than working through it alphabetically. A score might show that “wipers and filters” carry clean data while “braking” (a high-margin category) is missing fitment on much of the range. Remediation starts at these high-margin categories first, not at the letter A.
2. Remediate By Attribute, Not By Part
Cluster parts by the attributes that most affect retrievability, and fix those across the whole catalog at once rather than one product at a time. If “pad width” arrives from three suppliers as “width”, “pad_width,” and “W (mm)”, normalize that one attribute across every affected record in a single pass instead of opening each brake pad individually.
3. Automate The Bulk, Queue The Judgment
Attribute normalization, duplicate detection, and image standardization can be automated; the calls that need merchandiser judgment go into a prioritized queue rather than blocking the pipeline. A script can find every wrong-ratio image and every duplicated description overnight. Whether two nearly identical filters are genuinely the same part is a merchandiser call, so it lands in the queue instead of stalling the automated pass.
4. Engineer The Onboarding Standards
Required attributes, validation, and quality gates belong in the PIM and ingestion pipeline, not in reminders to the merchandising team. Nonconforming supplier files should fail at the door, where they are a data ticket rather than a lost sale. When a feed arrives with its fitment columns empty, the pipeline should reject it and open a ticket to the supplier; otherwise, the file loads anyway and those parts become invisible to vehicle search.
5. Put Telemetry On Data Quality
Monitor data quality like you monitor uptime, ensuring the catalog cannot degrade silently after the cleanup. This can be done by creating a dashboard tracking fitment coverage, duplicate descriptions, and attribute conformance by category, with an alert when a threshold slips. Such a dashboard would catch a bad August feed in August rather than in the January review.
The competitive position these five disciplines create is durable. A competitor can copy your AI vendor in an afternoon, but they cannot copy several quarters of disciplined catalog engineering. The retailer who fixes the foundation now earns compounding returns across every capability the commerce platform ships next. The one who skips it will keep blaming the AI for a problem the AI cannot solve.
Product data quality is not a glamorous problem. It does not have a vendor demo or get a keynote. But it is the single largest determinant of whether the capabilities above it—search, recommendations, bundles, agentic commerce—deliver what they promised or quietly underperform quarter after quarter. Retailers that treat catalog engineering as infrastructure rather than cleanup are the ones whose AI investments actually compound.
Frequently Asked Questions
Usually the AI engine is not the problem. The catalog cannot be indexed cleanly because fitment is missing, attributes are inconsistent, or descriptions are duplicated supplier text. Fixing the underlying data can improve performance without changing the engine.
No. A one-off cleanup starts to erode as soon as new products, supplier files, and manual edits enter without the same standards. It has to be a discipline, with enforced onboarding rules, validation gates in the PIM ingestion pipeline, and ongoing quality telemetry, not a single engagement.
Trade buyers frequently search by the OEM part number printed on the part they are replacing. When those cross-references are not in the catalog, the search returns nothing. The buyer does not see a wrong result; they see no result and go to a competitor. Because it looks like a search failure, the platform team may not realize the cause is a missing data field.
Yes. When the catalog cannot confirm whether a part fits a specific vehicle, the buyer either abandons the purchase or orders and receives a part that does not fit. Aftermarket returns are expensive, and buyers blame the platform, not the data. Fitment completeness is a direct lever on both conversion and return rate.
ACES and PIES are the North American aftermarket data standards maintained by the Auto Care Association. ACES defines vehicle and equipment fitment, while PIES standardizes product information; ACES 5.0 and PIES 8.0 are the current versions, and the Auto Care Association also provides API access to supporting reference databases. TecDoc is a leading aftermarket catalog and data ecosystem used widely across Europe, with separate services for publishing and receiving frequent catalog updates.
No. Many sellers republish the same supplier text with little or no differentiation, which creates duplicate content that weakens both SEO and AI readability. Write unique, structured descriptions on top of the feed instead – typically owned by the content or merchandising team, with SEO providing guidelines and review.
Score it yourself first. Sample your priority SKUs and rate each against the six dimensions: fitment coverage, attribute consistency, description uniqueness, taxonomy, relationships, and assets. The failures cluster quickly, and the clusters show where retrievability is being lost. If you would rather have it scored and sequenced for you, that is what our AI Growth Readiness Assessment does.
Find the Data Gaps Holding Back Your Commerce Platform
The AI Growth Readiness Assessment examines fragmented data, machine readability, and architectural gaps, then returns a maturity score, an executive report, and a prioritized roadmap showing what to address first.
