Product data management
Data modelling is not a trivial task. The challenge is to provide the customer with the most relevant products that they are searching for and at the same time not to overwhelm them with information so that they do not loose interest or get side tracked.
Consider a simple example whereby an electronics shop sells a computer mouse "Mini Mouse M187" in ten different colours. The simplest solution is to enter data for ten different products. We already see the problem with data entry as every singe product would need to repeat names, descriptions, most of specification attributes and category assignments. But leaving this aside lets think what happens when the customer searches for a "Mini Mouse" phrase. Top results would be ten items representing the same products in ten different colours, which simply clutters the screen pushing other products which could be relevant down the list or maybe even to the next page. This gives the customer watching the search results a feeling of system being imprecise and unhelpful simply dumping the data onto results page. A much better way would be to group all ten products into one thus being concise with the search results and providing the customer with a real choice.
The platform solves this issue using two distinct entities: products and SKU. In terms of the platform products are detailed descriptions of what generic products. Products represent a template for actual Stock Keeping Unit (SKU). SKU represents actual (real world products) that can be offered to the customers. Consider t-shirt as an example: t-shirt by Lacoste would be a description of a product, t-shirt by Lacoste in size M and red colour would be a SKU. Product in this case represents generic t-shirt of a particular brand. SKU represents a specific size and colour. This model works particularly well with multi SKU (e.g. t-shirt with many sizes and colour) because when customers search for a specific phrase or a generic one the relevancy search engine will present the with a single hit every time but will change the image and description to SKU that best matches the search.
Looking at "Mini Mouse M187" example on the demo store we can analyse how the platform handles search and data presentation. When entering data the difference (which is colour and imagery) is set on SKU, the rest is set once on the product avoiding data duplication issue. When searching for "Mini Mouse" we get only one result hit that invites the customer to explore more colours if they are interested in this particular product. If however the search is more precise "Red Mini Mouse" the system offers red version with red picture to the customer, but still only one result hit without any clutter on the search results. Every data search is precise and gives the customer feeling of guidance and support as sales person would in a traditional shop.
The depiction of the underlaying data organisation and the end result on the website can be viewed as follows:
Figure 2: Product type driven product view attribute values presentation
When viewing "red mouse" of the mini mouse on product details page (on the left) we get combined specification (product data + SKU data) to form a complete view. When searching for "black mouse" phrase the search results (on the right) display the product with correct colour image and price for the "black version". Everything is clean and tidy and straight to the point.
Products
Product management section of Admin allows to search for products and then modify product data via product editors. Search can be done by various properties of a product, please consult search help for which options are available.
Core information
Product core information is contained in several tabs. GUID and code are unique identifiers for the product across the whole platform they are used for bulk import. It is anticipated that code contains a human readable value (e.g. base SKU code or variation thereof) whereas GUID is auto generated. However it is possible to have the same values for code and GUID. Product code is also used to resolve product images during image import.
Product type allows to identify type of product and thus tell the system how to display its information to the client and how to use it during search and navigation (as described in other sections of PIM documentation).
Brand is used for brand navigation. List of available brands can be updated via brands management section.
Search and navigation
Product type and Brand as mentioned before can be referenced as attributes productType and brand from product type as attributes and thus can be part of generic filtered navigation configuration.
Tag is another useful tool for providing additional search capabilities. Each product (and SKU) can be marked with tags. These are optional and each product can have more than one. In the screenshot example "Mini Mouse" product has two tags: "multisku" and "newarrival". Thus when tag search is performed on storefront this product will appear in the results. Example URL for tag search for "multisku" is: https://demo.yes-cart.org/tag/multisku
All search links are SEO friendly and can be used for many different purposes such as creating group of products related to a promotion, combining products into collection or a bundle, provide recommendations etc. All is needed is to add one or more tags (words separated by space) and then tag links can be embedded into CMS components or pages to give customer direct access to these lists (as done on demo store top navigation menu item "Demo").
Finally all attributes that have searchable to navigatable flags enabled will contribute to the generic filter navigation configuration.
See documentation on how to configure the product types and how this affect the search for more details.
Product SEO
SEO tab provides settings for general values such as title and meta tags but also URI. URI refers to final portion of the URL to product details page. By default all products map to the following pattern:
# up to 3.6.0 http://www.shopdomain.com/product/[URI] # up to 3.7.0+ http://www.shopdomain.com/fc/[SUPPLIER_CODE]/product/[URI]
thus example below maps "Mini Mouse M187" product to:
# up to 3.6.0 http://www.shopdomain.com/product/mini-mouse-910-002-M187 # up to 3.7.0+ http://www.shopdomain.com/fc/Main/product/mini-mouse-910-002-M187
If URI is not specified then internal product ID is used.
Product attributes
Product attributes allow to describe the product in terms of its features, style, design, technical specification etc. Attributes set on the product are shared by all its SKU. Individual SKU can add additional attributes to enhance the overall description of the purchasable item.
By default the attributes panel is preloaded with all attributes available to product's type. However any extra attributes are still visible and manageable (e.g. imported via bulk import or simply add by using a plus button). Therefore setting product type does not restrict business user in terms of using any attributes.
Id marked with asterisk ('*') denotes attributes available to products of given type, which do not have a value set. Id that displays a number denotes a configured and saved attribute value.
Note that if attribute values have localisable display values, they will be presented to the customer, otherwise raw value is displayed.
However search and navigation tends to be more precise with raw values. Therefore it is best to set clean and precise raw values for searchable attributes and provide customer friendly display names.
Additional attributes can be added via attributes management.
Product images
Images can be added as any other attribute. Image attributes have special type: Image and will display if image file can be resolved correctly in the repository.
If images are not showing a preview that means the image file was not able to resolve. In most cases this is related to incorrect setup of the root directory for image repository, which can be configured in system preferences.
Additional attributes can be added via attributes management.
Linking products
Each individual product tends to have some kind of association to others. Be it spare parts or products that complement each other or other alternatives, business users can increase conversion and boost sales by providing a complete view of where current product fits in the range of products provided by the shop.
Associations tab provides easy way to accomplish this linking. Associations are split into several types. By default the platform provides: Product accessories, Up sell, Cross sell, Buy with this products and Expendable materials. Additional association can be easily added but above list provides a good start.
As product links are added they will appear as appropriate tabs on the product details page (in the default theme layout). It is highly recommended to provide associations thus encouraging customers by reminding them something they forgot (e.g. person buying a printer may need ink cartridges displayed in Expendable materials), or completing their thought (e.g. when buying a dress Buy with this product may suggest a hand bag and/or a pair of shoes), or provide alternatives when product is out of stock etc
Product categories
Placing product into a category allows to categorise the product and thus help customer with their search. If customer is looking for "shoes" the obvious place to look is the "shoes" category. But what happens when we broaden our perception of just putting products into categories by their function and start bringing more context. For example seasonal context. For example "flip flops" could be in "shoes" and "summer clothing", and when summer is over those flip flops make their way to the "clearance" category.
This is exactly how the platform manages products. Each product can be assigned to one or more categories to suit the kind of cases described above. It is up to the business to decide when and where to assign the product.
It is also possible to have products without a category. These will not be visible on the website since the web site only shows what it has in its catalog and catalog is made up of categories. This use case is for products such as gifts that are only available via promotion.
Product availability 3.6.0
Product availability refers to how inventory should be tracked for products. In version 3.6.0 and lower this information for part of the product details, which made it inflexible when sharing the products across multiple shops and even across multiple fulfilment centres. In order to make this more flexible these configurations are now part of the inventory information together with the thresholds on minimum, maximum and step order quantities.
See inventory management for more details.
SKU
Stock Keeping Unit (SKU) is a real world purchasable catalog item in terms of the platform. If product is "'All Saints' t-shirt 100% cotton" then SKU is "'All Saints' white t-shirt 100% cotton size M". And since it is SKU that customer will eventually purchase it is SKU that has specific price and inventory levels. Therefore for every product there is at least one SKU.
Every product has potential to become multi SKU. Product's "SKU" tab provides a list of currently defined SKU, which could be one or more. As soon as SKU selection is made the "Create", "Edit" and "Delete" buttons will act upon SKU (not the product).
SKU Summary
GUID and code work much in the same way as the product's GUID and code. The code is also used to resolve SKU images during bulk import.
Business user can also refine name and language specific name.
European Article Number (EAN) / Universal Product Code (UPC) is optional parameter that can be set on SKU since this is the purchasable entity and likely to have one. This parameter can uniquely identify the SKU and can be useful in PIM integrations.
Rank allows to sort the SKU within a product. For example when displayed on product details page SKU are sorted using rank. Also during search if no SKU in particular is applicable to search terms SKU with the highest rank is selected as default (i.e. to display price and imagery).
SKU SEO
SEO tab provides settings for general values such as title and meta tags but also URI. URI refers to final portion of the URL to SKU details page. By default all SKU map to the following pattern:
# up to 3.6.0 http://www.shopdomain.com/sku/[URI] # up to 3.7.0+ http://www.shopdomain.com/fc/[SUPPLIER_CODE]/sku/[URI]
If URI is not specified then internal SKU ID is used.
SKU Attributes
As described in product attributes section product set template for common features shares by all SKU. With SKU attributes business user has the opportunity to describe the differences. Most commonly these would involve: colour, size or product options (e.g. regular hard disk drive vs solid state hard drive).
All attributes defined for given product type will be displayed in SKU attributes tab with one subtle difference. All attributes that were configured on the product will be displayed with asterisk ('*') as prefix. This is very useful as it shows what features are inherited by this SKU.
Additional attributes can be added via attributes management.
SKU Image
SKU imagery is very important. Although product already has some images SKU images will show how exactly purchasable item will look like. This is especially important when SKU differ in colour or some visible features. For example "Mini Mouse" product on demo store demonstrates exactly these features whereby the colour of the image on the result page will change depending on whether search keywords are: "red mini mouse" or "blue mini mouse" etc.
Image panel is attribute panel that displays all attributes that relate to images or image configurations. SKU images are used on search results pages, SKU details pages, shopping cart, order summary page etc.
Additional attributes can be added via attributes management.
SKU Prices
Prices can only be configured for SKU as it is only possible to purchase SKU (not the product).
It is possible to have multitude of prices for a single SKU in which case the platform will automatically choose single "best price" for the customer. This especially works well for seasonal sales when additional price records are added with validity period specified that "override" the regular prices and automatically become unavailable when validity period is over without any need of keeping track when to switch them off.
Business user can add, remove or edit prices for any SKU of a given product.
For more details on pricing (i.e. multiple price lists, seasonal prices, multi buy) please refer to price list management.
SKU Inventory
Because SKU is considered part of the PIM and is shared across all shops hosted on the platform in order to specify that shop in fact does sell this items a corresponding inventory record should exist for a fulfilment centre associated with the shop. Inventory together with priceless for SKU ultimately defines a product that can be sold in a shop and what is referred to as an offer.
For more details on inventory please refer to inventory management.
Configurable products, components and optional extras SaaS 3.7.0+
In some cases a purchasable SKU does not represent the final purchasable products. Consider a case where custom laptops are sold and there is a choice of CPU from different vendors. Also consider that some components that customer chooses affect the overall price of the product. For example if a high end video card is desired. Not all extras are necessarily mandatory like CPU without which a laptop will not function, but some optional extra can also be sold such as extensive warranties or bundled optional extras.
In order to define a configurable product you need to select the "configurable" checkbox on the main tab. This will enable the "options" feature in the storefront and the options will become available to select.
Note that options are fully fledged products in their own right and therefore requirements for inventory and pricing will be applied just as if it was a regular product.
In terms of platform options can be mandatory i.e. a selection must be made to complete the purchase, or optional in which case they are displayed to select but customers do not have to make that selection to complete the purchase. Each option is associated with an attribute that defines the choices. Note that the choice can be made for all SKU under given configurable product if the SKU filter is not applied, or could be specific to SKU to further enhance the selection process.
Selecting an option can involve multiple quantities to be included in the configuration. For example when buying a dinning table set you could have different chairs as options with 1 to 4 mapping, so that when a table is purchased and chair option is selected then final purchase will have 1 table and 4 chairs.
It is also worth noting that some products options cannot be sold separately. For example with CPU option example a laptop retailer might not wish to sell CPU products on their own. In this case these products should be marked as "Component/Part" using checkbox on the main tab. This will prevent customers from searching or adding these products to cart.
Below is an example setup of a laptop that has two options: 1) OPTMOUSE to chose a computer mouse which is mandatory and 2) 11084 to choose a keyboard which is optional but there are 2 items for each laptop.
