Skip to Main Content

Feb 16, 2010 | 4 minute read

Why Prices are Moving Out of the Catalog

written by Michael Vax

In early ecommerce implementations, more often than not, price was treated as a property of a product and was kept together with the product in a Catalog. Think about a price sticker on a box in a supermarket.

As ecommerce systems grew in complexity a sale price was added in addition to a list price, followed by tiered pricing - an ability to define prices based on the quantity of items in the order.

For example:

QuantityList PriceSale Price
1$5$4.50
2$8-
3$11-

A need to support multiple currencies for the same catalog has further increased the complexity of price management. Now the online store operator needed to maintain multiple sets of list, sale, and tier prices for each product.

QuantityList PriceSale PriceList PriceSale Price
1$5$4.50€ 4.2€ 4.0
2$8-€ 7-
3$11-€ 9-

At this stage managing prices inside a catalog becomes problematic. Quite often responsibilities for different geographies and currencies are distributed through multiple branches of an organization. To further complicate matters, in the European Union a retailer may want to use different Euro prices in a French store than in a UK store while selling goods from the same catalog. A more flexible solution was needed and most modern ecommerce platforms started to separate prices from catalog and introduced price lists.

There are more business and technical reasons for prices to grow up and get a life of their own.

  • As an ecommerce channel is growing in importance, it becomes more tightly integrated with other enterprise IT systems. In many companies, different systems are used to manage pricing and catalog information. This means different integration points and update cycles as price information is changing more often than product attributes.
  • With ecommerce going global, it is not uncommon to delegate responsibility for maintaining pricing to local branches. In a big organization a person responsible for modifying catalog may not be the same guy who has the rights to set prices.
  • The ability to support multiple price lists is especially important in B2B environments where prices can be predetermined by a contract signed with each business customer.
  • By separating Price from Product, your ecommerce application will have more options to improve performance by having separate caching strategies for product and prices.

Making Price Lists Conditional

So, you have moved prices out of catalogs into price lists and created a separated list for each currency. Life is good and thoughts of a vacation in a nice sunny place start to cross your mind. Proudly, you demonstrate new functionality to business users. They like what they see but immediately recognize further ways to increase online revenue if only you can add a flexibility to use different price lists for different customers. For example, registered users can get lower prices than anonymous visitors and members of the site's VIP club can get even further discounts in the VIP price list on some luxury products.

In technical terms, it means you need to make price lists conditional.

Now it is not enough to have a permanent static link between a catalog and a price list. You need to support multiple links and attach conditions to them.

How to do customer segmentation and implementation of rules to decide which price lists to use is out of scope for this blog post. Let's discuss, however, how this would affect your price list implementation.

An additional set of questions needs to be addressed now:

  • What do you do if conditions for several price lists evaluate to TRUE? Do you need to have a priority assigned to each price list?
  • Should you have a default price list in case all conditions evaluate to FALSE?
  • What do you do if a price list does not have a price defined for a particular product?

Allowing multiple price lists to be used during the course of one user session gives a business the ability to create a price list for each category in a catalog. This becomes handy if responsibilities for catalog categories are distributed between different people in organization.

Another use case for the VIP price list mentioned above is when it only includes prices for a subset of luxury products. When a VIP customer enters the store, the system first looks for product price in the VIP price list. If the price is not found it falls back to another price list with a lower priority that contains prices for all products in the catalog.

Extra flexibility always brings additional complexity and developers need to implement a user friendly and straightforward UI for business users to manage prices. You do want to avoid confusion in such a business critical area.