When you sell products under your own store label or source generic goods with no manufacturer brand, the brand [brand] attribute becomes one of the most consequential fields in your feed. Submit it wrong and you risk warnings, reduced visibility, or a mismatch between identifier_exists and the identifiers you actually provide. This guide covers exactly what value to submit, when to leave the field blank, and how to pair these decisions with identifier_exists and gtin.

Why the Brand Attribute Matters for Private-Label Sellers

The brand, gtin, and mpn attributes together form what Google calls unique product identifiers (UPIs). Google documentation states that "unique product identifiers are submitted using the GTIN [gtin], MPN [mpn], and brand [brand] attributes." When all three are missing or incorrect, the system has little to work with when classifying your product, which can limit where it appears.

For a branded manufacturer product, you submit the manufacturer's brand name. For a private-label product — one you design or source and sell under your own store name — the situation is different. Your store name is a valid brand value. If your store is called "Harborline Home," submitting brand = Harborline Home is accurate and appropriate. You are the brand.

For truly unbranded products — generic goods with no manufacturer name and no store brand applied — there is no meaningful value to submit. In that case the right move is to omit brand entirely and handle the missing identifier situation through identifier_exists.

Do not fabricate a brand value. Submitting a made-up name, a generic term like "No Brand," or a competitor's brand name for a product they did not make creates inaccurate data and may trigger warnings.

How identifier_exists Interacts with Brand and GTIN

When a new product genuinely has no assigned UPIs — no GTIN, no MPN, and no brand — you must signal this explicitly. Google documentation explains: "If your product is new (which you submit using the condition [condition] attribute) and it doesn't have assigned product identifiers that meet the requirements below, you should submit the identifier exists [identifier_exists] attribute with a value of no [no] or false [false]." Note that this value must be submitted in English regardless of your feed's language.

Setting identifier_exists = no without genuinely lacking identifiers creates a different problem. The same documentation warns: "Products for which the identifier exists [identifier_exists] attribute is incorrectly set to no [no] or false [false] and for which there is evidence that a unique product identifier exists, will receive a warning."

This creates a clear decision tree:

  • Private-label product with your store brand: Submit brand = [Your Store Name]. If no GTIN exists for the product, leave gtin blank. You may or may not need identifier_exists = no depending on whether any UPI applies.
  • Fully unbranded, no GTIN, no MPN: Submit identifier_exists = no, leave gtin and mpn blank, and omit brand.
  • Branded manufacturer product: Submit the manufacturer's brand, and the manufacturer-assigned gtin if one exists.

On the GTIN side, Google documentation is direct: "If you're the only seller of a product or if your product is a store brand, it generally won't have a GTIN, so you don't need to submit one." This means private-label sellers are not expected to invent or apply a GTIN. Never guess or construct a GTIN value — submit one only when you are certain of the manufacturer-assigned number.

Hypothetical Example: Three SKUs, Three Different Approaches

The following is a hypothetical example for illustration. Product identifiers and store names are invented.

Imagine a catalog operator running an online home goods store called Crestwood Living. Their catalog has three SKUs:

SKU 1 — Manufacturer ceramic mug (branded) This mug is made by a third-party manufacturer and carries their brand and a UPC.

AttributeValue
brandAceraCo
gtin012345678905
identifier_exists(omit or leave as yes)

SKU 2 — Private-label linen cushion (store brand) Crestwood Living designs this cushion and sells it exclusively. No GTIN has been assigned.

AttributeValue
brandCrestwood Living
gtin(leave blank)
mpnCL-CUSH-001
identifier_existsno

The store name is a legitimate brand value here. The MPN is the operator's own internal part number, which is allowed.

SKU 3 — Generic unbranded cotton tote This tote is sourced from a generic supplier with no brand, no GTIN, and no MPN.

AttributeValue
brand(leave blank)
gtin(leave blank)
mpn(leave blank)
identifier_existsno

For SKU 3, identifier_exists = no is the correct signal. Submitting a placeholder like brand = Generic or brand = N/A is not a documented valid approach and could cause classification issues.

Common Mistakes to Avoid

Submitting a GTIN for a store-brand product. Because your store brand has no manufacturer-assigned GTIN, submitting one you found for a similar product — or one you constructed — will produce incorrect data. Per Google documentation, "Don't guess or make up a value. If you're unsure of a GTIN, don't submit one."

Using identifier_exists = no as a catch-all. Some catalog operators set this to no on every product to avoid GTIN errors. This triggers warnings for products where UPIs do exist. Reserve identifier_exists = no for products that genuinely have no GTIN, MPN, or brand.

Leaving brand blank on a private-label product. If you have a store name and the product is exclusively yours, that name is a valid brand. Omitting it when you could supply it removes a useful identifier from the feed.

Submitting variant GTINs incorrectly. If a manufacturer product comes in multiple colors or sizes, each variant has its own GTIN. Google documentation states: "Each product and variant of a product (different colors or sizes) has its own GTIN, so make sure to submit the correct value." For private-label variants, since no GTIN exists, each variant row should have gtin blank and identifier_exists = no.

Managing These Fields at Scale

Handling the brand, gtin, and identifier_exists combination correctly across hundreds or thousands of SKUs requires consistent mapping rules in your feed management workflow. A supplemental feed is a practical way to add or correct identifier_exists values without rebuilding your primary feed from scratch.

Magicfeedpro is built to help catalog operators map, transform, and audit these attributes before submission, reducing the risk of warnings caused by mismatched identifier signals across large catalogs.

The core principle is straightforward: submit what is true, omit what does not exist, and use identifier_exists = no only when you are certain no UPI applies to the product. Accurate identifier data gives Google the best chance of classifying and displaying your products correctly.


MagicFeedPro Team

Feed Optimization Practitioners

We're a team of e-commerce and paid-search practitioners who have spent the last decade running Google Shopping campaigns at scale. We write about what actually moves the needle on product feed quality, CTR, and conversion.

Related articles