Building a Product Data Standard

A shopper selects “Blue” and sees no results even though blue products are in stock. The catalogue contains Blue, blue, Navy Blue and BLU, while the filter expects one exact value. A shopping feed rejects a group of items because identifiers are missing. Search misses an available part because the specification lives inside a paragraph instead of the searchable field. These are not cosmetic defects. They interrupt discovery, channel acceptance and purchase.

Product data is infrastructure: a schema shared by the storefront, search, filters, inventory, marketplaces, advertising feeds, fulfilment and reporting. Typing more carefully cannot repair an undefined schema. The foundation is a written data standard—a category-aware attribute dictionary, controlled values, identifier rules, variant structure, source evidence and validation at entry.

The symptoms that trace back to product data

Catalogue defects often appear far from the field that caused them:

• Empty or fragmented filters result from inconsistent attribute names, values, units or category assignments.
• Feed warnings and disapprovals result when a channel’s required or conditionally required field is absent, malformed or inconsistent with the landing page.
• Weak internal search results when model numbers, synonyms and specifications are missing from structured or indexed fields.
• Suppressed marketplace listings can result when the selected product type and its current attribute requirements do not match the record.
• Overselling or wrong fulfilment occurs when variants share identifiers, parent records carry child-level stock, or channel matching joins the wrong items.
• Misleading comparisons occur when dimensions or capacities use mixed units without explicit conversion.

Measure the commercial effect locally. For filters, inspect zero-result combinations and exit. For feeds, count rejected items and impressions lost while unavailable. For search, sample high-intent terms against in-stock products. For returns and support, analyse reasons linked to size, compatibility, material or specification. A tidy spreadsheet is not the outcome; a product must be findable, understandable, matchable and fulfilable.

What a complete product record contains

A robust record has distinct layers. Mixing them creates ambiguous ownership.

Identity

Internal SKU, external barcode or GTIN where valid, manufacturer part number, brand, supplier identifier and platform record IDs connect the same sellable item across systems. Identity fields should not be repurposed as titles or regenerated because wording changes.

Taxonomy

Internal category, storefront collections, product type and channel classifications determine which attributes apply and where the item appears. Category is not merely navigation. It activates validation, filter and marketplace rules.

Descriptive attributes

Material, colour, size, capacity, compatibility, pattern, finish and technical specifications support filters, comparison, search and customer decisions. Values need a source and a declared unit. Marketing claims belong in descriptive copy, not inside factual specification fields.

Variant structure

Parent or group relationships define the shared product; child records define each sellable combination. Price, stock, barcode, image, weight and sometimes compliance data belong at variant level when they differ. The distinction affects stock accuracy and feed grouping.

Media and channel fields

Primary and additional images, alt text, video, title, description, URL, publication state and channel-specific attributes have different formats and policies. Store a durable master record, then transform it into channel outputs rather than forcing one overloaded field to serve every destination.

Compliance and operational specifications

Country of origin, age or safety information, ingredients, energy data, hazard restrictions, dimensions, shipping weight and other regulated or operational fields require authoritative evidence. Which fields apply depends on product, destination and channel. A data-entry team should record verified values and escalate gaps, never infer a compliance answer.

The attribute dictionary is the controlling artefact

Create one dictionary per category family, with shared global fields inherited. Each row should define:

• canonical field name and plain-language definition;
• data type, length, format and multiplicity;
• allowed values or controlled vocabulary;
• unit of measure and conversion rule;
• required, conditional or optional status;
• parent, variant or both as the correct level;
• authoritative source and acceptable evidence;
• storefront, feed and marketplace mappings;
• validation rule, error message and exception owner;
• dictionary version, effective date and steward.

Consider a hundred lamps whose supplier files describe colour temperature as 3000 Kelvin, 3000K, Warm White and warm-white. If the factual value is confirmed as 3000 K, the master model can store numeric 3000 with unit K and map it to the controlled customer label Warm White. Filters, comparisons and feeds then receive predictable values. The source value remains available for traceability.

Do not normalise distinct concepts into one label. Navy may be intentionally separate from blue; a UK size 8 is not automatically a US size 8. The category owner decides the customer-facing taxonomy, and conversion must be documented with evidence.

Writing the dictionary delays the first upload because definitions and exceptions must be decided. That is the useful delay. Without it, every operator makes local decisions and the team pays for reconciliation across hundreds of records.

