Sometimes, seeing how data changes over time can inform you about trends in your data. One way to do this is to use time-lapse. Who hasn’t been mesmerized by a cool video like this:

Credit: RankingTheWorld – https://www.youtube.com/watch?v=8WVoJ6JNLO8

Wouldn’t it be cool if you could do something similar with Adobe Analytics data? Imagine seeing something like the above time-lapse for your products, product categories, campaign channels! That would be amazing! Unfortunately, I doubt this functionality is on the Adobe Analytics roadmap, but in this post, I am going to show you how you can partially create this using Analysis Workspace and add time-lapse to your analytics presentations.

Step 1 – Isolate Data

To illustrate this concept, let’s start with a simple example. Imagine that you have a site that uses some advanced browser features of Google Chrome. It is important for you to understand which version of Chrome your website visitors are using and how quickly they move from one version to the next. You can easily build a freeform table in Analysis Workspace that isolates visits from a bunch of Google Chrome versions like this:

Here you can see that the table goes back a few years and views Visits by various Chrome versions using a cross-tab with values from the Browser dimension.

Step 2 – Add a Chart Visualization

The next step is to add a chart visualization. I have found that there are only three types of visualizations that work for time-lapse: horizontal bar, treemap and donut. I will illustrate all of these, but to start, simply add a horizontal bar visualization and link it to the table created above:

When you first add this chart visualization, it may look a bit strange since it has so much data, but don’t worry, we will fix it in a minute. Once you add it, be sure to use the gear icon to customize it so it has enough rows to encompass the number of items you have added to your table (I normally choose the maximum of 25):

Step 3 – Create Time-Lapse

The final step is to create the time-lapse. To do this, you have to have some sort of software that will allow you to record. I use a Mac product called GIF Brewery 3, but you can use Snagit, Goto Meeting, Zoom, etc… Once you have selected how you want to record the time-lapse, you have to learn the trick in Analysis Workspace that allows you to cycle through your data by week. The trick is to click on the cell directly to the right of the first time period (week of July 2, 2017 in my example) and then use your left arrow to move one cell to the left. This will allow you to select the entire first row as illustrated here:

Once you have the entire row selected, you can use the down arrow to scroll down one row at a time. Therefore, if you start recording, select the cell to the right of the first time period, select the row and then continue pressing the down arrow, you can stop the recording when you get to the end. Then you just have to clean it up (I cut off a bit at the beginning and end) and save it as a video file. Using GIF Brewery 3, I can turn these recordings into animated GIFs which are easy to embed into Powerpoint, Keynote or Google Slides.

Here is what the time-lapse for the Chrome browser scenario looks like when it is completed:

Another visualization type I mentioned was the treemap. The process is exactly the same, you simply link the treemap to your table and record the same way to produce something like this:

Venn Visualization

As mentioned above, I have found that time-lapse works best with horizontal bar, treemap and donut visualizations. One other one that is cool is the Venn visualization, but this one has to be handled a bit differently than the previous examples. The following are the steps to do a time-lapse with the Venn visualization.

First, choose the segments and metric you want to add to the Venn visualization. as an example, I am going to look at what portion of all Demystified visits view one of my blog posts and also how many people have viewed the page about the Adobe Analytics Expert Council (AAEC). I start this by adding segments to the Venn visualization:

Next, I am going to expose the data table that is populating the Venn visualization:

Then I use a time dimension to breakdown the table. In this case, I will use Week:

From here, you can follow the same steps to record weekly time-lapse to produce this:

Sample Use Cases

This concept can be applied to many other data points found in Adobe Analytics. For example, I recently conducted a webinar with the Decibel, an experience analytics provider, in which we integrated Decibel experience data into Adobe Analytics to view how many visitors were having good and bad website experiences. We were then able to view experience over time using time-lapse. In the following clip, I have highlighted in the time-lapse when key events took place on the website:

If you want to memorialize the time when your customers officially started ordering more products from their mobile phone than the desktop, you can run this device type time-lapse:

Another use case might be blog readership if you are a B2B company. Often times, blogs are used to educate prospects and drive lead generation. Here is an example in which a company wanted to view how a series of blogs were performing over time. Once again, you simply create a table of the various blogs (in this case I used segments since each blog type had several contributors):

In this case, I will use the donut chart I mentioned earlier (though it is dangerously close to a pie chart, which I have been told is officially uncool!):

Here is the same data in the typical horizontal bar chart:

As a bonus tip, if you want to see a cumulative view of your data in a time-lapse, all you need to do is follow the same process, but with a different metric. You can use the Cumulative formula in the calculated metric builder to sum all previous weeks as you go and then do a time-lapse of the sum. In this blog example, here is the new calculated metric that you would build:

Once you add this to your table, it will look like this:

Then you just follow the same steps to record your time-lapse:

Final Thoughts

These are just a few examples of how this concept can be applied. In your case, you might want to view a time-lapse of your top ten pages, campaign codes, etc. It is really up to you to decide how you want to use it. I have heard rumors that Analysis Workspace will soon allow you to add images to projects, so it would be cool if you could add animated GIFs or videos like this right into your project!

Other things to note. When you use the treemap and donut visualizations, Analysis Workspace may switch the placements and colors when one number increases over the other, so watch out for that. Another general “gotcha” I have found with this approach is that you have to pre-select the items you want in your time-lapse. It would be cool if there were a way to have the Adobe Analytics time-lapses be like the first market cap one shown in which new values can appear and disappear based upon data changes, but I have not yet found a way to do that. If you can find a way, let me know!

I will be traveling to London in early February, so I am going to try and throw together an Adobe Analytics “Top Gun” class whilst I am there (Feb 5th). As a special bonus, for the first time ever, I am also going to include some of my brand new class “Managing Adobe Analytics Like A Pro!” in the same training!  I promise it will be a packed day! This will likely be the only class I do in Europe this year, so if you have been wanting to attend this class, I suggest you register. Thanks!

Here is the registration link:

https://www.eventbrite.com/e/analytics-demystified-adobe-analytics-top-gun-training-london-2019-tickets-53403058987

Here is some feedback from class attendees:

Dear Adobe,

For Christmas this year I would like a product container in the segment builder. It is something I’ve wanted for years and if you saw my post on Product Segmentation Gotchas you’ll realize that there are some ways that people may inevitably get bad data when using product-level dimensions with any of the existing containers. Because there can be multiple products per hit, segmentation on product attributes can be tough. Really, any bad data is due to a misuse of how the segment builder currently works. However, if we were to add additional functionality to the segment builder we can expand the uses of the builder. A product container is also interesting because it isn’t necessarily smaller in scope compared to a visit or hit. One product could span all of those. So because of all this I would love a new container for Christmas.

Don’t get me wrong, I love the segment builder. This would be another one of those little features that adds to the overall amazingness of the product. Or, since containers are a pretty fundamental aspect of the segment builder, maybe it’s much more than just a “little feature”? Hmmm, the more I think about in those terms the more I think it would be a feature of epic proportions 🙂

How would this work?

Good question! I have some ideas around that. I imagine a product container working similar to a product line item in a tabular report. In a table visualization everything on that row is limited to what is associated with that product. Usually we just use product-specific metrics in those types of reports, but if you were to pull in a non-product-specific metric it would pull in whatever was the effective values for the hit that the product was on at that time. So really it wouldn’t be too different from how data is generated now. The big change is making it accessible in the segment builder.

Here’s an example of what I mean. Let’s use the first scenario from the  Product Segmentation Gotchas post. We are interested in segmenting for visits that placed an order where product A had a “2_for_1” discount applied. Let’s say that we have a report suite that has only two orders like so:

Order #101 (the one we want)

Notice that product A has the discount and this visit came from a PPC channel.

Order #102 (the one we don’t want)

Notice that product B has the discount now and this visit came from an Email channel.

Here is the resulting report if we were to not use any segments. You’ll notice that everything lines up great in this view and we know exactly which discount applied to which product.

The Bad

Now let’s get on to our question and try to segment for the visits that had the 2_for_1 discount applied to product A. In the last post I already mentioned that this segment is no good:

If you were to use this to get some high-level summary data it would look like this:

Notice that it doesn’t look any different from the All Visits segment. The reason for this is that we just have two orders in our dataset and each of them have product A and a 2_for_1 discount. To answer our question we really need a way to associate the discount specifically with product A.

The Correct Theoretical Segment

Using my theoretical product container, the correct segment would look something like the image below. Here I’m using a visit-level outer container but my inner container is set to the product level (along with a new cute icon, of course). Keep in mind this is fake!

The results of this would be just what we wanted which is “visits where product A had a ‘2_for_1’ discount applied”.

This visit had an order of multiple products so the segment would include more than just product A in the final result. The inner product container would qualify the product and the outer visit container would then qualify the entire visit. This results in the whole order showing up in our list. We are able to answer our question and avoid including the extra order that was unintentionally included with the first segment. 

Even More Specific

Let’s refine this and say that we wanted just the sales from product A in our segment. The correct segment would look like this with my theoretical product scope in the outer container.

And the results would be trimmed down to just the product-specific dimensions and metrics like so:

Notice that this gives us a single row that is just like the line item in the table report! Now you can see that we have great flexibility to get to just what we want when it comes to product-level dimensions.

Summary

Wow, that was amazing! Fake data and mockups are so cooperative! This may be a little boring for just this simple example but when thousands of products are involved the table would be a mess and I’d be pretty grateful for this feature. There are a bunch of other ways that this could be useful in building segments with this feature at different levels like wrapping visit or visitor containers or working with non-product-specific metrics but this post is already well past my attention span limits. Hopefully this is enough to explain the idea. I know that this Christmas is getting pretty close so I’d be glad to accept it as a belated gift on MLK Day instead. Thanks Adobe!

Sincerely,

Kevin Willeitner

PS, for others that might be reading this, if you’d like this feature to be implemented please vote for it here. After some searching I also found that several people have asked for related capability so vote for theirs as well! Those are linked to in the idea post.

If you have used Adobe Analytics segmentation you are likely very familiar with the hierarchy of container. These containers illustrate the scope of the criteria wrapped in the container and are available at the visitor, visit, and hit levels. These containers help you control exactly what happens on each of those levels and your analysis can be heavily impacted by which of these you use. These are extremely useful and handle most use cases.

When doing really detailed analysis related to products, however, the available containers can get confused. This is because there can be multiple products per visitor, visit, or hit. Scenarios like a product list page and checkout pages, when analyzed at a product level, can be especially problematic. Obviously this has a disproportionate impact on retailers but other industries may also be impacted if they use the products variable to facilitate fancy implementations. Any implementation that has a need to collect attributes that have a many-to-many relationship may need to leverage the products variable.

Following are a few cases illustrating where this might happen so be on the lookout.

Product Attributes at Time of Order

Let’s say you want to segment for visits that purchased a product with a discount. Or, rather than a discount, it could be a flag indicating the product should be gift wrapped. It could even be some other attribute that you want passed “per product” on the thank you page. Using the scenario of a discount, if a product-level discount (e.g. 2 for 1 deal) is involved and that same discount can apply to other products, you won’t quite be able to get the right association between the two dimension. You may be tempted to create a segment like this:

However, this segment can disappoint you. Imagine that your order includes two products (product A and product B) and product B is the one that has the “2_for_1” discount applied to it (through a product syntax merchandising eVar). In that case the visit will qualify for our segment because our criteria will be applied at the hit level (note the red arrow). This setting will result in the segment looking for a hit with product A and a code of “2_for_1” but it doesn’t care beyond that. This segment will include the correct results (the right discount associated with the right product), but it will also include undesired results such as right discount associated with the wrong product. This is caused when the correct product just so happened to be purchased at the same time. In the end you are left with a segment you shouldn’t use.

This example is centered around differing per-product attributes at the time of an order but really the event doesn’t matter. This could apply at any time you have a bunch of products collected at once that may each have different values. If multiple products are involved and your implementation is using merchandising evars with product syntax (correctly) then this will be a consideration for you.

Differentiating Test Products

I once had a super-large retailer run a test on a narrow set of a few thousand products. They wanted to know what kind of impact different combinations of alternate images available on the product detail page would have on conversion. This included still images, lifestyle images, 360 views, videos, etc. However, not all products had comparable alternate images available. Because of this they ran the test only across products that did have comparable imagery assets. This resulted in the need to segment very carefully at a product level. Inevitably they came to me with the question “how much revenue was generated by the products that were in the test?” This is a bit tricky because in A/B tests we normally look at visitor-level data for a certain timeframe. If someone in the test made a purchase and the test products were only a fraction of the overall order then the impact of the test could be washed out. So we had to get specific. Unfortunately, through a segment alone we couldn’t get good summary information.

This is rooted in the same reasons as the first example. If you were to only segment for a visitor in the test then your resulting revenue would include all orders for that visitor while in that test. From there you could try to get more specific and segment for the products you are interested in; however,  the closest you’ll get is order-level revenue containing the right products. You’ll still be missing the product-specific revenue for the right products. At least you would be excluding orders placed by test participants that didn’t have the test products at all…but a less-bad segment is still a bad segment 🙂

Changes to Product Attributes

This example involves the fulfillment method of the product. Another client wanted to see how people changed their fulfillment method (ship to home, ship to store, buy online/pickup in store) and was trying to work around a limited implementation. The implementation was set up to answer “what was the fulfillment method changed to?” but what they didn’t have built in was this new question — “of those that start with ship-to-home products in the cart, how often is that then changed to ship to store?” Also important is that each product in the cart could have different fulfillment methods at any given time.

In this case we can segment for visits that start with some product with a ship-to-home method. We can even segment for those that change the fulfillment method. We get stuck, though, when trying to associate the two events together by a specific product. You’re left without historical data and resorting to implementation enhancements.

Other Options

The main point of this post is to emphasize where segmenting on products could go wrong. There are ways to work around the limitations above, though. Here are a few options to consider:

• In the case of the product test, we could apply a classification to identify which products are in the test. Then you would just have to use a table visualization, add a dimension for your test groups, and break that down by this new classification. This will show you the split of revenue within the test group.
• Turn to the Adobe Data Feed and do some custom crunching of the numbers in your data warehouse.
• Enhance your implementation. In the case of the first scenario where persistence isn’t needed you could get away with appending the product to the attribute to provide the uniqueness you need. That may, though, give you some issue with the number of permutations that could create. Depending on how into this you want to get, you could even try some really crazy/fun stuff like rewriting the visitor ID to include the product. This results in some really advanced product-level segmentation. No historical data available, though.
• Limit your dataset to users that just interacted with or ordered one product to avoid confusion with other products. Blech! Not recommended.

Common Theme

You’ll notice in all of these examples the common thread is where we are leveraging product-specific attributes (merchandising eVars) and trying to tease out specific products from other products based on those attributes. Given that none of the containers perfectly match the same scope of a product you may run into something like the problems described above. Have you come across other segmenting-at-a-product-level problems? If so please comment below!

While training is only a small portion of what I do in my consulting business, it is something I really enjoy. Training allows you to meet with many people and companies and help them truly understand the concepts involved in a product like Adobe Analytics. Blog posts are great for small snippets of information, but training people face-to-face allows you to go so much deeper.

For years, I have provided general Adobe Analytics end-user training for corporate clients and, more recently, Analysis Workspace training. But my most popular class has always been my Adobe Analytics “Top Gun” Class, in which I delve deep into the Adobe Analytics product and teach people how to really get the most out of their investment in Adobe Analytics. I have done this class for many clients privately and also offer public versions of the class periodically (click here to have me come to your city!).

In 2019, I am launching a brand new class related to Adobe Analytics! I call this class:

Having worked with Adobe Analytics for fifteen years now (yeesh!), I have learned a lot about how to run a successful analytics program, especially those using Adobe Analytics. Therefore, I have attempted to put all of my knowledge and best practices into this new class. Some of the things I cover in the class include:

• How to run an analytics implementation based upon business requirements
• What does a fully functioning Solution Design Reference look like and how can you use it to track implementation status
• Why data quality is so important and what steps can you take to minimize data quality issues
• What are best practices in organizing/managing your Adobe Analytics implementation (naming conventions, admin settings, etc…)
• What are the best ways to train users on Adobe Analytics
• What team structures are available for an analytics team which is best for your organization
• How to create the right perception of your analytics team within the organization
• How to get executives to “buy-in” to your analytics program

These are just some of the topics covered in this class. About 70% of the class applies to those using any analytics tool (i.e. Adobe, GA, etc…), but there are definitely key portions that are geared towards Adobe Analytics users.

I decided to create this class based on feedback from people attending my “Top Gun” Class over the years. Many of the attendees were excited about knowing more about the Adobe Analytics product, but they expressed concerns about running the overall analytics function at their company. I have always done my best to share ideas, lessons, and anecdotes in my conference talks and training classes, but in this new class, I have really formalized my thinking in hopes that class participants can learn from what I have seen work over the past two decades.

ACCELERATE

This new class will be making its debut at the Analytics Demystified ACCELERATE conference this January in California. You can come to this class and others at our two-day training/conference event, all for under $1,000! In addition to this class and others, you also have access to our full day conference with great speakers from Adobe, Google, Nordstrom, Twitch and many others. I assure you that this two-day conference is the best bang for the buck you can get in our industry! Unfortunately, space is limited, so I encourage you to register as soon as possible.

Recently, while working on a client implementation, I came across something I hadn’t seen before in Adobe Analytics. For me, that is quite unusual! While in the administration console, I saw a new option under the success event visibility settings called “Builders” as shown here:

A quick check in the documentation showed this:

Therefore, the new Builders setting for success events is meant for cases in which you want to capture data and use it in components (i.e. Calculated Metrics, Segments, etc.), but not necessarily expose it in the interface. While I am not convinced that this functionality is all that useful, in this post, I will share some uses that I thought of related to the feature.

Using Builders in Calculated Metrics

One example of how you could use the Builders visibility is when you want to create a calculated metric, but don’t necessarily care about one of the elements contained in the calculated metric formula as a standalone metric. To illustrate this, I will reference an old blog post I wrote about calculating the average internal search position clicked. In that post, I suggested that you capture the search result position clicked in a numeric success event, so that it could be divided by the number of search result clicks to calculate the average search position. For example, if a user conducts two searches and clicks on the 4th and 6th results respectively, you would pass the values of 4 and 6 to the numeric success event and divide it by the number of search result clicks (6+4/2=5.0). Once you do that, you will see a report that looks like this:

In this situation, the Search Position column is being used to calculate the Average Search Position, but by itself, the Search Position metric is pretty useless. There aren’t many cases in which someone would want to view the Search Position metric by itself. It is simply a means to an end. Therefore, this may be a situation in which you, as the Adobe Analytics administrator, may choose to use the Builders functionality to hide this metric from the reporting interface and Analysis Workspace, only exposing it when it comes to building calculated metrics and segments. This allows you to remove a bit of the clutter from your implementation and can be done by simply checking the box in the visibility column and using the Builders option as shown here:

As I stated earlier, this feature will not solve world peace, but I guess it can be handy in situations like this.

Using Builders in Segments

In addition to using “Builders” Success Events in calculated metrics, you can also use them when building segments. Continuing the preceding internal search position example, there may be cases in which you want to use the Search Position metric in a segment like the one shown here:

Make Builder Metrics Selectively Visible

One other thing to note with Builders has to do with calculated metrics. If you choose to hide an element from the interface, but one of your advanced users wants to view it, keep in mind that they still can by leveraging calculated metrics. Since the element set to Builders visibility is available in the calculated metrics builder, there is nothing stopping you or your users from creating a calculated metric that is equal to the hidden success event. They can do this by simply dragging over the metric and saving it as a new calculated metric as shown here:

This will be the same as having the success event visible, but by using a calculated metric, your users can determine who they want to share the resulting metric with at the organization.

I love SAINT Classifications! I evangelize the use of SAINT Classifications anytime I can, especially in my training classes. Too often Adobe customers fail to take full advantage of the power of SAINT Classifications. Adding meta-data to your Adobe Analytics implementation greatly expands the types of analysis you can perform and what data you can use for segmentation. Whether the meta-data is related to campaigns, products or customers, enriching your data via SAINT is really powerful.

However, there are some cases in which, for a variety of reasons, you may choose to put a lot of data into an eVar or sProp with the intention of splitting the data out later using SAINT Classifications. Here are some examples:

