Archive for September, 2009

Towards the end of August, Google Base asked that merchants begin sending higher quality images. This is a great move forward for the user (shopper) experience when they can see higher resolution, larger images instead of tiny thumbnail sized ones. I wanted to take a moment to remind merchants that while images for Google Base may be optional, you should ALWAYS include them. Product images are also a field that is required with other comparison shopping engines, so if you are only on Google Product Search and want to be on Pricegrabber, Shopzilla, or Amazon Product Ads and don’t have images you won’t be able to list. Google is asking that images be at least 300×300 pixels, but we also suggest that you don’t submit images that are insanely large dimensions and file sizes. As for the file size, we recommend common file types such as .jpg or .gif. Formats such as .png or .tiff are larger in file size. The reason you want to keep file size down, is that it consumes your server bandwith when the shopping engines are showing your images. Remember that while on the comparison shopping engines this is the shopper’s first exposure to your website and the products you sell. If you have poor or no images, the shopper is likely to skip your listening and choose a competitor’s product.

If you want more resources about product images check out the following links:

Google Product Search has always had “out-of-the-box” support for a number of product attributes.  You can find the supported attribute list in their feed spec documentation.  While this list of supported attributes is robust (and has gotten more lengthy over the years), Google still allows merchants to submit “custom attributes” if they have additional, structured product data to provide.  For example, a power tool merchant may store information about the power of each of their handheld tools (ie: 12v, 14v, 18v).  In this case the retailer could submit these values to Google in a custom attribute field.  The benefit of doing this is still somewhat TBD and depends on the product category the merchant is participating in.  Sometimes Google could display your custom attribute as a filter, or they may index your attribute values so that they are search-able (ie:  if someone searched for “18v handheld drill” your listings would get a ranking boost)… but all of this is part of Google’s secret sauce, so merchants really just need to test various strategies.  Custom attributes are provided in the following format:  “c:attribute_name:attribute_type”.  Seven attribute types are supported and they include types like:  integer, datetime, string…  in the previous example, the power tool retailer could provide a field named:   “c:power:integer” and include values like “14″ or “18″ in that field.

Knowing all of the above, we learned something new about custom attributes recently.   If you include a custom attribute in your file with an attribute name that matches a supported attribute, then your feed will fail!  We aren’t sure if this occurs 100% of the time but it recently occurred for a SingleFeed customer and Google confirmed the problem.  As an example, if you include an attribute like “c:color:string”, your feed could fail.  This is because “color” is a supported Google attribute.  Whats even more perplexing is that, when feeds fail for this reason, there is no appropriate error messaging identifying the problem… the ambiguous “0 items of X items were inserted” message was given.  Obviously, in an ideal world, Google would recognize these custom attributes and simply treat them as supported attributes.  The second best scenario would be for them to return a feed processing error saying “you have custom attributes that should be regular attributes… please resubmit”.  Unfortunately, what’s currently occurring is the worst case scenario:  the feed fails with little to no feedback.  While this may be an edge case, we encountered it recently and so wanted to make sure you keep it in mind!

Recently we started working with a merchant who sells products on their site but they had not been including the type of product in the title/name of the item on the site or to the shopping engines. It was obvious at their website what they sell, but they weren’t conveying to the visitors, what the products were by their titles. Thus I was inspired to share and post.

If you sell mattresses, you better include the word mattress in your product title. If you sell electric toothbrushes, you better include the word “electric toothbrush” in the product title. If you sell Levi’s Jeans you better include “jeans” in the title. While you the merchant might think it is completely clear that AffordablePortableWidgets.com only sells a specific type widget, the shopper may not when searching on a comparison shopping engine. If you (the merchant) leave out the type of item, all a shopper is left with is a product result that leaves the shopper blind to the whole look, feel, and evidence of a theme on your website unless they click the listing and visit. Don’t just use a brand and a model number, but be sure to include the product “type” in the product name. By including the product type in the name, shoppers get confirmation that this indeed is the item they are looking for, and merchants get their products included more frequently in searches. I’m not going to go into the lengthy explanation of how search phrases and queries change and get more specific through the shopping/buying cycle online, but many merchants often miss out on being displayed for a product search simply by assuming the shopper knows what they want and are at the end of a search buying cycle. The CSE’s give you more of an opportunity to use “broad” type keywords that would typically cost much more than an exact match keyword in Google Adwords. Take the opportunity to include more generic keywords like the product type in the titles on the shopping engines.
Examples:

- a nameless merchant who sells only toothbrushes and teeth cleaning products has a “Oral-B Vitality Sonic” for sale, but they should be listing the product as “Oral-B Vitality Sonic Electric Toothbrush”

- another well known merchant who sells golfing equipment is listing a “Titleist Pro V1″ but doesn’t include the product type such as “Titleist Pro V1 Golf Balls”.

We see lots of product feeds everyday. One field that we see and frequently scratch our heads over is the color field. We strongly recommend this field for all of our clients, but push even harder for clothing and apparel merchants include their product color. One problem with this is that merchant’s will have some uncommon color names for their products which people may not use when they search.

For example, a search on Google Product Search for “Nine West brown sandals” returns 415 results. Another search for “Nine West mocha sandals” returns only 55 results. One could argue its better to stand out and compete in a smaller list of results, but I argue that more people are searching for the common color “brown” than the synonym “mocha”. Evidence from a Google Trends search show no results for “mocha sandals”.

Some examples of the common color and their synonyms would be:

Red = rose, rouge, crimson, scarlet, sangria, burgundy
Orange = amber, tangerine, pumpkin, persimmon, rust
Yellow = lemon, chartreuse, gold, saffron
Pink = coral, magenta, rose, salmon, fuchsia
Green = jade, lime, olive, moss, hunter
Blue = cerulean, cyan, turquoise, teal, azure, periwinkle, cornflower, cobalt, sapphire
Purple = amethyst, eggplant, indigo, lavender, violet, mauve
Black = espresso, carbon, charcoal, ebony, onyx, obsidian
Brown = auburn, bronze, burnt umber, rust, sepia, sienna, tan, taupe, chocolate

We recommend testing the replacement of different synonyms in your product titles with more common color names. This testing is the only way to determine what is right for your products. You can also include additional keywords in your feed for the other color names, and some merchants may be able to take advantage of NRF color codes.