A central concept in Sproxi is understanding how Sproxi prioritizes data to create your Google Listings.    The actual data that is sent to the Google Merchant Center is called the “Processed Value” in Sproxi.    But what and how does Sproxi get this “Processed value” to send to Google? 

How Sproxi Prioritizes Data to Create Your Google Listing the Way You Want it

Understanding this concept is critical to use Sproxi to its full potential.

The first thing to understand is how Sproxi Products, shopping cart Listings, & Google Listings are created in Sproxi.  When first connecting your shopping cart to Sproxi & clicking the “Import Products” link (see KB article “How to Setup Your WooCommerce Account in Sproxi” & “How to Import Shopping Cart Listings“) your products are imported & created in Sproxi in three locations:

  1. Sproxi Products
  2. WooCommerce Listings
  3. Google Merchant Listings

As mentioned above, Sproxi will pull product data from your connected WooCommerce catalog and use that data to create all three sets of products (Sproxi Products, WooCommerce Listings, & Google Listings).  For all intents and purposes, each instance of the product will mirror itself across all three locations when you do your initial import of products.    Within Sproxi you can edit your Sproxi Product and also directly edit specific Google Listing attribute fields (called “Override Values”, but not the WooCommerce Listing.  The WooCommerce Listing will ALWAYS mirror your store’s WooCommerce product.)

