Fashion catalog ads: the apparel feed attributes

Fashion is the catalog vertical with the most required attributes, and the requirements disagree across platforms. A coffee mug needs a title, a price, and an image. A dress needs all of that plus color, size, gender, age group, and a grouping ID that ties its eight sizes and four colors into one product family. Get those wrong and your catalog either disapproves in bulk (Google) or shows a shopper five near-identical tiles of the same jacket (Meta). This article maps which apparel attributes each platform actually demands, how strict each one is, and which images convert for clothing, then where a feed image editor like Emberfeed honestly fits and where it does not.

Apparel attributes by platform

Start with the map. The same five attributes show up on every platform, but the status, the exact field name, and the format rules differ enough that a feed tuned for Google is not automatically valid for Meta or Glami. Read the status column carefully: "required" on Google is not the same shape of required as it looks at first glance, and the Meta column is mostly "optional" in a way that is still functionally essential.

Three things in that table cause most of the confusion, so each gets its own line.

Google: required, but with a region twist

The popular shorthand says Google demands color, size, gender, and age_groupon every apparel product or it disapproves, full stop. That overstates it. Google's own attribute pages scope the requirement two ways. For free listingsthe attributes are effectively universal across the Apparel & Accessories category, so for the unpaid surfaces it is fair to treat them as required. For Shopping ads, the requirement only kicks in when you target Brazil, France, Germany, Japan, the United Kingdom, or the United States. So a shop running Shopping ads only in, say, Poland or the Netherlands is not held to the same hard wall the third-party guides imply. The honest statement is the two-tier one, not "globally required".

Format matters as much as presence. color accepts up to three colors, and they must be slash-separated (Red/Green/Black), not comma-separated. Hex codes, numbers as colors, and single letters are rejected, as are filler words like "variety" or "see image". gender is one of male, female, or unisex in English. size is a free-text label, but it has to agree with the size_system you declare, so an EU 38 tagged as a US system is its own quiet problem.

Meta: optional fields that are still essential

Meta's hard-required catalog fields are the nine universal ones (id, title, description, availability, condition, price, link, image_link, and one of brand / gtin / mpn). The apparel attributes, including color, size, gender, age_group, pattern, and material, are optional variant attributes, not ingest requirements. Do not let "optional" fool you, though. The field that actually carries the catalog is item_group_id: it groups every size and color of one garment into a single product family. Without it, every size and color is a separate item competing for impressions, and a Meta dynamic ad can serve a shopper several tiles of the same dress. So for Meta the framing is "not required to ingest, but functionally required for a catalog that does not cannibalize itself".

Glami: size and color hide in PARAM blocks

Glami is a fashion-only comparison engine (strong in the Czech and wider EU market), so its feed is apparel-shaped by design, but the plumbing is unusual. Its mandatory elements are ITEM_ID, PRODUCTNAME, DESCRIPTION, URL, IMGURL, PRICE_VAT, CATEGORYTEXT, and DELIVERY_DATE, plus size and color. The catch is how size and color travel: they go exclusively through PARAM blocks (a PARAM_NAME of velikost for size, barva for color), never as top-level elements. Send SIZE or COLOR at the top level and Glami silently ignores them. There is also no GENDER element: gender lives inside the CATEGORYTEXTpath, and Glami's guidance is to always encode it there. MANUFACTURER is optional, not required, and Glami explicitly says an unbranded shop should not send it. ITEMGROUP_ID groups variants the same way Google and Meta do.

If Glami is your channel, the deeper field-by-field walkthrough lives in the Glami channel guide and the Glami XML feed spec.

The look: which images work for fashion

Attributes get the catalog accepted. Images get the click. Fashion is the one vertical where the platform actually has a first-party opinion about what the main image should show, and it is not the opinion most merchants assume.

Google's model-versus-isolated split

Google's clothing best-practices page draws a clean line that most feed advice misses. For clothing, show it on a model: the guidance says showing how a product looks on a real person helps inspire customers, and on full-body shots you should not crop the model's head or feet. For shoes, handbags, and accessories, do the opposite: show the product alone in the main image, then on a model in the additional images. So "fashion" is really two image strategies in one category, model shot for garments, clean isolated shot for accessories. Google also wants a solid white or transparent background, a resolution of at least 512x512 (ideally 1024 or higher, width at least 1500 px), and the main image to match the specific variant the ad links to.

