Out of stock – basic reports

The wealthiest man in Spain (my home country) is the owner of Zara. There are Zara shops everywhere in the world. Just as an example, I was in Bangkok two months ago and I found a Zara store in one of the most popular shopping centres. The success of this company has been widely studied. One of the key success factors of this company is stock management. If you are interested in a detailed explanation, here you have a video that I found very interesting:

In real stores, the only way to determine if a product is popular or not is by the number of units sold. I am not saying that this is not useful, but the mathematical models used could benefit from additional metrics. In the online world, we can go one step further and include other metrics in the algorithm, like product views, add to carts and number of times it is out of stock.

With Adobe Analytics, product views, add to cart, remove from cart and orders are standard metrics that will be included in any typical retail implementation. On the other hand, there is no standard out-of-stock report. I am sure different people will have slightly different views on what “out of stock” is. For me, it is the number of times per visit a product has been shown to a visitor and it was out of stock.

Let me summarise why I chose this way of measuring. While a product is in stock, you can measure the popularity of a product using metrics like add to basket or units sold. However, the moment it is out of stock, you do not have any way to measure how popular it is: you just know it cannot be sold. It could well be that the product is not popular any more and you can just remove it from the inventory. Or, it might be the most popular product, with thousands of page views and frustrated visitors that cannot purchase it. With my solution, you can tell how popular an out-of-stock product is.

After this long introduction, let’s go to the implementation with Adobe Analytics. This is probably the simplest part of it. My suggestion is to use a cookie and a list prop:

  • In the list prop, you set a comma separated list of product IDs that are shown and are out of stock. You need a list prop as it is possible that on one page there are many out of stock products.
  • In the cookie, you should store the list of product IDs that have already been reported during that visit.

I would like to show you some code, but since it entirely depends on each implementation, I will just show you the results. Surprisingly, the best example is a bra web page, as it has many different sizes:


In this example, there are four sizes out of stock, so the list prop will get four values (I used the pipe as the separator):


Since we do not want to continuously be reporting these values for this session, I keep the value in a cookie. Before setting the prop, a piece of JavaScript checks whether the value has already been reported.


Finally, the report looks like:


In this case, I am only interested in instances, but visits and visitors are other valid metrics that can be useful. An alternative would be to remove the cookie and always report the products. In the end, it will depend on how you want to use those values.

Why a data layer is a good thing

Back in the old days, when we used the traditional division between an s_code and on-page code, the concept of a data layer made little sense. The developers had to add some code server-side to generate the on-page code. Gathering the information to be captured was a server-side issue: the CMS would have to collect the information from one or various sources (CMS DB, CRM…) and present it on-page, so that, when calling s.t(), the s object would have all needed information.

However, now that tag managers are becoming the norm, the previous approach does not work well. There is no on-page code; all code is generated in the tag manager and injected to the page through it. This means that, in order to track some data, it must already be in the HTML code or in other resources available to JavaScript, like query string parameters or cookies.

One might think that, as long as the required information is visible on the page can be extracted using CSS selectors, we are safe. Consider the requirement to capture the city in the delivery address and this code:

Using the selector #delivery-address .city, we should be able to extract “London”. But, what if the developers decide to change the id or the class? What if there is a new requirement to completely remove this data from the web page? Our tracking will be broken and, if this happens a few months after the release, we will probably not know why.

The most reliable solution is to add a JavaScript object, completely independent of the rest of the HTML code, with all the relevant information of the web page. Then, the tag manager just needs to reference directly the elements in the JavaScript object. The developers can then change anything in the HTML code and, as long as this JavaScript object is kept intact, the tracking will continue working.


There are many ways to create a data layer, but all fall into two categories: create a custom data layer or follow a standard. I will never recommend to create a custom data layer. There are a few standards that are worth mentioning:

  • AEM client context. This is the de facto standard that comes with AEM. I have spoken with AEM developers and all say that this can be used in many cases.
  • JSON-LD. I have never worked with this one, but one of my clients was already using it. More information here: json-ld.org.
  • W3C Customer Experience Digital Data Layer. I always recommend this standard, as it has been produced by the W3C (the same body standardising the Web) and Adobe took a role in this standardisation, together with other companies like Google, IBM, Red Hat… The previous image is an example of how the data layer would look like in this case. The standard itself is freely available: http://www.w3.org/2013/12/ceddl-201312.pdf.

In future posts, I will add some details about the last standard.

A brief introduction to AAM

The concept of a DMP (Data Management Platform) is not new in the digital marketing arena. However, there are still many marketers who do not know of this type of platform and what it can do for them. I will explain what is a DMP and what is Adobe Audience Manager.

In today’s digital life, visitors give a lot of information about their traits. However, that information tends to be siloed. The two main sources of information, CRMs and web analytics, do not “talk” to each other. Your web analytics tool just gives information about on-line visitors and your CRMs only knows about static data. Ideally, we would like to have all that information combined in real time so that we could provide the visitor with the best experience.

Think about these scenarios:

  • An airline wants to offer credit cards to frequent fliers between London and Paris.
  • A retailer would like to retarget visitors to their website, who have just moved to a different website without purchasing.
  • A media company is interested in selling ads on their own websites and wants to show mainly relevant ads.
  • A car manufacturer has created a series of ads, which should be shown in sequence.

All these scenarios and many more can be fulfilled with a DMP. Without getting into much detail, a DMP uniquely identifies a visitor and tries to get as much information from that visitor, using different sources and marrying the data from each of the sources. One other key property of a DMP is that it should be completely anonymous; in other words, no Personal Identifiable Information (PII) should be managed by the DMP.

Demdex was one of the companies that offered a DMP. Adobe acquired Demdex a few years ago and included the DMP in the Adobe Marketing Cloud. This product is now known as Adobe Audience Manager (AAM). What are some of the differentiating features of AAM?

  • It integrates nicely in the Adobe Marketing Cloud.
  • It can be natively be delivered through DTM.
  • It supports Adobe’s Visitor API. As a consequence, you can use the Master Marketing Profile (MMP) in AAM.
  • It captures natively all Adobe Analytics variables (eVars, props, events…)
  • It can be used in conjunction with Adobe Target to create personalised experiences.

I have been working with AAM now for a while and I can see a lot of potential in it.