Retail assortments: Defining your assortment schema

Your assortment schema will define the data fields (columns) that show up in your Assortment tool, how each one will be populated, and the overall user experience for how buying teams, merchants and brands will interact with your assortment plan.

A typical assortment schema will include:

• Product attributes, including those needed for planning, initial market selection/commit, ordering, and web setup
• Pricing, including adjustments/calculations per item
• Notes
• Internal hierarchy and classifications 
• Doors
• Formulas, including markup % and totals

 For each field, we will define: 

• Data source: Where will the data come from?
  • Uploaded by the brand with their catalogs (typically product attributes and pricing)
  • Entered manually by the buying/merchant team 
  • Entered manually by the brand sales team (applies to collaborative "external" assortments only)
  • Automatically populated or calculated based on other fields

• Data type, formatting, and constraints: 
  • Freeform text 
  • Numbers: units, currencies, percentages, number of decimal points
  • Yes/No or boolean
  • Dropdowns: Preset lists that apply to all users/assortments in the organization
  • Relationship/Lookups: Fields that are dependent on other fields (e.g. Department > Class > Subclass structure)

• Assortment user experience:
  • Will the column be visible (checked) or hidden (unchecked) in the default column view? 
    • Best practice: The default view should include the fields needed in market by the majority of buying/merchant teams, and those which drive critical analysis and buying/planning decisions. Additional views can be created and saved for other uses to include other fields, or to serve other user types such as marketing or web data collection.
  • Should the field be visible on the item details module?
    • Best practice: Include key attributes and notes that a buyer/planner may need to refer to, or to fill out when adding a placeholder (SMU) for exclusives developed during the appointment. Including the same fields as the default column view is usually a good place to start.
  • For dropdowns, should the user be allowed to overwrite the preset list and manually type in their own value?
    • Best practice: This is recommended for internal lists that may change frequently, such as Department, Class, or Subclass. It is not recommended for standardized dropdowns like Delivery Month or Yes/No.
  • Should users be notified in the "Updates Feed" if the field data changes? 
    • Best practice: Fields that have serious impact to buying/planning decisions should be included in the feed notifications. For example: Cost, Retail, Color, Size Range, and Availability.

What you (the merchant) will need to provide:

• Any data which will need to be populated in a specific way to match your back-office systems. (This can apply to field names as well as the values populated in the fields.) Common examples include:
  • Department, Class, Subclass and other hierarchical classifications
  • Vendor or manufacturer names and codes
  • If any of these fields have a "tree" or "nested" relationship to other fields (e.g. the Department selected impacts the list of possible options for Class), please note those relationships.

• Lists for any other pre-set dropdowns you wish to standardize across the buying/merchant teams. Examples might include:
  • Delivery names
  • Product Types
  • Key trend concepts or marketing tags
  • Price bands or price point ranges

• The different types of notes or hashtags needed to capture intent and analyze effectively. General "Notes" columns are useful, but more specific columns will help your buyers and merchants tag and track key strategies. Examples might include:
  • Cluster, region, or door notes
  • Trend notes
  • Styling or marketing notes for photo shoots
  • Collection or capsule notes
  • Special events (e.g. holiday, Black Friday / Cyber Monday, annual sale, etc)