Sharing my experience as an Adobe consultant

In my experience as an Adobe Audience Manager consultant, I have noticed that many clients need a lot of hand-holding at the beginning when working with this DMP. Coming from the Web analytics world, this was a bit of a surprise to me at the beginning. I remember when I started an Adobe Analytics project I worked on 6 months ago, one of the client teams had a spreadsheet with 138 requirements… and that was only one of the teams involved. They knew exactly what they needed from the tool, which made my life easier. However, this is rarely the case in an AAM project.


A while ago, a customer requested a call with me to discuss one issue. Usually, I get more technical questions, but this time, he wanted to have my input regarding something completely different. The developers had realised that they forgot to include a JavaScript library in the website and they could not add it immediately, due to code freeze. They thought of an alternative solution: load it through DTM. My customer, from the marketing department, was not sure whether this was possible or acceptable and, therefore, wanted to know my point of view.


If you have been developing websites for a while, you will know that one of the typical recommendation is to execute as much JavaScript as possible at the bottom of the page. This is nothing new and Yahoo recommended it in 2007. The reason is very simple: JavaScript code tends to add a delay, both when loading the JS file and executing it; so, moving it towards the bottom, you make sure the HTML is loaded and the page is rendered before starting to execute any JavaScript. The user believes the page is loaded a bit sooner than when it is actually fully loaded. DTM knows that very well and this is why you have to add the two pieces of code: one at the top and one at the bottom of the HTML.


A few years ago, one of my customers showed me a tip that I found very interesting: tracking the lifetime value of a customer. The SDKs offer a function to track the visitors lifetime value, but the traditional JavaScript implementation does not have anything similar. So, we will have to create it.


25 Oct 2015

VISTA rules

If you have been in an Adobe Analytics implementation, it is highly probable that, at one point or another, you have heard the expression “VISTA rules”. However, many of you might still wonder what those little beasts are. First of all, let’s start with the name. Unless you dig in Google or in the help section, you will never have guessed that VISTA stands for “Visitor Identification, Segmentation & Transformation Architecture”. Do not get too impressed with this name, it was just an imaginative way of getting a fancy name.


As all digital marketers know, surveys provide invaluable information from visitors. They allow you to know various types of information from the visitors: the website itself, likelihood of buying, preferred products… The outcome of these surveys can be used to modify certain aspects of the experience or target the visitors with specific messages. All marketers would like every single customer to perform a survey and use that information to create a perfect experience for each visitor, but the reality is far from this ideal. Only very few visitors end up accepting the invitation and this usually happens when there is a potential reward.


Now, looking into the standard, we will get into the different sections that conforms recommended data layer. Let’s review each of them in the following posts.


The classical problem of how to make sure that, in hybrid apps, the journey is not broken when transitioning from the native app to the embedded browser, is well known and it has been solved a long time ago. My colleague Carl Sandquist wrote a great post in the official Adobe blog some time ago about how to stitch visitors in hybrid apps. Two years later I still reference it to my customers. I recommend that, before you proceed with the rest of this post, you read it.


This is the first post of a series of posts, in which I am going to describe the W3C data layer. A few months ago, I explained why it was a good idea to have a data layer. In this series, I am going to dive into the details of one particular data layer implementation: the W3C standard. For those of you who do not know what the W3C does, it is the international body that creates the standards that we use everyday on the web: HTML, CSS, Ajax… Although there are other options for data layers, like JSON-LD, I personally prefer the W3C standard; after all, this body has created some of the most important standards in the Internet.


Back in the old days, before SiteCatalyst 15 was released, the limitation in segmentation meant that, usually, you needed multiple report suites. You would usually have a combination of JavaScript and VISTA rules to do that segmentation (in case you are wondering, the S in VISTA stands for Segmentation), sending the data to different report suites. After that, you would also need a rollup to try to get an overall picture.


In my last post, I described a simple solution to track out-of-stock products using Adobe Analytics. As its name implies, this is a rather simple approach: you just get a count of the number of times an out-of-stock product is shown. For many, that might be enough, but there are many different requirements for a one-size-fits-all solution.


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:


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.


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.


Some time ago, I received an urgent call from a customer that claimed that DTM broke their website. They wanted to see me immediately, as that was causing a huge impact in them. Fortunately, the problems only manifested in staging, but they could not move to production. Once I arrived at my client’s office, I immediately realised what had happened: the data analyst had created some data elements using JavaScript he found on the Internet and he just copied and pasted the code. The code worked on his computer, so he went to approve and publish it. The reality was that his code only worked in IE and crashed in other browsers.


When creating both page load rules and event based rules in DTM, you have the option of configuring some conditions to determine when to fire those rules: parts of the URL, cookies, browser properties, JavaScript variables… If you add more than one condition, the AND boolean operator is applied to all conditions. However, in some cases, these out-of-the-box conditions are not enough. Thankfully, DTM offers the custom condition, where you can write pure JavaScript.


A few months ago, I was working with a customer on premise and the manager asked me a tricky question: how to organise the analytics team. That company was undergoing significant changes in the analytics front, as a few key members of this team were leaving. As with most questions in life, there is not a clear and definitive answer to this particular one. However, I can share what I have been seeing in my customers.


After publishing my previous post, where I recommended tracking the s_code version, I realised it could have been enhanced with a new type of version to track. Another version number that is even more useful is the sprint reference or whichever value you use to track each of the releases of the website. This idea came from one of my customers (thanks Glenn), who is under the process of redeveloping the whole website and analytics implementation. If you either have a development team that is continously adding new features to the web or are in profoundly redeveloping the website, you want to know the ROI of this invesment.


One of the suggestions I usually did when I worked with a new client was to track the s_code version. Now that we are moving to DTM, we do not have any more the concept of the s_code, but we have the concept of publishing new rules, which is similar to an s_code version. The idea is to keep a value in a prop, which is changed every time a new s_code is pushed live or a new set of rules is published. My typical suggestion is to add both a date and a version to the string.


23 Feb 2015

Use a tag manager

Back in the old days, the only way to add Web analytics code to a website, was through manual coding. If you were using Adobe Analytics, you would need to add two pieces of code into the website: the s_code and the on-page code. The s_code is a JavaScript file with common code for Adobe Analytics (SiteCatalyst) and the on-page code contains the page-specific data.