Product data optimisation: make your products easier to find and choose

It covers facts such as dimensions, composition and compatibility, alongside titles, descriptions, images, identifiers and current offer details. Done well, it gives customers clearer answers, helps your team keep listings consistent and gives search and shopping systems a more accurate picture of what you sell.

Product data enrichment adds useful information to an existing record. Optimisation is broader: it also removes incorrect claims, resolves conflicts, fixes mappings and keeps information current. Replacing a stale price can matter more than adding another paragraph.

Facts and prose are separate. “24 litres” is a capacity value; “room for your daily essentials” is a description. The second may help explain a product, but it cannot stand in for the first when a shopper is comparing capacities. The product data audit entry covers the assessment stage; this guide covers what to do with the findings, across hundreds or thousands of products, without creating a queue of AI-written copy someone has to fact-check from scratch.

Start with a manageable batch: a small team might pick 20 available products in a commercially important category rather than every listing at once. Weigh four things together:

• commercial relevance;
• how much the missing information matters to a purchase decision;
• the scale of the inconsistency;
• whether you can get reliable evidence.

A popular item with an unanswered compatibility question may come before a low-demand item missing a decorative description.

Separate urgent corrections from enrichment opportunities. An incorrect price or a misleading material claim needs attention even on a product that rarely sells; a missing lifestyle paragraph does not carry the same urgency.

Put products whose source facts are unavailable in an exception queue with an owner, or the team keeps rediscovering the same gap and drafting copy it still cannot approve. The AI product readiness checklist helps find the issues before you prioritise the repairs.

A batch also gives you something to read the result against. In Sighted's pilot with The Bean Coffee Company the pilot products were enriched, and their revenue rose 31% against 10% across the rest of the catalogue, with search clicks going from 121 to 366. The rest of the range is the comparison, and a catalogue changed all at once has none.

For each important attribute, record the proposed value, its source, the variant it applies to, the person responsible and the date checked, with an approval state: verified, conflicting or unknown.

Choose the authoritative source field by field. A supplier specification might support material composition, a documented physical measurement the dimensions, and your commerce system the current price and availability. No single spreadsheet is authoritative for everything.

Where sources disagree, keep the conflict and assign a decision. If the supplier says 22 litres and the packaging says 24, do not average them or let an AI model pick the more attractive figure. With the fact map in place, a reviewer answers a shorter question, whether the proposed change faithfully reflects an approved source, instead of investigating every sentence from the beginning.

This record is an illustrative demonstration, not a live retailer SKU, a client result or a measurement of AI visibility. The existing title is “Everyday Backpack - Black” and the description “Your perfect companion for work and travel.” The SKU is EB24-BLK, with a separate navy variant, EB24-NVY.

An approved supplier specification confirms a 24-litre capacity, external dimensions of 45 × 30 × 20 cm and a 600D polyester outer fabric for both variants. The black variant's commerce record shows £69, in stock. The manufacturer has supplied no waterproof rating or laptop-fit specification.

Title: add identifiers without promising performance

Approved: “Everyday 24L Backpack - Black”, from the product name, the confirmed capacity and the black variant record, published to the title and supported title fields within each destination's rules. It adds a comparison attribute and keeps the item's identity. “Waterproof cabin-approved laptop backpack” would claim three things the evidence does not establish.

Dimensions: keep the units and say what was measured

Approved: “External dimensions: 45 cm high × 30 cm wide × 20 cm deep”, from the supplier specification, shown on the product page and in the relevant fields. A bare “45 × 30 × 20” is easier to misread, and these are not the dimensions of a laptop compartment.

Material: keep the scope of the fact

Approved: “Outer fabric: 600D polyester.” That says nothing about the lining, the straps or recycled content, and the shorter, precise statement is stronger for it.

Variants: connect the right colour, image and offer

Keep EB24-BLK and EB24-NVY as distinct records with their own colour, image and offer, and check the black page does not inherit the navy image or another variant's availability. Google Merchant Center's item group ID lets eligible variants share a group identifier while keeping their own records and distinguishing attributes; follow each destination's rules rather than merging variants into one listing.

Price and availability: use the live operational source

The £69 and in-stock values come from the commerce record. Send updates through the established publishing process, check the live variant, and keep changing values out of evergreen copy that will not update with the offer.

Shopper questions: answer only what the evidence allows

