On modern ecommerce Websites, most of the heavy-lifting when it comes to merchandising happens on Product List, Category and Aisle pages – not on Product Detail Pages. This shift from single product to multi-product views has a profound impact on merchandising analysis. On the Product Detail page, merchandising levers are almost always net positive. While cannibalization of other products isn’t impossible, the impact of merchandising levers is much more specific. What’s more, the interaction of multiple merchandising levers is easy to measure since they collectively drive to an identical action (Carting and Buying the Product).
Everything changes when merchandising levers like discounts, highlights, call-outs, and offers are placed on pages with multiple products. On these pages, multiple levers for different products are placed in obvious conjunction. Every product can’t be a winner. So the net impact of merchandising levers on a product list page is at least as likely to be a shift in the distribution of product purchases by product SKU than it is a net shift in total product purchased.
In my last post, I touched on measures like merchandising density (the # of call-outs per product by type on page), price range (the price gaps between products on the page), price gap distance (the dollar gaps between adjacent products) and discount range (the dollar gaps between discounts shown on the page – also interesting by distance) as powerful optimization variables for modeling the optimum configuration of multi-product pages.
I also noted in that post that creating these variables has been quite challenging. In real-world analytics practice, it seems like building models is the easy part of most projects. The hard part is getting the data and putting the data into the right format for analysis. That’s true in attribution modeling. It’s true in digital segmentation. It’s especially true in merchandising analytics.
The fact is that a great many ecommerce Web analytics implementations are created without ANY regard for the capture of merchandising levers. Even on the product detail page, it’s hardly unusual to find that the Web analytics tool is capturing nothing about the state of the merchandising levers. Is there a discount shown? No way to tell. Is there a rating call-out? It’s 50-50 that you can tell. Is there a video view? Your only clue may be click reports or video reports with no direct tie to the product. Is the product even IN-STOCK for heaven’s sake!
Can you imagine trying to do retail analytics when you can’t even tell if the product being viewed is shown as out-of-stock? Makes it a bit tough to understand conversion rate. With so many Web analytics implementations done by folks who don’t do analysis, the miss rate is awfully high.
There really is no excuse for not capturing merchandising lever information on Product Detail pages. On product list, facet, aisle and category pages, however, there are plenty of good excuses.
First, let’s suppose that you can capture all of the merchandising information about the products shown on a multi-product page. Hey, let’s go wild and assume you can capture the actual products shown on the page! It’s basically impossible to analyze product lists in a Web analytics tool. Web analytics tools provide little or no ability to manipulate lists. You can’t derive any of the variables I’ve talked about like density or gaps. And, of course, you can’t model those un-derived variables against outcomes. So there have been pretty good reasons why capture of this information wasn’t very important. Why would you capture something you couldn’t use?
I recently saw a digital measurement strategic plan recommending that a large enterprise use GA Premium as their digital data warehouse. Not their Web analytics tool – their data warehouse! Now god help them if they take this advice seriously. GA Premium is an excellent Web analytics tool and formidable competition for vendors like SiteCatalyst and Coremetrics. What it isn’t, is a data warehouse.
It lacks a few tiny little pieces of a data warehouse: things like the ability to create a data model, transform data, integrate data on multiple keys, type and work with numeric data appropriately, handle unstructured data, support procedural or declarative queries, protect sensitive PII data, and support data replication and provisioning. By and large, it’s not the slightest bit unique in these deficiencies. Web analytics tools ARE NOT data management tools and the recommendation would have been every bit as absurd if written about SiteCatalyst as it was about GA. Really, only someone completely ignorant of both advanced analytics and data warehousing could make such a recommendation.
So it’s a prerequisite, if you’re going to do merchandising analytics, that you have a data feed and a platform that will let you do the necessary manipulation of the data followed by the necessary analysis. That typically means either a true database platform or a true statistical analysis tool – and probably it means you need both.
But what about getting the data? I’ve suggested that adding merchandising levers on product detail pages is relatively straightforward. Adding it on product list page isn’t straightforward, and that’s the second big problem.
As a data collection mechanism, tagging works remarkably well for a wide variety of situations. It’s become the de facto means of digital analytics data collection for good reason. However, it does have some fundamental drawbacks in certain situations and capturing product impression data may be at the top of the list.
To do effective merchandising analytics, you’ll want to capture all of the following (and maybe a few more that are specific to your merchandising efforts):
- Product ID
- Product Position
- Product Price
- Product Discount
- Product Ratings
- Product # of Reviews
- Product Inventory
- Product Callouts (Usually there are 3-5 different styles on a site)
Even if you pack this information pretty tightly, it’s quite a bit of data. Enough so that while a single product will likely fit in the space allocated to a variable, a group of products almost certainly won’t. The most popular analytics solutions on the market place fairly strict limits on the amount of data that can be passed in a variable and also on the number of variables that can be passed. There are also limits on the total amount of data that can be passed in some browsers – a restriction that hits every Web analytics tool equally. This means that adding product impression data for 15 or 20 or 30 products on a page can break the collection even if you can find ways to fit the data into a multitude of variables. That’s a disaster – and one that can happen in unpredictable and even largely undetectable ways.
It’s also a case where tagging begins to put a serious burden on page weight. Concerns about page weight vary by industry, but nowhere are they higher than in ecommerce. Placing and then popping product list merchandising data is one of the few collection points that can actually add a noticeable burden to the tagging.
That’s really why I chose this topic as a good one to explore in conjunction with Cloudmeter. Some of you may know Cloudmeter better under their former appellation (Atomic Labs) or by their product: Pion. They’ve been around for quite a while and their product has carved out a distinct niche in the market-place. Pion Enterprise is a server-side data collection tool (a “sniffer”).
For a long time, Pion’s primary role was as a straightforward alternative to tag-based collection. Pion allows the enterprise to collect the data server-side and then source it to any (or even multiple) web analytics tool. In other words, you can setup Pion Enterprise and use it to source SiteCatalyst or GA.
The benefits are fairly obvious. With server-side collection, there is NO page weight at all. The impact on UI performance is zero. There’s also no page impact. Measurement can’t impact experience – so there’s no additional QA cycles and no need to interface with web UI or QA teams.
The biggest concern around Pion (and other server-side tools) has been around collection of client-side interactions. It’s hard to beat tagging for client-side capture – and if you have to add client-side capture to supplement server-side collection, some of the compelling advantage is lost.
Perhaps because of this, the market-share of server-side data collection has been limited.
Cloudmeter’s been re-thinking that positioning, however. With the dramatic growth in data warehousing, the question of sourcing Web analytics data has taken on new importance. As I pointed out earlier this year in a white paper on digital measurement infrastructure, there are some signal disadvantages to sourcing a warehouse from a Web analytics tool.
Pion Enterprise provides a pretty slick alternative to data feeds from tagging for enterprise warehouse sourcing. It provides real-time data collection. That may or may not be important now, but it’s critical when thinking about a long-term technology stack. Pion can protect your existing investment in tag-based Web analytics. It has zero impact on those solutions and can even be used (if desired) as a single point-source for those solutions. This potentially saves money around TMS solutions and eliminates some of the stickiest problems with Web analytics governance.
With Pion Enterprise, you can configure your data feed collection to be much more precise and efficient than with a data feed. You control data types, initial data structures, and data relationships. You’re data starts out in an efficient form – making all subsequent processing that much easier.
Best of all, Pion Enterprise provides a natural means for capturing data of the sort necessary for Merchandising analytics. All of those merchandising levers are ALREADY on the page. With Pion Enterprise, you just need to mark those fields so that Pion can recognize and extract them. There’s almost no page weight impact and there’s no additional impact on performance at all. What’s more, Pion can manipulate the Product Set information to create useful data tables right out the door.
This all makes Pion Enterprise a very nice fit for rich capture of product impression data and the associated merchandising levers that go along with it. I chose this topic in conjunction with Cloudemeter precisely because I think that among the really high-value analytics projects available to the enterprise, the analysis of merchandising levers best highlights their unique advantages. Under some fairly common circumstances, Pion Enterprise may be the ONLY viable solution you have to support rich merchandising analytics. At the same time, it provides a way to painlessly supplement or potentially replace your efforts around tagging to support your Web analytics solution, while delivering a true real-time data feed to almost any type of data warehouse.
I hope you’ll register for our webinar in early September to find out more!
[BTW – It’s worth reading the comment from Serenata Flowers (one of our client’s in this endeavor) on the applicability of the Laffer Curve. It’s a great comment – perfect to think about over a beer. So I’d encourage you to hoist a pint before proceeding because I’m going to stand by my guns here (at least to some extent).
While the shape of the curve is hotly debated and the impact of marginal tax rates may not be perfectly dis-incentivizing, there doesn’t seem to me much doubt that the curve exists. In one sense, of course, a function representing tax collected vs. tax rate must exist – even if it’s a straightforward linear interpolation. That’s it not a straightforward linear interpolation is, I think, beyond doubt. Going from a 50% tax rate to a 100% tax rate will not double revenue. So some form of Laffer curve does exist. What’s more, I think it’s almost beyond dispute that the curve does go negative (a key part of the concept) – a 100% tax rate will raise less than some lower marginal rate. The part that’s nearly impossible (it seems) for economists to decide is exactly the shape of that curve – and that’s where discussion of the impact of marginal tax rates is interesting. The curve almost certainly doesn’t look quite like Laffer first drew it.
Analogically, I’m fairly certain that taken in aggregate, the effect of merchandising levers on list pages will be similar. At some point, additional density will create negative lift for most merchandisers. Finding that point isn’t easy.
It may indeed be true, though, that for some customers there really is no curve. You can’t (as is captured perfectly in the comment) set tax rates on a segmented basis. Few would accept taxing those willing to work for nothing at 100% while taxing the less committed at significantly lower rates. On the other hand, in ecommerce when offering discounts, segmentation provides an opportunity to do just that.
The addition of segmentation to merchandising analytics makes perfect sense to me (I could hardly say otherwise). And, of course, it opens up a whole new set of analysis opportunities! It goes almost without saying that segmentation is another layer on top of the merchandising analysis – not a replacement for it.]
