Learn the Adobe Analytics implementation before reporting

17 Jul 2016 » Analytics Tips

As I mentioned in my previous post about the differences between intent and success, today I am going to talk about my point of view of what a web analyst needs to know regarding the implementation.

A few years ago, I was talking with an intern in my office. While talking about her tasks in the company, she told me that she had not followed the official Adobe Analytics training and, instead, she had taught herself the tool. That sentence surprised me a lot and I did not know what to say. I have devoted 5 years to Adobe Analytics and there are still some areas in which I could learn more. How could an intern learn in a few days or weeks enough of Adobe Analytics to use it with confidence, without proper training? Over time, I have been thinking a few times about that comment she made.

Adobe Analytics UI

The first thing I realised was that what she had actually done was to teach herself the Adobe Analytics UI. However, as many of you know, learning how to navigate through the UI does not equate to knowing Adobe Analytics. What is even worse is that she did not even know that difference and thought she understood the tool. In a situation like this, you can actually create reports that look like they make sense but, in reality, are totally wrong.

Let me put an example. Imagine you get a request to analyse what internal search keywords drive more revenue. You could pull a report like the following:

Apparently, the report fulfils the request: list of keywords and their associated revenue. I hope that some, if not most, of you have already spotted the problem with this report. Unless the search term variable is a merchandising eVar, this report is totally useless: it shows the persistent value of the eVar upon purchase. These values even could come from searches for products, which were not later added to the basket. As a consequence, even if the report seems to answer the initial question, it answers a completely different question.

There are a few things that I would ask to anyone performing such report to check how well she understands what she is doing:

Is the internal keyword a merchandising eVar?
What is the expiration of the search keyword eVar?
What does the “None” value mean?

What I want to show with this example is that in Adobe Analytics, you need to understand what the underlying data is really telling you and how the data is actually processed. You can navigate through the UI and you can use your imagination to try to understand what the data means, but does not mean that the reports you pull are right.

Data Quality

A few weeks ago I started an Adobe Audience Manager project for a client. While reviewing the SDR to see what useful traits I could create, the client pointed out that he was not confident with the data in some eVars. The implementation had been done long time ago, before he started working for the company. He was suspicious that some part of the implementation was not correct. Similarly to the example above, how can produce reports based on low quality data? What is even worse, what if you are not even aware of the quality of the data?

Again, following the story from the beginning, if you just know the UI and believe that you know the tool without caring about the data, your reports could potentially be skewed.