• Companies concatenate a lot of “ugly” campaign data into the Tracking Code eVar which is later split out via SAINT
• Companies store indecipherable data (like an ID) in an eVar or sProp which only makes sense when you look at the SAINT Classifications
• Companies have unplanned bad data in the “root” variable that they fix using SANIT Classifications
• Companies are low on variables, so they concatenate disparate data points into an eVar or sProp to conserve variables

One example of the latter I encountered with a client is shown here:

In this example, the client was low on eVars and instead of wasting many eVars, we concatenated the values and then split out the data using SAINT like this:

Using this method, the company was able to get all of the reports they wanted, but only had to use one eVar. The downside was that users could open up the actual eVar28 report in Adobe Analytics and see the ugly values shown above (yuck!). Because of this, a few years ago I suggested an idea to Adobe that they let users hide an eVar/sProp in the interface, but continue letting users view the SAINT Classifications of the hidden eVar/sProp. Unfortunately, since SAINT Classification reports were always tied directly to the “root” eVar/sProp from which they are based, this wasn’t possible. However, with the advent of Virtual Report Suites, I am pleased to announce that you now can curate your report suite to provide access to SAINT Classification meta-data reports, while at the same time not providing access to the main variable they are based upon. The following will walk you through how to do this.

Curate Your Classifications

The first step is to create a new Virtual Report Suite off of another report suite. At the last step of the process, you will see the option to curate/customize what implementation elements will go over to the new Virtual Report Suite. In this case, I am going to copy over everything except the Tracking Code and Blog Post Title (eVar5) elements as shown here:

As you can see, I am hiding Blog Post Title [v5], but users still have access to the four SAINT Classifications of eVar5. Once the Virtual Report Suite is saved and active, if you go into Analysis Workspace and look at the dimensions in the left nav, you will see the meta-data reports for eVar5, but not the original eVar5 report:

If you drag over one of the SAINT Classification reports, it works just like you would expect it to:

If you try to break this report down by the “root” variable it is based upon, you can’t because it isn’t there:

Therefore, you have successfully hidden the “root” report, but still provided access to the meta-data reports. Similarly, you can view one of the Campaign Tracking Code SAINT Classification reports (like Source shown below), but not have access to the “root” Tracking Code report:

Summary

If you ever have situations in which you want to hide an eVar/sProp that is the “root” of a SAINT Classification, this technique can prove useful. Many of the reasons you might want to do this are shown in the beginning of this post. In addition, you can combine Virtual Report Suite customization and security settings to show different SAINT Classification elements to different people. For example, you might have a few Classifications that are useful to an executive and others that are meant for more junior analysts. There are lots of interesting use cases where you can apply this cool trick!

When you are doing analysis for an organization that spans multiple time zones, things can get tricky. Each Adobe Analytics report suite is tied to one specific time zone (which makes sense), but this can lead to frustration for your international counterparts. For example, let’s say that Analytics Demystified went international and had resources in the United Kingdom. If they wanted to see when visitors located in the UK viewed blog posts (assume that is one of our KPI’s), here is what they would see in Adobe Analytics:

This report shows a Blog Post Views success event segmented for people located in the UK. While I wish our content was so popular that people were reading blogs from midnight until the early morning hours, I am not sure that is really the case! Obviously, this data is skewed because the time zone of our report suite is on US Pacific time. Therefore, analysts in the UK would have to mentally shift everything eight hours on the fly, which is not ideal and can cause headaches.

So how do you solve this? How do you let the people in the US see data in Pacific time and those in the UK see data in their time zone? Way back in 2011, I wrote a post about shifting time zones using custom time parting variables and SAINT Classifications. This was a major hack and one that I wouldn’t really recommend unless you were desperate (but that was 2011!). Nowadays, using the power of Virtual Report Suites, there is a more elegant solution to the time zone issue (thanks to Trevor Paulsen from Adobe Product Management for the reminder).

Time-Zone Virtual Report Suites

Here are step-by-step instructions on how to solve the time zone paradox. First, you will create a new Virtual Report Suite and assign it a new name and a new time zone:

You can choose whether this Virtual Report Suite has any segments applied and/or contains all of your data or just a subset of your data in the subsequent settings screens.

When you are done, you will have a brand new Virtual Report Suite that has all data shifted to the UK time zone:

Now you are able to view all reports in the UK time zone.  To illustrate this, let’s look at the report above in the regular report suite side by side with the same report in the new Virtual Report Suite:

As you can see, both of these reports are for the same date and have the same UK geo-segmentation segment applied. However, as you can see, the data has been shifted eight hours. For example, Blog Post Views that previously looked like they were viewed by UK residents at 2:00am, now show that they were viewed at 10:00am UK time. This can also be seen by looking at the table view and lining up the rows:

This provides a much more realistic view of the data for your international folks. In theory, you could have a different Virtual Report Suite for all of your major time zones.

So that is all you need to do to show data in different time zones. Just a handy trick if you have a lot of international users.

As loyal blog readers will know, I am a big fan of identifying business requirements for Adobe Analytics implementations. I think that working with your stakeholders before your implementation (or re-implementation!) to understand what types of questions they want to answer helps you focus your efforts on the most important items and can reduce unnecessary implementation. However, I am also a realist and acknowledge that there will always be times where you miss stuff. In those cases, you can set a new metric after the fact for the thing you missed, but what about the data from the last few years? It would be ideal if you could create a metric today that would be retroactive such that it shows you data from the past.

This ability to set a metric “after the fact” is very common in other areas of analytics and there are even vendors like Heap, SnowPlow and Mixpanel that allow you to capture virtually everything and then set up metrics/goals afterwards. These tools capture raw data, let you model it as you see fit and change your mind on definitions whenever you want. For example, in Heap you can collect data and then one day decide that something you have been collecting for years should be a KPI and assign it a name. This provides a ton of flexibility. I believe that tools like Heap and SnowPlow are quite a bit different than Adobe Analytics and that each tool has its strengths, but for those who have made a long-term investment in Adobe Analytics, I wanted to share how you can have some of the Heap-like functionality in Adobe Analytics in case you ever need to assign metrics after the fact. This by no means is meant to discount the cool stuff that Heap or SnowpPlow are doing, but rather, just showing how this one cool feature of theirs can be mimicked in Adobe Analytics if needed.

After The Fact Metrics

To illustrate this concept, let’s imagine that I completely forgot to set a success event in Adobe Analytics when visitors hit my main consulting service page. I’d like to have a success event called “Adobe Analytics Service Page Views” when visitors hit this page, but as you can see here, I do not:

To do this, you simply create a new calculated metric that has the following definition:

This metric allows you to see the count of Adobe Analytics Service Page Views based upon the Page Name (or you could use URL) that is associated with that event and can then be used in any Adobe Analytics report:

So that is how simple it is to retroactively create a metric in Adobe Analytics. Obviously, this becomes more difficult if the metric you want is based on actions beyond just a page loading, but if you are tracking those actions in other variables (or ClickMap), you can follow the same process to create a calculated metric off of those actions.

Transitioning To A New Success Event

But what if you want to use the new success event going forward, but also want all of the historical data? This can be done as well with the following steps:

The first step would be to set the new success event going forward via manual tagging, a processing rule or via tag management. To do this, assign the new success event in the Admin Console:

The next step is to pick a date in which you will start setting this new success event and then start populating it.  If you want to have it be a clean break, I recommend doing this one day at midnight.

Next, you want to add the new success event to the preceding calculated metric so that you can have both the historical count and the count going forward:

However, this formula will double-count the event for all dates in which the new success event 12 has been set. Therefore, the last step is to apply two date-based segments to each part of the formula. The first date range contains the historical dates before the new success event was set. The second date range contains the dates after the new success event has been set (you can make the end date some date way into the future). Once both of these segments have been created, you can add them to the corresponding part of the formula so it looks like this:

This combined metric will use the page name for the old timeframe and the new success event for the new timeframe. Eventually, if desired, you can transition to using only the success event instead of this calculated metric when you have enough data in the success event alone.

Summary

To wrap up, this post shows a way that you can create metrics for items that you may have missed in your initial implementation and provides a way to fix your original omission and combine the old and the new. As I stated, this functionality isn’t as robust as what you might get from a Heap, SnowPlow or Mixpanel, but it can be a way to help if you need it in a pinch.

If you are a veteran Adobe Analytics (or Omniture SiteCatalyst) user, for years the term attribution was defined by whether an eVar was First Touch (Original Value) or Last Touch (Most Recent). eVar attribution was setup in the administration console and each eVar had a setting (and don’t bring up Linear because that is a waste!). If you wanted to see both First and Last Touch campaign code performance, you needed to make two separate eVars that each had different attribution settings. If you wanted to see “Middle Touch” attribution in Adobe Analytics, you were pretty much out of luck unless you used a “hack” JavaScript plug-in called Cross Visit Participation (thanks to Lamont C.).

However, this has changed in recent releases of the Adobe Analytics product. Now you can apply a bunch of pre-set attribution models including J Curve, U Curve, Time Decay, etc… and you can also create your own custom attribution model that assigns some credit to first, some to last and the rest divided among the middle values. These different attribution models can be built into Calculated Metrics or applied on the fly in metric columns in Analysis Workspace (not available for all Adobe Analytics packages). This stuff is really cool! To learn more about this, check out this video by Trevor Paulsen from Adobe.

However, this post is not about the new Adobe Analytics attribution models. Instead, I wanted to take a step back and look at the bigger picture of attribution in Adobe Analytics. This is because I feel that the recently added Attribution IQ functionality is fundamentally changing how I have always thought about where and how Adobe performs attribution. Let me explain. As I mentioned above, for the past decade or more, Adobe Analytics attribution has been tied to eVars. sProps didn’t really even have attribution since their values weren’t persistent and generally didn’t work with Success Events. But what has changed in the past year, is that attribution has shifted to metrics instead of eVars. Today, instead of having a First Touch and Last Touch campaign code eVar, you can have one eVar (or sProp – more on that later) that captures campaign codes and then choose the attribution (First or Last Touch) in whatever metric you care about. For example, if you want to see First Touch Orders vs. Last Touch Orders, instead of breaking down two eVars by each other like this…

…you can use one eVar and create two different Order metric columns with different attribution models to see the differences:

In fact, you could have metric columns for all available attribution models (and even create Calculated Metrics to divide them by each other) as shown here:

In addition, the new attribution models work with sProps as well. Even though sProp values don’t persist, you can use them with Success Events in Analysis Workspace and then apply attribution models to those metrics. This means that the difference between eVars and sProps is narrowing due to the new attribution model functionality.

To prove this, here is an Analysis Workspace table based upon an eVar…

…and here is the same table based upon an sProp:

What Does This Mean?

So, what does this mean for you? I think this changes a few things in significant ways:

1. Different Paradigm for Attribution – You are going to have to help your Adobe Analytics users understand that attribution (First, Last Touch) is no longer something that is part of the implementation, but rather, something that they are empowered to create. I recommend that you educate your users on how to apply attribution models to metrics and what each model means. You will want to avoid “analysis paralysis” for your users, so you may want to suggest which model you think makes the most sense for each data dimension.
2. Different Approach to Implementation – The shift in attribution from eVars to metrics means that  you no longer have to use multiple eVars to see different attribution models. Also, the fact that you can see success event attribution for sProps means that you can also use sProps if you are using Analysis Workspace.
3. sProps Are Not Dead! – While I have been on record saying that outside of Pathing, sProps are just a relic of old Omniture days, but as stated above, the new attribution modeling feature is helping make them useful again! sProps can now be used almost like eVars, which gives you more variables. Plus, they have Pathing that is better than eVars in Flow reports (until the instances bug is fixed!). Eventually, I assume all eVars and sProps will merge and simply be “dimensions,” but for now, you just got about 50 more variables!
4. Create Popular Metric/Attribution Combinations – I suggest that you identify your most important metrics and create different versions of them for the relevant attribution models and share those out so your users can easily access them.  You may want to use tags as I suggested in this post.

One of my “soapbox” issues is that too few organizations focus on analytics business requirements and KPI definition. This is why I spend so much time working with clients to help them identify their analytics business requirements. I have found that having requirements enables you to make sure that your analytics solution/implementation are aligned with the true needs of the organization. For this reason, I don’t take on consulting engagements unless the customer agrees to spend time defining their business requirements.

A while back, I had the pleasure of working with Ingersoll Rand to help them transform their legacy Adobe Analytics implementation to a more business requirements driven approach. The following is a quick case study that shares more information on the process and the results:

The Demystified Advantage – Ingersoll Rand – September 2018

Recently, the Adobe Analytics team added a new Analysis Workspace feature called “Drop-downs.” It has always been possible to add Adobe Analytics components like segments, metrics, dimensions and date ranges to the drop zone of Analysis Workspace projects. Adding these components allowed you to create “Hit” segments based upon what was brought over or, in the case of a segment, segment your data accordingly. Now, with the addition of drop-downs, this has been enhanced to allow you to add a set of individual elements to the filter area and then use a drop-down feature to selectively filter data. This functionality is akin to the Microsoft Excel Filter feature that lets you filter rows of a table. In this post, I will share some of the cool things you can do with this new functionality.

Filter on Dimension Values

One easy way to take advantage of this new feature is to drag over a few of your dimension values and see what it is like to filter on each. To do this, you simply find a dimension you care about in the left navigation and then click the right chevron to see its values like this:

Next you can use the control/shift key to pick the values you want (up to 50) and drag them over to the filter bar. Before you drop them, you must hold down the shift key to make it a drop-down:

When this is done, you can see your items in the drop-down like this:

Now you can select any item and all of your Workspace visualizations will be filtered. For example, if I select my name in the blog post author dimension, I will see only blog posts I have authored:

Of course, you can add as many dimensions as you’d like, such as Visit Number and/or Country. For example, if I wanted to narrow my data down to my blog posts viewed in the United States and the first visit, I might choose the following filters:

This approach is likely easier for your end-users to understand than building complex segments.

Other Filters

In addition to dimensions, you can create drop-downs for things like Metrics, Time Ranges and Segments. If you want to narrow your data down to cases in which a specific Metric was present, you can drag over the Metrics you care about and filter like this:

Similarly, you can filter on Data Ranges that you have created in your implementation (note that this will override whatever dates you have selected in the calendar portion of the project):

One of the coolest parts of this new feature is that you can also filter on Segments:

This means that instead of having multiple copies of the same Analysis Workspace project for different segments, you can consolidate down to one version and simply use the Segment drop-down to see the data you care about. This is similar to how you might use the report suite drop-down in the old Reports & Analytics interface. This should also help improve the performance times of your Analysis Workspace projects.

Example Use – Solution Design Project

Over the last few weeks, I have been posting about a concept of adding your business requirements and solution design to an Analysis Workspace project. In the final post of the series (I suggest reading all parts in order), I talked about how you could apply segmentation to the solution design project to see different completion percentages based upon attributes like status or priority (shown here):

Around this time, after reading my blog post, one of my old Omniture cohorts tweeted this teaser message:

At the time, I didn’t know what Brandon was referring to, but as usual, he was absolutely correct that the new drop-down feature would help with my proposed solution design project. Instead of having to constantly drag over different dimension/value combinations, the new drop-down feature allows any user to select the ways they want to filter the solution design project and, once they apply the filters, the overall project percentage completion rate (and all other elements) will dynamically change. Let’s see how this works through an example:

As shown in my previous post, I have a project that is 44.44% complete as shown above. Now I have added a few dimension filters to the project like this:

Now, if I choose to filter by “High” priority items, the percentage changes to 66.67% and only high priority requirements are shown:

Another cool side benefit of this is that the variable panel of the project now only shows variables that are associated with high priority requirements:

If I want to see how I am doing for all of Kevin’s high priority business requirements, I can simply select both high priority and then select Kevin in the requirement owner filter:

This is just a fun way to see how you can apply this new functionality to old Analysis Workspace projects into which you have invested time.

Future Wishlist Items

While this new feature is super-cool, I have already come up with a list of improvements that I’d like to eventually see:

• Ability to filter on multiple items in the list instead of just one item at a time
• Ability to clear the entire filter without having to remove each item individually
• Ability to click a button to turn currently selected items (across all filters) into a new Adobe Analytics Segment
• Ability to have drop-down list values generated dynamically based upon a search criteria (using the same functionality available when filtering values in a freeform table shown below)

Last week and this week, I shared some thoughts on how to quantify content velocity in Adobe Analytics. As part of that post, I showed how to assign a publish date to each piece of content via a SAINT Classification like this:

Once you have this data in Adobe Analytics, you can download your SAINT file and clean it up a bit to see your content by date published in a table like this:

The last three columns split out the Year, the Month and then I added a “1” for each post. Adding these three columns allows you to then build a pivot table to see how often content is published by both Month and Year:

Then you can chart these like you would any other pivot table. Here are blog posts by month:

Here are blog posts by year:

As long as you are going to go through the work of documenting the publish date of your key content, you can use this bonus tip to leverage your SAINT Classifications file to do some cool reporting on your content creation.

Last week, I shared how to quantify content velocity in Adobe Analytics. This involved classifying content with the date it was published and looking at subsequent days to see how fast it is viewed. As part of this exercise, the date published was added via the SAINT classification and dates were grouped by Year and Month & Year. At the same time, it is normal to capture the current Date in an eVar (as I described in this old blog post). This Date eVar can also be classified into Year and Year & Month. The classification file might look like this:

Once you have the Month-Year for both Blog Post Launches and Views, you can use the new cross-tab functionality of Analysis Workspace to do some analysis. To do this, you can create a freeform table and add your main content metric (Blog Post Views in my case) and break it down by the Launch Month-Year:

In this case, I am limiting data to 2018 and showing the percentages only. Next, you can add the Blog Post View Month-Year as cross-tab items by dragging over this dimension from the left navigation:

This will insert five Blog Post View Month-Year values across the top like this:

From here, you can add the missing three months, order them in chronological order and then change column settings like this:

Next, you can change the column percentages so they go by row instead of column, but clicking on the row settings gear icon like this:

After all of this, you will have a cross-tab table that looks like this:

Now you have a cross-tab table that allows you to see how blog posts launched in each month are viewed in subsequent months. In this case, you can see that from January to August, for example, blog posts launched in February had 59% of their views take place in February and the remaining 40% over the next few months.

Of course, the closer you are to the month content was posted, the higher the view percentage will be for the current month and the months that follow. This is due to the fact that over time, more visitors will end up viewing older content. You can see this above by the fact that 100% of content launched in August was viewed in August (duh!). But in September, August will look more like July in the table above when September will steal a percentage of content that was launched in August.

This type of analysis can be used to see how sticky your content is in a way that is similar to the Cohort Analysis visualization. For example, four months after content was launched in March, its view % was 3.5%, whereas, four months after content was released in April, its view % was 5.3%. There are many ways that you can dissect this data and, of course, since this is Analysis Workspace, if you ever want to do a deeper dive on one of the cross-tab table elements, you can simply right-click and build an additional visualization. For example, if I want to see the trend of February content, I can simply right-click on the 59.4% value and add an area visualization like this:

This would produce an additional Analysis Workspace visualization like this:

For a bonus tip related to this concept, click here.

If publishing content is important to your brand, there may be times when you want to quantify how fast users are viewing your content and how long it takes for excitement to wane. This is especially important for news and other media sites that have content as their main product. In my world, I write a lot of blog posts, so I also am curious about which posts people view and how soon they are viewed. In this post, I will share some techniques for measuring this in Adobe Analytics.

Implementation Setup

The first step to tracking content velocity is to assign a launch date to each piece of content, which is normally the publish date. Using my blog as an example, I have created a SAINT Classification of the Blog Post Title eVar and classified each post with the publish date:

Here is what the SAINT File looks like when completed:

The next setup step is to set a date eVar on every website visit. This is as simple as capturing today’s date in an eVar on every hit, which I blogged about back in 2011. Having the current date will allow you to compare the date the post was viewed with the date it was published. Here is an example on my site:

Reporting in Analysis Workspace

Once the setup is complete, you can move onto reporting. First, I’ll show how to report on the data in Analysis Workspace. In Workspace, you can create a panel and add the content item you care about (blog post in my example) and then break it down by the launch date and the view date. I recommend setting the date range to begin with the publish date:

