I've been working on adding the new required attributes for Apparel products to my XML Data Feeds product. This has been a huge undertaking, but I think I have it almost ready.
There is one requirement that I expect will cause most merchant data to fail and that is the requirement that each variant combination of an apparel product have a unique image associated with it for 'color' and 'pattern'.
Let's take a tee shirt as an example where you sell the following option variants:
color: red, blue, green
pattern: solid, stripped
size: xs, s, m, l, xl, xxl
material: cotton, polyester
This will come out to 72 different entries for your one tee shirt item. Out of this, you will need 6 separate images for the color/pattern combinations.
If you don't (or can't) have the 6 unique images, Big G will reject your items due to not having unique imagery.
So my question is, how many of you who sell apparel products are really going to try and list all your variants versus just listing one set of combinations that will not show the real variants available?
I've modified the addon to pull data from Options in addition to the normal Features, products table and literal values and support variant images associated with options and features only. So it is possible to support unique images for variants but I don't know how many people will actually do so.
I'm afraid that Goggle's requirements are going to create a huge support nightmare for me because people just won't understand the implications of supplying more than one combination for an apparel product and they will blame the addon for Google's rejections when it is really a function of their store data.
The other conflict that exists is when there is more than one variant image available for a particular combination (like color and pattern). Big G only allows for one image, so which one to use?
This is a real mess and I'd welcome any feedback you might have. But please keep this on topic. I don't need this thread to end up being a “I don't like what Google did” thread. They did it, and that's that; because they can.
Appreciate your thoughtful responses.
I havent looked into it thoroughly yet as I am in Sunny Florida on my Hols but if it is allowable NOT to put in each variant then I will not be doing so. Nightmare as far as I am concerned. Initially I dont see any benefit in my particular case but I havent dug too deep.
John
If you provide clothing and provide more than one variant combination, then the image for the item must be unique among other item combinations.
I think the way most will get around this is figure out how to get it to take a single color and pattern so that the main image of the store can be used (since there will only be one combination). However, that will make it look like you only sell red/solid of the item when looking at Google's listing.
Not even sure why this is a US only requirement. Guess we're the guinea pigs.
Kudos for trying to tackle this issue!
I understand that from a programming standpoint you need to account for the extreme cases that might arise from trying to automate the organization of such a messy group of products as apparel. I don't think you'll ever get it exactly right (sometimes i wonder if Google could satisfy it's own requirements), but whats more important in my mind is providing a way to get as close to right with an export as possible while still understanding that some man hours will be required to satisfy all of the requirements.
“they will blame the addon for Google's rejections when it is really a function of their store data.”
In my experience, I RARELY see apparel products that have all four variant groups (‘color’, ‘material’, ‘pattern’, or ‘size’). Even if i did have a product as extreme as your example, in reality, i would never list that product as one listing on my site. Aside from that fact that the variant combinations would be a nightmare to manage, i'd end up with 3-4 drop-down boxes and possibly dozens of images on one page. Such a listing would be ugly, cluttered and hard to navigate. Instead, i'd break this product up into multiple listings on logical divisions of variants to make navigating and viewing this product easier. Arguably, anyone listing products with this many variants should consider following this method for no other reason than that it makes it easier to manage (for humans and machines).
That being said, images will still be a problem. I've been brainstorming for weeks now on a way to avoid product level filtering on these types of products, and it's become complex. Here's some ideas.
- Possibly need a way to label an entire category as a default export or extended export. A default export would ignore the need for special fields like group_id, gender, age_group and so on. An extended export flag would allow for separate handling of “needy” categories like apparel.
- If certain categories are handled differently then i would feel better about putting much stricter rules on what products are exported from “extended” export categories. For instance, i could exclude product listings that are missing required fields like a variant image. I'd rather get some of them right than all of them wrong.
As for multiple images per option combination, I don't think you should worry too much about programming for bad data structures. Why not assume that every listing in the “extended” category would have a maximum of two variant combinations that would only ever result in one unique image per combo. As long as you provide the ability to decide whether or not someone wants to export on such a detailed level, it should be ok if some people don't get the more complicated stuff. So, your example listing above would have to be turned in to the following listings to export properly:
- Striped Polyester T-shirt
- Striped Cotton T-shirt
- Solid Polyester T-shirt
- Solid Cotton T-shirt
Or, one could combine the 3 options into “combo” variants and have one “Style” option instead of 3 separate options, size excluded of course. You'd get something like:
Choose Style
- Red Striped Polyester
- Blue Striped Polyester
- Green Striped Polyester
- Red Solid Polyester
- and so on …
I'm sure I'm missing something here. this is all very complicated to wrap my head around. One thing is for sure though, there will be compromises.
***While we're tossing around the idea of dealing with google stuff on a category level, has anyone considered dealing with the required google_category by allowing CScart categories to be mapped to a google category so that product categorization is managed on the category level and not the product level?
Thanks for the detailed response.
The way the addon currently works is that if a variant has data, then it is used/included. If not, then it is not.
Additionally, each variant element can be flagged as “not used” by the addon. In this case, that variant (Pattern for instance) would be ignored for all products (I.e. not mapped into the XML).
You have an interesting point about managing the Google Categories as a mapping of Cart Categories… Right now, it is done on a product by product basis. That would be a future change since providing compatibility with existing installations would then become quite difficult (unless category defs overrode product defs which would be inverse to what you'd normally expect). In hindsight, his would probably have been a better way to approach it.
I have the addon built to comply with Google's Specs. I guess my main concern is that I doubt anyone will really be able to completely comply with the Apparel specs. Not because the addon can't do it, but because they don't have the supporting data to do so (images for every variant combination).
I've released a new version of the addon with a fix for sites that have permissions issues. On those sites, the “EZ Common Tools” addon did not get installed and the addon was dependent upon a function contained in the tools.
This new version 2.2.22 does NOT have the new garment stuff (above) enabled and does not support generating an item per option combination. I'm holding off on that one because:
- I've seen very little interest (I think people have given up on Google Merchant for Garments)
- It requires extensive code modifications and is therefore much riskier than this version.
The code is there, but the configuration info is commented out so most all of it will not be used.
If there is a current XML Data Feeds customer who sells garments who would like to experiment with different configuration settings to get Big G to accept their variants, Id be willing to work with you (with a test version). I.e. maybe requesting an exception for all the unique combination images or for allowing things like 'All' for sizes, colors and patterns. I don't really have the products to mess with working with Big G. I have implemented the code to their specification. However, I believe their spec to be unreasonable and nearly impossible for most merchants to comply with. And since I don't sell garments, it's difficult for me to both understand the need and to fight with Google.
Of course, you could get your products listed by just using one variant for each of color, and pattern. But then that might cause customers to think you only carry the one…
What a mess Big G has made of all this…
Well, that’s very encouraging … taking in consideration that i have to implement our shop data feed in google merchant center and we only have a lot of products with different colors, on different sizes, variants etc… not a big deal … 
any ideas from where should i get started ?
Not knowing what you sell nor how you want to list, it's hard to say.
This particular thread has been focused more or less on the Garment issues since they have special requirements for US sellers. But the problems/principles discussed can apply to any variant of any product.