Settle variant structure before the next hundred products

A variant should represent a sellable version of the same underlying product, not merely two items that look related. Ask:

• Which options does the customer choose before adding to cart?
• Does each combination have its own stock, price, barcode, weight or image?
• Which attributes are shared by every child and which differ?
• Can any option combination be impossible, and how will it be prevented?
• How does each channel represent parent-child relationships?
• What happens to orders, URLs, reviews and reporting if the family changes later?

Example: size and colour may be valid options for one shirt. “Pack of three” could instead be a separate product if its barcode, price basis, imagery and merchandising differ materially. A repair part that is “compatible with Model A” is not a variant of Model A. Model the commercial object, not the convenience of one upload sheet.

Restructuring later is expensive because variant IDs may be referenced by orders, inventory, ads, integrations and reporting. Export the current relationships before any migration. Create an old-to-new crosswalk, define redirects and channel impact, test a low-risk family and preserve historical identifiers where the platform allows.

Platform constraints change. Shopify’s current documentation explains that each combination of option values becomes a variant, and category metafields can make values reusable; check the current Shopify variant guidance before designing a large family. Treat platform limits and feature support as current configuration, not permanent catalogue architecture.

Identifiers make matching possible

An SKU is an internal operational identifier. Define a convention that is unique, stable, documented and safe for all connected systems. Avoid encoding facts likely to change, such as supplier, price or aisle. Do not reuse a retired SKU for a new product. Give every sellable variant its own SKU and preserve a cross-reference when legacy codes must remain searchable.

A barcode or GTIN is not the same as an SKU. Use a valid identifier issued or supplied for the exact trade item; do not invent one, copy a related variant’s code or add digits to make a field pass. Manufacturer part numbers identify the maker’s product and should preserve meaningful punctuation and case according to the source and channel rules.

Shopify’s official SKU guidance recommends unique SKUs for effective tracking and distinguishes them from barcodes. Google and marketplace requirements are category and condition dependent, so maintain separate mappings and exception evidence instead of declaring every identifier universally required.

Deduplication should use several signals: GTIN, brand plus manufacturer part number, supplier identity, normalised title, key specifications and images. A high-confidence match can be reviewed for merge; a fuzzy title alone should never trigger automatic deletion.

Build for channel requirements, not assumptions

Google Merchant Center defines attributes and accepted values in its current specification, including fields that are required for all items and fields required only in certain conditions. Incorrect formatting can prevent a product from being added. Use the live Google Merchant Center product file guidance and its linked specification when generating a feed; do not copy last year’s column list.

Amazon’s Selling Partner API exposes product-type and marketplace-specific schemas, including attribute requirements and conditionality. The official Amazon product listings guide describes retrieving those definitions. A category template saved locally must be versioned and refreshed because enumerations and requirements can change.

Keep channel validation separate from master-data validation. The master record may be correct while a destination requires a transformed title, grouped variants, different taxonomy or additional field. Record the transformation rule, channel error and last successful publication. Do not “fix” a master specification to satisfy an unrelated channel format.

Run bulk operations through staging

Import templates, staging and validation

Never use the production catalogue as the place where a bulk file is cleaned. Export a dated baseline, work in a controlled staging copy and identify records with stable platform IDs and SKUs. Lock template headers, types and value lists. Validate required fields, uniqueness, parent-child links, allowed values, units, URLs, image availability and cross-field logic before import.

Separate create, update and delete actions. A blank may mean “leave unchanged” in one importer and “erase value” in another. Test that behaviour explicitly. Include an operation ID in the file or change log so every modified record can be traced to the source batch and approver.

Sample, compare and prepare rollback

Run a small batch representing simple, variant, multi-image and exception products. Inspect the storefront, filter, search, inventory, structured data and channel output—not just the import success message. Compare counts and totals before and after: products, variants, active records, identifiers, prices, inventory quantities, missing required fields and feed issues.

Define rollback before the full run. Preserve a restorable export and document which fields the platform can restore without changing record IDs. Pause downstream syncs if they could propagate a bad change. Approve the sample, run in bounded batches and stop automatically when error thresholds are crossed.

Clean an existing catalogue by impact

Profile first. Count nulls, distinct values, format patterns, duplicate identifiers, invalid relationships, unused categories and channel errors. For a field such as colour, compare raw distinct values with the intended controlled list. For dimensions, detect mixed units and implausible values without silently converting them.