In this example, you can see that the blog post launched on 8/7/18 and that 36% of total blog post views since then occurred on the launch date. You can also see how many views took place on each date thereafter. As you would expect, most of the views took place around the launch date and then slowed down in subsequent days. If you want to see how this compares to another piece of content, you can create a new panel and view the same report for another post (making sure to adjust the date range in the new panel to start with the new post’s launch date):

By viewing two posts side by side, I can start to see how usage varies. The unfortunate part, is that it is difficult to see which date is “Launch Date,” Launch Date +1,” Launch Date +2, ” etc… Therefore, Analysis Workspace, in this situation, is good for seeing some ad-hoc data (no pun intended!), but using Adobe ReportBuilder might actually prove to be a more scalable solution.

Reporting in Adobe ReportBuilder

When you want to do some more advanced formulas, sometimes Adobe ReportBuilder is the best way to go. In this case, I want to create a data block that pulls in all of my blog posts and the date each post was published like this:

Once I have a list of the content I care about (blog posts in this example), I want to pull in how many views of the content occurred each date after the publish date. To do this, I have created a set of reporting parameters like this:

The items in green are manually entered by setting them equal to the blog post name and publish date I am interested in from the preceding data block. In this case, I am setting the Start Date equal to the sixth cell in the second column and the Blog Post equal to the cell to the left of that. Once I have done that I create a data block that looks like this:

This will produce the following table of data:

Now I have a daily report of content views beginning with the publish date. Next, I created a table that references this table that captures the launch date and the subsequent seven days (you can use more days if you want). This is done by referencing the first eight rows in the preceding table and then creating a sum of all other data to create a table that looks like this:

In this table, I have created a dynamic seven-day distribution and then lumped everything else into the last row. Then I have calculated the percentage and added an incremental percentage formula as well. These extra columns allow me to see the following graphs on content velocity:

The cool part about this process, is that it only takes 30 seconds to produce the same reports/graphs for any other piece of content (blog post in my example). All you have to do is alter the items in green and then refresh the data block. Here is the same reporting for a different blog post:

You can see that this post had much more activity early on, whereas the other post started slow and increased later. You could even duplicate each tab in your Excel worksheet so you have one tab for each key content item and then refresh the entire workbook to update the stats for all content at once.

Check out Part 2 of this post here: https://analyticsdemystified.com/featured/quantifying-content-velocity-in-adobe-analytics-part-2/

Last week, I shared how to calculate and incorporate your business requirement completion percentage in Analysis Workspace as part of my series of posts on embedding your business requirements and Solution Design in Analysis Workspace (Part 1, Part 2, Part 3). In this post, I will share a few more aspects of the overall SDR in Workspace solution in case you endeavor to try it out.

Updating Business Requirement Status

Over time, your team will add and complete business requirements. In this solution, adding new business requirements is as simple as uploading a few more rows of data via Data Sources as shown in the “Part 2” blog post. In fact, you can re-use the same Data Sources template and FTP info to do this. When uploading, you have two choices. You can upload only new business requirements or you can re-upload all of your business requirements each time, including the new ones. If you upload only the new ones, you can tie them to the same date you originally used or use the current date. Using the current date allows you to see your requirements grow over time, but you have to be mindful to make sure your project date ranges cover the timeframe for all requirements. What I have done is re-uploaded ALL of my business requirements monthly and changed the Data Sources date to the 1st of each month. Doing this allows me to see how many requirements I had in January, Feb, March, etc., simply by changing the date range of my SDR Analysis Workspace project. The only downside of this approach is that you have to be careful not to include multiple months or you will see the same business requirements multiple times.

Once you have all of your requirements in Adobe Analytics and your Analysis Workspace project, you need to update which requirements are complete and which are not. As business requirements are completed, you will update your business requirement SAINT file to change the completion status of business requirements. For example, let’s say that you re-upload the requirements SAINT file and change two requirements to be marked as “Complete” as shown here in red:

Once the SAINT file has processed (normally 1 day), you would see that 4 out of your 9 business requirements are now complete, which is then reflected in the Status table of the SDR project:

Updating Completion Percentage

In addition, as shown in Part 3 of the post series, the overall business requirement completion percentage would be automatically updated as soon as the two business requirements are flagged as complete. This means that the overall completion percentage would move from 22.22% (2/9) to 44.44% (4/9):

Therefore, any time you add new business requirements, the overall completion percentage would decrease, and any time you complete requirements, the percentage would increase.

Using Advanced Segmentation

For those that are true Adobe Analytics geeks, here is an additional cool tip. As mentioned above, the SAINT file for the business requirements variable has several attributes. These attributes can be used in segments just like anything else in Adobe Analytics. For example, here you see the “Priority” SAINT Classification attribute highlighted:

This means that each business requirement has an associated Priority value, in this case, High, Medium or Low, which can be seen in the left navigation of Analysis Workspace:

Therefore, you can drag over items to create temporary segments using these attributes. Highlighted here, you see “Priority = High” added as a temporary segment to the SDR panel:

Doing this, applies the segment to all project data, so only the business requirements that are marked as “High Priority” are included in the dashboard components. After the segment is applied, there are now three business requirements that are marked as high priority, as shown in our SAINT file:

Therefore, since, after the upload described above, two of those three “High Priority” business requirements are complete, the overall implementation completion percentage automatically changes from 44.44% to 66.67% (2 out 3), as shown here (I temporarily unhid the underlying data table in case you want to see the raw data):

As you can see, the power of segmentation is fully at your disposal to make your Requirements/Solution Design project highly dynamic! That could mean segmenting by requirement owner, variable or any other data points represented within the project! For example, once we apply the “High Priority” segment to the project as shown above, viewing the variable portion of the project displays this:

This now shows all variables associated with “High Priority” business requirements.  This can be useful if you have limited time and/or resources for development.

Another example might be creating a segment for all business requirements that are not complete:

This segment can then be applied to the project as shown here to only see the requirements and variables that are yet to be implemented:

As you can see, there are some fun ways that you can use segmentation to to slice and dice your Solution Design! Pretty cool huh?

Over the past two weeks, I have been posting about how to view your business requirements and solution design in Analysis Workspace. First, I showed how this would look in Workspace and then I explained how I created it. In this post, I am going to share how you can extend this concept to calculate the completion percentage of business requirements directly within Analysis Workspace. Completion percentage is important because Adobe Analytics implementations are never truly done. Most organizations are continuously doing development work and/or adding new business requirements. Therefore, one internal KPI that you may want to monitor and share is the completion percentage of all business requirements.

Calculating Requirement Percentage Complete

As shown in the previous posts, you use Data Sources to upload a list of business requirements and each business requirement has one or more Adobe Analytics variables associated to it:

When this is complete, you can see a report like this:

Unfortunately, this report is really showing you how many total variables are being used, not the number of distinct business requirements (Note: You could divide the “1” in event30 by the number of variables, but that can get confusing!). This can be seen by doing a breakdown by the Variable eVar:

Since your task is to see how many business requirements are complete, you can upload a status for each business requirement via a SAINT file like this:

This allows you to create a new calculated metric that counts how many business requirements have a status of complete (based upon the SAINT Classification attribute) like this:

However, this is tricky, because the SAINT Classification that is applied to the Business Requirement metric doesn’t sum the number of completed business requirements, but rather the number of variables associated with completed requirements. This can be seen here:

What is shown here is that there are five total variables associated with completed business requirements out of twenty-five total variables associated with all business requirements. You could divide these two to show that your implementation is 20% complete (5/25), but that is not really accurate. The reality is that two out of nine business requirements are complete, so your actual completion percentage is 22.22 % (2/9).

So how do you solve this? Luckily, there are some amazing functions included in Adobe Analytics that can be used to do advanced calculations. In this case, what you want to do is count how many business requirements are complete, not how many variables are complete. To do this, you can use an IF function with a GREATER THAN function to set each row equal to either “1” or “0” based upon its completion status using this formula:

This produces the numbers shown in the highlighted column here:

Next, you want to divide the number of rows that have a value of “1” by the total number of rows (which represents the number of requirements). To do this, you simply divide the preceding metric by the ROW COUNT function, which will produce the numbers shown in the highlighted column here:

Unfortunately, this doesn’t help that much, because what you really want is the sum of the rows (22.22%) versus seeing the percentages in each row. However, you can wrap the previous formula in a COLUMN SUM function to sum all of the individual rows. Here is what the final formula would look like:

This would then produce a table like this:

Now you have the correct requirement percentage completion rate. The last step is to create a new summary number visualization using the column heading in the Requirement Completion % column as shown highlighted here:

To be safe, you should use the “lock” feature to make sure that this summary number will always be tied to the top cell in the column like this:

Before finishing, there are a few clean-up items left to do. You can remove any extraneous columns in the preceding table (which I added just to explain the formula) to speed up the overall project so the final table looks like this:

You can also hide the table completely by unchecking the “Show Data Source” box, which will avoid confusing your users) :

Lastly, you can move the completion percentage summary number to the top of the project where it is easily visible to all:

So now you have an easy way to see the overall business requirement completion % right in your Analysis Workspace SDR project!

[Note: The only downside of this overall approach is that the completion status is flagged by a SAINT Classification, which, by definition, is retroactive. This means that the Analysis Workspace project will always show the current completion percentage and will not record the history. If that is important to you, you’d have to import two success events for each business requirement via Data Sources. One for requirements and another for completed requirements and use formulas similar to the ones described above.]

Click here to see Part 4 for even more cool things related to this concept!

Last week, I wrote about a concept of having your business requirements and SDR inside Analysis Workspace. My theory was that putting business requirements and implementation information as close to users as possible could be a good thing. Afterwards, I had some folks ask me how I implemented this, so in this post I will share the steps I took. However, I will warn you that my approach is definitely a “hack” and it would be cool if, in the future, Adobe provided a much better way to do this natively within Adobe Analytics.

Importing Business Requirements (Data Sources)

The first step in the solution I shared is getting business requirements into Adobe Analytics so they can be viewed in Analysis Workspace. To do this, I used Data Sources and two conversion variables – one for the business requirement number and another for the variables associated with each requirement number. While this can be done with any two conversion variables (eVars), I chose to use the Products variable and another eVar because my site wasn’t using the Products variable (since we don’t sell a physical product). You may choose to use any two available eVars. I also used a Success Event because when you use Data Sources, it is best to have a metric to view data in reports (other than occurrences). Here is what my data sources file looked like:

Doing this allowed me to create a one to many relationship between Req# (Products) and the variables for each (eVar17). The numbers in event 30 are inconsequential, so I just put a “1′ for each. Also note, that you need to associate a date with data being uploaded via Data Sources. The cool thing about this, is that you can change your requirements when needed by re-uploading the entire file again at a later date (keeping in mind that you need to choose your data ranges carefully so you don’t get the same requirement in your report twice!). Another reason I uploaded the requirement number and the variables into conversion variables is that these data points should not change very often, whereas, many of the other attributes will change (as I will show next).

Importing Requirement & Variable Meta-Data (SAINT Classifications)

The next step of the process is adding meta-data to the two conversion variables that were imported. Since the Products variable (in my case) contains data related to business requirements, I added SAINT Classifications for any meta-data that I would want to upload for each business requirement. This included attributes like description, owner, priority, status and source.

Note, these attributes are likely to change over time (i.e. status), so using SAINT allows me to update them by simply uploading an updated SAINT file. Here is the SAINT file I started with:

The next meta-data upload required is related to variables. In my case, I used eVar17 to capture the variable names and then classified it like this:

As you can see, I used classifications and sub-classifications to document all attributes of variables. These attributes include variable types, descriptions and, if desired, all of the admin console attributes associated with variables. Here is what the SAINT file looks like when completed:

