Product Feed Management: Stale Feeds Get Disapproved

A product feed is a file listing your catalog in a format somebody else's system reads. Google Shopping, Meta, Amazon, an affiliate network, a comparison site. Each one has its own required fields, its own vocabulary, and its own opinions about what counts as valid.

Feed management is the work of keeping those files correct while your catalog changes underneath them. It is unglamorous and it directly gates paid performance, because a disapproved product cannot be advertised no matter how much you bid.

The three things a feed has to be

Complete. Every required field present. Which fields are required varies by channel and by product category, and the requirements change without asking you.

Accurate. Matching what a customer will actually find. Price and availability in particular, because those are checked and being wrong is a disapproval rather than a warning.

Current. Reflecting your catalog now rather than the last time somebody remembered to export it.

Most feed problems are the third one. The feed was correct when it was built.

Where feeds actually break

Price and availability drift

You run a sale. The feed still carries the old price. The channel compares the feed to your landing page, sees a mismatch, and disapproves the product, sometimes the whole account if it happens broadly.

Same with stock. An out of stock product still being advertised wastes budget on clicks that cannot convert and irritates the people who click.

The fix is generation frequency. Hourly is a reasonable floor for a store with changing prices. A daily export is fine for a static catalog and dangerous during a promotion.

Identifiers

GTIN, MPN, brand. Channels use these to match your product to the same product everywhere else, and matching is what gets you into comparison surfaces at all.

A missing or wrong GTIN is the most common single cause of poor Shopping performance, and it is invisible because the product still runs. It just runs worse than the identical product from a competitor whose identifiers are right.

Variants

Feeds want one row per buyable thing, not one per product. Every size and colour is its own row, with its own identifier, its own price, its own availability, and a shared group identifier tying them together.

Stores that send one row per product lose most of their catalog from the channel's point of view.

Titles written for the wrong reader

Your product page title is written for a person browsing. A feed title is matched against a search query, and the useful ones front-load what somebody would type: brand, product, then the distinguishing attributes.

Nobody searches for the clever name. This is the biggest single improvement available in most feeds and it costs nothing but an hour.

Category mapping

Each channel has its own taxonomy, and yours does not map onto it cleanly. Mapping is a manual decision per category, and it is worth doing carefully because it decides which searches you are eligible for.

Restricted products

Some categories are outright prohibited, some are restricted by region, and the rules move. If you sell hemp, vape, supplements or anything similar, a rejection is frequently a policy question rather than a data error, and no amount of feed tidying fixes it. Read the channel's current policy directly rather than a summary.

The structural question

Three ways to produce a feed, and the differences matter.

Manual export. A spreadsheet, uploaded. Works for a small static catalog. Becomes stale the first time you change a price and forget.

A feed tool. Reads your store, transforms, publishes to each channel, with rules and mapping in an interface. Genuinely useful at multi-channel scale, and it introduces a copy of your catalog that is a few minutes to a few hours behind reality.

Generated from the catalog directly. The feed is a view of your live product data rather than an export of it. Nothing to fall behind, because there is no second copy.

The third is the right shape when the store's catalog is already the source of truth and the transformation is not complicated. The second earns its keep when you are on many channels with different rules and want somebody's interface for managing them.

What to check this week

Open your channel's diagnostics and read the disapprovals rather than the summary count. Pick three live products and compare the feed price to the landing page price right now. Confirm variants are appearing as separate rows. Check that identifiers are present on everything that has one. And look at when your feed was last generated, because that number explains most of what you find.

Where we fit, and where we do not

Because the catalog sits behind an API with variants, identifiers, attributes and stock on the record, generating a feed from live data is a small piece of work rather than an export pipeline, and it cannot go stale because there is nothing cached between the catalog and the file. The same modelling that makes product data correct in one place is what makes feeds correct downstream.

Where we are the wrong answer: if you publish to many channels with different taxonomies and rule sets, a dedicated feed tool has an interface for that and we do not. If you are on a hosted platform with a working feed app, this is not a reason to move. And if your problem is that a channel prohibits your category, that is a policy conversation and no platform solves it.

The short version

Feeds fail from staleness more than from anything else. Fix generation frequency first, then identifiers, then variant rows, then titles. The rest is mapping, and mapping only has to be done once.

If you want to see what the catalog exposes for building a feed, the docs have the product and variant fields.