Product feed optimization: the complete guide

Open the actual file first. Most feed work goes wrong because people optimise what they assume is being sent rather than what is being sent. Download the feed your store or app generates, open it in a spreadsheet, and look at it row by row for twenty minutes. You will find more in that session than in a month of dashboard reading.

Check four things. First, the row count against your live catalogue. If you sell 4,000 sellable variants and the feed has 2,300 rows, something is filtering them out, and knowing what is missing is worth more than improving what is present. Second, the columns present versus the columns available. Blank columns are usually the largest available gain. Third, a sample of twenty rows read end to end, including the products you sell least, because the bad data hides at the edges of a catalogue. Fourth, the top sellers specifically, since those rows carry most of the revenue and deserve to be right first.

Then look at the channel's own diagnostics beside the file. Errors stop items from showing at all and get fixed first. Warnings usually mean an item is showing but competing with a hand tied behind its back, most often a missing identifier or an unclassified category. Note which of them affect items that actually sell, because a warning on a discontinued line is not urgent.

Write down the current state before you touch anything: item counts by status, error and warning counts by type, and the share of the catalogue with each important attribute filled. This is your baseline. Feed work happens in many small edits over weeks, and without a written starting point you will not be able to tell whether the last month helped.

Only then start changing things, and change one category at a time so you can attribute the movement.

Eligibility comes before quality, so clear the blocking fields before you write a single better title. An item that is disapproved cannot be improved, only fixed.

The core set is small. Every item needs a stable unique id that never changes for the life of the product, a title, a description, a link, an image link, a price, an availability value and a condition. Get the id right first, because reusing an id for a different product later confuses performance history and reporting in ways that are hard to unpick. Use the variant identifier from your store, not the position in a spreadsheet.

Brand and product identifiers come next. Where a product has a manufacturer barcode, send it. Where you make the product yourself and no barcode exists, say so with the identifier exists field rather than leaving the barcode blank, because a blank field reads as missing data while an explicit declaration reads as a decision. Send the manufacturer part number when you have it.

Price and availability are the two fields most likely to cause trouble, because they change. The price in the feed has to match the price a shopper sees on the landing page, including currency and tax presentation, and any automatic discount that shows on the page needs to be reflected. Availability has to match reality, which means the feed needs to refresh often enough that a sold out item stops being advertised the same day.

Shipping and tax settings sit alongside these. They are usually configured once at the account level rather than per item, but products with unusual delivery need their own values. Getting them wrong tends to show up as a mismatch between advertised and actual cost at checkout, which costs an order and a bit of trust at the same time.

Categorisation is the least glamorous field and one of the most useful, because it tells the channel what kind of thing your product is before anyone reads the title. Two separate fields do two separate jobs, and stores routinely fill one and ignore the other.

The channel's own taxonomy is a fixed list maintained by the platform. Picking the most specific accurate node matters more than picking a node quickly. If your product is a travel kettle, do not settle for a general kitchen appliance node when a more specific one exists, because the specific node is what qualifies you for the comparison surfaces, the filters and the attribute expectations that come with that product type. Where the taxonomy has no exact match, choose the nearest parent rather than an unrelated sibling.

Your own product type field is free text and it is yours. Use it as a real hierarchy, with levels separated consistently, reflecting how your store is organised: home, kitchen, kettles, travel kettles. It becomes the handle for everything downstream. Campaign structure, feed rules that apply per category, title patterns, bid groupings and reporting all key off this field, so a sloppy product type makes every later step harder.

Be consistent about depth. A feed where some items have one level and others have four cannot be segmented cleanly. Pick a depth per category, usually three or four levels, and fill it for everything, even if the deepest level repeats the one above.

Audit it by counting. Export product type and count rows per value. Values with a single item usually mean a typo or a one off phrasing, and values with thousands of items usually mean a level is missing. Both are quick fixes that improve every rule you write afterwards.

Titles carry the matching, so they are where the biggest gains sit, but writing 4,000 of them by hand is not a plan. Build a pattern per category and apply it to every item in that category, then hand write only the small set of products that earn the exception.

A feed title is written for a stranger, not for someone already on your page. On the page, brand and model are enough because the photo and the breadcrumb supply the rest. In a results list, the title has to say what the thing is, what makes it the right one, and only then who made it. So the pattern normally runs product type, key attribute, size or capacity, colour, then brand, adjusted per category for whatever a buyer in that category leads with.

