Salsify is very flexible system, and your data can be stored to suit the needs of your organization and use cases. There is no absolute right or wrong in product content data storage - a lot will depend on how you will be using and syndicating your data. The best practices below should serve as guidelines to make informed decisions about how your data will be stored, but ultimately, the way your product content is stored best will be unique to your company and how you work.
Adding data to Salsify is an iterative process. You can easily add, delete, update and reformat data at any point. So at first, focus on getting easily available information into the system, and add to it as you go. It’s often very helpful to get a small set of data and products into the system that contains the typical types of products and product information your company will store in Salsify to start working with and learning from.
In Salsify, each product has a product ID, a unique identifier that is included in every import. It is what allows Salsify to recognize whether new data should be attached to an existing product or, where the product ID isn’t in the system yet, a new product should be created.
When choosing a product identifier, keep in mind that it should be an ID that is unique and available when the product is first added to Salsify. Often companies use an internal SKU number or model number as a product identifier. UPC/EAN could also be used as an identifier as long as it is available for each product as it is added to Salsify.
The identifier should also be as permanent as possible. You can update the product identifier, but only by going in and manually making the adjustment, or by importing all the information to a new record and removing the old one. Note that product identifiers cannot start with an underscore _ character. We recommend not including non-alphanumeric special characters in product identifiers.
Add products to the system and set property types that best support the kind of data in them. Choose specific data types to guide users to enter information in the right format. Each format type allows multiple values to be stored per property as well.
Data types in Salsify Include:
- String - plain text value
- Picklist / Category - dropdown menu of choices
- Number - only allows numeric characters
- Date - formatted yyyy-mm-dd
- Yes / No - only allows yes/no
- Rich Text - allows basic text formatting
- HTML - stores html formatting with text
- Link - stores value as a clickable link
- Digital Asset - stores images, videos and other files
See Data Property Types for more information on choosing property types.
Building Your Fields
Store product information at the most granular level at which you would need to pass it through to a retailer or filter by internally. When you’re building your fields, think about a few things:
What are your endpoints for data and what are their requirements? Consider top retailer requirements and store data that meets those. If syndicating to your e-commerce website, what are the requirements there? What are your company’s needs for the data? What format will lend itself best to filtering and exporting?
Where does this information come from? If it already exists in another system, what format is it in now? Does it need to be transformed for Salsify or is it useable as it is?
Who will add/maintain the information in Salsify? Note who will be responsible for the fields as you’re building them out so that when the workflows are developed, there’s a clear understanding of who will be entering or updating it.
What You Don't Need to Store
If you only need a piece of information to meet a specific retailer requirement, do you need to store it? When mapping to retailer requirements, you can use formulas to enter some information without storing it as a property. So for example, if Amazon requires you to answer whether or not a product has a battery, and none of your products do, you can use a formula to answer “No” to all. You can also base answers on logic, so if you have one category where the answer would be “Yes”, you could answer yes for that category but no to all others. Anywhere you could apply logic to meet a requirement, unless you have another need to store the data, it may make sense to just use formulas to meet the requirement.
Store Information Specifically
Store data in a format that gives you the most options in delivering your content. In many cases, it makes sense to break down information to the lowest possible level. In some cases, Salsify will be receiving already-formatted data from an existing PIM and you won’t have flexibility in how you break down data to store in Salsify. There are always ways to manipulate existing data to fit endpoint requirements, and our Customer Success team can help you find the best strategy to fit your use cases.
It often makes sense to store information as a multi-value property. For example, if you have informational bullet points that are not specific types of product information, storing them as a single, multi-value property makes syndicating the data easier because you can refer to one property in a formula and pull the number of values you need from it. If the values are stored in separate properties named Bullet Point 1, Bullet Point 2, etc. you have to refer to each of the properties in your formula and combine them for syndication.
A product could have information about skill level, awards, certifications and warnings and one retailer wants them as bullet points, but another wants that information in specific fields. If you stored all this information in a single property called "bullet points”, it would be difficult to pass Skill Level along to another retailer who asks for it in a separate field. If you store the information in fields called Skill Level, Awards, Certifications, and Warnings, you could pass the information along in either specific fields, in bullet points, or both. So there are cases where storing the data in separate, specifically-labeled fields is a better choice and allows more flexibility.
Label Properties Clearly
As you name your properties, use terms that your organization understands, and be clear about properties’ meanings. You can set help text inside the app for each property to explain the type of data that should be stored in it. The more specific and clear you are, the more consistent your data will be.
For example, if you have fields called Width, Height and Length, different users may interpret these very differently. They might think the dimensions are for the product package, the assembled product, or the shipping carton. And they may have questions about which side of the package should be represented by length or width. They may also assume an unintended unit of measure, some entering the information in feet or inches or centimeters. Better field names in these cases would be Retail Package Width, Retail Package Height, and Retail Package Length, with help text for each specifying what the unit of measure should be, and which part of the product should be represented by each measure.
Striking a Balance
Keep in mind that the more fields you have, the more fields you maintain. So finding the balance between complete granularity and consolidated information is really the key to having a Salsify organization that fits your needs.
Each of your product types will likely have a different set of product specifications unique to that product type. There may be opportunities in these cases to create single fields that mean different things to different types of products. Being clear about the definition of fields will keep your data consistent and useable.
For example, you could use a field like “Color” across multiple brands and product types. You just need to understand what “Color" means for each. For a backpack, is “Color" the main outside color or the interior? For a suitcase, is it the sides? Your decisions should be based on what “Color” means to your team, and how you use that information.
Using Product Variants
In some cases, you may have products that are very similar except for a few variations. Apparel, for example, may have one identical shirt in five sizes and three colors each. Products can be grouped into parent/variant relationships.
Where these relationships are set up, a parent is created, the variant products are created and the association is made between them. Everything that is entered at the parent level will be inherited to the variant product, unless a different value is entered specifically at the variant level.
So in our clothing example, all the logistic and marketing details about the product could be stored at the parent level: brand, manufacturer, product description, dimensions, weight, etc. Things that are specific to the variant would be stored at the variant level, like color and size. When products are syndicated, the parents are not published, but the inherited values are passed through with the variants.
It can be a little more complex to handle parents and variants though imports and exports, but the benefit of parent/variant setup is uniform information on all variants, and duplicated work on the variants is eliminated. A dropdown is also available on the product page, making it easy to navigate to all the associated variants.
For more information on using product variants, discuss with your Customer Champion or click Contact Us to reach out to Customer Success.