E-commerce options: Product Attributes vs. Master Products

At their simplest, product attributes are a way of associating additional information on a line item basis to an order. Do you want the t-shirt in green? Would you like the trophy personalized with your initials? What is the name of the animal the medication is for?

I always think of product attributes as a form builder – adding a number of fields of different types to the “add to cart” form on the product detail page (I usually find attributes don’t work well when you can add to cart from a product list screen – there is seldom the space to display all of the necessary attributes for 20 or 30 products down the page).

I also add some basic functionality to allow given attribute options to affect price, weight and/or SKU, so the XXL shirt is $5 extra or the chrome plated dumbbells weigh an extra 5 lbs. This allows a lot of smaller merchants to create entire stores just using product attributes – especially if they don’t need integration with their back end inventory system (or don’t HAVE a back end inventory system!).

The biggest problem with using attributes is the lack of support for inventory/availability and the ability to tie into back end systems if they have attribute combination SKUs (one for green large t-shirts, one for red large, another for green medium and another for red medium). I have never seen a compelling implementation of product attributes where there is an easy way to track inventory and availability of green large t-shirts as opposed to red large t-shirts.

For smaller merchants without inventory systems I usually recommend using product attributes for implementing their catalogs as it substantially decreases the amount of data entry. Adding 500 products is fairly easy, but if each comes in 3 sizes, 4 finishes and 8 colors that is 3 x 4 x 8 or 96 versions of each products for a finger flattening 48,000 unique product records to enter. That’s more work than most of our end customers are interested in doing just to put what they see as a few hundred products onto the web!

However, if you have a back end inventory system with that data (and the descriptions can be made end-user comprehensible – often a problem with old B2B industrial supply databases) you get the ability to offer only a subset of combinations and to track inventory and sales (and to implement more sophisticated dependent pricing where the additional cost of a large is greater in gold than in silver). In those cases we often implement a “master products” pattern, allowing them to set a subset of product properties in a “master product” and to then associate each inventory line item with a single master product so you don’t need to reference an image or upload a detailed description for every single version of a particular product. This is particularly important where the back end system doesn’t have all of the information you want to display on a web page about each inventory item.

In Short, we usually recommend using product attributes unless you:

• Have good quality, end user readable data for every single SKU in an existing accounting/ERP/POS/inventory package or are willing to create such data.
• Need to track inventory at a SKU level
• Need to track availability at a SKU level (usually important when SKUs have a long re-order lead times or go permanently out of stock at the end of a season)
• Need complex dependent price or weight rules where the price of a SKU cannot be calculated as a base price plus a sum of premiums for each selected attribute

One side note. Sometimes you cas use a combination of product attributes and master products. Sometimes some items are inventory based and need to use master products whereas others are custom built and just need attributes. Also, sometimes you might want to add product attributes to SKU level items. For example, you may want to allow people to personalize a green XL shirt with their monogrammed initials.