Disclaimer: If you had not heard already, I recently joined Google. This post not an official communication from Google. All the opinions (and errors!) here are my own. All information about Google is from public sources.

The ecommerce field to me is challenging and and dynamic. So much is going on on so many fronts. As I get up to speed at Google, I have been browsing around and digging deeper in areas that I previously skimmed over. This blog is a quick technical summary of my exploration of the Google Merchant Center. The purpose is only to help readers decide if they should take the next step and read the online documentation which goes into greater depth.

In a nutshell, the Google Merchant Center allows you to upload product details of your online store to Google. You can then link up the listings with an AdWords campaign. It’s also used by Google Express. My interest was however sparked when I saw public announcements around “Google Shopping Actions” which included voice interaction support (see Adwords blog and Reuters). Trendy!

Catalog Data Model

The data model is pretty simple. You give it a list of product listings, one row per product. Want to list all your variations? Or have the same product available in different countries or different languages? List each combination! Merchant Center is just a flat list of items people can buy – pretty simple. The supported list of attributes includes product identifiers, descriptions, language, pricing, currency details, color, size, and more.

Product Feeds

Different feed formats are supported. The Help Center suggests “small” merchants (merchants with less than 1,000 products) can list products in a comma or tab separated text file or a Google Sheet. (Google sheets I assume would have less risk of parsing problems.) You can upload the full file periodically, or get Google to fetch the contents according to a schedule. (Google Sheets can of course be easily fetched by Google.) There are also options to upload changes incrementally.

Merchant Center multi-source feeds go a bit further by supporting a primary file containing product data plus a series of secondary feeds that effectively annotate the primary feed. This is a simple way to bring data in from different systems and merge it. Simply create a separate secondary feed file per system and let Google do the merging for you.

Product feeds are simple to understand, but I would generally not suggest a Magento site manually keep the Magento catalog and product feed in sync. Automation through APIs is always better.

Content API

The Content API for Shopping provides an API to upload and manage product descriptions, allowing the Google copy of the data to be updated incrementally and automatically from Magento catalog updates. This to me is a much more sensible approach to keeping your Merchant Center listings in sync with your Magento store.

Structured Data

Structured Data is another approach worth understanding to get product data into the Google Merchant Center. Rather than encode all the data into feeds, you can embed machine readable product data directly into product pages on your web site. If the Google crawler finds a page with structured markup, and an offer is located on the page (pricing information) with sufficient details to identify the product (such as a GTIN), it can be automatically loaded into your Merchant Center account. The online documentation goes into more depth (I borrowed some the examples below from this site as well).

Note: if you want to update pricing and quantity information real time, I would not advise relying on the Google crawler as it may take a while to come back to your site. The Content API can be used to inform Google as soon as product details change on your site. Any inconsistencies spotted by Google between the feed and your product pages may suspend that product in Merchant Center until the discrepancy is rectified. (Google will not allow you to claim a product is on sale in the feed, but not have it on sale on your site.)

There are three forms of structured data that Google supports: LD+JSON, Microdata, and RDFa.

The first and recommended format is JSON embedded in the page inside a tag. This is recommended as it allows the richest nesting of provided data. (I could imagine it is also more efficient and reliable to parse.)

< script type="application/ld+json" > {
 "@context": "http://schema.org/",
 "@type": "Product",
 "image": "http://example.com/test.jpg",  
 "name": "Example Test",
 "description": "This is just a boring example",
 "offers": {
   "@type": "Offer",
   "priceCurrency": "USD",
   "price": "199.99"
 }
}
< /script >

The second format, Microdata, consists of additional markup embedded directly in the HTML markup. For example, a “div” around a product may have an “itemscope” attribute added, with child elements holding product titles, pricing, and descriptions having “itemprop” attributes to identify the HTML element’s content as useful data. (“itemprop” annotations are scoped by “itemscope” marked elements.)

The following example shows how markup could be included with the markup to be displayed. (The extra spaces are to stop WordPress from being “clever” with the markup.)

< div class=”product-listing” itemscope itemtype="http://schema.org/Product">
  < img itemprop="image" src="test.png" >
  < div class=”product-name” itemprop="name">Example Test</ div>
  < div class=”product-description” itemprop="description">This is just a boring example</ div>
  < div class=”product-offer” itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    < div class=”product-price” itemprop="price">119.99</ div>
    < div class=”product-price-currency” itemprop="priceCurrency">USD</ div>
  </ div>
</ div>

Hidden (not visually displayed) markup can also be included using <meta> tags.

<span itemscope itemtype="http://schema.org/Product" class="microdata">
 <meta itemprop="image" content="test.png">
 <meta itemprop="name" content="Example Test">
 <meta itemprop="description" content="This is just a boring example">
 <span itemprop="offers" itemscope itemtype="http://schema.org/Offer">
   <meta itemprop="price" content="119.99">
   <meta itemprop="priceCurrency" content="USD">
 </span>
</span>

A third format, RDFa, is also supported. It is a different encoding standard for HTML 5, very similar in concept to Microdata.

Chatting in the Magento community slack, a few people responded that they recommended using the JSON format (consistent with Google’s recommendation). It was suggested if Magento had a base function to return the JSON for a page, different extensions could add plugins to augment the returned JSON to be included in a page – so it should be easily extensible. There was also some discussion around possible challenges of Microdata in a PWA with client side rendering of HTML for display and web search crawlers. Server side generation of Structure Data may be more reliable, which also adds weight to the idea of creating a new function to return LD+JSON content per page in the new PWA work underway.

I should insert here that before you take on embedding Structured Data in your pages, check with your business owners as well. There may be business reasons to *not* make all your data easily accessible. For example, there may be sensitivity around making data too easily accessible by competitors. Just because technology makes something possible does not mean you should do it.

Brendan Falkowski in the Magento community engineering slack also mentioned needing to be careful of publicizing the same product multiple times from different domain names (I assume a merchant may have different domain names for different verticals with overlapping selections of products). He also pointed out B2B pricing is generally not public making Merchant Center more applicable for B2C, at least for now (I assume because B2B pricing is generally not something that should be made public, and is also may be negotiated per customer).

Conclusions

This was a quick overview of some of the technical details related to syncing your product listings into the Google Merchant Center to give you a taste of what is involved.

If you have reached here and think “that was pretty ho hum Alan”, then I think you have got the right understanding. It is pretty simple. So why did I write this blog? Yes, it’s a great way to advertise your products. Yes, it’s important if you want to become a part of the Google Express program. But the geek in me was more interested to see what Google is going to do with voice interactions. If you want to get into the voice space but don’t know how, then maybe getting your products listed in Google Merchant Center is a good first step. Then check out the Google Shopping Actions signup at the bottom of the AdWords blog post. (Please note: check if the Google Services you plan to use have fees to avoid unexpected hiccups later.)

Also please note that there are multiple extensions available on the Magento Marketplace to sync your products to Google Merchant Center. I have no personal experience with them so cannot make any recommendations.

Want to learn more about Voice Search in general? Check out Future Commerce episode #62. See also Inchoo’s post on using Browser features for Voice Search and Margarita Nikolenko’s talk about integrating the WebSpeech API at Meet Magento Netherlands 2018.