Skip to main content

SKU Feed


The SKU feed is only needed if you’re participating in our program for SKU functionality. 

This SKU Feed must be included in the Product Feed that is uploaded every day as a .zip or .gz file. In addition to the SKU feed, you will need to add SKUs to your instrumentation in order to support this functionality.

Note: Currently support for SKUs is not compatible with support for regions.

File Specification

The SKU Feed is much like the Product Attribute Feed with the key difference that it can only be accepted in row-based format. Take care around this point to avoid issues when first developing this feed. Unless otherwise noted, all IDs must be made up of alphanumeric characters.

SKU variation information is passed in the SKU feed; the image as attribute "image_url" and the link as attribute "link_url."

SKU Feed

Filename: sku_full_sitename_YYYY_MM_DD.txt requireD
Name Type Required? Definition
product_id ASCII Yes

Identifier for the product to be used for onsite JavaScript integration as well as in the RichRelevance Dashboard. Maximum length: 100 characters.

 This must be the same ID that is used in the Catalog Feed as well as in your site's instrumentation.
sku_id ASCII Yes ID for this specific SKU variant of this product.
attr_name text Yes The name of the SKU attribute being defined. Examples: "color," "size," etc.
attr_value text Yes The value or values being assigned to the SKU attribute for this SKU. Multiple values are permitted and are delimited by a period. See example below.



Note: There should be only one entry per product_id, sku_id, and attr_name combination. This means that if you have multiple values to assign to an attribute for any given SKU of a single product ID, it must be done using a list of values on one line.

Note: "Available" is an optional recommended SKU attribute that signifies if the specific SKU is available for recommendation or for sale.

Size Types

When you’re considering size preference for a shopper, you need to be able to differentiate between different types of sizes. A single shopper might wear size 8 shoes, size 4 dresses, and size S t-shirts. But if the only information given to the system is the sizes themselves, there may be unnecessary confusion between them.

When the shopper buys a pair of shoes, for example, it’s not enough to record that this shopper is a size 8. You need to know that the shopper is an 8 in shoes because you don’t want to later recommend size 8 dresses to that same shopper.

If you are able to send sizes as unique attributes like shirt_size, hat_size, or us_women_shoe_size for example, no further work is needed; that will be enough to keep this information appropriately separated and unconfused.

If you are not able to do this, then there is a workaround. You can create an attribute called SizeType to differentiate between the different types of sizes represented in your catalog. You then associate this parameter with each product in the SKU feed and can be log it each time a user shows a preference for a size. 

  • Was this article helpful?