This article will summarise the key differences in how data needs to be handled within the Content API compared to the old "Feed" method
As part of our migration to usig the Content API, there are a number of key differences in how data now needs to be handled.
1. Consolidated Template - There is now one consolidated template called 'Google Content API' and no variations or duplications of this template will be supported without first consulting and agreeing with Product but there should be no need for multiple templates.
This template has been aligned to the specification for the API and supports all of the API fields which you can find here - CLICK HERE
2. Field Naming Conventions - In line with the point above, you will note that field names now closely resemble, but do not match the feed specification here. This is deliberate and part of the Spec of the API. Please do not change any field names in the Google Content API template under any circumstances.
3. Custom Fields & Attributes - In the past, our Google Shopping templates have contained a mixture of correctly and incorrectly supported custom attributes. There is now a dedicated field in the template called 'customAttributes.*' where these can all be set up in Name Value Attribute (NVA) style Key Value Pairs.
As an example, if you wanted to add 'product_review_count' as a custom attribute, this would be added to the customAttribute field in the following format - ;;product_review_count::70;;
4. Shipping - One of the key changes between a feed driven approach and the API is how Shipping is handled. Previously, we would have sent the data in the following structure - AU::2 to 4 day delivery:
Now, the data is presented in a much clearer format, allowing the user to specify and control which sub-attribute is being populated e.g. ;;price::0.00;;;;country::AU;;minTransitTime::2;;;;maxTransitTime::4;;
By default, the template will show - ;;price::{@@Master.Shipping Cost};;;;country::[COUNTRY];;minTransitTime::{@@Master.Min Delivery (Days)};;;;maxTransitTime::{@@Master.Max Delivery (Days)};;
You will need to add a rule to Find and replace [COUNTRY] with the correct value.
5. Quantity, sellOnGoogleQuantity & Availability - There are now 3 columns in the data that pertain to stock. If you are setting any rules to affect availabililty or stock, you will need to make sure that these are mirrored across Quantity, sellOnGoogleQuantity and Availability.
6. Product Details - This is a relatively new attribute from Google and one we have not currently adopted or supported widely. The API makes it much more simple to support and the format for this field is as follows - ;;SectionName1:AttributeName1:AttributeValue1;;;;SectionName1:AttrubuteName2:AttributeValue2;;;;SectionName2:AttributeName3:AttributeValue3;;
Key thing to note here is that the Section Name needs to repeat for each attribute that sits within that section.
7. Certifications - This is a realtively new attribute and is currenty specific to EMEA merchants but we now support Certifications via an NVA style structure using the following format - ;;certificationAuthority::{value};;;;certificationName::{value};;;;certificationCode::{value};;;;certificationValue::{value};;
8. Delimited Fields (xyz.*) - Any field where the name ends with '.*' denotes a field that supports delimited values. The majority of these (except where noted) simply allow you to submit a list of values. The expected delimiter (like NVA's) is a double semi-colon ';;'.
This currently applies to:
- additionalImageLinks.*
- adsLabels.*
- certifications.* (covered above)
- displayAdsSimilarIds.*
- excludedDestinations.*
- freeShippingThreshold.*
- includedDestinations.*
- lifestyleImageLinks.*
- productDetails.* (covered above)
- productHighlights.*
- promotionIds.*
- shipping.* (covered above)
- shoppingAdsExcludedCountries.*
- sizes.*
- taxes.*
9. Attributes with Values and Units - Previously, values such as productWeight or shippingWeight would have expected only a value. In the API, you will notice that each field is split into two and now caters to a value and a unit of measurement e.g:
- productWeight.value - expects the numerical value e.g. 100
- productWeight.unit - expects the unit of measurement e.g. kg
10. Complex Objects/Attributes - There are a number of complex objects within the API Template. These are broken down into mutliple iterations of the attribute breaking out their various sub-attributes.
Taking the example of 'Loyalty Program' this is now supported from the following fields:
- loyaltyProgram.programLabel
- loyaltyProgram.tierLabel
- loyaltyProgram.price
- loyaltyProgram.cashbackForFutureUse
- loyaltyProgram.loyaltyPoints
- loyaltyProgram.memberPriceEffectiveDate
Each field just needs to be filled with the corresponding value that each sub-attribute expects.
If you have any questions or queries, please raise these with the Enablement Team