[Note: After doing this and thinking about it for a while, in hindsight, I probably should have uploaded Variable # into eVar17 and made variable name a classification in case I want to change variable names in the future, so you may want to do that if you try to replicate this concept.]

Hence, when you bring together the Data Sources import and the classifications for business requirements and variables, you have all of the data you need to view requirements and associated variables natively in Adobe Analytics and Analysis Workspace as shown here:

Project Curation

Lastly, if you want to minimize confusion for your users in this special SDR project, you can use project curation to limit the items that users will see in the project to those relevant to business requirements and the solution design. Here is how I curated my Analysis Workspace project:

This made it so visits only saw these elements by default:

Final Thoughts

This solution has a bit of set-up work, but once you do that, the only ongoing maintenance is uploading new business requirements via Data Sources and updating requirements and variable attributes via SAINT Classifications. Obviously, this was just a quick & dirty thing I was playing around with and, as such, not something for everyone. I know many people are content with keeping this information in spreadsheets, in Jira/Confluence or SharePoint, but I have found that this separation can lead to reduced usage. My hope is that others out there will expand upon this concept and [hopefully] improve it. If you have any additional questions/comments, please leave a comment below.

To see the next post in this series, click here.

Those who know me, know that I have a few complaints about Adobe Analytics implementations when it comes to business requirements and solution designs. You can see some of my gripes around business requirements in the slides from my 2017 Adobe Summit session and you can watch me describe why Adobe Analytics Solution Designs are often problematic in this webinar (free registration required). In general, I find that:

• Too few organizations have defined analytics business requirements
• Most Solution Designs are simply lists of variables and not tied to business requirements
• Often times, Solution Designs are outdated/inaccurate

When I start working with new clients, I am shocked at how few have their Adobe Analytics implementation adequately organized and documented. One reason for this, is that requirements documents and solution designs tend to live on a [digital] shelf somewhere, and as you know, out of sight, often means out of mind. For this reason, I have been playing around with something in this area that I wanted to share. To be honest, I am not sure if the concept is the right solution, but my hope is that some of you out there can possibly think about it and help me improve upon it.

Living in Workspace

It has become abundantly clear that the future of Adobe Analytics is Analysis Workspace. If you haven’t already started using Workspace as your default interface for Adobe Analytics, you will be soon. Most people are spending all of their time in Analysis Workspace, since it is so much more flexible and powerful than the older “SiteCatalyst” interface. This got me thinking… “What if there were a way to house all of your Adobe Analytics business requirements and the corresponding Solution Design as a project right within Analysis Workspace?” That would put all of your documentation a few clicks away from you at all times, meaning that there would be no excuse to not know what is in your implementation, which variables answer each business requirement and so on.

Therefore, I created this:

The first Workspace panel is simply a table of contents with hyperlinks to the panels below it. The following will share what is contained within each of the Workspace panels.

The first panel is simply a list of all business requirements in the Adobe Analytics implementation, which for demo purposes is only two:

The second panel shows the same business requirements split out by business priority, in case you want to look at ones that are more important than others:

One of the ways you can help your end-users understand your implementation is to make it clear which Adobe Analytics variables (reports) are associated with each business requirement. Therefore, I thought it would make sense to let users breakdown each business requirement by variable as shown here:

Of course, there will always be occasions where you just want to see a list of all of your Success Events, eVars and sProps, so I created a breakdown by variable type:

Since each business requirement should have a designated owner, the following breakdown allows you to see all business requirements broken down by owner:

Lastly, you may want to track which business requirements have been completed and which are still outstanding. The following breakdown allows you to see requirements by current implementation status:

Maximum Flexibility

As you can see, the preceding Analysis Workspace project, and panels contained within, provide an easy way to understand your Adobe Analytics implementation. But since you can break anything down by anything else in Analysis Workspace, these are just some sample reports of many more that could be created. For example, what if one of my users wanted to drill deep into the first business requirement and see what variables it uses, descriptions of those variables and even the detailed settings of those variables (i.e. serialization, expiration, etc…)? All of these components can be incorporated into this solution such that users can simply choose from a list of curated Analysis Workspace items (left panel) and drop them in as desired like shown here:

Granted, it isn’t as elegant as seeing everything on an Excel spreadsheet, it is convenient to be able to see all of this detail without having to leave the tool! And maybe one day, it will be possible to see multiple items on the same row in Analysis Workspace, which would allow this solution to look more like a spreadsheet. I also wish there were a way to hyper-link right from the variable (report) name to a new project that opens with that report, but maybe that will be possible in the future.

If you want to see the drill-down capabilities in action, here is a link to a video that shows me doing drill-downs live:

Summary

So what do you think? Is this something that your Adobe Analytics users would benefit from? Do you have ideas on how to improve it? Please leave a comment here…Thanks!

P.S. To learn how I created the preceding Analysis Workspace project, check out Part Two of this post.

The Transaction ID feature in Adobe Analytics is one of the most underrated in the product. Transaction ID allows you to “close the loop,” so to speak, and import offline metrics related to online activity and apply those metrics to pre-existing dimension values.  This means that you can set a unique ID online and then import offline metrics tied to that unique ID and have the offline metrics associated with all eVar values that were present when the online ID was set. For example, if you want to see how many people who complete a lead form end up becoming customers a few weeks later, you can set a Transaction ID and then later import a “1” into a Success Event for each ID that becomes a customer. This will give “1” to every eVar value that was present when the Transaction ID was set, such as campaign code, visit number, etc…. It is almost like you are tricking Adobe Analytics into thinking that the offline event happened online. In the past, I have described how you could use Transaction ID to import recurring revenue and import product returns, but in this post, I will share another example related to Human Resources and recruiting.

Did They Get Hired?

So let’s imagine that you work for an organization that uses Adobe Analytics and hires a lot of folks. It is always a good thing if you can get more groups to use analytics (to justify the cost), so why not have the HR department leverage the tool as well? On your website, you have job postings and visitors can view jobs and then click to apply. You would want to set a success event for “Job Views” and another for “Job Clicks” and store the Job ID # in an eVar. Then if a user submits a job application, you would capture this with a “Job Applications” Success Event. Thus, you would have a report that looks like this:

Let’s assume that your organization is also using marketing campaigns to find potential employees. These campaign codes would be captured in the Campaigns (Tracking Code) eVar and, of course, you can also see all of these job metrics in this and any other eVar reports:

But what if you wanted to see which of these job applicants were actually hired? Moreover, what if you wanted to see which marketing campaigns led to hires vs. just unqualified applicants? All of this can be done with Transaction ID. As long as you have some sort of back-end system that knows the unique “transaction” ID and knows if a hire took place, you can upload the offline metric and close the loop. Here is what the Transaction ID upload file might look like:

Notice that we are setting a new “Job Hires” Success Event success event and tying it to the Transaction ID. This will bind the offline metric to the Job # eVar value, the campaign code and any other eVars. Once this has loaded, you can see a report that looks like this:

Additionally, you can then switch to the Campaigns report to see this:

This allows you to then create Calculated Metrics to see which marketing campaigns are most effective at driving new hires.

Are They Superstars?

If you want to get a bit more advanced with Transaction ID, you can extend this concept to import additional metrics related to employee performance. For example, let’s say that each new hire is evaluated after their first six months on the job and that they are rated on a scale of 1 (bad) to 10 (great). In the future, you can import their performance as another numeric Success Event (just be sure to have your Adobe account manager extend Transaction ID beyond the default 90 days):

Which will allow you to see a report like this:

Then you can create a Calculated Metric that divides the rating by the number of hires. This will allow you to see ratings per hire in any eVar report, like the Campaigns report shown here:

Final Thoughts

This is a creative way to apply the concept of Transaction ID, but as you can imagine, there are many other ways to utilize this functionality. Anytime that you want to tie offline metrics to online metrics, you should consider using Transaction ID.

Recently, a co-worker ran into an issue in Adobe Analytics related to Visit Frequency. The Visit Frequency report in Adobe Analytics is not one that I use all that often, but it looks like this:

This report simply shows a distribution of how long it takes people to come back to your website. In this case, my co-worker was looking to show these visit frequencies as a percentage of all visits. To do this, she created a calculated metric that divided visits by the total number of visits like this:

Then she added it to the report as shown here:

At this point, she realized that something wasn’t right. As you can see here, the total number of Visits is 5,531, but when she opened the Visits metric, she saw this:

Then she realized that the Return Frequency report doesn’t show 1st time visits and even though you might expect the % of Total Visits calculated metric to include ALL visits, it doesn’t. This was proven by applying a 1st Time Visits segment to the Visits report like this:

Now we can see that when subtracting the total visits (27,686) from the 1st time visits (22,155), we are left with 5,531, which is the amount shown in the return frequency report. Hence, it is not as easy as you’d think to see the % of total visits for each return frequency row.

Solution #1 – Adobe ReportBuilder

The easiest way to solve this problem is to use Adobe ReportBuilder. Using ReportBuilder, you can download two data blocks – one for Return Frequency and one for Visits:

Once you have downloaded these data blocks you can create new columns that divide each row by the correct total number of visits to see your % of total:

In this case, I re-created the original percentages shown in the Return Frequency report, but also added the desired % of Total visits in a column next to it so both could be seen.

Solution #2 – Analysis Workspace & Calculated Metrics

Since Analysis Workspace is what all the cool kids are using these days, I wanted to find a way to get this data there as well. To do this, I created a few new Calculated Metrics that used Visits and Return Frequency. Here is one example:

This Calculated Metric divides Visits where Return Frequency was less than 1 day by all Visits. Here is what it looks like when you view Total visits, the segmented version of Visits and the Calculated Metric in a table in Analysis Workspace:

Here you can see that the total visits for June is 27,686, that the less than 1 day visits were 2,276 and that the % of Total Visits is 8.2%. You will see that these figures match exactly what we saw in Adobe ReportBuilder as well (always a good sign!). Here is what it looks like if we add a few more Return Frequencies:

Again, our numbers match what we saw above. In this case, there is a finite number of Return Frequency options, so even though it is a bit of a pain to create a bunch of new Calculated Metrics, once they are created, you won’t have to do them again. I was able to create them quickly by using the SAVE AS feature in the Calculated Metrics builder.

As a bonus, you can also right-click and create an alert for one or more of these new calculated metrics:

Summary

So even though Adobe Analytics can have some quirks from time to time, as shown here, you can usually find multiple ways to get to the data you need if you understand all of the facets of the product. If you know of other or easier ways to do this, please leave a comment here. Thanks!

One of the things I have noticed lately is how slowly some websites are loading, especially media-related websites. For example, recently I visited wired.com and couldn’t get anything to work. Then I looked at Ghostery and saw that they had 126 tags on their site and a page load time of almost 20 seconds!

I have seen lots of articles showing that fast loading pages can have huge positive impacts on website conversion, but the proliferation of JavaScript tags may be slowly killing websites! Hopefully some of the new GDPR regulations will force companies to re-examine how many tags are on their sites and whether all of them are still needed. In the meantime, I highly recommend that you use a tool like ObservePoint to understand how many tags are lingering on your site now.

As a web analyst, you may want to measure how long it is taking your pages to load. Doing this isn’t trivial, as can be seen in my partner Josh West’s 2015 blog post. In this post, Josh shows some of the ways you can capture page load time in a dimension in Adobe or Google Analytics, though doing so is not going to be completely exact. Regardless, I suggest you check out his post and consider adding this dimension to your analytics implementation.

One thing that Josh alluded to, but did not go into depth on, is the idea of storing page load time as a metric. This is quite different than capturing the load time in a dimension, so I thought I would touch upon how to do this in Adobe Analytics (which can also be done in Google Analytics). If you want to store page load time as a metric in Adobe Analytics, you would pass the actual load time (in seconds or milliseconds) to a Numeric Success Event. This would create an aggregated page load time metric that is increased with every website page view. This new metric can be divided by page views or you can set a separate counter page load denominator success event (if you are not going to track page load time on every page). Here is what you might see if you set the page load time and denominator metrics in the debugger:

You would also want to capture the page name in an eVar so you can easily see the page load time metrics by page. This is what the data might look like in a page name (actual page names hidden here):

In this case, there is a calculated metric that is dividing the aggregated page load time by the denominator to see an average page load time for each page. There are also ways that you can use Visit metrics to see the average page load time per visit. Regardless of which version you use, this type of report can help you identify your problem pages so you can see if there are things you can do to improve conversion. I suggest combing this with a Participation report to see which pages impact your conversion the most, but are loading slowly.

Another cool thing you can do with this data is to trend the average page load time for the website overall. Since you already have created the calculated metric shown below, you can simply open this metric by itself (vs. viewing by page name), to see the overall trend of page load speeds for your site and then set some internal targets or goals to strive for in the future.

Many retailers use product ratings as a way to convince buyers that they should take the next step in conversion, which is usually a cart addition. Showing how often a product has been reviewed and its average product rating helps build product credibility and something consumers have grown used to from popular sites like amazon.com.

Digital analytics tools like Adobe Analytics can be used to determine whether the product ratings on your site/app are having a positive or negative impact on conversion. In this post, I will share some ways you can track product review information to see its impact on your data.

Impact of Having Product Ratings/Reviews

The first thing you should do with product ratings and reviews is to capture the current avg. rating and # of reviews in a product syntax merchandising eVar when visitors view the product detail page. In order to save eVars, I sometimes concatenate these two values with a separator and then use RegEx and the SAINT Classification RuleBuilder to split them out later. In the preceding screenshot, for example, you might pass 4.7|3 to the eVar and then split those values out later via SAINT. Capturing these values at the time of the product detail page view allows you to lock in what the rating and # of reviews was at the time of the product view. Here is what the rating merchandising eVar might look like once split out:

You can also group these items using SAINT to see how ratings between 4.0 – 4.5 perform vs. 4.5 – 5.0, etc… You can also sort this report by your conversion metrics, but if you do so, I would recommend adding a percentile function so you don’t just see rows that have very few product views or orders. The same type of report can be run for # of reviews as well:

Lastly, if you have products that don’t have ratings/reviews at all, the preceding reports will have a “None” row, which will allow you to see the conversion rate when no ratings/reviews exist, which may be useful information to see overall impact of ratings/reviews for your site.

Average Product Rating Calculated Metric

In addition to capturing the average rating and the # of reviews in an eVar, another thing you can do is to capture the same values in numeric success events. As a reminder, a numeric success event is a metric that can be incremented by more than one in each server call. For example, when a visitor views the following product page, the average product rating of 4.67 is being passed to a numeric success event 50. This means that event 50 is being increased for the entire website by 4.67 each time this product is viewed. Since the Products variable is also set, this 4.67 is “bound” (associated) to product H8194. At the same time, we need a denominator to divide this rating by to compute the overall product rating average. In this case, event 51 is set to “1” each time that a rating is present (you cannot use Product Views metric since there may be cases in which no rating is present but there is a product view).  Here is what the tagging might look like when it is complete:

Below is what the data looks like once it is collected:

You can see Product Views, the accumulated star ratings, the number of times ratings were available and a calculated metric to compute the average rating for each product. Given that we already have the average product rating in an eVar, this may not seem important, but the cool part of this is that now the product rating can be trended over time. Simply add a chart visualization and then select a specific product to see how its rating changes over time:

The other cool part of this is that you can leverage your product classifications to group these numeric ratings by product category:

Using both eVars and success events to capture product ratings/reviews on your site allows you to capture what your visitors saw for each product while on your product detail pages. Having this information can be helpful to see if ratings/reviews are important to your site and to be aware of the impact for each product and/or product category.

Back in 2015, I wrote a post about using Calculated Metrics to create an Engagement Score. In that post, I mentioned that it was possible to pick a series of success events and multiply them by some sort of weighted number to compute an overall website engagement score. This was an alternative to a different method of tracking visitor engagement via numeric success events set via JavaScript (which was also described in the post). However, given that Adobe has added the cool Approximate Count Distinct function to the analytics product, I recently had an idea about a different way to compute website engagement that I thought I would share.

Adding Depth to Website Engagement

In my previous post, website engagement was computed simply by multiplying chosen success events by a weighted multiplier like this:

This approach is workable but lacks a depth component. For example, the first parameter looks at how many Product Views take place but doesn’t account for how many different products are viewed. There may be a situation in which you want to assign more website engagement to visits that get visitors to view multiple products vs. just one. The same concept could apply to Page Views and Page Names, Video Views and Video Names, etc…

Using the Approximate Count Distinct function, it is now possible to add a depth component to the website engagement formula. To see how this might work, let’s go through an example. Imagine that in a very basic website engagement model, you want to look at Blog Post Views and Internal Searches occurring on your website. You have success events for both Blog Post Views and Internal Searches and you also have eVars that capture the Blog Post Titles and Internal Search Keywords.

To start, you can use the Approximate Count Distinct function to calculate how many unique Blog Post Titles exist (for the chosen date range) using this formula:

Next, you can multiply the number of Blog Post Views by the number of unique Blog Post Titles to come up with a Blog Post Engagement score as shown here:

Note that since the Approximate Count Distinct function is not 100% accurate, the numbers will differ slightly from what you would get if you use a calculator, but in general, the function will be at least 95% accurate or greater.

You can repeat this process for Internal Search Keywords. First, you compute the Approximate Count of unique Search Keywords like this:

Then you create a new calculated metric that multiplies the number of Internal Searches by the unique number of Keywords. Here is what a report looks like with all six metrics:

Website Engagement Calculation

Now that you have created the building blocks for your simplistic website engagement score, it is time to put them together and add some weighting. Weighting is important, because it is unlikely that your individual elements will have the same importance to your website. In this case, let’s imagine that a Blog Post View is much more important than an Internal Search, so it is assigned a weight score of 90, whereas a score of 10 is assigned to Internal Searches. If you are creating your own engagement score, you may have more elements and can weight them as you see fit.

In the following formula, you can see that I am adding the Blog Post engagement score to the Internal Search engagement score and adding the 90/10 weighting all in one formula. I am also dividing the entire formula by Visits to normalize it, so my engagement score doesn’t rise or fall based upon differing number of Visits over time:

Here you can see a version of the engagement score as a raw number (multiplied by 90 & 10) and then the final one that is divided by Visits:

Finally, you can plot the engagement score in a trended bar chart. In this case, I am trending both the engagement score and visits in the same chart:

In the end, this engagement score calculation isn’t significantly different than the original one, but adding the Approximate Count Distinct function allows you to add some more depth to the overall calculation If you don’t want to multiply the number of success event instances by ALL of the unique count of values, you could alternatively use an IF function with the GREATER THAN function to cap the number of unique items at a certain amount (i.e. If more than 50 unique Blog Post Titles, use 50, else, use the unique count).

The best part of this approach is that it requires no JavaScript tagging (assuming you already have the success events and eVars you need in the calculation). So you can play around with the formula and its weightings with no fear of negatively impacting your implementation and no IT resources! I suggest that you give it a try and see if this type of engagement score can be used as an overall health gauge of how your website is performing over time.

As is often the case with Analysis Workspace (in Adobe Analytics), you stumble upon new features accidentally. Hopefully, by now you have learned the rule of “when in doubt, right-click” when using Analysis Workspace, but for other new features, I recommend reading Adobe’s release notes and subscribing to the Adobe Analytics YouTube Channel. Recently, the ability to use 100% stacked bar charts was added to Analysis Workspace, so I thought I’d give it a spin.

Normal vs. 100% Stacked Bar Charts

Normally, when you use a stacked bar chart, you are comparing raw numbers. For example, here is a sample stacked bar chart that looks at Blog Post Views by Author:

This type of chart allows you to see overall trends in performance over time. In some respects, you can also get a sense of which elements are going up and down over time, but since the data goes up and down each week, it can be tricky to be exact in the percentage changes.

For this reason, Adobe has added a 100% stacked bar visualization. This visualization stretches the elements in your chart to 100% and shifts the graph from raw numbers to percentages (of the items being graphed, not all items necessarily). This allows you to more accurately gauge how each element is changing over time.

To enable this, simply click the gear icon of the visualization and check the 100% stacked box:

Once this is done, your chart will look like this:

In addition, if you hover over one of the elements, it will show you the actual percentage:

The 100% stacked setting can be used in any trended stacked bar visualization. For example, here is a super basic example that shows the breakdown of Blog Post Views by mobile operating system:

For more information on using the 100% stacked bar visualization, here is an Adobe video on this topic: https://www.youtube.com/watch?v=_6hzCR1SCxk&t=1s

When I am working on a project to audit someone’s Adobe Analytics implementation, one of the things I often notice is a lack of organization that surrounds the implementation. When you use Adobe Analytics, there are a lot of “components” that you can customize for your implementation. These components include Segments, Calculated Metrics, Reports, Dashboards, etc. I have some clients that have hundreds of Segments or Calculated Metrics, to the point that finding the one you are looking for can be like searching for a needle in a haystack! Over time, it is so easy to keep creating more and more Adobe Analytics components instead of re-using the ones that already exist. When new, duplicative components are created, things can get very chaotic because:

• Different users could use different components in reports/dashboards
• Changes made to fix a component may only be fixed in some places if there are duplicative components floating out there
• Multiple components with the same name or definition can confuse novice users

For these reasons, I am a big fan of keeping your Adobe Analytics components under control, which takes some work, but pays dividends in the long run.  A few years ago, I wrote a post about how you can use a “Corporate Login” to help manage key Adobe Analytics components. I still endorse that concept, but today, I will share another technique I have started using to organize components in case you find it helpful.

Searching For Components Doesn’t Work

One reason that components proliferate is because finding the components you are looking for is not foolproof in Adobe Analytics. For example, let’s say that I just implemented some code to track Net Promoter Score in Adobe Analytics. Now, I want to create a Net Promoter Score Calculated Metric so I can trend NPS by day, week or month. To do this, I might go to the Calculated Metrics component screen where I would see all of the Calculated Metrics that exist:

If I have a lot of Calculated Metrics, it could take me a long time to see if this exists, so I might search for the Calculated Metric I want like this:

Unfortunately, my search came up empty, so I would likely go ahead and create a new Net Promoter Score Calculated Metric. What I didn’t know is that one already exists, it was just named “NPS Score” instead of “Net Promoter Score.” And since people are not generally good about using standard naming conventions, this scenario can happen often. So how do we fix this? How do we avoid the creation of duplicative components?

Search By Variable

To solve this problem, I have a few ideas. In general, the way I think about components like Calculated Metrics or Segments is that they are made up of other Adobe Analytics elements, specifically variables. Therefore, if I want to see if a Net Promoter Score Calculated Metric already exists, a good place to start would be to look for all Calculated Metrics that use one of the variables that is used to track Net Promoter Score in my implementation. In this case, success event #20 (called NPS Submissions [e20]) is set when any Net Promoter Score survey occurs. Therefore, if I could filter all Calculated Metrics to see only those that utilize success event #20, I would be able to find all Calculated Metrics that relate to Net Promoter Score. Unfortunately, Adobe Analytics only allows you to filter by the following items:

It would be great if Adobe had a way that you could filter on variables (Success Events, eVars, sProps), but that doesn’t exist today. The next best thing would be the ability to have Adobe Analytics find Calculated Metrics (or other components) by variable when you type the variable name in the search box. For example, it would be great if I could enter this in the search box:

But, alas, this doesn’t work either (though could one day if you vote for my idea in the Adobe Idea Exchange!).

Tagging to the Rescue!

Since there is no good way today to search for components by variable, I have created a workaround that you can use leveraging the tagging feature of Adobe Analytics. What I have started doing, is adding a tag for every variable that is used in a Calculated Metric (or Segment). For example, if I am creating a “Net Promoter Score” Calculated Metric that uses success event# 20 and success event# 21, in addition to any other tags I might want to use, I can tag the Calculated Metric with these variable names as shown here:

Once I do this, I will begin to see variable names appear in the tag list like this:

Next, if I am looking for a specific Calculated Metric, I can simply check one of the variables that I know would be part of the formula…

…and Adobe Analytics will filter the entire list of Calculated Metrics to only show me those that have that variable tag:

This is what I wish Adobe Analytics would do out-of-the-box, but using the tagging feature, you can take matters into your own hands. The only downside is that you need to go through all of your existing components and add these tags, but I would argue that you should be doing that anyway as part of a general clean-up effort and then simply ask people to do this for all new components thereafter.

The same concept can be applied to other Adobe Analytics components that use variables and allow tags. For example, here is a Segment that I have created and tagged based upon variables it contains:

This allows me to filter Segments in the same way:

Therefore, if you want to keep your Adobe Analytics implementation components organized and make them easy for your end-users to find, you can try out this work-around using component tags and maybe even vote for my idea to make this something that isn’t needed in the future. Thanks!

I am excited to announce that my partner Brian Hawkins and I will be joining the Adobe Insider Tour that is hitting several US cities over the next few months! These 100% free events held by Adobe are great opportunities to learn more about Adobe’s Marketing Cloud products (Adobe Analytics, Adobe Target, Adobe Audience Manager). The half-day sessions will provide product-specific tips & tricks, show future product features being worked on and provide practical education on how to maximize your use of Adobe products.

The Adobe Insider Tour will be held in the following cities and locations:

Atlanta – Friday, June 1
Fox Theatre
660 Peachtree St NE
Atlanta, GA 30308

Los Angeles – Thursday, June 21
iPic Westwood
10840 Wilshire Blvd
Los Angeles, CA 90024

Chicago – Tuesday, September 11
Davis Theater
4614 N Lincoln Ave
Chicago, IL 60625

New York – Thursday, September 13
iPic Theaters at Fulton Market
11 Fulton St
New York, NY 10038

Dallas – Thursday, September 27
Alamo Drafthouse
1005 S Lamar St
Dallas, TX 75215

Adobe Analytics Implementation Improv

As many of my blog readers know, I pride myself on pushing Adobe Analytics to the limit! I love to look at websites and “riff” on what could be implemented to increase analytics capabilities. On the Adobe Insider Tour, I am going to try and take this to the next level with what we are calling Adobe Analytics Implementation Improv. At the beginning of the day, we will pick a few companies in the audience and I will review the site and share some cool, advanced things that I think they should implement in Adobe Analytics. These suggestions will be based upon the hundreds of Adobe Analytics implementations I have done in the past, but this time it will be done live, with no preparation and no rehearsal! But in the process, you will get to see how you can quickly add some real-world, practical new things to your implementation when you get back to the office!

Adobe Analytics “Ask Me Anything” Session

After the “Improv” session, I will have an “Ask Me Anything” session to do my best and answer any questions you may have related to Adobe Analytics. This is your chance to get some free consulting and pick my brain about any Adobe Analytics topic. I will also be available prior to the event at Adobe’s “Genius Bar” providing 1:1 help.

Adobe Analytics Idol

As many of you may know, for the past few years, Adobe has hosted an Adobe Analytics Idol contest. This is an opportunity for you to share something cool that you are doing with Adobe Analytics or some cool tip or trick that has helped you. Over the years this has become very popular and now Adobe is even offering a free pass to the next Adobe Summit for the winner! So if you want to be a candidate for the Adobe Analytics Idol, you can now submit your name and tip and present at your local event. If you are a bit hesitant to submit a tip, this year, Adobe is adding a cool new aspect to the Adobe Analytics Idol. If you have a general idea, but need some help, you can email and either myself or one of the amazing Adobe Analytics product managers will help you formulate your idea and bring it to fruition. So even if you are a bit nervous to be an “Idol” you can get help and increase your chances of winning!

There will also be time at these events for more questions and casual networking, so I encourage you to register now and hope to see you at one of these events!

I have been in consulting for a large portion of my professional life, starting right out of school at Arthur Andersen (back when it existed!). Therefore, I have been part of countless consulting engagements over the past twenty-five years. During this time, there are a few projects that stand out. Those that seemed daunting at first, but in the end turned out to make a real difference. Those large, super-difficult projects are the ones that tend to stick with you.

A few years ago, I came across one of these large projects at a company called Elsevier. Elsevier is a massive organization, with thousands of employees and key locations all across Europe and North America. But what differentiates Elsevier the most, is how disparate a lot of their business units can be – from geology to chemistry, etc. When I stumbled upon Elsevier, they were struggling to figure out how to have a unified approach to implementing Adobe Analytics worldwide in a way that helped them see some key top-line metrics, but at the same time offering each business unit its own flexibility where needed. This is something I see a lot of large organizations struggle with when it comes to Adobe Analytics. Since over my career I have worked with some of the largest Adobe Analytics implementations in the world, I was excited to apply what I have learned to tackle this super-complex project. I am also fortunate to have Josh West, one of the best Adobe Analytics implementation folks in the world, as my partner, who was able to work with me and Elsevier to turn our vision into a reality.

While the project took some time and had many bumps along the way, Elsevier heeded our advice and ended up with an Adobe Analytics program that transformed their business. They provided tremendous support form the top (thanks to Darren Person!) and Adobe Analytics became a huge success for the organization.  To learn more about this, I suggest you check out this case study here.

In addition, if you want to hear Darren and I talk about the project while we were still in the midst of it, you can see a presentation we did at the 2016 Adobe Summit (free registration required) by clicking here.

OK. It may be a bit of a stretch to say that DB Vista is sexy. But I continue to discover that very few Adobe Analytics clients have used DB Vista or even know what it is. As I wrote in my old blog back in 2008 (minus the images which Adobe seems to have lost!), DB Vista is a method of setting Adobe Analytics variables using a rule that does a database lookup on a table that you upload (via FTP) to Adobe. In my original blog post, I mentioned how you can use DB Vista to import the cost of each product to a currency success event, so you can combine it with revenue to calculate product margin. This is done by uploading your product information (including cost) to the DB Vista table and having a DB Vista rule lookup the value passed to the Products variable and match it to the column in the table that stores the current product cost.  As long as you are diligent about keeping your product cost table updated, DB Vista will do the rest.  The reason I wanted to bring the topic of DB Vista back is that it has come up more and more over the past few weeks. In this post, I will share why and a few reasons why I keep talking about it.

Adobe Summit Presentation

A few weeks ago, while presenting at Adobe Summit, I showed an example where a company was [incorrectly] using SAINT Classifications to classify product ID’s with the product cost like this:

As I described in this post, SAINT Classifications are not ideal for something like Product Cost because the cost of each product will change over time and updating the SAINT file is a retroactive change that will make it look like each product ALWAYS had the most recently uploaded cost.  In the past, this could be mitigated by using date-enabled SAINT Classifications, but those have recently been removed from the product, I presume due to the fact they weren’t used very often and were overly complex.

However, if you want to capture the cost of each product, as mentioned above, you could use DB Vista to pass the cost to a currency success event and/or you could capture the cost in an eVar. Unlike SAINT, using DB Vista to get the cost, means that the data is locked in at the time it is collected.  All that is needed is a mechanism to keep your product cost data updated in the DB Vista table.

Measure Slack

Another case where DB Vista arose recently, was in the #Measure Slack group. There was a discussion around using classifications to group products, but the product group was not available in real-time to be passed to an eVar and the product group could change over time.

The challenge in this situation is that SAINT classifications would not be able keep all of this straight without the use of date-enabled classifications. This is another situation where DB Vista can save the day as long as you are able to keep the product table updated as products move groups.  In this case, all you’d need to do is upload the product group to the DB Vista table and use the DB Vista rule to grab the value and pass it to an eVar whenever the Products variable is set.

Idea Exchange

There are countless other things that you can do with DB Vista. So why don’t people use it more? I think it has to do with the following reasons:

• Most people don’t understand the inner workings of DB Vista (hint: come to my upcoming  “Top Gun” Training Class!)
• DB Vista has an additional cost (though it is pretty nominal)
• DB Vista isn’t something you can do on your own – you need to engage with Adobe Engineering Services

Therefore, I wish that Adobe would consider making DB Vista something that administrators could do on their own through the Admin Console and Processing Rules (or via Launch!). Recently, Data Feeds was made self-service and I think it has been a huge success! More people than ever are using Data Feeds, which used to cost $$ and have to go through Adobe Engineering Services. I think the same would be true for DB Vista. If you agree, please vote for my idea here. Together, we can make DB Vista the sexy feature it deserves to be!

Lately, I have been seeing more and more Adobe Analytics clients moving to Virtual Report Suites. Virtual Report Suites are data sets that you create from a base Adobe Analytics report suite that differ from the original by either limiting data by a segment or making other changes to it, such as changing the visit length. Virtual Report Suites are handy because they are free, whereas sending data to multiple report suites in Adobe Analytics costs more due to increased server calls. The Virtual Report Suite feature of Adobe Analytics has matured since I originally wrote about it back in 2016. If you are not using them, you probably should be by now.

However, when some of my clients have used Virtual Report Suites, I have noticed that there are some data elements that tend to not transition from the main report suite to the Virtual Report Suite. One of those items is data imported via Data Sources. In last week’s post, I shared an example of how you can import external metrics to your Adobe Analytics implementation via Data Sources, but there are many data points that can be imported, including metrics from 3rd party apps. One of the more common 3rd party apps that my clients integrate into Adobe Analytics are e-mail applications. For example, if your organization uses Responsys to send and report on e-mails sent to customers, you may want to use the established Data Connector that allows you to import your e-mail metrics into Adobe Analytics, such as:

• Email Total Bounces
• Email Sent
• Email Delivered
• Email Clicked
• Email Opened
• Email Unsubscribed

Once you import these metrics into Adobe Analytics, you can see them like any other metrics…

…and combine them with other metrics:

In this case, I am viewing the offline e-mail metrics alongside with the online metric of Orders and also created a new Calculated Metric that combines both offline and online metrics (last column). So far so good!

But watch what happens if I now view the same report in a “UK Only” Virtual Report Suite that is based off of this main report suite:

Uh oh…I just lost all of my data! I see this happen all of the time and usually my clients don’t even realize that they have told their internal users to use a Virtual Report Suite that is missing all Data Source metrics.

So why is the data missing? In this case the Virtual Report Suite is based upon a geographic region segment:

This means that any hits with eVar16 value of “UK” will make it into the Virtual Report Suite. Since all online data has an eVar16 value, it is successfully carried over to the Virtual Report Suite.  However, when the Data Sources metrics were imported (in this case Responsys E-mail Metrics), they did not have an eVar16 value so they are not included. That is why these metrics zeroed out when I ran the report for the Virtual Report Suite. In the next section, I will explain how to fix this so you make sure all of your Data Source metrics are included in the Virtual Report Suite

Long-Term Approach (Data Sources File)

The best long-term way to fix this problem is to change your Data Sources import files to make sure that you add data that will match your Virtual Report Suite segment. In this case, that means making sure each row of data imported has an eVar16 value. If you add a column for eVar16 to the import, any rows that contain “UK” will be included in the Virtual Report Suite. For this e-mail data, it means that your e-mail team would have to know which region each e-mail is associated with, but that shouldn’t be a problem. Unfortunately, it does require a change to your daily import process, but this is the cleanest way to make sure your Data Sources data flows correctly to your Virtual Report Suite.

Short-Term Approach (Segmentation)

If, however, making a change to your daily import process isn’t something that can happen soon (such as data being imported from an internal database that takes time to change), there is an easy workaround that will allow you to get Data Sources data immediately. This approach is also useful if you want to retroactively include Data Sources metrics that was imported before you make the preceding fix.

This short-term solution involves modifying the Segment used to pull data into the Virtual Report Suite. By adding additional criteria to your Segment definition, you can manually select which data appears in the Virtual Report Suite. In this case, the Responsys e-mail metrics don’t have an eVar16 value, but you can add them to the Virtual Report Suite by finding another creative way to include them in the segment. For example, you can add an OR statement that includes hits where the various Responsys metrics exist like this:

Once you save this new segment, your Virtual Report Suite will now include all of the data it had before and the Responsys data so the report will now look like this:

Summary

So this post is just a reminder to make sure that all of your imported Data Source metrics have made it into your shiny new Virtual Report Suites and, if not, how you can get them to show up there. I highly suggest you fix the issue at the source (Data Sources import file), but the segmentation approach will also work and helps you see data retroactively.

Last week, I explained how the Approximate Count Distinct function in Adobe Analytics can be used to see how many distinct dimension values occur within a specified timeframe. In that post, I showed how you could see how many different products or campaign codes are viewed without having to count up rows manually and how the function provided by Adobe can then be used in other Calculated Metrics. As a follow-on to that post, in this post, I am going to share a concept that I call “dimension penetration %.” The idea of dimension penetration % is that there may be times in which you want to see what % of all possible dimension values are viewed or have some other action taken. For example, you may want to see what % of all products available on your website were added to the shopping cart this month. The goal here is to identify the maximum number of dimension values (for a time period) and compare that to the number of dimension values that were acted upon (in the same time period). Here are just some of the business questions that you might want to answer with the concept of dimension penetration %:

• What % of available products are being viewed, added to cart, etc…?
• What % of available documents are being downloaded?
• What % of BOPIS products are picked up in store?
• What % of all campaign codes are being clicked?
• What % of all content items are viewed?
• What % of available videos are viewed?
• What % of all blog posts are viewed?

As you can see, there are many possibilities, depending upon the goals of your digital property. However, Adobe Analytics (and other digital analytics tools), only capture data for items that get “hits” in the date range you select. They are not clairvoyant and able to figure out the total sum of available items. For example, if you wanted to see what % of all campaign tracking codes had at least one click this month, Adobe Analytics can show you how many had at least one click, but it has no way of determining what the denominator should be, which is the total number of campaign codes you have purchased. If there are 1,000 campaign codes that never receive a click in the selected timeframe, as far as Adobe Analytics is concerned, they don’t exist. However, the following will share some ways that you can rectify this problem and calculate the penetration % for any Adobe Analytics dimension.

Calculating Dimension Penetration %

To calculate the dimension penetration %, you need to use the following formula:

For example, if you wanted to see what % of all blog posts available have had at least one view this month, you would calculate this by dividing the unique count of viewed blog posts by the total number of blog posts that could have been viewed. To illustrate this, let’s go through a real scenario. Based upon what was learned in the preceding post, you now know that it is easy to determine the numerator (how many unique blog posts were viewed) as long as you are capturing the blog post title or ID in an Adobe Analytics dimension (eVar or sProp). This can be done using the Approximate Count Distinct function like this:

Once this new Calculated Metric has been created, you can see how many distinct blog posts are viewed each day, week, month, etc…

So far, so good! You now have the numerator of the dimension penetration % formula completed.  Unfortunately, that was the easy part!

Next, you have to figure out a way to get the denominator. This is a bit more difficult and I will share a few different ways to achieve this. Unfortunately, finding out how many dimension values exist (in this scenario, total # of available blog posts), is a manual effort. Whether you are trying to identify the total number of blog posts, videos, campaign codes, etc. you will probably have to work with someone at your company to figure out that number. Once you find that number, there are two ways that you can use it to calculate your dimension penetration %.

Adobe ReportBuilder Method

The first approach is to add the daily total count of the dimension you care about to an Excel spreadsheet and then use Adobe ReportBuilder to import the Approximate Count Distinct Calculated Metric created above by date. By importing the Approximate Count Distinct metric by date and lining it up with your total numbers by date, you can easily divide the two and compute the dimension penetration % as shown here:

In this case the items with a green background were inputted manually and mixed with an Adobe Analytics data block. Then formulas were added to compute the percentages.

However, you have to be careful not to SUM the daily Approximate Count numbers since the sum will be different than the Approximate Count of the entire month. To see an accurate count of unique blog posts viewed in the month of April, for example, you would need to create a separate data block like this:

Data Sources Method

The downside of the Adobe ReportBuilder method is that you have to leave Adobe Analytics proper and cannot take advantage of its web-based features like Dashboards, Analysis Workspace, Alerts, etc. Plus, it is more difficult to share the data with your other users. If you want to keep your users within the Adobe Analytics interface, you can use Data Sources. Shockingly, Data Sources has not changed that much since I blogged about in back in 2009! Data Sources is a mechanism to import metrics that don’t take place online into Adobe Analytics. It can be used to upload any number you want as long as you can tie that number to a date. In this case, you can use Data Sources to import the total number of dimension items that exist on each day.

To do this, you need to use the administration console to create a new Data Source. There is a wizard that walks you through the steps needed, which include creating a new numeric success event that will store your data. The wizard won’t let you complete the process unless you add at least one eVar, but you can remove that from the template later, so just pick any one if you don’t plan to upload numbers with eVar values. In this case, I used Blog Post Author (eVar3) in case I wanted to break out Total Blog Posts by Author. Here is what the wizard should look like when you are done:

Once this is complete, you can download your template and create an FTP folder to which you will upload files. Next, you will create your upload file that has date and the total number of blog posts for each date. Again, you will be responsible for identifying these numbers. Here is what a sample upload file might look like using the template provided by Adobe Analytics:

Next, you upload your data via FTP (you can read how to do this by clicking here). A few important things to note are that you cannot upload more than 90 days of data at one time, so you may have to upload your historical numbers in batches. You also cannot data for dates in the future, so my suggestion would be to upload all of your historical data and then upload one row of data (yesterday’s count) each day in an automated FTP process. When your data has successfully imported, you will see the numbers appear in Adobe Analytics just like any other metrics (see below). This new Count of Blog Posts metric can also be used in Analysis Workspace.

Now that you have the Count of Blog Posts that have been viewed for each day and the count of Total Blog Posts available for each day, you can [finally] create a Calculated Metric that divides these two metrics to see your daily penetration %:

This will produce a report that looks like this:

However, this report will not work if you change it to view the data by something other than day, since the Count of Blog Posts [e8] metric is not meant to be summed (as mentioned in the ReportBuilder method). If you do change it to report by week, you will see this:

This is obviously incorrect. The first column is correct, but the second column is drastically overstating the number of available blog posts! This is something you have to be mindful of in this type of analysis. If you want to see dimension penetration % by week or month, you would have to do some additional work. Let’s look at how you can view this data by week (special thinks to Urs Boller who helped me with this workaround!). One method is to identify how many dimension items existed yesterday and use that as the denominator. Unfortunately, this can be problematic if you are looking at a long timeframe and if there are many additional items added. But if you want to use this approach, you can create this new Calculated Metric to see yesterday’s # of blog posts:

Which produces this report:

As you can see, this approach treats yesterday’s total number as the denominator for all weeks, but if you look above, you will see that the first week only had 1,155 posts, not 1162. You could make this more precise by adding an IF statement to the Calculated Metric and use a weekly number or if you are crazy, add 31 IF statements and grab the exact number for each date.

The other approach you can take is to simply divide the incorrect summed Count of Blog Posts [e8] metric by 7 for week and 30 for month. This will give you an average number of blog posts that existed and will look like this:

This approach has pretty similar penetration % numbers as the other approach and will work best if you use full weeks or full months (in this case, I started with the first full week in January).

Automated Method (Advanced)

If you decide that finding out the total # of items for each dimension is too complicated (or if you are just too busy or lazy to find it!), I will demonstrate an automated approach to find out this information. However, this approach will not be 100% accurate and can only be used for dimension items that will be persistent on your site from the day they are added. For example, you cannot use the following approach to identify the total # of campaign codes, since they come and go regularly.  But you can use the following approach to estimate the total # of values for items that, once added, will probably remain like files, content items or blog posts (as in this example).

Here is the approach. Step one is to create a date range that spans all of your analytics data like this:

You will also want to create another Date Range for the time period you want to see for recent activity. In this case, I created one for the Current Month To Date.

Next, create Segments for both of these Date Ranges (All Dates & Current month to Date):

Next, create a new Calculated Metric that divides the Current Month Approximate Count Distinct of Blog Posts by the All Dates Approximate Count Distinct of Blog Posts:

Lastly, create a report like this in Analysis Workspace:

By doing this, you are letting Adobe Analytics tell you how many dimension items you have (# of total blog posts in this case) by seeing the Approximate Count Distinct over all of your dates. The theory being that over a large timeframe all (or most) of your dimension items will be viewed at least once. In this case, Adobe Analytics has found 1,216 blog posts that have received at least one view since 1/1/16. As I stated earlier, this may not be exact, since there may be dimension items that are never viewed, but this approach allows you to calculate dimension penetration % in a semi-automated manner.

Lastly, if you wanted to adjust this to look at a different time period, you would drag over a different date range container on the first column and then have to make another copy of the 3rd column that uses the same date range as shown in the bottom table:

In Adobe Analytics, there are many advanced functions that can be used in Calculated Metrics. Most of the clients I work with have only scratched the surface of what can be done with these advanced functions. In this post, I want to spend some time discussing the Approximate Count Distinct function in Adobe Analytics and in my next post, I will build upon this one to show some ways you can take this function to the next level!

There are many times when you want to know how many rows of data exist for an eVar or sProp (dimension) value. Here are a few common examples:

• How many distinct pages were viewed this month?
• How many of our products were viewed this month?
• How many of our blog posts were viewed this month?
• How many of our campaign tracking codes generated visits this month?

As you can see, the possibilities are boundless. But the overall gist is that you want to see a count of unique values for a specified timeframe. Unfortunately, there has traditionally not been a great way to see this in Adobe Analytics. I am ashamed to admit that my main way to see this has always been to open the dimension report, scroll down to the area that lets you go to page 2,3,4 of the results and enter 50,000 to go to the last page of results and see the bottom row number and write it down on a piece of paper! Not exactly what you’d expect from a world-class analytics tool! It is a bit easier if you use Analysis Workspace, since you can see the total number of rows here:

To address this, Adobe added the Approximate Count Distinct function that allows you to pick a dimension and will calculate the number of unique values for the chosen timeframe. While the function isn’t exact, it is designed to be no more that 5% off, which is good enough for most analyses. To understand this function, let’s look at an example. Let’s imagine that you work for an online retailer and you sell a lot of products. Your team would like to know how many of these products are viewed at least once in the timeframe of your choosing. To do this, you would simply create a new calculated metric in which you drag over the Approximate Count Distinct function and then select the dimension (eVar or sProp) that you are interested in, which in this case is Products:

Once you save this Calculated Metric, it will be like all of your other metrics in Adobe Analytics. You can trend it and use it in combination with other metrics. Here is what it might look like in Analysis Workspace:

Here you can see the number of distinct products visitors viewed by day for the month of April. I have also included a Visits column to show some perspective. I have also added a new Calculated Metric that divides the distinct count of products by Visits and used conditional formatting to help visualize the data. Here is the formula for the third column:

The same process can be used with any dimension you are interested in within your implementation (i.e. blog posts, campaign codes, etc.)

Combining Distinct Counts With Other Dimensions

While the preceding information is useful, there is another way to use Approximate Distinct Count functions that I think is really exciting. Imagine that you are in a meeting and your boss asks you how many different products each of your marketing campaigns has generated? For example, does campaign X get people to view 20 products and campaign Y get people to view 50 products? For each visit from each campaign, how many products are viewed? Which of your campaigns gets people to view the most products? You get the gist…

To see this, what you really want to do is use the newly created Approximate Count of Products metric in your Tracking Code or other campaign reports. The good news is that you can do that in Adobe Analytics. All you need to do is open one of your campaign reports and add the Calculated Metric we created above to the report like this:

Here you can see that I am showing how many click-throughs and visits each campaign code received in the chosen timeframe. Next, I am showing the Approximate Count of Products for each campaign code and also dividing this by Visit. Just for fun, I also added how many Orders each campaign code generated and divided that by the Approximate Count of Products to see what portion of products viewed from each campaign code were purchased.

You can also view this data by any of your SAINT Classifications. In this case, if you have your campaign Tracking Codes classified by Campaign Name, you can create the same report for Campaign Name:

In this case, you can see that, for example, the VanityURL Campaign generated 19,727 Visits and 15,599 unique products viewed.

At this point, if you are like me you are saying to yourself: “Does this really work?  That seems to be impossible…” I was very suspicious myself, so if you don’t really believe that this function works (especially with classifications), here is a method that Jen Lasser from Adobe told me you can use to check things out:

1. Open up the report of the dimension for which you are getting Approximate Distinct Counts (in this case Products)
2. Create a segment that isolates visits for one of the rows (in the preceding example, let’s use Campaign Name = VanityURL)
3. Add this new segment to the report you opened in step 1 (in this case Products) and use the Instances metric (which in this case is Product Views)
4. Look at the number of rows in Analysis Workspace (as shown earlier in post) or use the report page links at the bottom to go to the last page of results and check the row number (if using old reports) as shown here:

Here you can see that our value in the initial report for “VanityURL” was 15,599 and the largest row number was 15,101, which puts the value in the classification report about 3% off.

Conclusion

As you can see, the use of the Approximate Count Distinct function (link to Adobe help for more info) can add many new possibilities to your analyses in Adobe Analytics. Here, I have shown just a few examples, but depending upon your business and site objectives, there are many ways you can exploit this function to your advantage. In my next post, I will take this one step further and show you how to see how to calculate dimension penetration, or what % of all of your values received at least one view over a specified timeframe.

I am pleased to announce my next Adobe Analytics “Top Gun” class, which will be held May 24th in Chicago.

For those of you unfamiliar with my Adobe Analytics “Top Gun” class, it is a one day crash course on how Adobe Analytics works behind the scenes based upon my Adobe Analytics book. This class is not meant for daily Adobe Analytics end-users, but rather for those who administer Adobe Analytics at their organization, analysts who do requirements gathering or developers who want to understand why they are being told to implement things in Adobe Analytics. The class goes deep into the Adobe Analytics product, exploring all of its features from variables to merchandising to importing offline metrics. The primary objective of the class is to teach participants how to translate every day business questions into Adobe Analytics implementation steps. For example, if your boss tells you that they want to track website visitor engagement using Adobe Analytics, would you know how to do that? While the class doesn’t get into all of the coding aspects of Adobe Analytics, it will teach you which product features and functions you can bring to bear to create reports answering any question you may get from business stakeholders. It will also allow you and your developers to have a common language and understanding of the Adobe Analytics product so that you can expedite getting the data you need to answer business questions.

Here are some quotes from recent class attendees:

I have purposefully planned this class for a time of year where Chicago often has nice weather in case you want to spend the weekend!  There is also a Cubs day game the following day!

To register for the class, click here. If you have any questions, please e-mail me. I hope to see you there!

Each year, I like to let my blog readers know where they can find me, so here is my current itinerary for 2018:

Adobe Summit – Las Vegas (March 27-28)

Once again, I am honored to be asked to speak at the US Adobe Summit. This will be my 13th Adobe Summit in a row and I have presented at a great many of those. This year, I am doing something new by reviewing a random sample of Adobe Analytics implementations and sharing my thoughts on what they did right and wrong. A while ago, I wrote a blog post asking for volunteer implementations for me to review, and I was overwhelmed by how many I received! I have spent some time reviewing these implementations and will share lots of tips and tricks that will help you improve your Adobe Analytics implementations. To view my presentation from the US Adobe Summit, click here.

Adobe Summit – London (May 3-4)

Based upon the success of my session at the Adobe Summit in Las Vegas, I will be coming back to London to present at the EMEA Adobe Summit.  My session will be AN7 taking place at 1:00 pm on May 4th.

DAA Symposium – New York (May 15)

As a board member of the Digital Analytics Association (DAA), I try to attend as many local Symposia as I can. This year, I will be coming to New York to present at the local symposia being held on May 15th. I will be sharing my favorite tips and tricks for improving your analytics implementation.

Adobe Insider Tour (May & September)

I will be hitting the road with Adobe to visit Atlanta, Los Angeles, Chicago, New York and Dallas over the months of June and September. I will be sharing Adobe Analytics tips and tricks are trying something new called Adobe Analytics implementation improv!  Learn more by clicking here.

Adobe Analytics “Top Gun” Training – Chicago/Austin (May 24, October 17)

Each year I conduct my advanced Adobe Analytics training class privately for my clients, but I also like to do a few public versions for those who don’t have enough people at their organization to justify a private class. This year, I will be doing one class in Chicago and one in Austin. The Chicago class will be at the same venue downtown Chicago as the last two years. The date of the class is May 24th (when the weather is a bit warmer and the Cubs are in town the next day for an afternoon game!). You can register for the Chicago class by clicking here.

In addition, for the first time ever, I will be teaming up with the great folks at DA Hub to offer my Adobe Analytics “Top Gun” class in conjunction with DA Hub! My class will be one of the pre-conference training classes ahead of this great conference. This is also a great option for those in the West Coast who don’t want to make the trek into Chicago. To learn more and register for this class and DA Hub, click here.

Marketing Evolution Experience & Quanties  – Las Vegas (June 5-6)

As you may have heard, the eMetrics conference has “evolved” into the Marketing Evolution Experience. This new conference will be in Las Vegas this summer and will also surround the inaugural DAA Quanties event. I will be in Vegas for both of these events.

ObservePoint Validate Conference – Park City, Utah (October 2-5)

Last year, ObservePoint held its inaugural Validate conference and everyone I know who attended raved about it. So this year, I will be participating in the 2nd ObservePoint Validate conference taking place in Park City, Utah. ObservePoint is one of the vendors I work with the most and they definitely know how to put on awesome events (and provide yellow socks!).

DA Hub – Austin (October 18-19)

In addition to doing the aforementioned training at the DA Hub, I will also be attending the conference itself. It has been a few years since I have been at this conference and I look forward to participating in its unique “discussion” format.

For the past seven years (and many years prior to that while at Omniture!), I have reviewed/audited hundreds of Adobe Analytics implementations. In most cases, I find mistakes that have been made and things that organizations are not doing that they should be. Both of these issues impede the ability of organizations to be successful with Adobe Analytics. Poorly implemented items can lead to bad analysis and missed implementation items represent an opportunity cost for data analysis that could be done, but isn’t. Unfortunately, most organizations “don’t know what they don’t know” about implementing Adobe Analytics, because the people working there have only implemented Adobe Analytics oncee, or possibly two times, versus people like me who do it for a living. In reality, I see a lot of the same common mistakes over and over again and I have found that showing my clients what is incorrect and what can be done instead is a great way for them to learn how to master Adobe Analytics (something I do in my popular Adobe Analytics “Top Gun” Class).

Therefore, at this year’s Adobe Summit in Las Vegas, I am  going to try something I haven’t done in any of my past Summit presentations. This year, I am asking for volunteers to have me review your implementation (for free!) and share with the audience a few things that you either need to fix or net new things you could do to improve your Adobe Analytics implementation. In essence, I am offering to do a free review of your implementation and give you some free consulting! The only catch is that when I share my advice, it will be in front of a live audience so that they can learn along with you. In doing this, here are some things I will make sure of:

• I will work with my volunteers to make sure that no confidential data is shown and will share my findings prior to the live presentation
• I will not do anything to embarrass you about your current implementation. In fact, I have found that most of the bad things I find are implementation items that were done by people who are no longer part of the organization, so we can blame it on them 😉
• I will attempt to review a few different types of websites so multiple industry verticals are represented
• You do not have to be at Adobe Summit for me to review your implementation

So….If you would like to have me do a free review of your implementation, please send me an e-mail or message me via LinkedIn and I will be in touch.

Most websites have specific conversion goals they are attempting to achieve. If you manage a retail site, it may be orders and revenue. Conversely, if you don’t sell products, you might use visitor engagement as your primary KPI. Regardless of the purpose of your website (or app), having a good experience and having people like you and your brand is always important. It is normally a good thing when people use your site/product/app and recommend it to others. One method to capture how often people interacting with your site/brand/app have a good experience is to use Net Promoter Score (NPS). I assume that if you are a digital marketer and reading this, you are already familiar with NPS, but in this post, I wanted to share some ways that you can incorporate NPS scoring into Adobe Analytics.

NPS

The easiest way to add NPS to your site or app is to simply add a survey tool that will pop-up a survey to your users and ask them to provide an NPS. My favorite tool for doing this is Hotjar, but there are several tools that can do this.

Once your users have filled out the NPS survey, you can monitor the results in Hotjar or whichever tool you used to conduct the survey.

But, if you also want to integrate this into Adobe Analytics, there is an additional step that you can take. When a visitor is shown the NPS survey, you can to capture the NPS data in Adobe Analytics as well. To start, you would pass the survey identifier to an Adobe Analytics variable (i.e. eVar). This can be done manually or using a tag management system. In this case, let’s assume that you have had two NPS submissions with scores of 7 and 4. Here is what the NPS Survey ID eVar report might look like:

At the same time, you can capture any verbatim responses that users submit with the survey (if you allow them to do this):

This can be done by capturing the text response in another Adobe Analytics variable (i.e. eVar), which allows you to see all NPS comments in Adobe Analytics and, if you want, filter them by specific search keywords (or, if you are low on eVars, you could upload these comments as a SAINT Classification of the NPS Survey ID). Here is what the NPS Comments eVar report might look like when filtered for the phrase “slow:”

Keep in mind that you can also build segments based upon these verbatim comments, which is really cool!

Trending NPS in Adobe Analytics

While capturing NPS Survey ID’s and comments is interesting, you probably want to see the actual NPS scores in Adobe Analytics as well. You can do this by capturing the actual NPS value in a numeric success event in Adobe Analytics when visitors submit the NPS survey. You can also set a counter success event for every NPS survey submission, which allows you to create a calculated metric that shows a trend of your overall NPS.

First, you would setup the success events in the Adobe Analytics administration console:

Let’s look at this using the previously described example. When the first visitor comes to your site and completes an NPS survey with a score of 7, you would set the following upon submission:

s.events="event20=1,event21=7";

When the second visitor completes an NPS survey with a score of 4, you would set the following:

s.events="event20=1,event21=4";

Next, you can build a calculated metric that computes the your overall NPS. Here is the standard formula for computing NPS using a scale of 1-10:

In our scenario, the NPS would be -50, since we had one detractor and no promoters, computed as ((0-1)/2) x 100 = -50.

To create the NPS metric in Adobe Analytics, you first need to create segments to isolate the number of Promotors and Detractors you have in your NPS surveys. This can be done by building a segment for Promoters…

…and a segment for Detractors:

Once these segments have been created, they can be applied to the following calculated metric formula in Adobe Analytics:

Once you have created this calculated metric, you would see a trend report that looks like this (assuming only the two visitors mentioned above):

This report only shows the two scores from one day, so if we pretend that the previous day, two visitors had completed NPS surveys and provided scores of 9 & 10 respectively (a score of 100), the daily trend would look like this:

If we looked at the previous report with just two days (November 3rd & 4th) for a longer duration (i.e. week, month, year), we would see the aggregate NPS Score:

In this case, the aggregate NPS score for the week (which in this case just includes two days) is 25 computed as: ((2 Promoters – 1 Detractor)/4 Responses) x 100 = 25.

If we had data for a longer period of time (i.e. October), the trend might look like this (shown in Analysis Workspace):

And if we looked at the October data set by week, we would see the aggregate NPS (shown in Analysis Workspace):

Here we can see that there is a noticeable dip in NPS around the week of October 22nd. If you break this down by the NPS Comments eVar to see if there may be comments telling us why the scores dipped:

In this case, the comments let us know that the blog portion of the website was having issues, which hurt our overall NPS.

One side note about the overall implementation of this. In the preceding scenario I built the NPS as a calculated metric, but I could have also used the Promoter and Detractor segments to create two distinct calculated metrics (Promoters and Detractors)…

…which would allow me to see a trend of Promoters (or Detractors) over time:

Alternatively, you could also choose to set success events for Promoter Submissions and Detractor Submissions (in real-time) instead of using a segment to create these metrics. Doing this would require using three success events instead of two, but would remove the need for the segments, but the results would be the same.

Summary

As you can see, this is a fair amount of work. So why would you want to do all of this if you already have NPS data in your survey tool (i.e. Hotjar)? For me, having NPS data in Adobe Analytics provides the following potential additional benefits:

• Build a segment of sessions that had really good or really bad NPS scores and view the specific paths visitors have taken to see if there are any lessons to be learned
• Build a segment of sessions that had really good or really bad NPS scores and see the differences in cart conversion rates
• Look at the retention of visitors with varying NPS scores
• Identify which marketing campaigns are producing visitors with varying NPS scores
• Easily add NPS trend to an existing Adobe Analytics dashboard
• Easily correlate other website KPI’s with NPS score to see if there are any interesting relationships (i.e. does revenue correlate to NPS score?)
• Use NPS score as part of contribution analysis
• Create alerts for sudden changes in NPS
• Identify which [Hotjar] sessions (using the captured Survey ID) for which you want to view recordings based upon behavior found in Adobe Analytics

These are just some ideas that I have thought about for incorporating NPS into your Adobe Analytics implementation. If you have any other ideas, feel free to leave a comment here.

Due to a special request, I will be doing an unexpected/unplanned Adobe Analytics “Top Gun” class in Minneapolis, MN on December 7th. To register, click here.

For those of you unfamiliar with my Adobe Analytics “Top Gun” class, it is a one day crash course on how Adobe Analytics works behind the scenes based upon my Adobe Analytics book. This class is not meant for daily Adobe Analytics end-users, but rather for those who administer Adobe Analytics at their organization, analysts who do requirements gathering or developers who want to understand why they are being told to implement things in Adobe Analytics. The class goes deep into the Adobe Analytics product, exploring all of its features from variables to merchandising to importing offline metrics. The primary objective of the class is to teach participants how to translate every day business questions into Adobe Analytics implementation steps. For example, if your boss tells you that they want to track website visitor engagement using Adobe Analytics, would you know how to do that? While the class doesn’t get into all of the coding aspects of Adobe Analytics, it will teach you which product features and functions you can bring to bear to create reports answering any question you may get from business stakeholders. It will also allow you and your developers to have a common language and understanding of the Adobe Analytics product so that you can expedite getting the data you need to answer business questions.

Here are some quotes from recent class attendees:

To register for the class, click here. If you have any questions, please e-mail me. I hope to see you there!

Many years ago, I wrote a post about shopping cart persistence based upon a query from a client. That post showed how to see how long items had been in the cart and a few other things. In this post, I am going to take a different slant and talk about how you can see which items are persisting in the cart and whether visitors are purchasing products they have persisted in the shopping cart.

What’s Persisting In The Cart?

The first step is to identify what items are persisting in the shopping cart when visitors arrive at your site. To do this, you can set a success event on the 1st page of the session (let’s call it Persistent Cart Visits) and then set the Products variable with each product that is in the cart.

s.events=”event95″;
s.products=”;blue polo shirt,;soccer ball”;

This will allow you to easily report upon which products are most often in the cart when visits begin:

This data can also be trended over time to see if there are certain products that are frequently persisting in the cart and you can merge this data with product cost information to see potential missed opportunities for revenue. This data can also be useful for re-marketing efforts, like offering a coupon or discount on items left in the cart. You can also use Date Range segments to see which products added to the cart last week (for example) were viewed as a persistent cart this week.

Compare Cart Persistence to Orders

Once you have the preceding items tagged, you can look to see how often any of the products that were persisting in the cart were purchased. One way to do this is to use the Products report to compare Persistent Cart Visits and Orders. This will allow you to see a ratio of orders per persistent cart visits (by product):

This allows you to see which products are getting purchased and you can break this report down by campaign to see if any of your re-marketing efforts are leading to success.

General Persistent Cart Conversion

Another approach to cart persistence is understanding, in general, how often cart persistence leads to conversion. Using the calculated metric shown above by itself, you can easily see the cart persistence conversion rate over time:

Alternatively, you can use segmentation to isolate visits that had an order AND had items in the cart when the visit began. This can be done by creating a success event using the Orders and Persistent Cart Visits success events:

Once this segment is created, it can be added to a Visits metric or Revenue metric or any other number of items to create some interesting derived calculated metrics.

Of course, you can also create product-specific segments to see how often visitors are purchasing a specific product that they have persisted in the cart by adding the Products variable to the preceding segment like this:

Advanced Cart Persistence

If you like this concept and want to take it to the “Top Gun” level, here is another cool use case you can try out. When visitors come to your site and have an item persisting in their cart, have your developers note which products were in the cart (same list passed to the Products variable above). Next, wait until visitors complete an order on the site and look at the persistent cart product list and if any of the products purchased were in the persistent cart list, track that via a Merchandising eVar (as a flag). At the same time, you can add two new success events (Persistent Cart Orders and Persistent Cart Revenue) in the Products string as well:

 s.events=”purchase,event110.event111″;
s.products=”;blue polo shirt;1;50;event110=1|event111=50;evar90=persistent-cart,;blue purse;1;45″;

In this example, the customer is purchasing two items, but only one was a result of the persistent cart. By setting a flag in the Merchandising eVar and two new success events, we can isolate the specific product that was attributed to the persistent cart and see a count of Orders and Revenue resulting from cart persistence. Once this is done, you can trend Persistent Cart Orders and Revenue and even compare those metrics to total Orders and Revenue to see what % of Orders and Revenue is due to cart persistence.

Another super-cool thing you can do is use the new Analysis Workspace Cohort Analysis visualization to compare Cart Additions and Persistent Cart Orders to see what % of people adding items to the cart come back to order items in the cart.

Unfortunately, since you cannot yet use derived calculated metrics in Cohort Analysis, you may get some extraneous data you don’t want in the Cohort table (i.e. people purchasing multiple items and only some being due to cart persistence), but it should still give you some interesting data (and maybe one day Adobe will allow calculated metrics in Cohort Analysis!).

In summary, there are lots of cool ways you can measure shopping cart persistence. These are just a few of them. If you have any other ways you have done this, feel free to leave a comment here.  Thanks!

A while back I ask folks to fill out a form if they were interested in me doing one of my Adobe Analytics “Top Gun” classes locally. and soon after, I had many European folks fill out the form! Therefore, this October 19th I will be conducting my advanced Adobe Analytics class in London. This will likely be the last time I offer this class in Europe for a while, so if you are interested, I encourage you to register before the spots are gone.

For those of you unfamiliar with my Adobe Analytics “Top Gun” class, it is a one day crash course on how Adobe Analytics works behind the scenes based upon my Adobe Analytics book. This class is not meant for daily Adobe Analytics end-users, but rather for those who administer Adobe Analytics at their organization, analysts who do requirements gathering or developers who want to understand why they are being told to implement things in Adobe Analytics. The class goes deep into the Adobe Analytics product, exploring all of its features from variables to merchandising to importing offline metrics. The primary objective of the class is to teach participants how to translate every day business questions into Adobe Analytics implementation steps. For example, if your boss tells you that they want to track website visitor engagement using Adobe Analytics, would you know how to do that? While the class doesn’t get into all of the coding aspects of Adobe Analytics, it will teach you which product features and functions you can bring to bear to create reports answering any question you may get from business stakeholders. It will also allow you and your developers to have a common language and understanding of the Adobe Analytics product so that you can expedite getting the data you need to answer business questions.

Here are some quotes from recent class attendees:

To register for the class, click here. If you have any questions, please e-mail me. I hope to see you there!

Recently, I had a client ask me about content freshness on their site. In this case, the client wanted to know if the content on their site was going stale after a few days or weeks so they could determine when to pull it off the site. While the best way to use what I will show is on a site that has a LOT of content and new content on a regular basis (like a news site), in this post, I will demonstrate the concept using our blog, which is all I can share publicly.

Step 1 – Set Dates

The first step in seeing how long it takes your users to interact with your content is to capture the number of days between the content publish date and the view date. To do this, you can add an eVar that subtracts the current date from the content publish date. For example, if I look at one of my old blog posts today, I can see in eVar10 the number of days after it was posted that I am viewing it:

In this case, the value of “13” is being passed to the eVar, which tells Adobe Analytics that the post being viewed is 13 days old. Once you have done this, you will see a report like this in Adobe Analytics:

If I break down the “13” row, I will see that it represents the previously shown blog post and if any other posts were published on the same date, they would appear also:

Step 2 – Classify Dates

However, the above report is pretty ugly and way too granular for analysis! Therefore, you can then apply SAINT Classifications to the number of days and make the report a bit more readable. Here is an example of the SAINT file that I used:

Keep in mind that you can pre-classify the number of days ahead of time (I went up to 20,000 to be safe) so that you only have to upload this once.

Next, you can open the classification report and see this, which is much more manageable and can be trended:

Step 3 – Reporting

In this case, I decided to create a data block in Adobe ReportBuilder to see data on a daily/trended basis. Here is what the data block looked like:

This produced a report like this:

Which I then graphed like this:

using Excel pivot tables, you can group the data any way you’d like once you have the data in Excel.

Lastly, you can also use the Cohort Analysis feature of Analysis Workspace to get a different view on how your content is being used:

Last week, I described how to track product and non-product click-through rates in Adobe Analytics. This was done via the Products variable and Merchandising eVars. In this post, I will take it a step further and explain how to view click-through rates by placement location. I suggest you read the last post before this one for continuity sake.

Placement Click-Through Rates

In my preceding post, I showed how to see the click-through rate for products by setting two success events and leveraging the products variable. As an example, I showed a page that listed several products like this:

To see click-through rates, you would set the following code on the page showing the products to get product impressions:

s.events=”event20″;
s.products=”;11345,;11367,;12456,;11426,;11626,;15522,;17881,;18651″;

Then, when visitors click on a product, you would set code like this:

s.events=”event21″;
s.products=”;11345″;

Then you can create a click-through rate calculated metric and produce a report that looks like this:

However, what if you wanted to see the click-through rate of each product based upon its placement location? For example, you can see above that product# 11345 has a click-through rate of 26.97%, but how much does this click-through rate depend upon its location? How much better does it perform if it is in Row 1 – Slot 1 vs. Row 2 – Slot 3? To understand this, you have to add another component to the mix – Placement.

To do this, you can add a new Merchandising eVar that captures the Placement details and set it in the merchandising slot of the Products string like this:

s.events=”event20″;
s.products=”;11345;;;;evar30=Row1-Slot1,;11367;;;;evar30=Row1-Slot2,;12456;;;;evar30=Row1-Slot3,;11426;;;;evar30=Row1-Slot4,;11626;;;;evar30=Row2-Slot1,;15522;;;;evar30=Row2-Slot2,;17881;;;;evar30=Row2-Slot3,;18651;;;;evar30=Row2-Slot4″;

As you can see, the string is the same as before, just with the addition of a new merchandising eVar30 for each product value. This tells Adobe Analytics that each impression (event20) should be tied to both a product and a placement. And since the product and placement are in the same portion of the product string, there is an additional connection made between the specific product (i.e. 11345) and the placement (i.e. Row1-Slot1) for each impression. This allows you to perform a breakdown between product and placement (or vice-versa), which I will demonstrate later.

If a visitor clicks on a product, you would set the click event and capture the product and placement in the Products string:

s.events=”event21″;
s.products=”;11345;;;;evar30=Row1-Slot1″;

In theory, you don’t need to set the merchandising eVar again on the click, since it can persist, but there is no harm in doing so if you’d like to be sure.

Once this is done, you can break down the any product in the preceding report by its placement and use the click-through rate calculated metric to see click-through rates for each product, by placement location. In addition, since each impression and click is also associated with a placement, you can also see impressions, clicks and the click-through rate for each placement by using the merchandising eVar on its own. Here is what the eVar30 report might look like:

This allows you to see placement click-through rates agnostic of what was shown in the placement. Of course, if you want to break this down by product, you can do that to see a report like this:

Lastly, one other cool thing you can do with this is to view click-through rates by placement row and column using SAINT Classifications. In the report above that shows click-through rates by Row & Slot (the one with 8 rows), you can easily classify each of these rows by row and column (slot). For example, the first four rows would all be grouped into “Row 1” and another classification would group rows 1 & 5, 2 & 6, 3 & 7 and 4 & 8 into four column (slot) values. This would allow you to see click-through rate by row and column with no additional tagging.

Another cool thing you can do is to embed a page identifier in the placement string passed to the merchandising eVar. This is helpful if you want to see how click-through rates differ if products are shown on page A vs. Page B. To do this, simply pre-pend a page identifier before the “Row1-Slot1” values, which can then be filtered or classified using SAINT. For example, you might change the value above to “shoe-landing:Row1-Slot1” in the merchandising eVar value. This would break out the Row1-Slot1 values by page and give you additional data for analysis. The only catch here is that you want to be careful about what data you pass during the click portion of the tagging, as you either want to leave the merchandising eVar value blank (to inherit the previous value with the page of the impression) or you want to set it with the value of the previous page so your impressions and clicks are both associated with the same page. If you are tracking impressions and clicks for things other than products (Ferguson example in my previous post), you can either include the placement in the merchandising eVar string or you can set a second merchandising eVar (like shown above) to capture the placement.

Hence, with the addition of one merchandising eVar, you can see click-through rates by placement, product & placement, placement & product, row, column and page.

One of the more advanced things you can do with Adobe Analytics is to track click-through rates of elements on your web pages. Adobe Analytics doesn’t do this out of the box, but if you know how to use the tool, there are some creative ways that you can add click-through rate tracking to your implementation. In this post, I will share a few different ways to track click-throughs for both products and non-product items.

Product Click-Through Rates

If you sell physical products, you may have pages that show a bunch of products and want to see how often each product is viewed, clicked and the click-through rate. In my Adobe Analytics book, I show an example of a product listing page like this:

If you worked for this company, you might want to know how often each product is shown and clicked, keeping in mind that this could be dynamic due to tests you are running or personalization tools. Luckily, this is pretty easy to do in Adobe Analytics because the Products variable allows you to capture multiple products concurrently. In this case, you would simply set a “Product Impressions” success event and then list out all of the products visible on the page via the Products variable like this:

s.events=”event20″;
s.products=”;11345,;11367,;12456,;11426,;11626,;15522,;17881,;18651″;

Then, if a visitor clicks on one of the products, on the next page, you would set a “Product Clicks” success event and capture the specific product that was clicked in the Products variable:

s.events=”event21″;
s.products=”;11345″;

Once this is done, you can open the Products report and view impressions and clicks for each product. In addition, you can create a new calculated metric that divides Product Clicks by Product Impressions to see the click-through rate of each product:

This report allows you to see how each product performs and can also be trended over time. Additionally, once the click-through rate calculated metric has been created, you can use that metric by itself to see the overall product click-through rate like this:

Non-Product Click-Through Rates

There may be times that you want to see click-through rates for things that are not products. Some examples might include internal website promotions, news story links on a home page or any other important links on key pages. In these cases, you could use the previously described Products variable approach, I don’t recommend it. Using the Products variable for these non-product items would result in many (hundreds or thousands) of non-product values being passed to the Products variable, which is not ideal. It is best if you keep your Products variable for products so you don’t confuse your users.

When I ask Adobe Analytics power users in my Adobe Analytics “Top Gun” class how they would track click-through rates, the most frequent response I get (after the Products variable) is to use a List Var. For those unfamiliar, a List Var is an eVar that can collect multiple values when they are passed in with a delimiter, similarly to how the Products variable is used. On the surface, it makes sense that you can follow the same approach outlined above using a List Var, but unfortunately, this is not always the case. To illustrate why, I will use an example from a company that faced this problem and used a creative solution to it. Ferguson is a plumbing supplies company that displays its main product categories on the home page. They wanted to see the click-through rate of each, but this got complicated because once a visitor clicked on one of the categories, they were taken to a page that had product sub-categories and they also wanted to see impressions of those! So, on the first page, they wanted impressions and then on the second page they wanted to capture the click of the item from the first page, but at the same time capture impressions for more items on the second page! This illustrates why the List Var is not always good for tracking click-through rates. If they were to try and use a List Var, we could easily track impressions on the first page, but what would we do on the second page? It isn’t possible to tell the same List var to collect the ID of the item clicked on the first page AND the list of items getting impressions on the second page. If you passed all of items at the same time, the success events you set (Clicks and Impressions) would be attributed to both and all of your data would be wrong! You could use multiple List Vars, but then you’d have to use two different reports to see impressions and clicks, which makes things very difficult and time consuming. You could also fire off extra server calls when things are clicked, but that can get really expensive!

Therefore, my rule of thumb is that if you want to see impressions and clicks of products, use the Products variable and if you want to see impressions and clicks for non-product items, only use a List Var if there are no items on the page visitors get to after clicking that require impressions themselves. But what if you do want impressions on the subsequent page like Ferguson did? This is where you have to be a bit more advanced in your use of Adobe Analytics as I will explain next.

Advanced Click-Through Rate Tracking (Experts Only!)

The following gets a bit complex, so if you aren’t an Adobe Analytics expert, be forewarned that your head might spin a bit!

As mentioned above, you have solved 2/3 of your impression and click tracking problems – products and non-products where there are no impressions on the subsequent page. Now you are left with the situation that Ferguson faced when they had impressions on both pages. To solve this, you have to use the Product Merchandising feature of Adobe Analytics. This is because you need to find a way to assign impression events and click events on the same page, which means you need to set your success events in the product string so you can be very deliberate about which items get impressions and which get clicks. However, as I started earlier, you don’t want to pass hundreds of non-product items to the Products variable, but you cannot use Merchandising without setting products (I warned you this was advanced stuff!).

To solve this dilemma, you can set two “fake” products and use the Product Merchandising feature to document which non-product items are getting impressions and clicks. By using the Merchandising slot of the Products string in combination with the success events slot of the Products string, you can line up impressions and clicks with the correct values. To illustrate this, let’s look at an example from Ferguson’s website. If you use the Adobe Debugger on the home page, you will see the following in the Products variable:

While this looks pretty intimidating, if you break it down into its parts, it isn’t that bad. First, you will see that a “fake” product named “int_cmp_imp” is being passed to the Products variable once for each item that gets an impression. This means that instead of hundreds of products being added, only one is added to the Products report. Next, in the success event slot of the Products string, you will see that event40 is being incremented by 1 for each item receiving an impression. Next you will see that the actual item receiving the impression is captured in a product syntax merchandising eVar18. For example, the first one captured is “mrch_hh_kob_builder” (you can put whatever values you want here). Then the same approach is repeated once for every item receiving an impression on the page. By setting event40 and eVar18 together, each eVar18 value will increase by one impression upon page load (note: that the “fake” product will receive impressions as well, but we probably will just disregard that).

While this may seem like overkill for this type of tracking, this approach will begin to pay dividends when the user clicks on one of the items and reaches the next page. On the next page, you need to set impressions for all of the new items shown on that page AND set a click for the item clicked on the previous page. Here is what it might look like:

Notice here that the beginning of this string is exactly the same as the first page with the “fake” product of “int_cmp_imp” being set for each item as well as the impression event40 and the item description in eVar18. The key difference here is highlighted in red in which a new product is set “int_cmp_clk” and a new click event41 is incremented by 1 at the same time as eVar18 is set to the item that was clicked on the previous page. The beauty of using the Products variable and Product Merchandising is that you can set both impressions and clicks in the same in the same Products string, while at the same time only adding two new products to the overall Products report.

When you look at the data in Adobe Analytics, you can now add your impressions event (event40), your clicks event (event41) and add a calculated metric to see the click-through rate:

Final Thoughts

By using a combination of success events, the Products variable and, in some cases, Product Merchandising, it is possible to see how often specific items receive impressions, clicks and the resulting click-through rate. There may be some cases in which you have a large number of items for which you want to see impressions and clicks and in those cases, I suggest checking with Adobe Client Care on any limitations you may run into and, as always, be cognizant of how tagging can impact page load speeds. But if you have specific items for which you have always wanted to see click-through rates, feel free to try out one of the techniques described above.

This past May, I conducted my annual Adobe Analytics “Top Gun” classes to a packed room in Chicago. I always love doing this class because it helps the attendees get more out of Adobe Analytics when they get back to their organizations. I have done this class in Europe several times and usually once a year in the US. The feedback has been tremendous as can be seen by some of the reviews on LinkedIn shown below.

However, I often get requests to do my class in various cities across the US (and the world), but I don’t have the time to orchestrate doing that many trainings per year. To conduct a class, I need a minimum of 15 people and the cost of the class is about $1,250 per person for the full one-day class. I also need to find a free venue to conduct the class, which is often at a company that has a large conference room or a training room.

Since I would like to do more classes, but am time constrained, I am going to try something new this year.  I am going to let anyone out there bring my “Top Gun” class to their city by asking you to help host my class.  If you have a venue where I can conduct my Adobe Analytics “Top Gun” class, and you think you can work with your local Adobe Analytics community to get at least 10 people to commit (I can usually get a bunch once I advertise the class), I am happy to hit the road and come to you and conduct a class. So if you are interested in hosting my “Top Gun” class, please e-mail me and let’s discuss. I also conduct my class privately for companies that have enough people wanting to attend to justify the cost, so feel free to reach out to me about that if interested as well.

To help identify cities that are interested (or if you just want to be notified of my next class), I have created a Google Form where anyone can submit their name, e-mail and City/Region, so if you are interested in having my “Top Gun” class in your city, please submit this form!

In case you need help selling the class to your local folks, more info about the class follows.

Adobe Analytics “Top Gun” Class Description

It is a one day crash course on how Adobe Analytics works behind the scenes based upon my Adobe Analytics book. This class is not meant for daily Adobe Analytics end-users, but rather for those who administer Adobe Analytics at their organization, analysts who do requirements gathering or developers who want to understand why they are being told to implement things in Adobe Analytics. The class goes deep into the Adobe Analytics product, exploring all of its features from variables to merchandising to importing offline metrics. The primary objective of the class is to teach participants how to translate every day business questions into Adobe Analytics implementation steps. For example, if your boss tells you that they want to track website visitor engagement using Adobe Analytics, would you know how to do that? While the class doesn’t get into all of the coding aspects, it will teach you which product features and functions you can bring to bear to create reports answering any question you may get from business stakeholders. It will also allow you and your developers to have a common language and understanding of the Adobe Analytics product so that you can expedite getting the data you need to answer business questions.

Adobe Analytics “Top Gun Class Feedback

To view more feedback, check out the recommendations on my LinkedIn Profile.

Recently, I was working with a client who was interested in seeing how often their internal search results page was the exit page. Their goal was to see how effective their search results were and which search terms were leading to high abandonment. Way back in 2010, I wrote a post about how to see which internal search terms get clicks and which do not, but this question is a bit different from that. So in this post, I will share some thoughts on how to quantify your internal search exit rates in Adobe Analytics.

The Basics

Seeing the general exit rate of the search results page on your site is pretty easy to do simply with the Pages report. To start, simply open the pages report and add the Exits metric to the report and use the search box to isolate your search results page:

Next, you can trend this by changing to the trended view:

But to see the Exit Rate, you need to create a new calculated metric that divides these Exits by the Total # of Visits (keep in mind that you need to use the gear icon to change Visits to “Total”). The calculated metric would look like this:

Once you have this metric, you can change your previous trending view to use this calculated metric (still for the Search Results Page) to see this:

Now we have a trend of the Search Results page exit rate and this graph can be added to a dashboard as needed.

More Advanced

As you can see getting our site search results page exit rate is pretty easy. However, the Pages approach is a bit limiting because it is difficult to view these Search Result page exit rates by search term. For example, if I want to see the trend of Search Result Exit Rates for the term “Bench,” I can create a segment defined as “Hit where Internal Search term = Bench” and apply it to see this:

Here you can see that this search term has a much higher than average Search Result page Exit Rate. But if I want to do this for more search terms, I would have to create many keyword-based segments, which would be very time consuming.

Fortunately, there is another way. Instead of using the Pages report, you can create a new Search Result Page Exit Rate calculated metric that is unrelated to the Pages report. To do this, you would first build a segment that looks for Visits where the Exit Page was “Search Results” as shown here:

Next, you would use this new segment in a new “derived” calculated metric and use it to divide Search Page Exit Visits by all Visits like this:

This would produce a trend that is [almost] identical to the report shown above:

Just as before, this trend line can be added to a dashboard as needed. But additionally, this new calculated metric can be added to your Internal Search Term eVar report to see the different Search Result Page Exit Rates for each term:

This allows you to compare terms and look for ones that are doing well and/or poorly. Whereas before, if you wanted to see a trend for any particular phrase, you had to create a new segment, in this report, you can simply trend the Search Result Page Exit Rate and then pick the internal search terms you want to see trended. For example, here is a trend of “Bench” and “storage bench” seen together:

This means that you can see the Search Page Exit Rate for any term without having to build tons of segments (yay!). And, as you can see, the daily trend of Search Page Exit Rates for “Bench” here are the same as the ones shown above for the Pages version of the metric with the one-off “Bench” segment applied.

One More Thing!

As if this weren’t enough, there is one more thing!  If you sort the Search Term Exit Rate (in descending order) in the Internal Search Term eVar report, you can find terms that have 100% (or really high) exit rates!

This can help you figure out where you need more content or might be missing product opportunities. Of course, many of these will be cases in which there are very few internal searches, so you should probably view this with the raw number of searches as shown above.

For retail/e-commerce websites that sell physical products, one of the worst things that can happen is having your products be out of stock. Imagine that you have done a lot of marketing and campaigns to get people to come to your site, led them to the perfect product, only to find that for some people, you don’t have enough inventory to sell them what they want. Nothing is more frustrating than having customers who want to give you their money but can’t! Often times, inventory is beyond the control of merchandisers, but I have found that monitoring the occurrences of products being out of stock can be beneficial, if for no other reason than, to make sure others at your organization know about it and to apply pressure to avoid inventory shortfalls when possible. In this post, I am going to show you how to monitor instances of products being out of stock and how to quantify the potential financial impact of out of stock products.

Tracking Out of Stock Products

The first step in quantifying the impact of out of stock products is to understand how often each product is out of stock. Doing this is relatively straightforward. When visitors reach a product page on your site, you should already be setting a Product View success event and passing the Product Name or ID to the Products variable. If a visitor reaches a product page for a product that is out of stock, you should set an additional “Out of Stock” success event at the same time as the Product View event. This will be a normal counter success event and should be associated with the product that is out of stock. Once this is done, you can open your Products report and add both Product Views and this new Out of Stock success event and sort by the Out of Stock event to see which products are out of stock the most:

In this example, you can see that the products above are not always out of stock and how often each is out of stock. If you wanted, you could even create an Out of Stock % calculated metric to see the out of stock percent by product using this formula:

This would produce a report that looks like this:

If you have SAINT Classifications that allow you to see products by category or other attributes, you could also see this Out of Stock percent by any of those attributes as well.

Of course, since you have created a new calculated metric, you can also see it by itself (agnostic of product) to see the overall Out of Stock % for the entire website:

In this case, it looks like there are several products that are frequently out of stock, but overall, the total out of stock percent is under two percent.

Tracking Out of Stock Product Amounts

Once you have learned which products tend to be out of stock, you might want to figure out how much money you could be losing due to out of stock products. Since the price of the product is typically available on the product page, you can capture that amount in a currency success event and associate it with each product. For example, if a visitor reaches a product page and the product normally sells for $50, but is out of stock, you could pass $50 to a new “Out of Stock Amount” currency success event. Doing this would produce a report that looks like this:

This shows you the amount of money, by product, that would have been lost if every visitor viewing that product actually wanted to buy it. You can also see this amount in aggregate by looking at the success event independently:

However, these dollar amounts are a bit fake, because it is not ideal to assume a 100% product view to order conversion for these out of stock products and doing so, greatly inflates this metric. Therefore, what is more realistic is to weight this Out of Stock dollar amount by how often products are normally purchased after viewing the product page. This is still not an exact science, but it is much more realistic than assuming 100% conversion.

Fortunately, creating a weighted version of this Out of Stock Amount metric is pretty easy by using calculated metrics. To do this, you simply take the Out of Stock Amount currency success event and divide it by the Order to Product View ratio. This is done by adding a few containers to a new calculated metric as shown here:

Once this metric is created, you can add it to the previous Products report to see this:

In this report, I have added Orders and this new Weighted Out of Stock Amount calculated metric. If you look at row 4, you can see that the total Out of Stock Amount is $348, but that the Weighted Out of Stock Amount is $34. The $34 is calculated by our new metric by dividing the normal product conversion rate (26/268 = 9.70149%) by the total Out of Stock Amount of $348 (348*.0970149=33.76), which means that the $34 amount is much more likely to be the lost value amount for that product. The cool part, is that since each product has different numbers of Orders and Product Views, the discount percent applied to each product is calculated relatively by our new weighted calculated metric! For example, while the Product View to Order conversion ratio for row 4 was 9.7%, the conversion rate for row 10 is only 2.6% (4/154), meaning that only $22 out of the $843 Out of Stock Amount is moved to the Weighted Out of Stock Amount calculated metric. Pretty cool huh?

One Last Problem

Before we go patting ourselves on the back, however, we have one more problem to solve. If you look at the report above, you might have noticed the problem in rows 1,2,3,5,6,8,9. Even though there is a lot of money in the Out of Stock Amount success event, there is no money being applied to the Weighted Out of Stock Amount calculated metric we created. This is due to the fact that there were no Orders for these products, meaning that the conversion rate is zero, which when multiplied by the Out of Stock Amount also results in zero (which hopefully you recall from elementary school). That is not ideal, because now the Weighted Out of Stock Amount is too low and the raw amount in the success event is too high! Unfortunately, our calculated metric above only works when there are Orders during the time range, so we can calculate the average Product View to Order ratio for each product.

Unfortunately, there is no perfect way to solve this without manually downloading a lot of historical data to look for what the Product View to Order ratio was for each product over the past year or two, but the good news is that if you use a large enough timeframe, the cases of zero orders should be relative small. But just in case you do have cases where zero orders exist, I am going to show you an advanced trick that you can use to get the next best thing in your Weighted Out of Stock Amount calculated metric.

My solution for the zero-order issue is to use the average Product View to Order ratio for all cases in which there are zero orders. The idea here is that if the first metric is counting 100% and zero-Order rows are count 0%, why not use the site average for the zero-Order rows? This will not be perfect, but it is far better than using 100% or 0%! To do this, you need to make a slight tweak to the preceding calculated metric. This tweak involves adding an IF statement to first look to see if an Order exists. If it does, the calculated metric should use the formula shown above. But if no Order exists, you will multiply the Out of Stock Amount success event metric by the average (site wide) Order to Product View ratio. This is easy to do by using the TOTAL metrics for Orders and Product Views. While this all sounds complex, here is what the new calculated metric looks like when it is completed:

Next, you simply add this to the previous report to see this:

As you can see, the rows that worked previously are unchanged (rows 4,7,10), but the other rows now have Weighted Out of Stock Amounts. If you divide the total Orders by total Product Views, you can see that the average Order to Product View ratio is 4.21288% (16215/384,891). If you then apply this ratio to any of the Out of Stock Amounts with zero-Orders, you will get the Weighted Out of Stock Amount. For example, row 1 has a value of $286, which is 4.21288% multiplied by $6,786. In this case, you can remove the old calculated metric and just use the new one and as you use longer date ranges, you will have fewer zero order rows and your data will be more accurate.

Of course, since this is a calculated metric, you can always look at it independent of products to see the weighted Out of Stock Amount trended over time:

While this information is interesting by itself, it can also be applied to many other reports you may already have in Adobe Analytics. Here are just some sample scenarios in which knowing how often products are out of stock and a ballpark amount of potential lost revenue could come in handy:

• How much money are we spending on marketing campaigns to drive visitors to products that are out of stock?
• Which of our known customers (with a Customer ID in an eVar) wanted products that were out of stock and can we retarget them via e-mail or Adobe Target later when stock is replenished?
• Which of our stores/geographies have the most out of stock issues and what is the potential lost revenue by store/region

Summary

If your site sells physical products and has instances where products are not in stock, the preceding is one way that you can conduct web analysis on how often this is happening, for which products and how much money you might be losing out on as a result. When this data is mixed with other data you might have in Adobe Analytics (i.e. campaign data, customer ID data, etc.), it can lead to many more analyses that might help to improve site conversion.

I recently had a client of mine ask me how they could report new and retained visitors for their website. In this particular case, the site had an expectation that the same visitors would return regularly since it is a subscription site. At first, my instinct was to use the Cohort Analysis report in Adobe Analytics Workspace, but that only shows which visitors who came to the site came back, not which visitors are truly new over an extended period of time. In addition, it is not possible to add Unique Visitors to a cohort table, so that rules this option out. What my client really wanted to see is which visitors who came this month, had not been to the site in the past (or at least past 24 Months) and differentiate those visitors from those who had been to the site in the past 24 months. While I explained the inherent limitation of knowing if visitors were truly new due to potential cookie deletion, they said that they still wanted to see this analysis assuming that cookie deletion is a common issue across the board.

While at first, this problem seemed pretty easy, it turned out to be much more complex that I had first thought it would be. The following will show how I approached this in Adobe Analytics Workspace.

Starting With Segments

To take on this challenge, I started by building two basic segments. The first segment I wanted was a count of brand new Visitors to the website in the current month. To do this, I needed to create a segment that had visitors who has been to the site in the current month, but not in the 24 Months prior to the current month. I did this by using the new rolling date feature in Adobe Analytics to include the current month and to exclude the previous 24 months like this:

If you have not yet used the rolling date feature, here is what the Last 24 Months Date Range looked like using the rolling date builder:

As you can see, this date range includes the 24 months preceding the current month (April 2017 in this case), so when this date range is added to the preceding segment, we should only get visitors from the current month who have not been to the site in the preceding 24 months. Next, you can apply this segment to the Unique Visitors metric in Analysis Workspace:

As you can see, this only shows the count of Visitors for the current month and it excludes those who had been to the site in the preceding 24 months. In this case, it looks like we had 1,786 new Visitors this month. We can verify this by creating a new calculated metric that subtracts the “new” Visitors from all Visitors:

When you add this to the Analysis Workspace table, it looks like this:

Next, we can create a retention rate % by creating another calculated metric that divides our retained Visitors by the total Unique Visitors:

This allows us to see the following in the Analysis Workspace table:

[One note about Analysis Workspace. Since our segment spans 25 months, the freeform table will often revert back to the oldest month, so you may have to re-sort in descending order by month when you make changes to the table.]

The Bad News

So far, things look like they are going ok. A bit of work to create date ranges, segments and calculated metrics, but we can see our current month new and retained Visitors. Unfortunately, things take a turn for the worse from here. Since date ranges are tied to the current day/month, I could not find a way to truly roll the data for 24 months (I am hoping there is someone smarter than me out there who can do this in Adobe!). Therefore, to see the same data for Last Month, I had to create two more date ranges and segments called “Last Month Visitors” & “Last Month, But Not 24 Months Prior Visitors” and then apply these to create new calculated metrics. Here are the two new segments I created for Last Month::

When these are applied to the Analysis Workspace table, we see this:

To save space, I have omitted the raw count of Retained Visitors and am just showing the retention rate, which for last month was 7.42% vs. 10.82% for the current month.

Unfortunately, this means that if you want to go back 24 months, you will have to create 24 date ranges, 24 segments and 24 calculated metrics. While this is not ideal, the good news is that once you create them, they will always work for the last rolling 24 months, so it is a one-time task and if you only care about the last 12 months, your work is cut in half. However, a word of caution when you are building the prior 24-month date ranges, you have to really keep track of what is 2 months ago and 3 months ago.  To keep it straight, I created the following cheat sheet in Excel and you can see the formula I used at the top:

Here is what the table might look like after doing this for three months:

And if you have learned how to highlight cells and graph them in Analysis Workspace, you can select only the retention rate percentages and create a graph that looks like this:

Other Cool Applications

While this all may seem like a pain, once you are done, there are some really cool things you can do with it. One of those things is to break these retention rates down by other segments. For example, below, I have added three segments as a breakdown to April 2017. These segments look for specific visits that contain blog posts by author. Once this breakdown is active, it is possible to see the new, retained and retention rate by month and blog author:

Alternatively, if your business was geographically-based, you could look at the data by US State by simply dragging over the State dimension container:

Or, you could see which campaign types have better or worse retention rates:

Summary

To summarize, the new features Adobe has added to Analysis Workspace, including Rolling Dates, open up more opportunities for analysis. To view rolling visitor retention, you may need to create a series of distinct segments/metrics, but in the end, you can find the data you are looking for. If you have any ideas or suggestions on different/easier ways to perform this type of analysis in Adobe Analytics, please leave a comment here.

Most of my consulting work involves helping organizations fix and clean-up their Adobe Analytics implementations. Often times, I find that organizations have multiple Adobe Analytics report suites and that they are not setup consistently. As I wrote about in this post, having different variables in different variable slots across different report suites can result in many issues. To see whether you have this problem, you can select multiple report suites in the administration console and then review your variables. Here is an example looking at the Success Events:

As you can see, this organization is in real trouble, because all of their Success Events are different across all of their report suites.  The biggest issue with this is that you cannot aggregate data across the various report suites. For example, if you had one suite with “Internal Searches” in Success Event 1 and another suite with “Lead Forms Completed” in Success Event 1, combining the two in a master [global] report suite would make no sense, since you’d be combining apples and oranges.

Conversely, if you do have the same variable definitions across your Adobe Analytics report suites, you get the following benefits:

• You can look at a report in one report suite and then with one click see the same report in another report suite;
• You can re-use bookmarks, dashboards, segments and calculated metrics, since they are all built on the same variable definitions;
• You can apply SAINT Classifications to the same variable in all suites concurrently via FTP;
• You can re-use JavaScript code and/or DTM configurations;
• You can more easily QA your data by building templates in ReportBuilder or other tools that work across all suites;
• You can re-use implementation documentation and training materials.

To read more about why you should have consistent report suites, click here, but needless to say, it is normally a best practice to have the same variable definitions across most or all of your report suites.

How Do I Re-Align?

So, what happens if you have already messed up and your report suites are not synchronized (like the one shown above)? Unfortunately, there is no magic fix for this. To rectify the situation, you will need to move variables in some of your report suites to align them if you want to get the benefits outlined above. The level of difficulty in doing this is directly correlated to the disparity of your report suites. Normally, I find that there are a bunch of report suites that are set up consistently and then a few outliers or that the desktop website implementation is different from the mobile app implementation. Regardless of the cause of the differences, I recommend that you make the report suite(s) that are most prevalent the new “master” suite and then force the others to move their data to the variable slots found in the new “master.”

Of course, the next logical question I get is always: “What about all of my historical data?” If you move data from variable slot 1 to slot 5, for example, Adobe Analytics cannot easily move all of your historical data. You won’t lose the old data, it just is not easy to transfer historical data to the new variable slot. Old data will be in the old variable slot and new data will be in the new variable slot. This can be annoying for about a year until you have new year over year data in the new variable slot. In general, even though this is annoying for a year, I still advocate making this type of change, since it is much better for the long term when it comes to your Adobe Analytics implementation. It is a matter of short-term pain, for long-term gain and in some way is a penitence for not implementing Adobe Analytics the correct way in the beginning. However, there are ways that you can mitigate the short-term pain associated with making variable slot changes. In the next section, I will share two different ways to mitigate this until you once again have year over year data.

Trending Data After Moving Variables

Adobe ReportBuilder Method

This first method of getting year over year data from two different variable slots is to use Adobe ReportBuilder. ReportBuilder is Adobe’s Microsoft Excel plug-in that allows you to import Adobe Analytics data into Excel data blocks. In this case, you can create two date-based data blocks in Excel and place them right next to each other. The first data block will be the metric (Success Event) or dimension (eVar/sProp) from the old variable slot and it will use the old dates in which data was found in that variable. The second data block will be the new variable slot and will start with the date that data was moved to the new variable slot. For example, let’s imagine that you had a report suite that had “Internal Searches” in Success Event 2, but in order to conform to the new standard, you needed to move “Internal Searches” to Success Event 10 as of June 1st. In this case, you would build a data block in Excel that had all data from Success Event 2 prior to June 1st and then, next to it, another data block that had all data from Success Event 10 starting June 1st. Once you refresh both data blocks, you will have one combined table of data, both of which contain “Internal Searches” over time. Then you can build a graph to see the trend and even show year over year data.

This Excel solution, still takes some work, since you’d have to repeat this for any variables that move locations, but it is one way to see historical data over time and mask for end-users the fact that a change has occurred. Once you have a year’s worth of “Internal Search” data in Success Event 10, you can likely abandon the Excel solution and go back to reporting on “Internal Searches” using the new variable slot (Success Event 10 in this case), which will now show year over year data.

Derived Calculated Metric Method

The downside of the preceding Excel approach is that seeing year over year data requires your end-users to [temporarily for one year] abandon the standard web-based Adobe Analytics interface in order to see trended data. This can be a real disadvantage since most users are already trained on how to use the normal Adobe Analytics interface, including Analysis Workspace. Therefore, the other approach to combining data when variables have to be moved is to use a derived calculated metric. Now that you can apply segments, including dates, to calculated metrics in Adobe Analytics, you can create a combined metric that uses data from two different variables for two different date ranges. This allows you to join the old and new data into one metric that has a historical trend of the data and the same concept can apply to dimensions like eVars and sProps.

Let’s illustrate this with an example. Imagine that you have a metric called “Blog Post Views” that has historically been captured in Success Event 3. In order to conform to a new implementation standard, you need to move this data to Success Event 5 as of April 5th, 2017. You ultimately want to have a metric that shows all Blog Post Views over time, even though behind the scenes the data will be shifting from one variable to another on April 5th. To to this, you would start by creating two new Date Ranges in Adobe Analytics – one for the pre-April 5th time period and one for the post-April 5th period. While you could make a different set of date ranges for each variable slot being moved, the odds are that you will be making multiple changes with each release, so I would suggest making more generic date ranges that can be used for any variables changing in a release like these:

In this case, let’s assume that your historical data started January 1st, 2016, and that you won’t need the combined calculated metric past December 31st, 2019, but you can put whatever dates you’d like. The important part is that one ends on April 4th and the next one begins on April 5th. Once these date ranges have been created, you can create two new segments that leverage them. Below, you can see two basic segments that include hits for each date range:

Once these segments are created, you can begin to create your derived calculated metric. This is done by creating a metric that adds together the two Success Events that represent the same metric (Blog Post Views in this case). To do this, you simply add the old Success Event (Event 3 in this case) and the new Success Event (Event 5 in this case):

But before you save this, you need to apply the date ranges to each of these metrics. For Success Event 3 that is the date range prior to April 5th and for Success Event 5, it is the date range after April 5th. To do this, simply drag over the two new segments you created that are based upon the date ranges like this:

By doing this, you are telling Adobe Analytics that you want Success Event 3 data prior to April 5th to be added to Success Event 5 data after April 5th. Therefore, if your tagging goes as planned, you should be able to see a unified historical view of Blog Post Views from January 1st, 2016 until December 31st, 2019 using this new combined calculated metric. Here is what it would look like (with post-conversion data showing in the red highlight box):

This report is being run on April 8th, shortly after the April 5th conversion and you can see that the data is flowing seamlessly with the historical data.

For you Analysis Workspace junkies, you can see the same data there either by using the new calculated metric or applying the same segments as shown here:

Of course, this still requires some end-user education, since looking at Success Event 3 or Success Event 5 in isolation can cause issues during the transition period. But in reality, most people only look at the last few weeks of data, so the new variable (Success Event 5 in this case) should be fine for most people after a few weeks and the combined metric is only necessary when you need to look at historical or year over year data. In extreme cases, you can hide the raw variable reports (Event 3 & Event 5) and use the Custom Report feature to replace them with this new combined calculated metric in the reporting menu structure (though that won’t help you in Analysis Workspace).

Summary

To summarize, if your organization isn’t consistent in the way it implements, you may lose out on many of the advantages inherent to Adobe Analytics. If you decide that you want to clean house and make your implementations more consistent, you may have to shift data from one variable to another. Doing this can cause some short-term reporting issues, since it is difficult to see historical data spanning across two different variables. However, this can be mitigated by using Adobe Report Builder or a derived calculated metric as shown in this post. Both of these are not perfect, but they can help get your organization over the hump until you have enough historical data that you can disregard the old data prior to your variable conversion.

Back by popular demand, it is once again time for my annual Adobe Analytics “Top Gun” class! This May 17th (note: originally the date was June 19th, but had to be moved) I will be conducting my advanced Adobe Analytics class downtown Chicago. This will likely be the only time I offer the class publicly (vs. privately for clients), so if you are interested, I encourage you to register before the spots are gone (last year’s class sold out).

For those of you unfamiliar with my class, it is a one day crash course on how Adobe Analytics works behind the scenes based upon my Adobe Analytics book. This class is not meant for daily Adobe Analytics end-users, but rather for those who administer Adobe Analytics at their organization, analysts who do requirements gathering or developers who want to understand why they are being told to implement things in Adobe Analytics. The class goes deep into the Adobe Analytics product, exploring all of its features from variables to merchandising to importing offline metrics. The primary objective of the class is to teach participants how to translate every day business questions into Adobe Analytics implementation steps. For example, if your boss tells you that they want to track website visitor engagement using Adobe Analytics, would you know how to do that? While the class doesn’t get into all of the coding aspects, it will teach you which product features and functions you can bring to bear to create reports answering any question you may get from business stakeholders. It will also allow you and your developers to have a common language and understanding of the Adobe Analytics product so that you can expedite getting the data you need to answer business questions.

Here are some quotes from past class attendees:

To register for the class, click here. If you have any questions, please e-mail me. I hope to see you there!

A few weeks ago, I shared a new tool called Alarmduck that helps detect data anomalies in Adobe Analytics and posts these to Slack. This data anomaly tool is pretty handy if you want to keep tabs on your data or be notified when something of interest pops-up. Unlike other Slack integrations, Alarmduck doesn’t use the out-of-box Adobe Analytics anomaly detection, but rather, has its own proprietary method for identifying data anomalies. In this post, I will demonstrate a few examples of how I use the Alarmduck tool in my daily Adobe Analytics usage.

Identifying Hot Prospects

As I have demonstrated in the past, I use a great tool called DemandBase to see which companies are visiting my blog. This helps me see which companies might one day be interested in my Adobe Analytics consulting services. Sometimes, I will notice a huge spike in visits from a particular company, which may indicate that I should reach out to them to see if they need my help (“strike while the iron is hot” as they say). However, it is a pain for me to check daily or weekly to see if there are companies that are hitting my blog more than normal, but this is a great use for Alarmduck.

To do this, I would create a new Alarmduck report (see instructions in previous post) that looks for anomalies using the DemandBase eVar which contains the Company Name by selecting the correct eVar in the Dimension drop-down box:

In this case, I am also going to narrow down my data to a rolling 14 days, US companies only and exclude any of my competitors (which I track as a SAINT Classification of the DemandBase Company eVar):

Once I set this up, I will be notified if there are any known companies that hit my blog over a rolling 14-day period that cause a noticeable increase of decrease. This way, I can go about my daily business and know that I will automatically be notified in Slack if something happens that requires my attention. For example, the other day, I sat down to work in the morning and saw this notification in Slack:

It is cool that Alarmduck can show graphs of data right within Slack! However, if I want to dig deeper, I can click on the link above the graph to see the same report in Adobe Analytics and, for example, see which of my blog posts this company was viewing:

Eventually, if I wanted to, I could reach out to the analytics team of this company and see if they need my help.

Competitor Spikes

From time to time, I like to check out what some of my “competitors” (more like others who provide analytics consulting) are reading on our website or my blog. This is something that can also be done using DemandBase. In my case, I have picked a bunch of companies and classified them using SAINT. This allows me to create a “Competitors” segment and see what activity is taking place on our website from these companies. Just as was done above, I can create a new Alarmduck report and use a segment (Competitors in this case) and then choose the Demandbase Company Dimension and select the metrics I want to use (Page Views and Visits in this case):

Once this is created, I will start receiving alerts (and graphs!) in Slack if there are any spikes by my competition like this:

In this case, there were two companies that had unusually high Page Views on our website. If I want to, I can click on the “Link to Web Report” link within Slack to see the report in Adobe Analytics:

Once in Adobe Analytics, I can do any normal type of analysis, like viewing what specific pages on our website this competitor viewed:

In most cases, this is just something I would view out of curiosity, but it is a fun use-case for how to leverage anomaly detection in Adobe Analytics via Alarmduck.

Summary

These are just two simple examples of how you can let bots like Alarmduck do the work for you and use more of your time on more value-added activities, knowing that you will be alerted if there is something you need to take action upon. If you want to try Alarmduck for free with your Adobe Analytics implementation, click here.

One of the most difficult parts of managing an Adobe Analytics implementation is uncovering data anomalies. For years, Adobe Analytics has offered an Alerts feature to try and address this, but very few companies end up using them. Recently, Adobe improved their Alerts functionality, in particular, allowing you to add segments to Alerts and a few other options. However, I still see very few companies engaging with Adobe Analytics Alerts, despite the fact that few people (or teams) have enough time to check every single Adobe Analytics report, every day to find data anomalies.

Part of the issue with Alerts is the fact that many people don’t go into Adobe Analytics every day, so even if there were Alerts, they wouldn’t see them.Even the really cool data anomaly indicators in Analysis Workspace are only useful if you are in a particular report to see them. While Adobe Analytics Alerts can be sent via e-mail, those tend to get filtered into folders due to all of the noise, especially on weekends! To rectify this, I have even tried to figure out how to get Adobe Analytics Alerts into the place where I spend a lot of my time – Slack. But despite my best efforts, I still wasn’t able to get the right alerting that I needed from Adobe Analytics to the people that needed to see them. I felt like there had to be an easier way…

Introducing Alarmduck