Most feed work goes into titles and images, which is reasonable, because they are the visible part. The fields that quietly decide whether the product is eligible in the first place are three small ones: the global identifier, the manufacturer's part number, and the brand.
Together they answer a single question for the system reading your feed. Is this a product the world already knows about, and if so, which one. A product that is recognised can be matched to the same item sold elsewhere, which is how it joins the comparison view, inherits the descriptive information attached to that product, and appears for searches that name it specifically. A product that cannot be recognised is treated as an unknown, which is not fatal but is a weaker position.
The temptation, when a field is required and you do not have a value, is to put something in it. That is the one move that makes things worse, and it is worth understanding why before touching the feed.
What each field is actually saying
The global trade item number, the GTIN, is the barcode number the product carries in the world. It comes from the manufacturer, it is issued through the international numbering system, and it identifies the item globally regardless of who sells it. In practice it is the UPC, EAN, JAN or ISBN printed on the packaging.
The manufacturer part number, the MPN, is the code the maker uses for that exact item. It is not global and it is not unique across all makers, which is why it is only meaningful alongside the brand.
The brand is the name of the maker as a buyer would recognise it. Not your store, unless you made the product.
So the identifier pair is either the GTIN on its own, which is unambiguous, or the brand and the MPN together, which identify the product within that maker's range. When neither exists, there is a way to say so, and saying so is the correct action rather than a workaround.
Once you see the fields as a claim about identity rather than as required boxes, the right value in each case becomes fairly obvious.
Declaring that a product has no barcode is honest. Inventing one is not.
Brand is not always your store name
This is the field stores get wrong most often, in both directions.
If you resell other makers' products, the brand is the maker. Putting your store name there breaks the match to the known product, and it also misrepresents the item to a shopper who is searching for that maker by name. You lose the searches that mention the brand, which for reselling is a large share of the intent.
If you make the product yourself, or it is made for you and sold only under your name, then your name is the brand, and it should be consistent across every product and spelled the same way every time. Inconsistency here fragments your own products into several brands as far as the system is concerned.
The awkward middle case is a private label version of a generic item. If it is genuinely your product, your brand is correct and there will be no GTIN unless you obtained one. If it is a generic item you have relabelled in name only, claiming a brand is a stretch and the honest route is the no identifier declaration.
When in doubt, ask what the packaging says. The buyer will.
When you genuinely do not have a GTIN
Plenty of products legitimately have no barcode. Handmade items. Custom and made to order pieces. Personalised goods. Bundles you assembled yourself. Vintage and one of a kind stock. Books and media from before numbering. Products from small makers who never registered.
For those, the feed specification includes a way to state that the identifier does not exist. Setting that flag truthfully is the correct action. It tells the system to stop expecting a value rather than to treat the product as faulty.
What you should not do is leave the field blank without the declaration, because that reads as missing data rather than as an intentional statement, and it tends to produce warnings that turn into restrictions.
Products declared without identifiers can still be advertised and still appear. What they lose is the automatic connection to the same product sold elsewhere. For a unique or handmade item that is fine, because there is no comparison to join. For a mass produced item you resell, it is a real cost, and it is worth going back to the supplier for the barcodes rather than accepting it.
Invented identifiers are the expensive mistake
The worst outcome is not a missing identifier. It is a wrong one.
When a made up number is submitted, one of two things happens. Either it fails validation, because these numbers carry a check digit and are verifiable, and the product is rejected. Or, worse, it validates and matches to a completely different product, and your listing is now attached to somebody else's item. Your data and their data get merged in ways you cannot see or control, your product may appear against the wrong searches, and the price comparison you are entered into is against a product you do not sell.
Recycling one product's barcode across a range of variants has the same effect, blurring several of your own products into one.
The cleanup is slow, because you are not just correcting a field, you are undoing a match. So the rule is simple: submit a real identifier, or declare that there is not one. Never construct one, never reuse one from a similar product, and never let a supplier spreadsheet's placeholder column become the value you send. If a supplier cannot provide barcodes, that is a supplier conversation, not a feed workaround.
Variants: one identifier per sellable item
Identifiers belong to the item a customer receives, not to the style you merchandise.
A shirt in three colours and five sizes is fifteen distinct products in the world, and if the maker barcoded them, there are fifteen barcodes. Sending the style level number for all fifteen tells the system they are the same item, which undermines the size and colour attributes you carefully filled in and can produce mismatches between what was advertised and what the page offers.
The same applies to pack sizes. A single unit and a six pack are different items with different barcodes, and a shopper comparing prices needs them separated or your pricing looks inconsistent.
Bundles you assemble are their own case. They are new items that did not exist before you made them, so they have no inherited identifier, and the honest declaration applies unless you have registered your own.
The practical version of this rule: whatever the customer can add to a cart on its own is what needs its own identity in the feed, with its own price, its own availability and its own identifier or declaration.
A short audit you can run this week
This is an hour of work on most catalogues and it tends to find something.
Export the feed and count how many products have each of the three fields populated, split by whether you made the product or resell it. Reselling with a low identifier rate is the clearest opportunity in the list.
Check the brand column for your store name appearing on products you did not make, and for spelling variants of your own brand.
Spot check a sample of barcodes against the actual packaging in the warehouse. Not the spreadsheet, the physical product. This is where recycled and placeholder values are found.
Check that variants carry their own values rather than inheriting the parent's.
Then check whether the declaration for products without identifiers is set where it applies, and remove it wherever a real barcode does exist, since it should never be used as a shortcut past a field you could fill.
Fix the rules that generate the feed rather than the exported values, or the same faults return the next time the catalogue is rebuilt. That is the difference between an audit and a habit.