A product data feed is a structured file (usually XML, CSV, or JSON) that carries your product information from your source system into every channel that displays it, including your digital catalog. When the feed refreshes, the catalog refreshes with it, so a price change made in your PIM or ERP shows up on the catalog page without anyone touching the layout. That connection is what separates a catalog that stays accurate from one that quietly goes wrong three days after publication.
The reason this matters is timing. Catalog design happens weeks before publication, but prices, stock, and product attributes keep moving right up to the moment a shopper opens the page. Without a feed, someone has to notice each change and fix it by hand. With one, the catalog is reading from the same source of truth as the website, and the two stop disagreeing with each other.
What Actually Sits Inside a Product Feed
At minimum a feed carries an identifier, a title, a description, a price, a stock status, an image URL, and a link to the product page. The identifier is the piece everything else depends on, usually a SKU, GTIN, or EAN, because that is how a catalog page knows which row of the feed belongs to which product on which spread. Get identifiers wrong and every other field lands on the wrong product.
Beyond the basics, feeds usually carry variant data (size, color, material), category paths, brand, sale price with a validity window, shipping attributes, and any custom fields a retailer has defined. A furniture retailer might include dimensions and assembly requirements. A grocer might include unit price and allergen flags. A B2B supplier might include minimum order quantity and tiered pricing, which is exactly the data that used to require a phone call.
The quality of a feed shows up in its edge cases rather than its happy path. What happens to a discontinued SKU, whether a product with zero stock is removed or flagged, how a multi currency catalog handles regional pricing, whether a bundle appears as one row or several. Feeds that handle these cleanly tend to have been built deliberately. Feeds that do not tend to produce catalogs with phantom products in them.
How Often a Feed Should Refresh
Refresh frequency should follow how fast the underlying data moves. Grocery and pharmacy promotions change weekly and stock changes hourly, so hourly or near real time syncing is reasonable. Fashion and general retail often sit comfortably at two to four refreshes a day. Furniture, industrial, and made to order categories can run daily or even weekly without anyone noticing, because a lead time of 10 weeks does not change between breakfast and lunch.
There is a cost to over syncing, which is why the answer is not simply “as often as possible.” Every refresh puts load on the source system, and very frequent full file pulls can be heavy. Delta feeds, which send only what changed since the last sync, solve most of this and are worth asking about if your catalog covers more than a few thousand SKUs.
The failure mode people underestimate is the silent one. A feed that stops updating does not throw an error on the catalog page, it just keeps showing yesterday’s data indefinitely. Monitoring the timestamp of the last successful sync, and alerting when it goes stale, catches more problems than validating the file contents ever will.
Where Feeds Break and What It Costs You
The most common breakage is a schema change upstream. Someone renames a column in the ERP export, the mapping no longer matches, and a field arrives empty. Prices drop to zero, images disappear, or descriptions default to the SKU. Validation rules that reject a file outright when a required field is missing are better than rules that let a partial file through, because a stale catalog is less damaging than a wrong one.
Image handling causes its own problems. Feeds carry image URLs rather than image files, so if the image host changes paths or a CDN rule blocks hotlinking, the catalog fills with gaps. Retailers with large assortments often find that a small percentage of images fail on any given sync, which sounds tolerable until it lands on a hero product.
Then there is the commercial cost of being wrong. Research into ecommerce behaviour has consistently linked inaccurate pricing and stock information to abandoned carts and to returns, and the damage is not limited to the sale you lose. A shopper who clicks a catalog page and lands on a product that is out of stock or priced differently learns not to trust the catalog, which is a harder thing to repair than a broken sync.
Feeding a Catalog Versus Feeding a Marketplace
Retailers usually already run feeds for Google Shopping, Meta, Amazon, or a marketplace, and it is tempting to point the catalog at the same file. Sometimes that works. Often it does not, because marketplace feeds are shaped to satisfy that channel’s validation rules rather than to describe products fully. The Merchant Center specification is a good illustration, since it defines exactly which attributes are required, optional, or rejected, and a file built to pass it will have been trimmed accordingly. A Google Shopping feed might strip the long description, flatten variants, and omit attributes that a catalog page would genuinely want to display.
The better pattern is one source, several outputs. A PIM holds the complete record, and each channel receives a transformed version of it. That way the catalog can pull richer attributes without breaking the marketplace mapping, and nobody has to maintain the same product description in three places. Platforms that publish straight from a live feed generally expect this arrangement, which is why the setup conversation tends to start with what your source system is rather than what your publication looks like.
Segment differences matter here too. A retailer with 300 SKUs and stable pricing can survive on a daily CSV export and a spreadsheet. One with 80,000 SKUs across four countries and three currencies needs proper feed infrastructure, because manual correction at that scale is not a thing a person can do. The break point is usually somewhere around a few thousand SKUs or the moment a second market gets added.
What Accuracy Looks Like From the Shopper’s Side
Shoppers do not think about feeds. They notice that the price on page 12 matched the price at checkout, that the item they clicked was available, and that the sofa they liked had its actual dimensions listed rather than a vague promise. Accuracy reads as competence, and competence is most of what a catalog is selling before the product itself.
The shape of the experience changes too. A catalog connected to live data can hide sold out items, surface stock warnings, and reflect regional pricing based on where the reader is. None of that is possible when the catalog is a static file, which is why an uploaded PDF and a feed driven catalog can look similar on screen and behave completely differently once someone starts clicking.
If you are setting this up for the first time, start by auditing what your source system can actually export rather than by designing the catalog. The constraint is almost always upstream. Once you know which fields exist, which are reliable, and how often they can be refreshed, the catalog decisions follow quickly, and you avoid the common outcome of building a beautiful publication around data that cannot support it.