Asked “Will it meet my airline's personal-item allowance?”, the approved answer is: “The backpack's external dimensions are 45 × 30 × 20 cm. Compare these with your airline's current allowance for your ticket before travelling.” It helps without claiming an approval nobody has established.

The resulting description

“Carry your everyday essentials in a 24-litre backpack with a 600D polyester outer fabric. This black version measures 45 cm high × 30 cm wide × 20 cm deep externally. Check these measurements against your own storage or travel requirements before ordering.” Brand voice can change its rhythm and tone; it should not change its capacity, materials or limitations.

Suppose an AI draft says: “Stay dry in any weather with this waterproof backpack, designed to fit a 16-inch laptop and approved for all major airlines.” The whole sentence has to be held. A photograph of a coated-looking surface is not a waterproof rating, external dimensions do not establish laptop-compartment fit, and a bag's size does not prove universal airline acceptance.

Use separate review outcomes: approved, revise, evidence required and rejected. Record the reason beside the claim so the next draft does not bring it back, and ask the supplier for missing technical evidence where the answer matters commercially.

AI is useful for extracting supplied facts, finding gaps, standardising units and drafting explanations, and more useful still when the source material and approval rules are explicit. Fluent wording is not evidence.

A corrected spreadsheet does nothing for a customer until the published product reflects it. Decide how the approved record reaches the commerce platform, the visible product page, structured data and the relevant feeds. Google's Merchant Center product data specification holds the current attribute definitions and requirements, which vary by product and destination; a sensible internal field is not automatically a supported feed attribute.

Keep important purchase information visible to shoppers and keep structured data aligned with the product and offer; the guide to feeds, schema and product pages explains their different jobs, and for ChatGPT the visible page is the record most product cards are built from, as the ranking factors guide sets out.

Where supported, Merchant Center's conversational attributes give you another place for useful shopper context. Do not force every question into an unsupported field or assume every platform distributes it the same way.

After publishing:

• Open the actual variant and check its title, image, dimensions, material, price and availability against the approved record.
• Inspect destination diagnostics to confirm the update arrived, rather than trusting a successful export message.
• Test a small batch before a catalogue-wide change, and keep the previous values.
• Record what was approved, by whom and when, and recheck exceptions after syncs and supplier updates.

Keep operational measures apart from commercial outcomes. Fewer missing attributes, fewer conflicting values and shorter review time say whether the process improved; visibility observations, relevant visits and purchases answer different questions. A readiness score helps prioritise, but a higher score is not proof of more sales.

Is product data optimisation the same as rewriting descriptions?

No. Description writing is one part. Optimisation also covers identifiers, specifications, variant relationships, images, current offer details, publication mappings and the processes that keep them accurate.

Can AI fill missing product attributes?

It can extract and organise facts from supplied evidence and flag what is missing. Do not approve a value because a model predicts it confidently; if a claim needs supplier confirmation or measurement, get that evidence first.

Which product attributes matter most?

Start with the information that affects identification, suitability and purchase decisions in your category, alongside destination requirements. Compatibility may be critical for an accessory; composition and fit matter more for clothing. No universal enrichment list replaces category expertise.

How often should product data be reviewed?

Match the review to how the field changes. Offer data needs a reliable update process; stable specifications need review when products or source records change. Assign owners and a cadence, with alerts for conflicts rather than one annual clean-up.

1. Pick a batch of around 20 available products in a commercially important category, and put products with no source facts in an exception queue with an owner.
2. Build the fact map: for each attribute, the proposed value, its source, the variant, the person responsible, the date checked and an approval state.
3. Optimise each record field by field, keeping every value within what the approved source establishes.
4. Review each AI draft claim by claim, marking it approved, revise, evidence required or rejected, with the reason recorded beside the claim.
5. Publish the approved record to the commerce platform, the visible page, structured data and the relevant feeds, within each destination's rules.
6. Open the live variant and the destination diagnostics to verify the change, then measure process improvements and commercial outcomes separately.

Sighted scores every product on the fields shopping assistants read, drafts the missing ones from your own descriptions, options and photos, holds each claim to what that data supports, and publishes to your store and channels once you approve, or automatically if you switch that on. It does this at catalogue scale, the technology behind SO-ME, and on Shopify each approved value goes into the category attribute the store already has for it.

The free AI visibility audit is the scoring step on up to 50 of your product pages. Every important field still needs a source and an owner, and every uncertain claim an exception route.