Which attribute leads depends entirely on the category, and this is where the pattern work earns its keep. For clothing, size and colour matter. For components, compatibility matters more than anything else. For consumables, quantity and unit size decide the click. For tools, power rating and cordless or corded. Write the pattern by asking what the customer would say out loud if they were describing the product to a friend on the phone.

Keep the front of the title dense. The visible portion is short in most placements, so the words that decide relevance belong at the start and anything decorative belongs at the end or not at all. Cut marketing words, cut punctuation that adds nothing, cut promotional text entirely, and never put a phrase like free shipping in a title.

Build the patterns from fields you already have rather than free text, so the titles regenerate correctly when the catalogue changes. Then review a sample of thirty per category before rollout, because every pattern has products that break it, and those are the ones that need the manual override.

The image decides the click, and the feed image is judged in a grid of competing thumbnails, which is a harder job than being the hero on your own page. Send the picture that makes the product obvious at thumbnail size.

The rules are practical. A clean shot of the product on a plain background, filling most of the frame without touching the edges, at a resolution high enough that the channel can crop and scale it. No text overlays, no logos on the image, no promotional stickers, no borders, no watermarks. Those are common grounds for disapproval and, even when accepted, they make a thumbnail look cheaper than the product is.

Send the image that matches the variant. A blue shirt row with a photo of the white one is a mismatch, and it produces exactly the sort of click that bounces. If your platform stores variant images, map them properly. If it does not for some variants, that is a catalogue task worth doing rather than a feed limitation to accept.

Use the additional image field. Most stores fill the main image and leave the rest empty, which throws away free real estate on surfaces that show more than one photo. Send the alternative angles, the scale shot and, where it helps, the in use shot. Keep the plainest one as the main image and put the atmosphere shots in the additional slots.

When you have a choice between two acceptable main images, pick the one that reads at small size. Products that are dark, thin or detailed often lose in a grid because the shape is not legible, and a slightly zoomed or higher contrast version wins clicks without changing anything else. This is one of the few feed changes where the effect shows quickly, because click through responds faster than eligibility work does.

Attributes are how a channel decides you belong in a filtered set, and blank attributes quietly remove you from searches you would have won. They cost nothing to send and most stores send half of them.

Start with the ones tied to your category. Apparel needs colour, size, size system, age group, gender and material. Furniture needs material, dimensions and colour. Electronics need compatibility and capacity. Consumables need unit pricing, which lets the channel show a per unit price and puts you in comparisons that reward honest packaging. Check the required and recommended list for your specific taxonomy node rather than guessing, because it changes by node.

Colour and size deserve particular care because they are usually stored as internal variant option values and those values are rarely shopper language. Midnight and charcoal need to map to black and grey. A supplier size code needs to map to the size system used where you sell. Build that mapping as a table, use it in a rule, and keep it in one place so the next supplier import does not undo it.

The description field matters more than its low profile suggests. It is not marketing copy and it is not the place for shipping policy. Write the specification a buyer would check before ordering: what it is, what it is made of, what fits it, what is in the box, care and warranty. Lead with the sentence that would answer the question you get asked most about that product.

Finally, send the fields that describe the offer rather than the product where they apply: sale price with its effective dates, multipack count, whether the item is a bundle. These are what let a channel show the offer correctly, and getting them wrong is a common cause of a price that looks inconsistent between the listing and your page.

Every variant should be its own row, and every row in a family should carry the same group identifier. This is the field that tells a channel these eleven rows are one product in eleven sizes rather than eleven separate products, and getting it wrong produces the two failure modes stores complain about most.

The first failure is a catalogue that looks eleven times bigger than it is, with a results page showing the same shirt repeatedly in slightly different shades. That looks like clutter to a shopper and it splits the performance data across rows that should have been learning together. The second is the opposite, where a store sends only the parent product to keep things tidy, and then loses every search that specifies a size or a colour, along with the ability to stop advertising the sizes that are out of stock.

So send them all, grouped. Use a group id that is stable and shared across the family, usually the parent product identifier from your store. Keep the distinguishing attributes populated on every row so the channel knows what separates them. Keep availability accurate per row, because the whole point of variant level rows is that the sold out large stops showing while the medium keeps selling.

