Product data feed
CrossEngage's product data feed feature allows you to load all of your product data and update product attributes or stock that may be then used in marketing communication.
Every file is a full sync between your product database and CrossEngage:
- For each product in your file the corresponding product is updated or created in the CrossEngage product database (if the record in the CrossEngage database is older than your file).
- Products not in your file will be removed from the CrossEngage database (if the record in the CrossEngage database is older than your file).
- All products in the CrossEngage database which have an update timestamp newer than the file will be kept and not updated.
Format: product_feed_YYYYMMDDhhmmss.[json|xml].[zip|gzip] Example: product_feed_20200324100002.json
The date in the file name is important as we will use it to determine its freshness (and therefore whether to update products or not). The timestamp has to be in UTC. As an example, imagine the CrossEngage database currently holds two products:
- SKU-1 last updated on 2020-03-24 07:00:00
- SKU-2 last updated on 2020-03-24 10:34:00
In the above example, processing the file will update SKU-1 because its last update timestamp is older than the file. SKU-2 will not be touched because its last update timestamp is newer than the file.
This is done to resolve conflicts between API updates and feed file uploads and also to determine when to ignore a file – see below.
The data file must contain an array of the products to be loaded into the CrossEngage database. The only mandatory field is sku (stock keeping unit) which is the main product identifier in CrossEngage. Each product can also be assigned to a businessUnit but this is optional. Product feeds without a business unit are also perfectly valid. The combination of SKU and business unit has to be unique for a product.
"title": "Puke Duke",
"description": "Das Bier mit Zimt-Vanille-Geschmack.\nInhalt:\n- Eine Dose à 0,5 Liter.",
"category": "Getränke → Bier",
<?xml version="1.0" encoding="UTF-8" ?>
<description>Das Bier mit Zimt-Vanille-Geschmack.
- Eine Dose à 0,5 Liter.</description>
<category>Getränke → Bier</category>
- The file will be moved to the /processed folder if
- it has been successfully processed. If the file itself could be processed but individual products could not be updated this will be reported but we still consider the file processed.
- The file will be moved to the /error folder if
- we could not read the file (for example because it did not contain a valid JSON or XML structure).
- we could only partially process a file (for example where the first half of a file contains valid JSON objects but the second half contains a different structure)
- the timestamp in the file name could not be parses (meaning we found a file with the product_feed_ prefix but could not read the timestamp following the prefix)
- The file will be moved to the /ignored folder if
- the timestamp in the filename is in the future.
- multiple files were found (in this case the newest file will be processed while the other files will be ignored)
- Files in the root folder without the prefix product_feed_ will not be touched by the product feed functionality.
File uploads should be used for the initial upload and for infrequently synchronization of the respective product databases. A maximum of one file per day is processed. More frequent updates can be performed using the Product Feed API.
For implementation and testing purposes it is also possible to temporarily increase the feed file processing frequency. Please reach out to your CrossEngage contact to arrange this.
Product feed processing can end with four different results:
- 1.The file was fully processed and we were able to process every product in the file.
- 2.The file itself was fully processed but we had to skip individual products.
- 3.The file was partially processed, i.e. we encountered an invalid format after processing a part of the file.
- 4.The file was not processed at all.
For case 1 we will clean-up all products with a last modification timestamp older than the file timestamp.
For cases 2, 3 and 4 we would not perform any clean-up as there is a risk of unintentionally removing products (which were in a part of the file that could not be processed).
When a product is updated either through a product feed or through our API, CrossEngage will observe changes in either the stockQuantity field or the price field of each product. If any of these values change, we emit the events listed below. When using these events in the user journeys of real-time campaigns, keep in mind that the journey builder does not validate the journey logic.
When submitting other product-related events such as Added/Removed Product or Added/Removed to Wishlist to CrossEngage, you will need to include the sku of the respective product on the top level of your event payload. This allows you to combine these events with the events generated by CrossEngage in real-time campaign user journeys.
This event is triggered when the stock quantity is not empty and changes from 0 to 1 or more. No event will be triggered in other cases, for example where a product was not available in previous product feeds but becomes available again or where the stock quantity value was not available and becomes available again.
The following event properties are available in user journeys and real-time campaign messages:
This event is triggered when the stock quantity is not empty and changes from 6 or more to 5 or less. The following event properties are available:
This event is triggered when the price for a product is available and increases. Any increase will trigger this event, even if it is just a cent. The following event properties are available:
This event is triggered when the price for a product is available and decreases. Any decrease will trigger this event, even if it is just a cent. The following event properties are available: