Product feed management: keep your products accurate across shopping channels

Feed management keeps product records moving from approved sources to the destinations that use them. It includes maintaining product identity, translating source fields into each destination's supported attributes, handling exclusions and reviewing processing errors. For a growing retailer, the useful outcome is fewer mismatches, clearer ownership and a repeatable way to investigate an error before it turns into a recurring manual repair.

Feed optimisation is related but narrower: it improves the quality or usefulness of the information you submit. A working delivery process can distribute weak information perfectly, and excellent source data can be undermined by a stale mapping or a failed update.

Keep those two questions separate: is the record good, and did the intended record arrive? The product data optimisation guide covers the first; this article covers the second.

For one product, identify its authoritative sources, the transformation rules applied to it, the export or integration that carries it, the destination record and the live landing page. Record who owns each stage and what evidence shows its most recent successful update.

“It comes from Shopify” is not enough detail if an app, a supplemental file or a manual rule changes the value afterwards. A successful export message proves that one stage completed; it does not show that every destination accepted and displayed the new value.

A simple trace record for each disputed field turns a vague disagreement into a specific investigation:

• the SKU and the field;
• the approved source value and when it was set;
• the transformed value;
• when it was published;
• the destination's processing status;
• the value observed live, and when you observed it.

Imagine a lamp reduced from £85 to £72 in the store. The product page and checkout show £72, while a destination record still shows £85. These are illustrative values, not a client incident.

First confirm you are comparing the same variant, currency, market and pricing context. Then inspect the current source value, the transformation and the destination's latest processed record. Where the old price survives tells you which stage to investigate:

• If the export still contains £85, investigate the source selection or the rule.
• If the export contains £72 but the destination processed an older file, investigate delivery and processing.
• If the destination holds £72 but a shopping surface still displays £85, record that distinction and investigate the remaining update stage.

For Merchant Center, Google's price specification asks for an amount and currency that match the price on your landing page and checkout pages. Use that destination's own rule to guide the repair, rather than assuming a correct value somewhere in your systems is enough.

Keep stable internal references so you can trace a sellable item across systems, and document which field identifies a product family and which identifies an individual variant. Do not substitute a product title for a stable key just because titles look unique in today's export.

Google's product data specification asks you to keep an item's id the same when you update your data, and to give each group of variants its own item group id that also stays the same.

Test what happens when a title changes, a variant is retired or a supplier introduces a new model. If those events create duplicates or overwrite sibling variants, the identity mapping needs attention.

Where barcodes and part numbers are involved, verify the item they describe rather than copying values between columns. The guide to GTINs, EANs and MPNs explains how manufacturer references differ from internal stock codes.

A useful feed rule has a purpose, an owner, a scope and a test example. “Add capacity to the title when a verified capacity exists” is clearer than a chain of transformations nobody can explain.

Write the exception into the rule. What happens when capacity is missing, the product is a bundle or the source holds conflicting units? Leave unsupported values out and flag the record, instead of filling every field with a plausible-looking default.

Keep previous versions of each rule and an export of the records it affected. Before applying a change to the full catalogue, try it on a small batch that includes ordinary products and the awkward cases.

Each destination has its own accepted formats, attributes and rules. Map the same approved facts into those requirements, and never create conflicting specifications to make one export look more complete.

The receiving end shows why. SO-ME, the consumer shopping platform Sighted powers, takes feeds from ASOS, REVOLVE, Vinted, M&S, New Look, Debenhams and EGO, and the attributes they carry and the way they categorise the same kind of product differ from one feed to the next. Any system reading several feeds has to reconcile those differences before it can compare products.

For Merchant Center, Google's product data specification marks each attribute as required, optional or dependent on the product, and some requirements differ by target country. For any other destination, check its current specification and the integration you actually have. One accepted Google record is not proof that a product is eligible anywhere else.

A feed does not remove the need for a clear, accurate product page that a shopper can read. The guide to feeds, schema and product pages explains how the three representations complement each other.

Group feed issues by cause and severity:

• A wrong price or an availability conflict may need urgent operational attention.
• A missing optional attribute may be a planned enrichment task.
• An unsupported certification claim should be held until there is evidence for it, rather than reformatted again and again.

Every exception should name the affected records, the destination, an owner, the next action and when it was last checked. Close it only when the intended output has been verified at the destination; “file regenerated” is an intermediate step, not necessarily a resolution.

Track recurring causes. If the same material mapping breaks with every supplier update, fixing individual rows becomes expensive maintenance, and correcting the source contract or the transformation may remove the repeated work.

AI shopping gives retailers more reasons to make product information answer detailed purchase questions. It does not remove the need for dependable distribution: enriched facts are worth little if they never reach the sources you intend to update.

Do not treat a feed submission as a guaranteed recommendation. OpenAI's feed, for instance, rejects a row with a missing required field or an availability value it does not recognise, one of the causes the ChatGPT troubleshooting guide walks through.

Verify delivery and acceptance first, then observe visibility as a separate question. The AI shopping measurement guide connects these operational checks to recommendation observations and commercial outcomes.

Is a product feed the same as product structured data?

No. They are different representations that reach shopping systems by different routes. Keep both aligned with the approved product and offer wherever you use them.

How often should a product feed update?

Choose an update process that reflects how quickly your information changes and what the destination supports. Monitor delays against your own operational needs instead of assuming one interval suits every catalogue.

Do you need feed management software?

It depends on how many destinations you send to, how complex your transformations are, how many errors you see and how maintainable your current process is. Document the failure first; a new tool will not supply product facts that are missing at source.

1. For one disputed product, write down its sources, rules, export, destination record and live page, with each stage's owner and its last successful update.
2. Confirm you are comparing the same variant, currency, market and pricing context, then check the source value, the transformation and the destination's latest processed record in that order.
3. Document which field identifies a family and which a variant, and test a title change, a retired variant and a new model against the mapping.
4. Give each feed rule a purpose, an owner, a scope and a test example, and try a change on a small batch before the full catalogue.
5. Map the same approved facts into each destination's current specification, checked against the integration you actually have.
6. Run an exception queue that names the records, the destination, an owner, the next action and the last check, and close an item only once it is verified at the destination.
7. Verify delivery and acceptance first, then observe visibility with a defined method.

Sighted builds a Merchant Center feed in Google's format from your approved product data, one item per variant with that variant's own price, stock, identifiers and image, and can send it to your Merchant Center account through Google's Merchant API. Only approved rewrites reach a feed, whether you approved each one or switched on automatic approval. The trace, the rules and the decision on a disputed source value stay with your team.

• A product missing a field the destination requires is left out rather than sent broken, and the Publish page shows how many products went into each feed, how many were left out and how many items Merchant Center rejected on the last push.
• The feeds rebuild after each enrichment run, and after a publish when automatic export is on. Each rebuild is pushed to Merchant Center when it is connected, and a full push runs every week as well.
• A store on any platform can start from a CSV or feed URL, and the Merchant Center guide covers what the feed carries.
• The free AI visibility audit shows what up to 50 of your product pages state before any feed is built from them; the enrichment that fills the record is the technology behind SO-ME.