The price pressure
Twenty first century shopper has so many options. Unless a retailer is a niche player, it is a shopper's world. While retailer has many tricks up their sleeve to bring eyeballs to their e-commerce website, keep them there, convert into a sale and bring them back, the de-facto strategy that all retailer's adopt is the ubiquitous price strike through to give the shopper a sense of getting a good deal on the goods. Price used to be decided by business teams pouring over their analytics reports, industrial demand/supply reports and peering into the crystal ball of future trends. It still is done like that in many places. But what has changed is that price gets revised (usually downwards) more frequently than before. What used to take months and weeks earlier now happens matter of days and hours.
Let us say your client has a pricing strategy in place - and have the experts coming up the right prices to show for a product each hour of the day and change that every two hours . What would be your strategy as a technical architect and adviser?
Options for price updates
In technology, every thing is possible but may not be practical within the constraints a particular solutions may be operating within. Understanding the when and what to compromise on is the trick.
So what is possible in WebSphere Commerce?
If you get your price as CSV from your pricing engine, then refer here for how to load up your price: . If your pricing engine is IBM DemandTec, then see DemandTec with WebSphere Commerce.
For more control BODL service asset could be used to create a custom load handler.
Or if CSV file is not your cup of tea - say you need this as a true "feed", a look at the current "Content Management system web feed" utility provides some clues. At the end, same data load framework will be used to load information into WC database, but ability to establish connection to the feed provider and transform the feed into WC specific business objects is the real work here (how to do this will be taken up in a future post).
Or may be old style (now deprecated) massload may be used.
Some may use a form of database export/import.
Of course, WebSphere Commerce may be the price master so that business users create/manage price using Commerce Management Center.
Any which way we load the price - the question considered in this blog is : How often should we propagate updated price to our live site?
Real question: How many times?
A change in price needs the following to happen:
1. Change must be propagated from authoring DB to live DB.
2. Search index must be rebuilt (if using priceMode = 1 or 2)
3. Dynacache must be invalidated and warmed
4. CDN cache must be invalidated and warmed
All the above takes time. I don't mean hours - but we need to be cognizant of the number of minutes each of this takes.
If the price to be shown is dependent on conditions (price rules) or if the retailer wants to define price reductions via promotions because that is how they see price discounts, then some pre-processing will be necessary to decide which price to index and how to cache your price by associating the correct combination of customer segment, promotions and price rules.
And cache invalidation and warming takes time unless you have a caching appliance like WebSphere eXtreme Scale solution that has excellent cold-cache capabilities that renders warming unnecessary.
The price change also affects in-flight transactions. A robust business logic should inform shopper of the change in price up to a point in their shopping journey and otherwise accept the order with previous price. Visible price change during checkout affects shopper's trust on the retailer. Frequent switching of price may just make people wait longer and delay their buying decision. But not changing the price for long could expose the retailer to competitors under cutting them. Finding the right balance is more of an art than science.
One customer agreed for twice a day price change. Another was OK with hourly updates. Most challenging one was a customer who insisted on instant change and that too on average 50 times a day. Things we need to work with retailers is batching as many updates together as possible and helping the retailers work out some form of prioritization within their process. For example, price is wrong (missing a digit altogether) warrants instant reaction. In other cases, it may not be that urgent. Also, solution could be found by a different strategy altogether. For example, reaction to under cutting could just be advertising a policy of price match with reputed retailers rather than getting into a no-win war on price. Winning the retail race on core differentiators such as engaging shopping experience, after sales service etc is more profitable.
Random closing thought
One random, but relevant thought: What is the deal with strike through price? Some retailer may just want all their prices to be struck through with a lower price right next to them. And the "offer" price may just be one cent or one rupee less than the "list" price. Such tricks may just train the shoppers to filter out the struck-out price altogether, robbing the emotional benefit of scoring a deal. Often the actual value of saving in numbers is more transparent than percentage saving.