A judgement call comes up with colours that are really the same product. If the eleven colours share a page and a price, group them. If a colour is genuinely a different product with a different page, do not. The test is whether a shopper who clicked the wrong one would feel they had landed in the right place.

Watch out for the common breakage here. A bulk edit or a theme change can reset the option names, and once colour stops being recognised as colour the whole family degrades into unrelated rows. That is a good candidate for the weekly monitoring covered later.

Custom labels are free text fields that mean nothing to the channel and everything to your campaigns. They are how business information that lives in your head or your accounting reaches the place where budget decisions are made. Without them, campaigns can only be built around product categories, which are the wrong unit for spend.

Decide what each label slot means before you fill any of them, write it down, and never change a slot's meaning afterwards. A common set is margin band, stock position, price band, seasonality and performance tier. Margin band is the most valuable, because it lets you set a different target on products where you actually make money instead of treating a thin margin accessory the same as a healthy margin flagship.

Stock position is the second most valuable and the most often missed. Labelling items as overstocked, normal or low lets you push spend towards inventory you need to move and hold it back on products you are about to run out of. That single link between the warehouse and the ad account solves a problem most stores handle with manual pausing.

Seasonality lets you switch groups of products in and out on a schedule rather than by hand. Performance tier, updated periodically from your own data, lets you separate the products that carry the account from the long tail so each can be given its own budget treatment.

Set the labels with rules rather than by hand, sourced from fields you already maintain. Margin band comes from cost and price, which your store already holds. Stock position comes from inventory. If a label needs a human to update it, it will go stale, and a stale label is worse than no label because campaigns keep acting on it. Review the definitions once a quarter and check that the row counts in each band still look sensible.

Every manual edit is a change that will be overwritten. The next catalogue sync, supplier import or app update regenerates the feed from source data, and anything typed directly into a channel interface or a downloaded spreadsheet disappears. So decide where each field genuinely lives, and change it there.

The order of preference is simple. Fix it in the store first, because that fixes the website too and the feed inherits it. If the store cannot hold the field, use a feed rule that transforms store data on the way out. Only when neither works should a supplemental feed carry the value, and then it should be a documented file with an owner and a refresh schedule, not a spreadsheet somebody remembers to upload.

Rules are the workhorse. They handle the mappings that would otherwise be thousands of edits: colour normalisation, title patterns per category, appending a size to a title where the category needs it, stripping supplier codes, setting a default where a field is empty, excluding products below a margin floor or under a price where advertising does not pay.

Write rules so they are readable six months later. Name each one for what it does, keep one job per rule, and order them so a general rule runs before the specific one that overrides it. A stack of twenty small named rules is far easier to debug than five clever ones that each do four things.

Supplemental feeds still earn their place for data your platform genuinely cannot hold: a barcode list from a supplier, promotion identifiers, a custom label set maintained in a finance sheet. Match them on the item id, keep them narrow, and put a date in the file so anybody can see how fresh it is. Anything that stops being needed should be deleted rather than left running, because an old supplement quietly overriding good data is one of the harder faults to trace.

Feeds do not fail loudly. They fail by degrees, and a store usually notices weeks later when someone asks why sales in one category went quiet. Monitoring is what turns that into a two day problem instead of a quarter.

Watch coverage rather than errors alone. The number that matters is the share of your sellable catalogue that is currently active on each channel, checked against your own product list rather than against the feed. A feed with zero errors that is missing 600 products is worse than one with a handful of warnings across everything. Track that percentage over time and treat a drop as an incident.

Add field level checks beside it. For each important attribute, record how many rows have a value. When a column that was 94 out of 100 full yesterday is 60 today, a supplier import or a bulk edit has broken something, and you will find it far faster from the count than from the symptom. The same check catches option renames that break variant grouping.

Set a small number of alerts and make them specific. Active item count falls more than a few percent. Disapproval count rises. A named attribute drops below its normal fill rate. Price mismatch appears on a top selling item. Broad alerts get ignored; a short list of specific ones gets acted on.

Then give the feed a monthly review that is not about breakage. Read a fresh sample of titles in the categories you changed last, look at what the search terms report says people are actually typing to reach those products, and adjust the patterns. Feed optimization is not a project with an end date, because the catalogue, the suppliers and the way people search all keep moving, and the file has to keep up with all three.