Prioritise by revenue, traffic, feed exposure, return or support reason and business risk—not alphabetically. Clean top categories and high-demand SKUs first, but stop new errors at entry simultaneously. Otherwise the backlog shrinks while daily onboarding rebuilds it.

1. Define the category dictionary and source hierarchy.
2. Standardise high-impact attributes and units.
3. Repair parent-child structures and identifiers cautiously.
4. Deduplicate through reviewed match candidates.
5. Fill evidence-backed gaps and mark unavailable facts explicitly.
6. Republish channels, capture errors and update transformation rules.

Physical measurement may be needed when reliable source data does not exist. Record method, unit, precision and whether the value is product-only or packaged. A person measuring a sample cannot assume every supplier revision is identical.

Quality control that scales

Prevent errors with field controls: required states by category, dropdowns for allowed values, numeric bounds, format checks, uniqueness, cross-field logic and referential integrity. Automated checks catch conformity, not truth. A value can be correctly formatted and factually wrong, so compare a sample with supplier evidence, packaging or an approved technical source.

Distinguish:

• Critical error: wrong identifier, price, compliance fact, compatibility, variant link or other defect likely to mislead, misfulfil or create material risk.
• Major error: missing or wrong discoverability field, image association, unit or channel attribute that impairs publication or customer choice.
• Minor error: a permitted formatting or style defect with limited functional effect.
• Variance: a different value that remains correct under the standard, such as an approved synonym in free text.

A contract should define fields in scope, source hierarchy, error classes, measurement unit, sampling method, acceptance threshold, review period, rework, critical-error treatment and disputed-case process. “99% accuracy” is meaningless unless everyone knows whether accuracy is measured by record, field or weighted critical field. Set the standard from business risk, baseline and review capacity rather than promising a universal rate.

Normalise supplier data before it enters the master

Supplier files are inputs, not ready catalogue records. One may provide centimetres, another millimetres and a third no unit. Marketing sentences appear in material fields. A blank can mean unknown, not applicable or unchanged. Images may have ambiguous filenames, duplicates or channel-incompatible formats.

Create a supplier mapping: source column to canonical field, unit conversion, value translation, identifier rule and exception. Preserve the raw file and received date. Reject or quarantine ambiguous values. If one source conflicts with another, follow a documented hierarchy—manufacturer specification, verified packaging, authorised supplier record or physical measurement as appropriate—and log the decision.

AI can draft titles, descriptions and attribute candidates from supplied evidence, then a person can review them against the standard. It must not invent dimensions, ingredients, compatibility, safety or compliance claims. A plausible fabricated specification can cause returns, suppression or liability. Use “unknown” and request evidence when fact is unavailable.

Build the ongoing catalogue operation

Steady-state work includes new-product intake, seasonal status, price and specification changes, discontinued products, image and document updates, channel mapping, error repair and dictionary maintenance. Give each change type a source, approval, effective time and validation.

Estimate capacity from a timed pilot. Segment simple products, variant families and research-heavy exceptions. For each segment:

Daily accepted records = productive minutes ÷ median end-to-end minutes per accepted record.

Include research, QA, correction and upload time. Multiply by working days and compare with new-product volume plus backlog. This is stronger than quoting one products-per-day number across categories. An internal team can absolutely run the operation if ownership and protected capacity exist; the usual failure is that catalogue work is repeatedly displaced by urgent merchandising and trading tasks.

OVELITHUB structures product data entry services around the client’s dictionary, source hierarchy, staging and review controls. A supervised team can onboard and cleanse records, maintain exception queues and produce batch-level quality reporting. Wider store operations belong with ecommerce data entry services; listing merchandising and inventory planning remain separate functions.

A 30-day recovery plan

1. Days 1–5: profile. Sample top categories and long-tail items; quantify missingness, distinct values, duplicate identifiers, variant defects and channel errors.
2. Days 6–12: define. Write the dictionary for the top categories, establish source hierarchy, choose controlled values and map channel requirements.
3. Days 13–22: repair. Clean high-revenue and high-traffic records in staged batches; validate storefront, feeds and stock relationships.
4. Days 23–27: stop drift. Add entry validation, supplier mappings, exception ownership and change approval.
5. Days 28–30: operationalise. Set intake service levels, sampling, audits, dictionary stewardship and capacity based on pilot throughput.