Why bad product data continues to limit online store search

What product data does to search quality

A search engine compares the customer’s need with information about the assortment. The more complete and consistent that information is, the better products can be found, filtered and arranged. For example, a product with only a commercial title is difficult to match reliably on material, application or technical feature.

Product data also determines the context. The same term can mean something different in different categories. A size with clothing works differently than a size with furniture; ‘power’ is relevant in electronics but not with care products. Categories and attributes help search understand those differences.

This does not mean that every product feed must be perfect before search can deliver value. However, it must be clear which data fields are essential for the most important customer questions. Start there, instead of cleaning up all the fields at once.

Problem 1: product titles are incomplete or inconsistent

A good product title contains sufficient distinctive information without becoming a list of each available feature. When make, model, product type, size and execution are in random order, matching becomes less predictable and results are harder for customers to compare.

Also pay attention to internal abbreviations and supplier names. A warehouse code can be operationally useful, but a customer doesn't say anything. Conversely, a commonly used customer term may be missing because the supplier uses a technical name. Where possible, store both the source value and a customer-centric view so that search can connect to both.

Create title rules by product group. A usable pattern for a laptop differs from that for a dress or a spare part. Then check that the parts remain available as separate fields; only a composite title makes filtering and targeted boosting more difficult.

Problem 2: Attributes missing, bumping or using free text

Attributes are needed for filters and for search queries in which customers combine multiple properties. If material is missing from half of the products, a material filter can exclude relevant items. When values such as ‘dark blue’, ‘navy’ and ‘navy’ are next to each other without normalization, fragmented filters arise.

Free text is flexible, but difficult to process consistently. For values that customers filter or compare, controlled fields are usually more useful. At the same time, keep sufficient original detail information; too aggressive normalization can lose meaning. For example, a water resistance class is not the same as a general value ‘water resistant’.

Check by category which attributes are mandatory, recommended or irrelevant. Make data quality visible as coverage: what proportion of saleable products has a valid value? Combine that coverage with search volume to determine priorities.

• Missing values for frequently viewed or frequently sought after products.
• Multiple writing modes for the same meaning.
• One field in which several units are mixed.
• Values that are internally correct but incomprehensible to customers.
• Attributes associated with the wrong product group.

Problem 3: Categories follow the organization instead of the customer

An internal or logistics category tree is not automatically suitable for product discovery. Suppliers, warehouses and financial systems group items for reasons other than customers. When search uses that structure without translation, results and filters can feel illogical.

A customer-centric taxonomy helps with query understanding, filter selection and ranking. That doesn't have to mean that all source systems have to use the same tree. A translation layer can link internal categories to sales categories, use cases and alternative inputs.

Pay attention to products that fit in multiple contexts. A water bottle can be relevant under sports, travel and office. One mandatory category should not unnecessarily limit that findability. Work where appropriate with main category, additional classifications, and attributes describing the usage context.

Problem 4: variants, identifiers and availability are not reliable

Variants should be presented as one logical product without hiding important differences. If each color and size appears as a separate result, a result page quickly becomes filled with almost identical articles. If variants are too strongly combined, a search for a specific size or version can wrongly show a product that is not available.

SKUs, EANs and model codes are important for customers who know exactly what they are looking for, especially in B2B and parts. Normalize spaces, dashes, and capitals for matching, but save the original value for display and control. Protect exact identifier matches from broad synonym or spelling rules.

Price and stock must be updated in a timely manner. A highly ranked but not available product can sometimes still be useful, for example with an alternative or expected delivery date. The choice must be conscious. Outdated status that inadvertently affects ranking and filters is a data problem.

Use search data to improve product data in a targeted manner

A complete data audit can be bulky. Search data helps determine the order. Start with commonly used queries, key categories, unsuccessful searches, and terms with remarkably low click ratio. Then investigate which missing or inconsistent data causes multiple problems at once.

Make each finding a concrete data rule. Do not ‘improve titles’, but for example ‘for all saleable running shoes, brand, model, product type and target group are filled separately’. Link the rule to an owner and validate in source, feed, index, and storefront. A correction in one intermediate layer that disappears at the next import is not a sustainable solution.

After a change, do not only measure whether more products are found. Also check relevance, filtering behavior, product clicks and conversion. More results are not automatically better results. The goal is to make the right products more accessible.

• Prioritize customer impact and number of affected products.
• Solve problems as close to the reliable source as possible.
• Add automatic validations for required fields and values.
• Test important queries again after each major feed or taxonomy change.
• Establish exceptions so that temporary repairs do not become permanent fault.