As time goes on and you begin to make changes in your WooCommerce store (which will automatically update your WooCommerce Listings), you may not want to update your Sproxi Inventory Product.  In addition to that, you may have made a very specific change to a Google Listings attribute value that you don’t want undone the next time your update the product in your WooCommerce store.  So what Sproxi does is to keep these three sets separated and allow you to decide what the ultimate values are we send to Google (called “Processed Values” through tools such as field mapping, custom fields, bulk edits, and “Override” Google values.

Here’s an example.  After you imported your WooCommerce products for the first time and created Sproxi products,  you decide that  you want to use the Sproxi Product “Name” field for the Google Listings attribute field “Title” so that you have a distinction between your WooCommerce Listing and your Google Listing.   When products import again from your WooCommerce store (through a new import or a webhook), you wouldn’t want to overwrite the Sproxi Product “Name.”  By mapping the Sproxi Product field “Name” to the Google attribute Value “Title,” we will always send out the Sproxi Name as the “Processed Value” to Google rather than the WooCommerce Listing.

The ultimate goal is to create an optimized Google Product Listing exactly the way you want it.  Through directly writing data into the Google Listings field (the Override Value), applying field maps & recipes (mapping data fields, attributes, & meta data from WooCommerce, or mapping & applying data from products), or applying custom fields from Sproxi Products, you are given the flexibility to do just that–create a fully customized Google Listing exactly the way you want it.  But once you begin creating custom fields, mapping attributes & applying recipes, it can get confusing to know & understand “which actual values are being applied to my Google Product Listing?”  What if you change a product title in your WooCommerce store?  Will that change my title in my Google Product Listing? To understand this, we need to understand how data is prioritized in Sproxi.

Understanding Data Hierarchy in Sproxi

Because Sproxi has the ability to pull in all your shopping cart data, provides the ability to create custom data, allows mapping for these fields to Google Listings attributes, provides recipes, and provides the ability to write directly into your Google Listings attribute fields, there has to be some form of Data Hierarchy in Sproxi.  Without this structure it would be impossible to know what data will actually be sent out to the Google Merchant Center.  What Sproxi sends out as Listings to the Google Merchant Center is referred to as “Processed Values.”  The result of this hierarchy is that prior to sending out a Google Listing, Sproxi will go down the hierarchy tree, search for data for each Google Attribute field.  As it progresses through the tree, if it finds the data, it will use it as the “Processed Value” for that field, stop, and then start searching for data for the next Google Attribute field.

The Highest “Priority of Data” is how Sproxi chooses what to send to Google as “Processed Values,” in other words, what we send to Google as as your Google Listing.  Note: level 1 data is written into the “Override Value” field for the respective Google attribute field.  Levels 2-3 is “dynamic data” meaning as soon as you change a mapping, for example, the “processed value” will change.  Level 1 data, as it is directly placed inside the “Override Value Field” you would need to remove it from the Google attribute “Override Value” field in order to remove it.

  1. HIGHEST PRIORITY – Google “Override Value” for a Google attribute field.    Data can appear here in one of three ways – *Note: data is directly written into the Google attribute field.
    1. Written directly into the Google “Override Value” field.
    2. Bulk selecting Google Listings and click the blue “Edit” button.
    3. Uploading data into the a Google Attribute field found in your Google Listing through a CSV file.
  2.  Dynamically Applied Data to Google Listings.   By selecting specific Google Listings and using the “Bulk Edit” feature, you can map WooCommerce attributes, WooCommerce metadata, recipes, & custom fields.  *Note:  this data IS NOT actually written into the Google “Override Value” attribute field, but rather is “dynamically” place & used as the Google “Processed” value & sent to Google. 
  3. Mapped Data through the “Dynamic Field Map.”  Versus the level above, data here is mapped using the “Dynamic Field Map” tool and mapped at the Google account level.  Here you can map WooCommerce Attributes & Metadata, Custom fields, and Recipes.  For example, mapping a WooCommerce attribute  MPN to the Google attribute field “MPN” would apply this across all the Google Listings for this specific Google Merchant Center Account. 
  4.  Shopping Cart Listing Matches.   Sproxi will automatically match certain shopping cart fields to Google attribute fields.  For example. the SKU from the WooCommerce Listing will be used for the Google attribute “Offer ID” in your Google Listing.
  5.  LOWEST PRIORITYSproxi Product Data You could create a custom field and apply it to a Sproxi product.   You could dynamically map it directly to a Google Listing product(s) or globally map it though the field map.  In addition to this, and very important, if Sproxi cannot satisfy a required Google Attribute field through your mappings, bulk edits, etc., it will look, as a last resort, to the connect Sproxi inventory product.

Regardless of how you have things mapped, if Sproxi finds a null or empty value, it will look at a next level in the hierarchy to find data to satisfy Google requirements.

Here’s an example:  If you are very familiar with WooCommerce, you know that the GTIN is not a native field to a WooCommerce product.   That’s is, however, something you want in your Google Listings.  So you create an attribute in your WooCommerce store called “GTIN,” and populated these fields with the appropriate value, in this case you use the 12-digit UPC.  As you know, however, this created attribute does not populate to the variations you may have created for a product.  You are not stuck trying to figure out how to populate a GTIN value for your WooCommerce variable products that are simple Google Listings sent to the Merchant Center.

The first step would be to use the “Dynamic Field Map” tool to map the WooCommerce attribte you created “GTIN” to the Google attribute field “GTIN.”    After doing this, Sproxi will begin “local validation” and begin dynamically applying this data to the respective Google Listings fields.  Here’s how it does it”   

  • Sproxi looks to the Google attribute field “Define Value.”  If nothing is there, it goes to the next level.
  • We did not map this attribute at the Google Listing level, but rather we mapped it globally using the dynamic “Field Map” tool.  Since nothing was mapped at the Google Listing level, Sproxi moves to the next level.
  • It’s at this level, using the “Field Map” tool, we dynamically mapped the WooCommerce attribute to the Google attribute.  For many of the products, Sproxi found a value in the GTIN field and thus will use this as the “Processed Value” field for the Google attribute field “GTIN.”  As mentioned above,  since the WooCommerce attribute we created does not apply to the WooCommerce variations, there was no GTIN value found for these created Google Listings, so Sproxi moved to the next step.
  • We then went to the Sproxi complex products, edited each variation, and inserted the respective GTIN.  Sproxi will detect this change and begin local validation, inserted the Sproxi “GTIN” the remaining Google attribute field’s “Processed Data.”