Beyond Google's own rule, the broader question of model versus flat-lay versus ghost-mannequin versus lifestyle is conversion craft, not platform policy, so treat the following as industry consensus, not a measured Emberfeed benchmark. On-model photography dominates fashion ecommerce because shoppers judge fit, drape, and proportion from it, which also tends to reduce fit-related returns. Ghost-mannequin shots tend to out-convert flat-lay for structured garments like blazers, jackets, and dresses, while flat-lay stays the cheap, fast, consistent option for large fast-fashion catalogs. On Meta, lifestyle or on-model images that authentically represent the target customer tend to beat bare studio packshots for click-through. None of those are numbers we can put a controlled figure on, so no invented conversion percentages appear here, just the direction the industry agrees on.

The image floors, and the overlay catch

The hard minimums differ by platform, and one of them has a deadline that lands squarely on apparel images.

Then there is the cross-platform catch that bites anyone who builds one designed apparel image and pushes it everywhere. Google forbids promotional text and overlays on the main image_link: a price chip, a "-30%" flag, or a "SALE" banner on the main image is a promotional-overlay disapproval. Meta allows those same badges. So a badge-heavy apparel image is Meta-safe and Google-unsafe, while a clean on-model or lifestyle composite with no promo text is safe on both. Any AI-composited apparel image on Google also has to keep its IPTC DigitalSourceType tag (mandatory since February 2024) or Google disapproves it. This is the same overlay-policy split, with sources, that the multi-image catalog ads article lays out in full.

The gaps apparel shops hit most

Across fashion feeds the same handful of mistakes recur, and they are specific enough to check for directly.

• Missing or broken item_group_id. The number-one apparel-specific gap. Without it, every size and color is a separate item: Meta dynamic ads cannibalize impressions across them, Google cannot collapse the variant family, and on Glami the variants do not roll up. Google requires it for variants on free listings; Meta needs it to avoid N tiles of the same dress.
• Missing or malformed color / size / gender / age group on Google. The single biggest cause of bulk apparel disapprovals on free listings, and on Shopping ads in the six countries. It is compounded by format violations: commas instead of slashes in color, hex codes, non-color words, and sizes that do not match the declared size_system.
• GTIN confusion on apparel. Apparel is the one category where GTIN is not required: clothing and custom-made goods are exempt. For unbranded, handmade, or private-label items the correct move is identifier_exists=false, not leaving GTIN blank (a blank yields a "Limited performance [gtin]" warning). Branded and resold fashion still needs a real GTIN, and fabricating one risks a counterfeit-goods suspension, so do not invent one to silence the warning.
• One image reused across color variants. Both Google and Meta want a distinct image per color variant. Reusing the parent photo on every color is a quality and representation problem, and on Google the image also has to match the selected-variant landing page.
• Low-resolution or mis-sized images.Shipping a 600x600 crop to Meta when the store has a 4096x4096 original looks blurry across placements, and clothing under Google's 250x250 floor (500x500 from January 2027) gets flagged outright.
• Glami-specific slips. Sending SIZE or COLOR as top-level elements (silently ignored) instead of PARAM blocks, sending MANUFACTURER for an unbranded shop, or omitting the gender segment from CATEGORYTEXT.

Where Emberfeed fits

Emberfeed touches two of those problems honestly, and it is worth being precise about which, because it does not fix all of them and it is not a feed generator.

• It validates the apparel set per platform. The required-field matrix flags missing color, size, gender, and age_group on Google apparel (it over-approximates here: because a feed carries no target country, it cannot tell whether your Shopping ads actually fall in the six required countries, so it flags the attributes for all apparel). What it does notdo today is enforce Google's slash-versus-comma color syntax or the size_system match, so treat those format rules as your own checklist item, not something the validator catches.
• It renders a templated apparel image into image_link from the feed you already have. An on-model or clean packshot plus a brand frame, and for Meta a price chip, rendered per product from one template so the served image is consistent across the whole catalog. The boundary: it cannot conjure a color or size value the source feed never carried. Missing variant data is a feed-source fix, not a render fix, so a garment that arrives without color stays without color.
• The duplicate-feed pattern handles the Meta-badge versus Google-clean split. One source feed, two served outputs, two templates: a badge-heavy main image for Meta and a clean overlay-free one for Google, so neither platform rejects what the other rewards.

The render mechanics underneath this (how one template produces a unique on-demand image for every product, and where AI helps with the design step) are covered in AI-designed catalog images. The boundary worth repeating: Emberfeed works from an imported feed, it does not build a catalog from nothing, and it is hosted SaaS, not self-hosted.