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

It was around this time that I stumbled upon some folks building a tool called Alarmduck. The idea of Alarmduck was to make it super easy to be notified in Slack when data in your Adobe Analytics implementation has changed significantly. Being a lover of Adobe Analytics and Slack, it was the perfect union of my favorite technologies! Alarmduck uses Adobe Analytics API’s to query your data and look for anomalies and then Slack API’s to post those anomalies into the Slack channel of your choosing.

For example, a few weeks ago, we had a tagging issue on our Demystified website that caused our bounce rate to metric to break. The next day, here is what I saw in my Slack channel:

I was alerted right away, was able to see a graph and the data causing the anomaly and even had a link to the report in Adobe Analytics! In this case, we were able to fix the issue right away and minimize the amount of bad data in our implementation. Best of all, I saw the alert in the normal course of my work day, since it was automatically injected into Slack with all of my other communications.

Going From Good to Great

So, as I started using Alarmduck, I was pleased that my metrics (including Success Events) were automatically notifying me if something had changed significantly, but as you could imagine (being an Adobe Analytics addict), I wanted more! I got in touch with the founders of the company and shared with them all of the other stuff Alarmduck could be doing related to Adobe Analytics such as:

• Allowing me to get data anomalies for any eVar/sProp and metric combination (i.e. Product anomalies for Orders & Revenue or Tracking Code anomalies for Visits)
• Allowing me to check multiple Adobe Analytics report suites
• Allowing me to check Adobe Analytics Virtual Report Suites
• Allowing me to apply Adobe Analytics segments to data anomaly checks
• Allowing me to post different types of data anomaly alerts to different Slack channels
• Allowing me to send data anomalies from different report suites to different Slack channels

As you could imagine, they were a bit overwhelmed, so I agreed to be their Adobe Analytics advisor (and partial investor) so they could tap into my Adobe Analytics expertise. While there were almost 100 companies already testing out the free beta release of the product, I was convinced that power Adobe Analytics users like me would eventually want more functionality and flexibility.

Over the last few months, the Alarmduck team has been hard at work and I am proud to say that all of the preceding features have been added to the product! While there are many additional features I’d still love to see added, the v1.0 version of the product is now available and packs quite a punch for a v1.0 release. Anyone can try the product for free for 30 days and then there are several tiers of payment based upon how many data anomaly reports you need. The following section will demonstrate how easy it is for you to create data anomaly alerts.

Creating Data Anomaly Reports

To get started with Alarmduck, you first have to login using the credentials of your Slack team (like any other Slack integration). When you do this, you will choose your Slack team and then identify the Slack channel into which you’d like to post data anomalies (you can add more of these later). You should make the channel in Slack first so it will appear in the dropdown list shown here:

Next, you will see an Adobe Analytics link in the left navigation and be asked to enter your Adobe Analytics API credentials:

If you are not an administrator of your Adobe Analytics implementation, you can ask the admin to get you your username and secret key, which is part of your Adobe Analytics User ID:

Next, you will add your first Adobe Analytics report suite:

(Keep in mind that in most cases, the preceding steps will only have to be done one time.)

Once you are done with this, Alarmduck will create your first data anomaly report for your first 30 metrics (you can use the pencil icon to customize which metrics you want it to check):

This will send metric alerts to the designated Slack channel once per day.

Beyond Metrics

The preceding metric anomaly alerts will be super useful, but if you want to go deeper, you can add segments, eVars, sProps, etc. To do this, click the “Add Report” button to get this window:

Next, you choose a report suite or a Virtual Report Suite (Exclude Excel Posts in this example). Once you do this, you will have the option to select a segment (if desired):

And then choose a dimension (eVar or sProp) if needed:

Lastly, you can choose the metrics for which you want to see data anomalies:

In this case, you would see data anomalies for a Virtual Report Suite, with an additional segment applied and see when there are data anomalies for Blog Post (eVar5) values for the Blog Post Views (event 3) metric (Note: At this time, Alarmduck checks the top 20 eVar/sProp dimension values over the last 90 days to avoid triggering data anomalies for insignificant dimension values). That shows how granular you can get with the new advanced features of Alarmduck (pretty cool huh?)!

When you are done, you can save and will see your new report in the report list on the Adobe Analytics page:

Here is a video of a similar setup process:

Summary

As you can see, adding reports is pretty easy once you have your Slack team and Adobe Analytics credentials in place. Once setup, you will begin receiving daily alerts in your designated Slack channel unless you edit or remove the report using the screen above. You can create up to 10 reports in the lowest tier package and during your 30-day free trial. After that, you can use a credit card and pay for the number of reports you need:

Since the trial is free and setting up a Slack team (if you don’t already have one) is also free, there is no reason to not try Alarmduck for your Adobe Analytics implementation. If you have any questions, feel free to ping me. Enjoy!

Being a Chicagoan, I tend to hibernate in the winter when it is too cold to go outside, but as Spring arrives, I will be hitting the road and getting back out into the world! If you’d like to hear me speak or chat about analytics, here are some places you can find me:

US Adobe Summit

Next week I will be attending what I believe is my 14th US Adobe Summit (which makes me sound pretty old!). It is in Las Vegas again this year and I am sure will be bigger than ever.

At the conference, I will be doing a session on Adobe Analytics “Worst Practices” in which I highlight some of the things I have seen companies do with Adobe Analytics that you may want to avoid. I have had a great time identifying these and have had the help of many in the Adobe Analytics community. This session is meant for those with a bit of experience in the product, but should make sense to most novices as well. Here is a link to the session in case you want to pre-register (space is limited): https://adobesummit.lanyonevents.com/2017/connect/sessionDetail.ww?SESSION_ID=4340&tclass=popup#.WMbsL2nTGYY.twitter

In addition to this session, I will also be co-presenting with my friends from ObservePoint to share an exciting new product they are launching related to Adobe Analytics. Many of my clients use ObservePoint, which is highly complimentary and this session should be useful to those who focus on implementing Adobe Analytics. Here is a link to that session: https://adobesummit.lanyonevents.com/2017/connect/sessionDetail.ww?SESSION_ID=4320&tclass=popup#.WMbrvEN9wcM.twitter

Last, but not least, I will be stopping by the SweetSpot Intelligence booth (#1046) on Wednesday March 22nd @ 4:00 PST to sign the last hardcopies of my book in existence! As you may have seen in some of my recent tweets, Amazon is no longer producing hardcopies of my Adobe Analytics book. I have 25 of these hardcopies left and am selling the last 10 on Amazon and the remaining 15 will be auctioned off by Sweetspot Intelligence during Adobe Summit and signed by yours truly Wednesday @ 4:00. This is your last chance to get a physical copy of my book and a signed one to boot! So if you want a copy of my book, make sure to stop by their booth on Tuesday and find out how to win a copy.

EMEA Adobe Summit

In addition to the US Adobe Summit, I will also be attending the EMEA Adobe Summit in the UK. I have been to this event a few times and it is a bit smaller than the US version, but just as much fun! I will be presenting there with my friend Jan Exner, who is one of the best Adobe Analytics folks I know, so it should be a great session. We are still working out the details on that session now, but you will not want to miss it!

Chicago Adobe Analytics “Top Gun” Class

On May 17th in Chicago, I will be hosting my annual Adobe Analytics “Top Gun” class for those who want to go really deep into the Adobe Analytics product. You can learn more about that class in this blog post.

A4 Conference – Lima, Peru

The following week, I will be speaking at the A4 Conference in Lima, Peru. This will be my first time to Peru and I am excited to use my Spanish skills once again and to meet marketers from South and Latin America!

eMetrics Chicago

In June, I will be back home and attending the Chicago eMetrics conference where I will be sharing information about the success of the DAA’s Analysis Recipe initiative and enjoying having analysts come visit my hometown when the weather is actually warm!

So that is where I will be! If you happen to be anywhere near these places, I’d love to see you. In addition, you can see all of the places my Demystified Partners will be by clicking here.

Some of my clients have many websites that they track with Adobe Analytics. Normally, this is done by having a different Report Suite for each site and then a Global Report Suite that combines all data. In some of these cases, my clients are interested in seeing how often the same person, in the same visit, views more than one of their websites. In this post, I will share some ways to do this and also show an example of how you can see the converse – how often visitors view only one of the sites instead of multiple.

Multi-Site Pathing

The first step in seeing how often visitors navigate to your various properties, is to capture some sort of site ID or name in an Adobe Analytics variable. Since you want to see navigation, I would suggest using an sProp, though you can now see similar data with an eVar in Analysis Workspace Path reports. If you capture the site identifier on every hit of every site and enable Pathing, in the Global Report Suite, you will be able to see all navigation behavior. For example, here is a Next Flow report showing all site visits after viewing the “Site1” site:

Here we can see that (~42%) remained in the “Site1” site, but if they did navigate to others, it was the “Site2″or “Site3” sites. You can switch which site is your starting point at any time and also see reverse flows to see how visitors got to each site. You can also see which sites are most often Entries and Exits, all through the normal pathing reports.

Single Site Usage

Now let’s imagine that upon seeing a report like the one above, you notice that there is a high exit rate for “Site1,” meaning that most visitors are only viewing “Site1” and not other sites owned by the company. Based upon this, you decide to dig deeper and see which sites do better and worse when it comes to inter-site pathing.

The easiest place to start with this is to go to your Global Report Suite and open the Full Paths report for “site” variable in the Global Report Suite and then pick one of your sites (in this case “Site1”) where shown in red below:

This report shows you all of the paths that include your chosen site (“Site1” in this case). Next, you can add this report to a dashboard so you see a reportlet like this:

You can now do the same for each site and see which ones are “one and done” and which are leading people to other company-owned sites.  For some clients, I add a bunch of these reportlets to a single dashboard to get a bird’s eye view of what is going on with all of the sites.

Trending Data

However, the preceding reports only answer part of the question, since they only show a snapshot in time (the month of February in this case). Another thing you may want to look at is the trend of single site usage. Getting this information takes a bit more work. First, you will want to create a segment for each of your sites in which you look for Visits that view a specific site and no other sites. This can be done by using an include and exclude container in the segment builder. Here is an example in which you are isolating Visits in which “Site1” is viewed and no other sites are viewed:

One you save this segment, you can apply it to the Visits report and see a trend of single site visits for “Site1” over time, as shown here:

You will have to build a different segment for each of your sites, but you can do that easily by using the Save As feature in the segment builder.

Lastly, since all of the cool kids are using Analysis Workspace these days, you can re-use the segments you created above in Analysis Workspace and apply them to the Visits metric and then graph the trends of as many sites as you want. Below I am trending two sites and using raw numbers, but could have just as easily trended the percentages if that is more relevant and added more sites if I wanted. This allows you to visually compare the ups and downs of each sites’ single site usage in one nice view.

Summary

So to conclude, by using a site identifier, Pathing reports and Analysis Workspace, you can begin to understand how often visitors are navigating between your sites or using just one of them. The same concept can be applied to Site Sections within one site as well. To see that, you simply have to pass a Site Section value to the s.channel sProp and repeat the steps above. So if you have multiple sites that you expect visitors to view in the same session, consider trying these reports to conduct your analysis.

Recently, I gave a presentation in which I posited that tracking every single hyperlink on a web page is not what digital analytics is all about. I argued that looking at every link on a page can create a lot of noise and distract from the big picture KPI’s that need to be analyzed. This led to a debate about the pros and cons of tracking every link, so I thought I would share some of my thoughts here and see if anyone had opinions on the topic.

Why Track Everything?

I have some clients who endeavor to track every link on their site. Most of these pass the hit level data to Hadoop or something similar and feel that the more data the better, since data storage is cheaper every day. For those using Adobe Analytics, these links are usually captured in an sProp and done through a query string parameter on the following page or a Custom Link. In Adobe Analytics, the sheer number of these links often hits the monthly unique value limit (low traffic), so the data is somewhat less useful in the browser-based reporting interface, but is fine in DataWarehouse and when data is fed to back-end databases.

But if you ask yourself what is the business goal of tracking every link on a page, here are the rationalizations I have heard:

• We want to know how each link impacts conversion/success;
• We want to see which links we can remove from the page;
• If multiple links to the same page exist, we want to know which one is used more often;
• We just want to track everything in case we need it later.

Let’s address these one at a time. For the first item, knowing how each link contributes to success is possible, but since many links will be used prior to conversion, several should get credit for success. In Adobe Analytics, you can assign this contribution using the Participation feature, but this becomes problematic if you have too many links tracked and exceed the monthly unique limit. This forces you to resort to DataWarehouse or other systems, which puts analysis out of the hands of most of your business users but is still possible by a centralized analytics team that is a bit more advanced. Instead of doing this, I would propose that instead of tracking every link, you pick specific areas of the website that you care about and track those links in an sProp (or an eVar). For example, if you have an area on your website that is a loan calculator, you can track all of the discrete links there in a custom variable. You can then turn on Participation and Pathing for that variable and get a good sense of what is and is not being used and not exceed any unique variable limits. I would also argue that once you learn what you have to learn, you can re-use the same variable for a different area of your website in the same way (i.e. loan application form pages). Hence, instead of tracking every link on the website, you are more prescriptive on what you are attempting to learn and can do so with greater accuracy. If you need to track several areas of the site concurrently, you can always use multiple variables.

For the second question – seeing which links can be removed from the page – I have found that very few analyses on links have actually resulted in links being dropped from pages. In general, most people look to see how often Page A leads to Page B or Page C and by the time they get to Page Z, the referral traffic is very low. If you truly want to remove extraneous links, you could start by finding the pages that people rarely go to from Page A and then remove the links to those pages on Page A. Doing this doesn’t require doing granular link tracking.

Next, there is the age-old question of which link, of multiple going to the same place, people use. I am not quite sure why people are so fascinated with these types of questions, but they are! In most cases, I find that even after conducting the analysis, people are loathed to remove the duplicative links for fear of negatively impacting conversion (just in case). Therefore, for cases like this, I would suggest using A/B testing to try out pages that have duplicate links removed. Testing can allow you to see what happens when secondary or tertiary links are removed, but for a subset of your audience. If the removal doesn’t negatively impact the site, then you can push it site-wide after the test is complete.

Lastly, there is the school of thought that believe they should track everything just in case it is ever needed. This has become easier over the years as data storage prices have fallen. I have seen many debates rage about whether time should be spent pre-identifying business requirements and tracking specific items desired by stakeholders or just tag everything and assume you may need it later. Personally, I prefer the former, but I don’t disparage those who believe in the latter. If your organization is super-advanced at data collection, has adequate database expertise and an easy way to analyze massive amounts of data, tracking everything may be the right choice for you. However, in my experience, most analytics teams struggle to do a great job with a handful of business questions asked by stakeholders and the addition of reams of link-level data could easily overwhelm them. For every new thing that you track, you need to provide QA, analysis and so on, so I would advise you to focus on the biggest questions your stakeholders have. If you ever get to the point where you have satisfied those and have processes in place to do so in an efficient manner, then you may want to try out “tracking everything” to see how much incremental value that brings. But I do not advise doing it the other way around.

Focus on KPI’s

The other complaint that I have about tracking every link is that it takes time away from your KPI’s. Most analytics teams are busy and strapped for resources. Therefore, focusing time on the most important metrics and analyses is critical. I have seen many companies get bogged down in detailed link tracking that results in nominal potential ROI increases (is the juice worth the squeeze?). Just outlining all of the links to be tracked can take time away from analysts doing analysis, not to mention the time spent analyzing all of the data. In addition, doing granular link tracking can sometimes require a lot of tagging and quality assurance, which takes developers away from other efforts. Developers’ time is usually at a premium, so you need to make the most of it when you have it.

Consider Other Tools

If you are truly interested in tracking every link, I would suggest that you consider some other analytics tools that may be better suited for this work (vs. Adobe Analytics). One set of tools to consider are heat map and session replay tools. I often find that when analytics customers want to track every link on the site, many times, they really want to understand how people are using the different areas of the site and are not aware that there are better tools suited to this function. While heat map tools are not perfect (after many years, even the Adobe Click Map tool takes extra work to make it functional), they can provide some good insights into which parts of pages visitors are viewing/clicking and answer some of the questions described above. I have even seen some clients use detailed link data in Adobe Analytics to create a “heat map” view of a page manually (usually in PowerPoint), which seems like a colossal waste of time to me! I suggest checking out tools like Crazy Egg and others in the heat mapping area.

Personally, I am a bigger fan of session replay tools like Decibel Insight (full disclosure: I am on the advisory board for Decibel), because these tools allow you to see people using your website. I have found that watching someone use an area of your website can often time be easier that analyzing rows and rows of link click data. Unfortunately, just as in engineering or construction, sometimes using the wrong tool can lead you down a path that is way more complicated than you need versus simply selecting the right tool for the job in the beginning. Most of these tools can also show you heat maps, which is nice as it reduces the number of disparate tools you need to work with and pay for.

Lastly, if tracking every link is absolutely essential, I would check out tools like Heap or Mixpanel, which is pre-built for this type of tracking. But in general, when you are in meetings where link-level tracking is discussed, keep these tools in mind before doing a knee-jerk reaction to use your traditional analytics tool.

Final Thoughts

There you have some of my thoughts on the topic of tracking every link on your site. I know that there will be some folks who insist that it is critical to track all links. On that, I may have to agree to disagree, but I would love to hear arguments in favor of that approach as I certainly don’t profess to know everything! I have just found that doing granular link tracking produces minimal insights, can create a lot of extra work, can detract time from core KPI’s and sometimes can be more effective using different toolsets. What say you?

One of the more difficult types of analyses to conduct in the digital world is an analysis that looks at what visitors did before or after actions on a website or within an app. For example, it’s easy to see what pages visitors view in the same visit that they added a product to the cart, but seeing what pages they viewed before or after they added something to the cart is more difficult. Since Adobe Analytics introduced Sequential Segmentation, it has been slightly easier, but being precise about before or after events or page sequences can still be tricky. Fortunately, Adobe Analytics recently released a product update that will make this much easier and in this post, I’ll explain how it works and provide some examples of how this new functionality can be used.

Why Should You Care?

So why should you care about seeing what visitors did before or after a sequence of events? Website visits and mobile app sessions can be sporadic or chaotic. If you try to follow every page path that visitors undertake, you can get lost in the details. For this reason, fallout reports have always been popular. With a fallout report, you can reduce the noise and view cases in which visitors viewed Page A, then eventually Page B and then eventually Page C. In this case, you don’t necessarily care if they went directly from Page A to Page B and Page C, but rather, that they performed that sequence. This concept of fallout was greatly expanded when Adobe Analytics began allowing you to add Success Events, eVars and segments to fallout reports as I described in this post.

But even with all of these improvements, there will still be times when you want to see what happened before a fallout sequence or after the sequence. For example, you may want to see:

• What did website visitors do after they viewed a series of videos on your website?
• What search phrases were used before they add items to the shopping cart?
• What products are purchased after visitors come from an e-mail campaign and then a social media campaign?
• What pages do people view before they complete all steps of a credit card application?

This is especially true when you take into account that the sequence can span multiple visits by using a Visitor container instead of a visit container. For example, a bank may want to see how often visitors use calculators in any visit prior to applying for a loan. And once you have the ability to segment analytics data based upon before and after sequences, you can then apply those new segments to all Adobe Analytics reports and increase your analytics opportunities.

Example

To illustrate this functionality, let’s look at an example. Let’s say that on the Demystified website, I want to see what pages visitors view before they view our main services page and then our Adobe Analytics services pages (in either the same visit or subsequent visit). The goal of this would be to see which pages are the most important for us in getting new business leads.

To start, I would create a simple fall-out report that defines the sequence I am interested in. In this case, the sequence is viewing our main services page and then viewing one of our two Adobe Analytics services (can be one or the other or both):

Once I have this fall-out report, I can right-click on the last portion of it and choose the “create segment from touchpoint” option as shown here:

This will open the segment builder and allow me to build the corresponding segment. If I want to limit my segment to people who did both actions in the same visit, I would select “Visit,” but in this case I want the sequence to include multi-session activity, so I have selected the “Visitor” option:

However, the segment above includes all cases in which visitors viewed the services page and then one of the Adobe Analytics services. This means that they could have viewed these pages before or after the sequence that I care about. While that is interesting, in this case, my objective is to only view data that occurred before they completed this sequence. This is where the new Adobe Analytics functionality I described earlier comes into play. While editing the above segment, you can now see a new option that says “Include Everyone” to the left of the gear icon (see above). Clicking on this item, brings up a new menu option shown below that lets you narrow the scope of your segment to behavior that occurred before or after the sequence. In the screenshot below, I am selecting the “before” option, since my goal is to see what visitors did before this fall-out sequence transpired:

Once I select this, I can save my segment as shown here:

Now I have a segment that can be applied to any Adobe Analytics report which limits data to only those cases that took place before visitors viewed the main services page and then viewed one of our Adobe Analytics services pages. This segment can be applied to any report in either the traditional Reports & Analytics interface or Analysis Workspace. If I want to see what pages visitors view before my sequence, I can add the segment to the Pages report in a freeform table as shown here:

In this report, I am comparing overall page views to pages with page views to pages taking place before my fall-out sequence. This shows me which pages on our website visitors are viewing prior to viewing the Adobe Analytics services, so I may want to make sure those pages look good!

If I wanted to take this concept further, I could also view which of my blog posts visitors viewed prior to the fall-out sequence (checking out our services and then our Adobe services). To do this, I can add a new Blog Post Views metric to the freeform table and then use another segment to limit this to “Adam Greco” blog posts like this:

Notice that I have applied the “Before Services & Adobe Services” segment to both Page Views and Blog Post Views, but only the “Adam Blog Posts” segment to the Blog Post Views metric. Lastly, I can sort by the Blog Post Views column to see the top “Adam Blog Posts” viewed before the sequence to see which ones may be helping me get new clients!

Final Thoughts

Hopefully you can see that there are many different use cases for this new functionality. I would recommend that you consider using this new feature anytime you get asked a question about what happens before or after a sequence of events on your website (or mobile app). Keep in mind that you can make your fall-out sequences as granular as you want by adding segments to any node of the fall-out report. This should provide ample flexibility when it comes to reporting what is happening before or after activity on your website.

To learn more about using this feature, check out this short video by Ben Gaines on the Adobe Analytics YouTube channel. There is also some additional documentation you can read about this functionality here.

One of the great things about Analysis Workspace is that it begs you to keep driving deeper and deeper into analysis in ways that the traditional Adobe Analytics reports do not. I have heard Ben Gaines talk about this as one of the reasons he loves Workspace so much and he is spot on. Ever since it burst onto the scenes, those who understand Adobe Analytics have realized that it represented the future of the product. The only thing holding it back was the fact that some key types of reports were unavailable, forcing users to continue to use the traditional Adobe Analytics reports.

However, this all changed yesterday. I believe that October 20th will go down in history (at least the history of Adobe Analytics geeks like me) as the day the world changed! On this day, a host of great new Analysis Workspace visualizations were released. These include:

• Fallout Report Visualization
• Flow Visualization (video)
• Histogram Visualization (video)
• Anomaly Detection & Contribution Analysis (video)

While this may not seem like such a big deal, let me tell you why it is a huge deal. I believe that these additions represent the tipping point in which Adobe Analytics end-users give in and decide that Analysis Workspace is their primary reporting interface. While I have seen some of my clients dive head first into Analysis Workspace, I have also seen many of my clients “dip their toe in the water” with Analysis Workspace, but fall back to their comfort zone of traditional reports. It is my contention that this will no longer be possible and that Analysis Workspace will become the default going forward. Of course, this will take some time to learn the new interface, but the advantages are so compelling at this point, that those not making the shift will risk becoming Adobe Analytics dinosaurs.

To illustrate why I think this will happen, I am going to demonstrate the power of Analysis Workspace in the following section.

Stream of Consciousness

In my opinion, the intrinsic value of Analysis Workspace, like Discover before it, is the ability to come up with an analysis idea and be able to follow it through like a stream of consciousness. As an analyst, you want to be able to ask a question and then when you find the answer, ask a follow-up question and so on. In the traditional Adobe Analytics reports, there are a few cases in which you can break a report down by another, but it is somewhat limited. This limitation can break your train of thought and instead of asking the next question, you end up spending time thinking about how you need to work around the tool or, worse yet, add more implementation items to answer your follow-up question.

For example, let’s say that I want to see which products had the most orders this month. I can open the Products report and add the Orders metric. Then I want to see which campaigns drove the highest selling product, so I break the product down by campaign tracking code. Next I want to see the trend of that campaign code leading to orders of that product. At this point, I am a bit stuck since I need to build a segment and apply it to a Visits report. But to do this, I need to stop what I am doing, identify the correct segment definition, save it, open up a Visits report and apply the segment. Next I might want to see if there were any abnormal peaks or valleys in the data, so I might export the data to Excel and run a standard deviation formula against it for the last few months. This involves exporting data and making sure I have the formulas correct in Excel. What if I want to repeat this analysis on a weekly basis going forward? That means I need to open up Adobe ReportBuilder, make a data block, use formulas to apply the standard deviation and then schedule it to be sent weekly.

As you can see, there are a lot of manual steps involving Adobe Analytics, Excel, ReportBuilder, etc. At any point in this process, the phone could ring and I could get distracted and lose my train of thought. In the best case scenario, I am looking at a few hours to follow my concept through to analysis.

What Analysis Workspace does is two-fold. First, pretty much everything you need is built into the same tool so you don’t have to jump between different tools. Second, most of the things you need are one click away and can be done so fast that sometimes it feels like you are slowing down the tool instead of the other way around!

To illustrate this, I am going to build upon an example scenario that I blogged about last week. In that post, I described a situation in which I used the new Analysis Workspace Fallout report visualization to see what percent of visits to my website viewed my blog posts and of those how many found their way to some of my “sales pages. If you haven’t read that post, I suggest you take a few minutes and read that post now to have more context for what follows.

As described in the previous post, I have isolated a situation in which very few people are checking out my sales pages:

Upon seeing this, one question I might ask is where are visitors going who don’t go to my sales pages? I can easily see this by right-clicking on the sales page checkpoint item and selecting the fallout option like this:

This will result in a brand new report being populated that shows the answer to this question:

In addition, I may want to see which pages people who do eventually reach my sales pages also view. I can do this by again right-clicking on the sales pages checkpoint and then choosing fall-though like this:

This will create a brand new report showing where visitors went between the second to last and last steps like this:

Finally, I may want to see the general trend of visitors viewing my blog post and then reaching a sales page. To see this, I right-click on the last checkpoint and select the trend option to see a graph like this:

So in a matter of seconds, I can follow-up on my top queries and continue to dig deeper. In fact, when I see the graph above, Analysis Workspace shows me the statistical trend and the normal upper and lower bands of expected data. This provides context and negates my need to export data to Excel and do analysis there. In addition, I see two circles indicating cases in which my trend was outside of the norm via Adobe Analytics Anomaly Detection functionality. When I hover over either of these circles, I am given the opportunity to dig deeper into these data anomalies with one click:

Running this allows me to see what data is contributing to the data anomaly like this:

But another analysis I may be curious about is from which companies are visitors coming who do make it from my blog pages to my sales pages. Ideally, I’d like to build a segment of these folks and start marketing to them. Luckily, I can right-click on the final checkpoint and select the “create segment from touchpoint” option and see a brand new segment like this:

All I have to do is give this segment a name and I can use it in any report. So next, I will open a freeform table and add my DemandBase Company Name report with the Visits metric and then apply this new segment to the report like this:

Next I can right-click on the top prospect (row 2 above) and see the trend of them visiting my site:

Another way to analyze this might be to add a cohort table and see how often people who fall into my Blog to Sales segment visit my site and then return to it. I can do this by adding a cohort visualization, selecting Visits as the metrics and then applying my new auto-created segment to it like this:

here I might see that I have some people coming back in week one, two and three, so they might be serious about working with me. I can then right-click on the week three cell and create a new segment called “Really Interested in Adam” and add that back to my DemandBase Company Name freeform table:

Phew! Now, I purposely went a bit crazy there, but was to drive home the point. While you may not go through things exactly the way I just did, the cool part is that you can! You can easily keep adding visualizations and right-clicking to create sub-reports and segments (and I didn’t even hit all of the other visualizations that can be used as well!). At no point did I have to leave Adobe Analytics and use other tools and I was able to run all of these reports in under ten minutes!

This is why I think most Adobe Analytics users will make the leap to Analysis Workspace in the future. I encourage you to avoid digging your head into the sand and to get with the program. There are lots of blog posts and videos available to show you how to use Analysis Workspace and if you need more help, I offer training services as well 😉

Congrats to the Adobe Analytics product management team and their developers. Welcome to the future of Adobe Analytics…

Yesterday, the Adobe Analytics team added a lot of cool new functionality related to Analysis Workspace. One of these additions was the addition of a Fallout visualization, which was previously available in the Ad Hoc Analysis product, but unavailable in Analysis Workspace. In this post, I will share some of my thoughts on this new visualization and how it can be used.

Fallout Report Refresher

Back in 2008, I blogged about how to use Fallout reports in SiteCatalyst, but a lot has changed since then! The concept of the Fallout report is that you add checkpoints to a report and Adobe Analytics will tell you what percent of your paths dropped off or continued from checkpoint A to B to C. Unfortunately, the traditional version of this report has many limitations:

• Fallout is limited to a finite number of checkpoints (normally four unless you pay for more)
• Fallout can only include values from one dimension. For example, if you are doing a fallout report for Pages, only pages can be used as checkpoints. Therefore, you cannot mix values from two different dimensions
• Fallout reports could only be used for Traffic Variables (sProps), so this might cause you to track data you have in Conversion Variables (eVars) in an sProp as well, just to see fallout. This sProp limitation also means that you could not add metrics (Success Events) to Fallout reports
• Checkpoint values in the Fallout report could not be grouped, so if you wanted to see a checkpoint in which either value A or value B was present, you would have to create a new sProp for that purpose, which creates a lot of unnecessary work
• Fallout reports are limited to one visit

So as you can see, traditional Fallout reports were useful, but had a lot of limitations. Most people got around these limitations, by using Fallout reports in the Ad Hoc Analysis (formerly Discover) tool. That was helpful, but it required the installation of a Java client and understanding how to use a much more sophisticated tool, which didn’t always appeal to casual analytics users.

Welcome to the Future!

But now, Adobe has brought the best of the Ad Hoc Analysis Fallout reports to Analysis Workspace, the new reporting/visualization interface that works for both casual and advanced analytics users. As you probably know, Analysis Workspace works natively in the browser, but packs the same punch as the Java-based Ad Hoc Analysis product.

The new Fallout visualization removes all of the previously mentioned limitations so you can:

• Have an unlimited number of checkpoints
• Include Success Events, eVars or sProps and mix and match them in the same Fallout report
• Group items together into one checkpoint
• View fallout across multiple visits

To illustrate this, let’s go through an example. Imagine that I want to know how often people come to the Analytics Demystified website, read one of my blog posts and then proceed to view a few of the pages that pitch my consulting services. In a normal Fallout report, this would be difficult because I would need to have some sort of “Page Type” sProp that had one value for all of my blog posts (i.e. Adam Blog Posts) and another value for all of my sales pages (i.e. Adam Sales Pages). That would require some manual tagging effort, but if I did that, I could see a fallout from Adam Blog Posts to Adam Sales Pages, but within a visit only.

Let’s see how I could do this using the new Analysis Workspace visualization. First, I would add the Fallout visualization to the canvas. Then I would drag over my Blog Post Views Success Event as a checkpoint like this:

So now we can see that about 93% of our Visits have people who view blog posts. Next, I want to limit the second checkpoint to only those who read my blog posts. To do this, I can simply add a segment to the second checkpoint. This is another thing that has never been possible in traditional Fallout reports. So I will add my “Adam Blog Posts” segment to the second checkpoint by dragging it next to the Blog Post Views Success Event (you will see a black bar) so it looks like this:

Now I can see that about 16% of all visits find their way to one of my blog posts. Next, I want to see what percent of those folks make it to one of my sales pages. To do this, I use the left navigation of Analysis Workspace to find the Pages dimension, click the arrow next to it and then find the sales pages. Here is what the left navigation will look like before you click the arrow:

Once you click, you will see your pages and can search for the ones you want:

Once you find the pages you care about, you can drag them over one at a time (or select multiple using Command/Control) and drop them next to each other. Combining them creates an OR clause so if any of those pages is viewed, the Fallout report will count it. Here is what it looks like after I dragged over three different pages:

So now I can see that I am not getting a lot of folks reading my blog posts to view my consulting sales pages (darn freeloaders!). Since my percent is lower than I’d like, in this case, I am going to start adding a call to action for my sales pages to the bottom of my blog posts (see below) and then check in a few weeks to see if this helps decrease this large drop-off…

Additionally, there are some settings associated with this report that you can tweak. Using the “gear” icon, you can choose whether you want to include All Visits as the first checkpoint, or exclude that and start my fallout report with the first checkpoint.  You can also choose if you want to include Visits or Visitors in the report:

Here is what the report looks like if I uncheck the “All Visits” box:

Segmentation

But wait…there’s more. While we saw that we can add segments to checkpoints, there is much more you can do with segmentation and Fallout visualizations. First, you can add a segment to the entire workspace project which will impact all visualizations, including the Fallout report. For example, I can add my “Competitors” segment (which I get from DemandBase data) to the top of the project  and see my data change like this:

Now I can see that instead of 16% of visits viewing my blog posts, I have 44% of visits viewing them (not cool guys!) and that very few of them view my sales pages, which is understandable. But to make this easier to see, I can alternatively drag this segment next to the All Visits area at the top of the Fallout visualization and see the Fallout report separately for each segment like this:

This is a much easier way to see the differences. You can add up to three different versions to the Fallout report, so here is an example if I wanted to view All Visits, US Visits and Europe Visits together:

Additional Info

So that is a quick tutorial on the new Fallout visualization. I hope it helps you see some of the power that now exists. To see some more cool ways you can use this new functionality, check out this blog post by Antti Koski and watch this YouTube video from Adobe. Enjoy!

If you are an online retailer, there are situations in which you will offer your products in various pricing states. For example, there may be some products that are on sale, some that have discounts based upon a discount code or some that are on clearance. In these cases, you may want to document the original price, the discounted price and see how the pricing state impacts conversion. In this post, I will show how to do this in Adobe Analytics and a few examples.

Capturing the Pricing State

The first thing you may want to see is whether pricing state has any conversion implications. This can be tracked in general and by product or product category. To do this, you will want to set an eVar with the current pricing state when visitors open each product page. For example, if a visitor opens Product A and it is a product priced at retail price, you may pass the phrase “retail price” to the eVar. But if a product is discounted, you would pass in the type of discount the visitor saw. Let’s imagine that your visitor viewed a product that had this pricing associated with it:

In this case, the pricing state was “clearance” and it was discounted sixty-seven percent. There are a few ways to capture this, but to save eVars, I would probably capture this as “clearance:67” in the eVar to denote that the active pricing state was “clearance” and the percent off amount. Here is what the report might look like when viewed with the Product Views Success Event (with retail price value excluded):

This report can be broken down by Product as needed or you can begin with the Products report and then break that down by Pricing State as needed. And if you have classified your Products into Product Categories, you can see the same information by Product Category.

Of course, those who have been reading my blog for a while may recognize that this new “Pricing State” eVar will require the use of Merchandising. This is due to the fact that your visitors may view multiple products, and Adobe Analytics needs to record the pricing state for each product viewed versus just storing the last pricing state and applying that to all products (as would be done with a non-Merchandising eVar). In this case, since we are setting the Pricing State eVar on the product page where we are already setting the Products variable, I would suggest using Product Syntax Merchandising.

Once you have set the eVar, each product viewed will have a its own Pricing State value and Adobe Analytics will wait and see which products are purchased in the visit or beyond (depending upon your eVar expiration). That means that you can add both the Product Views and Orders metrics to the Pricing State eVar report and create a calculated metric to see the conversion rate. The report may look something like this (again shown with retail pricing filtered out):

This type of report will allow you to see if any combination of pricing state and discount percent performs better than others. You can use the search filter or segmentation to narrow down items as needed (i.e. just sale rows).

By capturing both the pricing state and the discount percent in the same eVar, you can later use the SAINT Classifications Rule Builder to group all items by pricing state (i.e. all “clearance” items together) and use REGEX to see a report by discount percent. That gets you three reports with only one eVar. You can switch to the pricing state type classification to see a higher-level view of conversion by pricing state as shown here:

Or you can switch to the discount classification to see performance by discount amount, agnostic of pricing state as shown here:

Pricing State Metrics

While conducting analysis related to Pricing State, keep in mind that it is also possible to capture the dollar amounts associated with Pricing States in currency Success Events. Since all of the amounts are present the product page, it is simply a matter of passing the correct amounts to the appropriate Success Events. Let’s look at this via an example. If a visitor views the product shown above, you know that the original price was $40 and the current price is $12.99. Therefore, if a visitor orders this product, $12.99 will be passed to the Revenue metric (using the Purchase event), but nothing will be done with the $40 amount.

But if desired, you could capture the original $40 price on the order confirmation page in a new metric called “Original Price.” This new metric would always capture the original price and can be compared to the Revenue amount by Product or Product Category. This can be done by creating a calculated metric that divides Revenue by this new Original Price metric. You can add this calculated to the Products report or the Product Category report to see which products and categories are selling the most/least at a discount as shown here:

On its own, this new calculated metric will show you percent of discount across the entire site. This might be an interesting KPI to monitor or upon which to set alerts in Adobe Analytics:

Another cool way you can use these metrics is in the Campaigns area. By opening the Campaigns report, you can see which campaigns lead to the most/least discounted sales (see below). This might help you shift marketing dollars to campaigns that are driving sales for non-discounted products.

These are just some of the ways that you can augment your Adobe Analytics implementation by capturing data related to pricing state and discount amounts. Enjoy!

While using Adobe Analytics, there will be times when you want to see how often visitors go from Page A to Page B to Page C, etc. This is easy to do with Adobe Analytics Pathing reports. You can use the “Next Page” or the “Next Page Flow” report to see this. But when you run these reports, you are seeing only a one-time snapshot of the paths. For example, if you are looking at the month of August, you will see how often visitors in that month went from Page A to Page B, but not see if that behavior is trending up or down over time. There will be situations when you want to see the trend data, but the normal pathing reports don’t show this unless you know how to find it. Therefore, in this post, I will demonstrate how you can tweak the pathing reports in Adobe Analytics to see pathing trends and provide a few examples.

Trending the Next Page Report

To demonstrate how you can trend the paths between two pages, let’s imagine that you want to see how often visitors navigate from your home page to your blog page. To do this, you would open the Next Page Path report and at the top right, select the start page, which in this case is the “home” page. Once you do that, you will see a report like this:

This report shows all of the times that visitors went from “home” to any other page. In this case, I am interested in those going directly to the “blog/” page, which looks to happen approximately 6% of the time. Next, you can click the “Trended” link near the top-left and view this report in the trended view. This is similar to other Adobe Analytics reports that you may have trended in the past. In this case, you will use the “Selected Items” area to manually select the “blog/” page as the one you want to see trended and when you are done, you would see a report that looks something like this:

In this report, you are seeing the weekly trend of paths from “home” to “blog/” and can save, bookmark or email this report or add it to a dashboard. If you want to see the trend by day or month, you can change the settings in the calendar or by changing the “View By” setting near the top-left. So with a few clicks, you can trend paths between two pages. This is a feature that has always been in the product, but I am amazed how few people know that it is there.

But Wait…There’s More!

In addition to seeing trends of page paths, there is more you can do with this concept. As I have preached for years, Pathing in Adobe Analytics is one of the most under-utilized features. There are many times where you would like to see the sequence of events including KPI Pathing, Product Cart Addition Pathing, Page Type Pathing, etc. For all of these items, you can also see pathing trends as shown above.

For example, let’s say that you have a blog and want to see how often visitors view two posts in succession. In my case, I have a popular blog post on Merchandising and another more advanced follow-up post on the topic. If I pass the title of my blog posts to an sProp with Pathing enabled, I can choose the first Merchandising post and then see how often the next post viewed is the advanced follow-up post. To do this, I open the Next Page path report for the “Blog Post Title” sProp, choose the first post (Merchandising as shown below) and then view the subsequent posts.

Next, I switch to the trended view of the report and use the report settings to isolate the follow-up post as shown here:

Now I can see the trend between these two posts over time and see how they are doing. In this case, I don’t see a lot of follow-up blog post views. This is probably due to the fact that the follow-up post was created after the first one and there is no link tying the two together. I can then add a link to the bottom of the first post advertising the follow-up post (which I am going to do right now in fact!) and then watch the trend line to see if that results in an increase.

Using Sequential Segmentation

There is an alternative method of seeing the trends between two pages and it involves the use of the sequential segmentation feature. For those, not familiar with sequential segmentation, you can check out this video by my partner (even though it uses Discover, the concept is the same), but it is essentially segmenting on the order in which data is collected or events are set.

Let’s look at an example that shows how this is both similar and different from what we covered above. Let’s start by using the Next Page Path report like we did above to see a week trend of paths from the “home” page to the “blog/” page:

Now, let’s create a sequential segment that isolates visits in which visitors saw the “home” page and then saw the “blog/” page. This is done by adding the Page dimension to a Visit container twice, defining each one with the appropriate page name and using the “Then” operator between them as shown here:

Once you have this segment defined, you can apply it to the Visits report and you should see similar trend data as we saw above. For example, if we look at the same week, here is the trend:

However, as you may have noticed, the data is slightly different (31 vs. 38). This is due to a technical “gotcha” that you need to take into account when using sequential segmentation. The segment above includes all visits where people viewed the “home” page and eventually saw the “blog/” page. This doesn’t necessarily mean that they went directly from the “home” page to the “blog/” page like they did using the Next Page Path trend report. If you want to make sure that it was a direct path you have to define the “Then” operator further by constraining it to “within 1 Page View” as shown here:

Once this more detailed segment is applied, the trend of Visits should be the same (or very close) to what was shown in the Next Page Path trend report as shown here:

There are times when you may want to do more advanced analysis that goes beyond the Next Page Path trend report, so knowing how to see pathing trends both ways is advantageous.

So there you have it. A few ways to see trends of paths for you to add to your Adobe Analytics arsenal. If you have any questions, feel free to leave them as a comment here.

Last week, I covered some of the cool new Success Event allocation features available in Adobe Analytics. These new allocations allow you to create different flavors of Success Events for Last Touch, Linear, Participation, etc. In this post, I will build on last week’s post and cover one of my favorite allocation additions – Reporting Window Participation. If you haven’t read the previous post, I recommend you do that first.

Expanding the Participation Window

In the last post, I demonstrated how you could create Visit-based Participation versions of any Success Event in your implementation. However, one of the six new allocation options is one that I can’t resist talking about because it is something I have been eagerly awaiting for years – “Reporting Window Participation.” While the Participation feature has been around for over a decade, it has always been limited to the session (Visit). This means that if you wanted to see which pages lead to orders, you could use Participation, but your data would be constrained to pages they viewed within a visit. That means if a visitor viewed ten pages, then came back tomorrow and viewed five pages and completed an order, only the last five pages would get credit, which can be very misleading.

But as you will notice, one of the new allocation options in the Calculated Metric Builder is called Reporting Window Participation and this allows you to see which items within the entire date range you are looking at led to the success event. So if you created an Orders Participation metric based upon the Reporting Window, all fifteen pages in the preceding example would get credit for the Order. This makes reporting more accurate and interesting.

Another great use for this is marketing campaigns. In the past, if you wanted to see which Orders or Leads were generated from each campaign code, your options were basically First Touch or Last Touch. But if you create a reporting window participation metric and view it in the campaign tracking code report, you can see which campaign codes, across multiple visits contributed to success. While this is still not true attribution (which divides credit as you desire), it does provide additional insights into cross-visit effectiveness of campaign codes.

To illustrate how the Reporting Window Participation feature works, let’s build upon the blog post example from my previous post. In this case, I want to do a similar analysis, but remove the Visit constraint from my analysis. To do this, I repeat the steps from the previous post to create a new Participation metric for Blog Post Views, but this time, change the Visit Participation to Reporting Window Participation like this:

When this is added to the report (I am using a longer duration period of several months), I can now see the difference between Visit and Reporting Window Participation:

As you can see, the Participation in the Reporting Window is much greater than the Visit. This means that visitors [who don’t delete cookies] are coming back and viewing multiple posts, just not always in the same session. If you want, you can create another calculated metric that divides the Reporting Window Participation by the original metric to see which post gets people to view the most other posts within the longer reporting window timeframe:

In this report, you can see blog post pull-through for the visit or the reporting window and do some analysis to see how each post does in each scenario.

Finally, if you read my post on using Scatter Plots in Analysis Workspace, you can compare blog posts views and Participation (pull-through) to see which posts have the most pull-through, but lower amounts of views:

Here you can see that I have some blog posts with a very high pull-through, but low views in the top-left quadrant. These may be ones that I want to publicize more since they seem to get people to read other posts afterwards in the same visit or a subsequent visit. Keep in mind, that this example is using blog posts, but the same type of analysis can be done to see which products on your site people view that lead them to view other products, categories lead to other categories, videos lead to other videos and so on.

One other note that has come to my attention is that Reporting Window Participation is, at times, based upon full months, such that selecting a mid-month date range might include data from the beginning of the month. You can learn more about that in this knowledge base article.

So between these two posts, you have a quick tutorial on how to find and use some of the new Success Event allocation options in Adobe Analytics. For more information, check out the Adobe documentation and there is also a video Ben Gaines created that you can view here.

Recently, the Adobe Analytics product team made some enhancement to how metrics (Success Events) can be allocated using the Calculated Metric Builder. I have noticed that many people have not learned about this new update, so I am going to share a bit more information about it and some examples of how it can be used.

Allocation of Success Events

As I have explained in numerous past blog posts, when a Success Event fires in Adobe Analytics, that number (which can be a 1 or more) is bound to the current eVar value for each eVar report. For each eVar, you can choose if the metric is allocated as First Touch, Last Touch or Linearly (divided amongst values within the visit). It has been this way for years. However, those who have used the Ad-Hoc Analysis product (formerly Discover), have probably seen that each metric can be viewed as Last, Linear or as the Participation version (Participation gives credit to all values viewed) in each eVar report. That was a cool bonus of using Ad-Hoc – even if you choose First Touch for an eVar, in Ad-Hoc, you could see Last Touch as well and not have to waste more eVars.

Now, this same concept has been brought to the normal Adobe Analytics Reports (browser) interface through the Calculated Metric Builder. This means that you can see different flavors of Success Event metrics by Last, Linear and so on. There is even a great new one added that expands upon the use of Participation that I will cover in Part two of this post next week. To illustrate what has changed, let’s look at what is new in the Calculated Metric Builder:

Here you will notice that there is a new/expanded Allocation drop-down box found within the gear icon of a Success Event that has been added to the Calculated Metric Builder. This drop-down allows you to choose which “flavor” of the Success Event you want to use in your calculated metric and you will notice both familiar and some new options. Unbeknownst to you, metrics added have always been using the “Default” option unless you manually changed it. But now there are additional options here, such as Linear, Visit Participation, Reporting Window Participation, Last Touch, etc. By selecting one of these and providing your metric with a new name, you can create a brand new metric.

Since this can be a bit confusing, let’s look at an example of how this new feature can be used. For this example, I will use the “Visit Participation” option within the Allocation drop-down. The scenario is that I have a blog and I have an eVar that captures the title of each of my posts. This is a Last Touch eVar and is commonly used with a Blog Post Views success event. Here is what a typical report looks like:

Now, let’s say that I want to see which of my blog posts gets visitors to view the most other blog posts. To do this, I would normally go to the Admin Console and enable Participation on the Blog Post Views success event and then I would see a new metric called Blog Post Views Participation. This metric would give one “point” to each blog post title that is viewed and another point to each blog post for subsequent views of blog posts. For example, if someone viewed the Merchandising blog post and then viewed the Cohort Analysis post, the Merchandising post would receive two Participation points – one for itself and one for the Cohort post. Then I could divide the total Participation points by the total Blog Post Views to see which post had the most “pull-through.” This is something that has been done for years and you can read more about it here in my old Participation post (from 2009!).

But what has changed now, is that you no longer have to be an Adobe Analytics Administrator to do this. Traditionally, only Admins have been able to turn on Participation, so end-users were stuck until they could get help. But now, you can create a Participation version of any Success Event right in the Calculated Metric Builder. Here is how you do it:

• To begin, simply open an eVar report and add the metric for which you want to see Participation like what you see in the report above (note that you can create the Participation metric outside of a report, but I will do it within the report context to simplify things)
• From here, use your link of choice to bring up the metrics left-nav window and click “Add” to create a new metric
• Next, drag over the metric for which you want Participation, which in this case is the Blog Post Views Success Event
• Then, click the gear icon and then the Allocation dropdown to display the options. When you complete these steps, it should look something like this:

In this scenario, you will select the “Visit Participation” option and provide an appropriate name for the metric until you have something that looks like this:

When I save this and add it to my report, you’ll see this:

This report is the same as you would have seen if your administrator has enabled Participation for the Blog Post View success event. The Participation numbers will be higher than the raw metric because each blog post gets a “1” for itself and then credit for subsequent posts viewed. The closer the numbers are in the two columns, the less the post drove views of other posts. If you want, you can even create a calculated metric that divides this new Participation metric by the original metric. The formula might look like this:

Adding this new metric to the report would show us which blog posts are the best at pulling visitors into other blog posts as shown here:

Using this report, you can easily see that the Merchandising post drives more posts than the Advanced Search Filters post. If you wanted, you could even re-sort to find the posts that have the most pull-through:

In the end, the cool addition here is that any end-user can enable Participation for any metric without having to get any approvals or harass your Adobe Analytics administrator. But at a higher level, you can create six new flavors of each Success Event in your implementation without having to do any additional tagging! In this post, there isn’t time to cover all six of the options, but most should be self-explanatory and can be created using the same steps outlined above. Next week, I will continue this topic with one of my favorite new additions – the Reporting Window Participation feature!

Last week, I wrote about how to use the new Venn Diagram visualization in Analysis Workspace. Now I will discuss another new Analysis Workspace visualization – the Scatter Plot. This visualization should be familiar to those in the field and has been available in Microsoft Excel for years. The purpose of the scatter plot is to show two (or three) data points on an x/y axis so that you can visualize the differences between them. In this post, I will continue using my blog as an example of how the scatter plot can be leveraged.

Scatter Plot Visualization – Step by Step

The first step in creating a scatter plot visualization is to create a freeform data table. This normally means adding a dimension and a few metrics. I would recommend starting with two metrics that you want to see plotted against each other. Here you can see that I am looking at my blog posts sorted by popularity and also added Visit Time Spent:

Once I have this table the way I like it, I can drag over the scatter plot visualization and then highlight the two columns to see this:

In this case, I am seeing the views of each blog post on the “x” axis and the time spent on the “y” axis. Blog posts that have a lot of views will appear on the right side of the visualization, while those with fewer views will be on the left. At the same time, those with more time spent in the visit will be near the top and those with lower time spent will be near the bottom. Blog posts with the most views and the most time spent will be in the upper-right quadrant. You can hover your mouse over any of the scatter plot points to learn more about it. For example, if I want to see what the best item is at the top-right (in green), I can hover to see this:

In this case, my post on Merchandising eVars seems to be the one viewed the most and with the most time spent (probably because Merchandising is a tricky topic!).

Most web analysts use scatter plots to identify improvement opportunities. For example, if you are plotting products, cart additions and orders, you can see which products have a high number of cart additions, but a low number of orders and figure out ways to take action on that. In this case, I may look for blog posts that have a large amount of time spent (which may mean that they are engaged with the content), but a low number of views. In this example, I might hover over the purple circle and see this:

This may indicate that I need to promote this report suite tweaking blog post more to get it more views.

When using scatter plots, there are some ways you can customize what you see in the visualization. If you want to flip the x/y axis, you simply reverse the metric columns in your freeform data table. If you want to see percentages instead of raw numbers, you can do this in the settings as well. You can also choose whether or not you want to see a legend in the visualization.

Finally, if you want to plot an additional data point, you can add a third metric to your freeform data table and the scatter plot visualization will modify the size of the circles to reflect the size of the new data point. For example, if I add Average Page Depth to the freeform table, the circle size will reflect the average depth associated with each blog post. Now I can see that my Merchandising post seems to be more of a “one and done” reading versus other posts that appear to be viewed concurrently or with other website content.

Seamless Adobe Analytics Integration

One of the best parts of Analysis Workspace and its visualizations is how seamlessly it works with the other aspects of Adobe Analytics. Last week, I showed how you can apply segments to Venn Diagram visualizations and the same is true for scatter plots. But the integration doesn’t end there. Imagine that I look at some of the visualizations above and ask myself, “which types of blog posts do people view the most and spend the most time on?” While the above visualization helps me differentiate the different blog posts, I tend to write a lot of posts and that can make it difficult to see the big picture. To conduct this kind of analysis, I can use SAINT Classifications to associate a “Blog Post Type” with each blog post. In my case, my blog posts tend to be either about Adobe Analytics features, types of analyses you can do, implementation best practices, etc. So if I put each blog post into one category or type using SAINT, I can get a much higher level view of how my blog is performing. Here is a sample of what my SAINT file might look like:

Once this is done, I can repeat the above steps to create a scatter plot, but this time, instead of using the Blog Post Title dimension, I will use the Blog Post Type dimension (classification of Blog Post Title) and re-build my scatter plot. This allows me to see fewer data points, since all of my blog posts have been grouped into a small number of types:

This new scatter plot allows me to see that blog posts focused on implementation best practices and analyses tend to get the most views and have the most time spent. Posts around product features are next, but have a drop-off in the time spent. I can also see that posts on Analysis Workspace have a low number of views and time spent, but I attribute that to the fact that those posts haven’t been around very long and I would expect that category to move closer to the pink circle (Adobe Analytics product feature posts) over time. Finally, I can see that my posts about training classes and my miscellaneous posts that are a bit different don’t seem to get as many views or time spent. This combination of SAINT Classifications and the scatter plot allows me to learn things that I could not have easily surmised by looking at the scatter plot of the individual blog posts above.

As you can see the combination of pre-existing Adobe Analytics features and the new Analysis workspace visualizations can be extremely powerful. Since they are easy to build, unlimited and have no additional cost, I suggest that you try them out with your implementation. Enjoy!

If you are an Adobe Analytics customer, you have probably noticed that they have been tearing it up lately when it comes to Analysis Workspace. There has been a lot of cool innovations and fun stuff for you to play around with in this new freeform interface. Being an “old fogey” myself, sometimes it takes me a while to play around with the new stuff, but I have started doing that lately and found it to be interesting. In this post, I will demonstrate how you can use the new Venn Diagram visualization to do analysis.

Venn Diagram Visualization

If you are in the analytics space, you probably already know what a Venn Diagram is, but just to be sure, it is a data visualization that allows you to see how much of an overlap there is between data elements. In Analysis Workspace, Adobe allows you to add up to three Segments to the Venn Diagram and then choose a metric for which you want to see the intersection. To illustrate this, let’s look at an example. Let’s say that I want to see what percent of visitors to the Analytics Demystified blog view my blog posts and I also want to see how often my competitors are reading my blog posts. The first part is relatively easy, since I can build a segment to see which visitors view at least one of my blog posts. The latter requires me to use a tool like DemandBase to identify the companies hitting my blog and then SAINT Classifications to pick out companies that I think might be competitors of mine (or at least offer similar services to mine).

Once I have these segments built, I can go to Analysis Workspace and add the Venn Diagram visualization to the canvas and add my segments and the desired metric:

Once this is done and I click the “Build” button, I will see the Venn Diagram like this:

Here I can see that I have 26,000 unique visitors that have viewed my blog and about 4,000 competitors who viewed our website. But if I want to see the intersection of these, I can hover over the overlapping area and see this:

Now I can see that there are about 1,300 visitors (~5%) who have read my blog and are competitors.  I can also click the “Manage Data Source” area to see a tabular view of this data if desired:

Next, I might want to do more research on the intersection of these two segments. To do this, I simply right-click on the overlapping area and create a brand new segment from the Venn Diagram overlap:

This will take me to the segment builder, where the segment is already pre-populated and I can make any tweaks necessary and provide a name:

Now that I have a brand new segment, I can use it like I would any other segment anywhere within Adobe Analytics. In this case, if I want to see the specific list of competitors reading my blog, I can add a new freeform table and add the DemandBase Company eVar, the Visitors metric and then apply this new segment to see the top competitors viewing my blog:

Of course, I can use the unlimited breakdown feature of Analysis Workspace to drill down as much as I want. For example, I can see exactly which blog posts a particular company is viewing, I can break that down by the Blog Post eVar and maybe even again by the Cities report:

As if that weren’t cool enough, I can also apply additional segments to the entire workspace canvas and those segments will be applied to ALL elements on the workspace canvas. For example, I noticed in the table above that a lot of competitors reading my blog appear to be from overseas. If I want to limit all of this data to companies hitting my blog from the US only, I can create a US Only segment and apply that to the entire canvas by dropping it into the segment area at the top of the page:

This will limit all of the canvas visualizations to US Only data and all of the tables and Venn Diagram will instantly update!

As you can see, the Venn Diagram visualization can be very powerful. Instead of creating hundreds of segments to identify interesting intersections, you can simply add them to the Venn Diagram visualization and then when you find the ones you like, create the segments right from there. These segments can contain visitors who viewed products from Category A and Category B or visitors who viewed a video and purchased. The possibilities are truly endless. I recommend that you pick some of your favorite segments and try it out. I think you will have a much fun as I have had seeing the intersections of your data.

One of the primary use cases for digital analytics tools like Adobe Analytics and Google Analytics (GA) is the ability to track external campaign referrals and see their impact on KPI’s. Way back in 2008 (yes, 8 years ago!), I blogged about how to track campaigns in Adobe Analytics (then called Omniture SiteCatalyst). Since then, a lot has changed in the online marketing landscape. With many digital marketers being exposed to Google Analytics, the way campaign tracking is done in GA has almost become the industry de facto standard. The most popular GA method uses a set of UTM parameters to identify the campaign source, medium, term, content and campaign (though there is a “utm_id” option similar to how Adobe does it). These parameters are normally passed in the URL and parsed by GA to populate the appropriate analytics reports. But as Adobe Analytics users know, Adobe uses one variable (s.campaigns) to track external campaigns. So what if you are running both Adobe Analytics and Google Analytics or you simply want to use the Google standard since that is what your advertising agencies are using? In this post, I will show how you can make the UTM campaign code tracking standard work in Adobe Analytics so your campaign data matches what is in GA.

Updating the Query String Parameter Code

Most Adobe Analytics clients are using something akin to http://www.mysite.com?cid=abc123 in their URL’s and having the GetQueryParameter JavaScript Plug-in pass the value after “cid=” to the s.campaigns variable. But in reality, you can pass any values you want to s.campaigns and the plug-in can be configured to look for any query string parameter. Therefore, if you want to use the UTM campaign parameters, you can adjust the plug-in to concatenate the values into one string with a separator and pass it to the s.campaigns variable. For example, if you view the URL below, you will see that I have used four out of the five UTM parameters in the URL:

From here, the plug-in does the concatenation and as you can see in the JavaScript Debugger, here is what is passed to the s.campaigns variable in Adobe Analytics:

If you want more details on the technical implementation of this, you can check out this article on the Adobe forum.

Reporting on UTM Campaign Codes

Once you have completed the above technical implementation and have campaign data populating into Adobe Analytics, here is what it might look like in the campaigns report:

Now that you have the data in a consistent format, you can use SAINT Classifications to split out each of the parameters into separate reports. To do this, you would add a new SAINT Classification for each UTM parameter you used. This is done in the Administration Console and as shown below, I have added four new classifications (Source, Medium, Campaign Description and Campaign Owner):

Once you have your classification reports created, you need to tell Adobe Analytics how to populate them. You could upload the meta-data manually, but the easiest way to do this is to use the SAINT Rule Builder, which allows you to automate the classifications using RegEx or other methods. In this scenario, RegEx is the most logical option since it can be used to parse out each parameter using the “:” as the separator. This is what the rule set would look like:

Once this is activated, you can see your campaign data in each of these reports (Source report shown here as an example):

Final Thoughts

It is up to each organization to decide how it wants to track its marketing campaigns. I have many clients who like to customize how assign campaign codes, so please don’t take this post as a recommendation for adopting the UTM approach. A similar process can be adopted no matter what naming convention you decide to use for your campaign codes. However, there are many benefits of adopting naming conventions once they become a standard, such as integration with 3rd party tools and data integration. It is my hope that this post simply educates you on how you can use the UTM campaign code approach in Adobe Analytics if needed. There is more discussion on this topic in Quora if you are interested in delving into the topic in more detail.

In my last post about Virtual Report Suites, I discussed some of the pros and cons of consolidating an Adobe Analytics implementation with multiple report suites into one combined report suite and using Virtual Report Suites. However, one of the reasons why your organization might not be able to combine its report suites and leverage Virtual Report Suites, is the pervasive problem of report suite inconsistency. This is a topic I have ranted about periodically, most recently in this post about whether you should start over when re-implementing Adobe Analytics. In this post, I will review why report suite inconsistency is important, especially as you consider moving to an implementation with fewer report suites and more Virtual Report Suites.

Why Are Report Suites Inconsistent?

Most organizations implementing Adobe Analytics have the best intentions at the start. They want to implement one site and track the most important items. But after a while, things start to go downhill. A second site is implemented and it has some different needs, so different variables are used. Then maybe a different team implements a mobile app and yet another set of variables is used. This process continues until the organization has 5-10 report suites and very little is common amongst them. You know you have a problem when you see this in the Administration Console (with all of your report suites selected):

It is so easy to fall into this trap, so I don’t mean to blame you if it has happened to your organization. Often times, it was done by your predecessors over a long timeframe. Unless you have strict policies and procedures to prevent this type of inconsistency, it is will happen more often than not.

Of course, there are specific cases where you want different report suites to be inconsistent and for which seeing a “multiple” above is expected. For example, you may decide that each report suite will have 5-10 variables that are unique to each suite and for those variable slots, any data they want can be collected. I have many clients who specify 20 eVars, 20 sProps and 50 Success Events to be “local” variables that are purposely not consistent across report suites. That is a valid approach and requires discipline and management to enforce. The report suite inconsistency I am talking about is the unintentional inconsistencies that occur in many Adobe Analytics implementations. This is what I hope to help you avoid.

Why Is Report Suite Inconsistency Bad?

There are several reasons why not having report suite consistency can hurt you. Here are some of the ones that I encounter the most:

Data in Global Data Set Can be Wrong

If you have different data points feeding into the same variable in different report suites, when you combine the dataset, you will have different values rolled up. For example, if you track Cities in eVar5 for one suite and Zip Codes in eVar5 for another, in the shared data set, you will see a mixture of Cities and Zip Codes. This is even worse if you think about Success Events. If you are tracking Leads in event1 in one suite and Onsite Searches in event1 for another suite and roll the data up, you will see a sum of Leads and Onsite Searches in the shared data set and have no way to know which is which! That can get you in a lot of trouble, especially if you label event1 as Leads in the shared data set and many of the numbers represent Onsite Searches!

Can’t Use Virtual Report Suites

As mentioned in my previous post, if you want to save money on secondary server calls and consolidate your report suites into one master suite (using Virtual Report Suites), you need to make your report suites consistent. This is due to the fact that having one master report suite necessitates having just one set of variable definitions.

Can’t Re-Use Reporting Templates

One of the greatest benefits of having consistent report suites is the re-use of reports and reporting templates. If you use the same variables across multiple report suites, you can easily jump from one Adobe Analytics report to the same report in another suite, by simply changing the suite in the top-right dropdown. Let’s say that you have configured a great report in Adobe Analytics with a dimension and a few metrics. With one click you can change the report suite and see the same report for the second report suite without any re-work. The same applies if you use dashboards or reporting templates in Adobe ReportBuilder. Adobe ReportBuilder is where report suite consistency pays off the most, since you may spend a lot of time getting your Excel reports/dashboards to work and formatted properly. But this time can be leveraged for multiple report suites by tying the report suite ID to a cell in Microsoft Excel and refreshing the data for a different suite. If your report suites aren’t consistent, you would have to have different data blocks for each report suite and lose out on one of the best features of Adobe ReportBuilder.

Can’t See Aggregated Pathing

If you having Pathing turned on for sProps, you can see paths before and after specific items, but only for paths within the site for which the report suite is configured. If you send data to a global (shared) report suite, you can see paths across multiple web properties as long as both have the same sProp and Pathing enabled. For example, let’s say that you have a search phrase sProp20 with Pathing enabled in your Brand A report suite, but for Brand B, you have the search phrase in sProp15. In both of these report suites, you can see the Pathing of search phrases, but if the same person visits both brand sites in the same session, you might want to see search phrases paths across both sites. Even if you have a global (shared) report suite, you cannot see this, since the data is being stored in two different sProps. But if you had used the same sProp in both suites, you could see all search phrase Pathing in the global (shared) report suite for the entire session.

Can’t Re-use Training and End-User Documentation

I always like to provide good end-user documentation and training for implementations I work on. This means having some sort of file or presentation that explains each business requirement, how it is tagged, what data is collected and how it can enable analysis. I also like to provide training on how to use Adobe Analytics and the key reports/dashboards that have been pre-built for end-users. When you have a consistent implementation across multiple sites, you can build these deliverables once and re-use them for all sites. But if you have an inconsistent implementation, you have to create these deliverables multiple times, which can use up a lot of unnecessary bandwidth.

Can’t Use Consistent Tagging/JS File/Tag Management Setup

Last, but certainly not least, having inconsistent variable definitions means that each site has to be implemented slightly differently. Instead of always passing search phrases to sProp20 (as in the preceding example), your developers have to know that for Brand B, they have to place that data in sProp15 instead. Even if you use a tag management system and a data layer, you still have to configure your TMS differently by report suite, which increases your odds of mistakes and data quality issues. In addition, documentation of your implementation becomes much more difficult and time-consuming.

How Do You Avoid Report Suite Inconsistency?

So, how do you avoid report suite inconsistency? That is often the million dollar question, but there is no perfect answer for this (unfortunately). In my experience, this comes down to process and coordination. When I ran the Adobe Analytics implementation at Salesforce.com, I ruled it with an iron glove. I was the only one with Admin access, so no one could add any variables to any report suites without going through me. But since that approach might not be practical at larger organizations, I recommend that you have a shared solution design document that is kept up to date and always in line with the settings in the Adobe Analytics administration console. You can do this by comparing the two at least once a month and by using the administration console to compare the variables across your report suites. I also recommend that you drive your analytics program by business requirements instead of variables, so that you are only adding variables when new business requirements arise. I explain more about that process in my Adobe white paper.

Final Thoughts

Having consistency in your analytics implementation is difficult, but a goal worth striving for (in my opinion). I hope this post helps you see why it is advantageous and why I encourage my clients to pursue this goal. While it may take a bit more planning and forethought in the beginning of the process, it definitely pays dividends down the road. If you have any thoughts, questions or comments, please let me know.  Thanks!

Recently, Adobe provided an Adobe Analytics update that includes a cool new feature called “Virtual Report Suites.” Virtual Report Suites are an exciting new way to segment your Adobe Analytics data and control access to it. In this post, I will share some of my thoughts on this new feature and share some resources that Adobe has provided so you can learn more about it.

A Brief History Lesson

Before I get into Virtual Report Suites, I think it is worthwhile to go back in time to see how this feature evolved, and why it is so cool. Back in the early days of Omniture SiteCatalyst (I am dating myself!), it was not possible to segment data instantaneously. To see segmented data, you had to either run a DataWarehouse report or use the Discover product (now called Ad Hoc Analysis). But there was also another feature that wasn’t used very often called Advanced Segment Insight (ASI). ASI was a way that you could define a segment and then re-process all of your data for just that segment and it acted just like a new report suite. However, the data was usually about 24 hours in arrears, so it didn’t provide anything close to real-time segmentation.

With the advent of instant segmentation in v15 of Adobe Analytics, the entire game changed for Adobe Analytics customers. Suddenly, you could segment data in real-time! This meant that ASI was no longer needed, so that feature was phased out of the product (or at least hidden!). This new ability to instantly segment also brought with it some new Adobe Analytics architecture considerations. For example, people began wondering whether they still needed to have multiple report suites and pay for extra secondary server calls. Why not just throw all of your data into one massive report suite and use segmentation to narrow down your data set? This would save money and avoid having to deal with different report suites. As I outlined at the time in this blog post, some of the reasons to not go down to one report suite were as follows:

• The complexity of segments your users might have to make when dealing with just one data set;
• The fact that even though you could segment, you could not enforce security constraints, so everyone could see all data in the combined data set (i.e. users in the UK can see USA data and vice-versa);
• You could not have different local currencies in the combined data set, so you’d have to pick just one currency.

For me, the most critical of these items was #2 – the one around security. But many companies over the last few years have decided to consolidate their implementations and trade segmentation complexity and data security control for implementation complexity and to save some money.

Virtual Report Suites

Now let’s chat about Virtual Report Suites. This new feature allows you to create a new report suite based upon a segment definition and have its data available in near real-time. When you create a Virtual Report Suite, it appears in the list of report suites with a blue dot to differentiate it. This is really what ASI should have always been if the technology would have allowed it! The cool part about Virtual Report suites is that they solve the #2 item about around security. With Virtual Report Suites, you can assign users to a security group and limit what data they can see. Here are some examples of how you can use this new security feature:

• You have multiple brands as part of your company and want to track all data in one report suite, but only let marketers from each brand see their own data;
• You have multiple country websites and want to track all data together, but only allow each country marketing team to see its own data;
• You have an agency that you work with and want them to see campaign and some conversion data, but not all of your analytics data.

As you can see, the addition of security can tip the scales towards a consolidated report suite approach. For those clients of mine that were worried about security, they now have one less reason to not reduce the number of report suites they maintain.

Obviously, the main driver for consolidating your report suites into one combined one is to save money on your Adobe contract. Secondary server calls can add up quickly and money saved can be applied to more analysts or adding Adobe Target to your implementation. Combining report suites also avoids some of the inconsistency issues I find in client implementations described in this post.

However, there are still some “gotchas” you need to consider before you decide to consolidate all of your report suites into one suite and use Virtual Report Suites. Adobe has outlined these considerations in this great FAQ document. Here are the ones that jump out to me as being most important:

• Unique Values – Sometimes combining data sets leads to variables exceeding the monthly unique value limits (normally 500,000). Exceeding this limit has negative ramifications when it comes to segments and SAINT Classifications;
• Current Data – If you like seeing up to the minute data in your Adobe Analytics reports, you will only be able to see that in the normal report suite, not the Virtual Report Suites;
• Non-Shared Variables – If you have different report suites for different sites, you can provide each site with its own set of non-shared variables. This means that Site A might use eVars 75-100 to track different things than Site B does. But if you combine your data sets, you cannot have different values in the same variable slots, so you you might have to allocate different variable slots (i.e. Site A gets eVars 75-85 and Site B gets eVars 86-100) to each site and might not have enough variables to go around;
• Full Picture – One of the issues of using multiple report suites or Virtual Report suites is that sometimes your users don’t get the full picture when doing analysis. For example, if you have a segment that looks for visits that enter on a campaign landing page, when you look at the segmented reports, it will show a different story than the main report suite where visitors could have entered on any page. This means that paths, participation and eVar allocation are all different between the main suite and the multi-suite tagged or Virtual Report Suite.  That isn’t necessarily a bad thing, but it can be if the people doing analysis don’t realize or remember that they are not seeing the full picture. Here is a typical example. Imagine that a paid search campaign code drove lots of people to your website. You can see that clearly in your main report suite. But when you look at the Virtual Report suite, depending upon the segment used to create it, the primary entry pages may not be included, so the campaign variable isn’t populated. Therefore, when doing analysis in your Virtual Report Suite, you may find that most visits originate from “Typed/Bookmarked,” when, in fact, they were driven by a paid search campaign. This just takes some practice and education to make sure you don’t make bad business decisions due to your report suite architecture;
• Currencies – As mentioned previously, if you deal with multinational sites, you may want to have a different currency for each site and Virtual Report Suites don’t currently support this.

These are the main things I would suggest you think about, but you can get more information in the Adobe FAQ document. You can also check out the short video that Ben Gaines created on Virtual report suites here.

Final Thoughts

The addition of Virtual Report Suites is an exciting development in the evolution of Adobe Analytics and one that will definitely have a long-term positive impact. It brings with it the opportunity to drastically change how you architect your analytics solution. But making the decision to change your Adobe Analytics report suite architecture is not something you do every day. Therefore, I would suggest that you do some due diligence before you make any drastic changes. There are still ways that you can use and get value from Virtual Report Suites, even if you don’t choose to move all of your data into one combined data set right away. If you have questions or want to bounce ideas off me as an objective 3rd party, feel free to contact me.  Thanks!

As I work with and train clients to use Adobe Analytics, sometimes I encounter confusion around custom variables and segmentation. Both of these Adobe Analytics features are used to segment data, but they do so in different ways. In this post, I am going to take a step back and discuss how to think of these different product features in the proper context when doing analysis.

Custom Variables

So what exactly are custom variables? In daily use, Adobe Analytics custom variables are dimensions, taking the form of conversion variables (eVars) and Traffic Variables (sProps). Each implementation gets a specific number of these custom variables in addition to the ones that are provided out-of-the-box. These variables are used to track specific data elements that are meaningful to your organization. For example, if you have visitors log into your website (or mobile app), you may decide to allocate an eVar to the User ID  and pass that ID upon login. By storing this value in an eVar, any activity from that point forward can be associated with a specific User ID. The choice to use an eVar vs. an sProp depends on a few factors including how long you want the value to persist, whether you need Pathing, etc. Additionally, you can use the various expiration settings to determine for how long the User ID will be retained in Adobe’s virtual cookie.

However, one downside of custom variables is that activity is only tied to their values from the time they are set and afterwards. For example, in the scenario above, it could be the case that a visitor viewed twenty pages on the website prior to logging in and providing their User ID to the eVar. In that case, all of the activity from the first twenty pages will not be associated to any User ID. Therefore, if various Success Events are set (i.e. Cart Add, File Download) during those initial twenty pages, they would appear in the “None” row of the User ID eVar report. Unfortunately, over the years, I have seen that many Adobe Analytics customers don’t understand this nuisance, which is pretty important.

Ideally, you set as many of your custom variables as early as you can in the visit, but there will always be cases in which Success Events occur prior to an eVar receiving a value. Let’s illustrate this with another common example. Imagine that a visitor visits a B2B software site, views a bunch of products and eventually views the pricing page for a CRM product. Based upon the fact that they ended up on the pricing page of the CRM product, your marketing team chooses to assign a value of “CRM Prospect” to a “Marketing Segment” eVar. Hence, from that point forward, you can see all website activity for “CRM Prospects” by using the “Marketing Segment” eVar, but what about all of the activity that these people did before they were assigned to this segment? Up until that point, they were anonymous as far as that eVar was concerned. For example, if you were to create a Conversion Funnel report in Adobe Analytics and filter it by the “Marketing Segment” eVar value of “CRM Prospect,” you would only see filtered Success Events that took place (were set) after the eVar had been populated with the value. This can create issues at times and lead to real confusion.

In all of these cases, the common theme is that custom variables are useful, but sometimes don’t show the complete picture. Next we’ll talk about how using Segmentation can help complete the picture.

Segmentation

As you hopefully know by now, the Segmentation feature within Adobe Analytics allows you to narrow down your data set to only those hits, visits or visitors that meet the specific criteria you have added to your segment definition. This feature allows you to instantly focus your web analysis on the exact population you care about. As you would expect, the segments you create can use out-of-the-box data elements or any of the aforementioned custom variables. However, the reason why Segmentation is so powerful is that when you use a Visit or Visitor based segment, you are able to include all of the data that took place within the session (or beyond if using a Visitor container) instead of just the data that took place after a value was set in a custom variable.

Since this can be confusing, let’s use one of our previous examples to illustrate this. Imagine that you are interested in seeing the internal search phrases (stored in an eVar) used by visitors in the “CRM Prospect” segment, which uses the “Marketing Segment” eVar describe above. If you were to open the “Marketing Segment” eVar and find the row for “CRM Prospect,” you could then break this row down by the internal search phrase eVar (possibly using the “Internal Searches” Success Event) and see all of the search phrases used by that group of people. However, as explained above, you would really only be seeing the search phrases that were used after people were identified as being in the “CRM Prospect” segment. It is possible that some of the folks who eventually got placed in to the “CRM Prospect” segment conducted searches for various phrases prior to them being added to the segment. Therefore, using the custom eVar may not give you the entire picture.

If you want to be more thorough, in addition to using the custom eVar, you can rely on Segmentation to get your answer. In this case, you could create a segment in which the Visit contained a “Marketing Segment” eVar value of “CRM Prospect.” This means that Adobe Analytics will look for any activity that took place in the entire visit in which the “CRM Prospect” value took place. This segment would include all of the activity after the eVar value was set and the activity that took place before it was set. Once you apply this segment, if you open the internal search phrase eVar, the values in the report will, by segment definition, include all of the search phrases conducted by people who at some point were added to the “CRM Prospect” segment [for the advanced folks, you can even use exclude containers to take out any other segments if you want to be exact]. Therefore, the data you will get back using the custom variable approach may not be as complete as you would get back using the segment approach. This becomes even more potent if you use a Visitor container in your segment since that will include data from all visits in which a visitor was placed into the “CRM Prospect” segment.

Final Thoughts

While this topic can be a bit confusing to novices, it is something that is important for your end-users to understand. I often find that end-users are not properly trained on how to use Segmentation to its fullest extent and, therefore, many end-users rely solely on custom variables. This sometimes means that they are not getting the full picture when it comes to data analysis. It is for this reason that I suggest you read this post a few times and teach your users how custom variables really work, including what happens before and after they are set and how using Segmentation differs. You will probably end up seeing a steep increase in the usage of Segmentation as a result!

As someone who has made a living auditing, fixing and improving Adobe Analytics implementations, there are a few questions related to this that I receive all of the time. One of these questions, is whether a company doing a cleanup/re-implementation of their Adobe Analytics implementation should make changes to their existing report suite(s) or start over with brand new report suites. As you would expect, there is no one right answer to this, but I thought I would share some of the things I consider when making this decision.

Auditing What You Have

The first step of the cleanup process for an Adobe Analytics implementation is doing a thorough audit or review of what you have today. I can’t tell you how many companies I have worked with who hired me to do a “quick” review of their implementation and had no idea how inaccurate or bad it really was in its current state. Too often, I see companies that don’t question the data they are collecting and assume it is useful and that the data is correct. Trust me when I tell you that, more often than not, it isn’t!  I’d say that most of the companies I start with have scores around 60% – 70% out of 100% when it comes to their Success Events, eVars and sProps functioning properly. If you are unsure, I suggest you read this white paper that I wrote in partnership with Adobe (and if you think you may have some issues or want an objective validation that your implementation is in good shape, check out this page which describes my service in this area).

As you audit your existing implementation, you will want to make sure to look at the following:

1. How many report suites do you have and which are actively being used (and which can be hidden in the Admin Console)?  How consistent are these report suites?  If you select all of them in the Admin Console, how often do you see “Multiple” values?  The more you do, the more you may be in trouble.
2. How good is your data? If you have incomplete or inaccurate data, what is the value of sticking with your old report suites that are filled wth garbage?
3. How important to your business is year over year data? Some organizations live and die by YoY data, while others focus more on recent periods, especially if they have recently undergone a website re-design.

The answers so these types of questions will have impacts on the ultimate decision as I will dive into below.

Old Report Suites or New Ones?

So getting back to the original question – if you are going to re-implement, should you use existing report suites or new ones? The only way I can explain this is to show you the scenarios that I see most often.

Report Suite Inconsistency

If in the audit process above, you find that you have lots of report suites, and that the variable assignments in each of them are pretty different, the odds are that you should start from scratch with new report suites and, this time, make sure that they are set-up consistently. As mentioned above, the easiest way to see this is to select all of your active suites, choose a variable type (i.e. Events, eVars or sProps) and view the settings like this:

If you see this when selecting multiple report suites, the odds are you are in trouble, unless you manage lots of different websites that have absolutely nothing in common across them. I tend to see this issue most in the following situations:

1. Different sites are implemented by different parts of the business and no communication exists between them or there is no centralized analytics “Center of Excellence”
2. One business is acquired and both used the same analytics tool, but the implementations were done while the companies were separate
3. Two businesses or business units with different websites/products had implemented separately and, only later, decide they want to combine their data
4. A mobile team goes rogue and creates new report suites and tags all mobile sites/apps with a brand new set of variables without talking to the desktop group

Regardless of how you got there, the reason report suite inconsistency is so bad, is that salvaging it requires a massive variable reconciliation if you want to use your existing report suites and, even then, all but one suite is going to have different data in it than it did in the past. For example, let’s say that event 1 above is “Internal Searches” for two report suites and for the eight other suites has a different definition.  That means you have nine different definitions for event 1 across ten report suites. Even if you lay down the law and say that after your re-implementation, event 1 will always be “Internal Searches,” you will still have numbers that are not Internal Searches in eight out of 10 of your report suites historically. Thus, if someone looks at one of the suites that historically didn’t have event 1 as Internal Searches, for a long period of time, it will not actually be Internal Search data. Personally, I’d rather have no historical data than potentially misleading data. In addition, I think it is easier to start anew and tell the developers from all of your disparate sites that they must move their data from wherever they have it now to the new standard variable assignment list, rather than trying to map existing data to new variables using Processing Rules, DTM, VISTA Rules or other work-arounds.  Doing the latter just creates Band-Aids that will eventually break and corrupt your data once again in the future.

Here is an example of the eVars for one of my clients:

In this case, I only compared five different report suites out of more than fifty that they have in total. As you can see, reconciling this to ultimately have a global report suite or to send all data into one suite would be quite a challenge!

Conversely, if it turns out that all of your suites have pretty good variable definition consistency, then you can move the data from the incorrect variable slots to the correct ones in your lower priority report suites and continue using your existing report suites. For example, if you have one main report suite and then a bunch of other less significant report suites (like micro-sites), you may decide that you want to keep the main suite the way it is and force all of the other suites to change and adhere to the variable definitions of the main suite. This is a totally acceptable solution and will allow you to have year over year data for your main suite at least.

However, if you go down this path, I would suggest that if there are variables that the non-main report suite uses, that they be added to the main report suite in new variable slots so that eventually all of your report suites are consistent. For example, let’s say that one of the lesser important suites has a success event #1 that is registrations, but there is no registrations event in the main suite that you want to persist. In this case, you should move event 1 in the non-main suite to the next available event number (say event 51) and then add this event 51 to the main report suite as well. If you will never have registrations in your main suite, it is still ok to label event 51 as registrations, simply disable it in the admin console. This way, you avoid any variable definition conflicts in the future. For example, if the main report suite needs a new success event they would use event 52 instead of event 51 since they now know that event 51 is taken elsewhere. The only time this gets tricky is when it comes to eVars, since they are limited to 100 for most customers, but conserving eVars is a topic for another day!

Regardless of what you find, looking at the consistency of your variable definitions is an important first step in the process.

Data Quality

As mentioned above, if the data quality for your existing implementation isn’t very good, then there are fewer reasons to not start fresh. Therefore, another step I take in the process is to determine what percent of my Success Events, eVars and sProps in my current implementation I trust. As described in this old post, data quality is paramount when it comes to digital analytics and if you aren’t willing to put your name on the line for your data, then it might as well be wrong. Even if your report suites are pretty consistent (per the previous section), there may be benefits to starting over with new report suites if you feel that the data you have is wrong or could be misleading.

When I joined Salesforce.com many years ago to manage their Omniture implementation, I had very little faith in the data that existed at the time. When doing my QA checks, it seemed like most metrics came with a list of asterisks associated with them, such that presentation slides looked like bibliographies! While I hated the idea of starting over, I decided to do it because it was the lesser of two evils. It caused some temporary pain, but in the end, helped us shed a lot of baggage and move forward in a positive direction (you can read a lot more about how we did this in this white paper). For this reason, I suggest you make data quality one of your deciding factors in the new vs. old report suite decision.

Year over Year Data

Finally, there is the issue of year over year data. As mentioned above, if your variable definitions are completely inconsistent and/or your data quality is terrible, you may not have many options other than starting with new suites for some or all of your report suites. Moreover, if your data quality is poor, having year over year flawed data isn’t much of an improvement over having no year over year data in my opinion. The only real data that you would lose if your data quality is bad is Page Views, Visits and Unique Visitors (which are pretty hard to mess up!). In most cases, I try to avoid having year over year data be the driving force in this decision. It is a factor, but I feel that the previous two items are much more important.

Sometimes, I advise my clients to use Adobe ReportBuilder as a workaround to year over year data issues. If you decide to move to new report suites, you can build an Excel report using ReportBuilder that combines two separate data blocks into one large Excel data table that can be graphed continuously. In this case, one data block contains data for a variable in the old report suite and the other data block contains data for the same data point in a different variable slot in the new report suite. But to an end user of the Excel sheet, all they see is one large table that updates when they refresh the spreadsheet.

For example, let’s imagine that you have two report suites and one has internal searches in event 1 and the other has internal searches in event 5. Then you decide to create a brand new suite that puts all internal searches into event 1 as of January 1st. In ReportBuilder (Excel), you can create one data block that has event 1 data for suite #1 for dates prior to January 1st, another data block that has event 5 data for suite #2 for dates prior to January 1st and a third data block that has event 1 data for January 1st and beyond in the new report suite. Then you simply use a formula to add the data from event1 and event 5 in the data blocks that precede January 1st and then put that data block directly next to the final data block that contains event 1 data starting January first (in the new suite). The result will be a multi-year view of internal search data that spans all three report suites. A year later, your new report suite will have its own year over year data in the new combined event 1, so eventually, you can abandon the Excel workaround and just use normal Adobe Analytics reporting to see year over year data.

While this approach may take some work, it is a reasonable workaround for the few major data points that you need to report on year over year while you are making this transition to a newer, cleaner Adobe Analytics implementation.

Justification

Sometimes, telling your boss or co-workers that that you need to re-implement or start over with new report suites can be a difficult thing to do.  In many respects, it is like admitting failure. However, if you do your homework as described above, you should have few issues justifying what you are doing as a good long-term strategy. My advice is to document your findings above and share them with those who may complain about the initiative. There will always be people who complain, but at the end of the day, you need to instill faith in your analytics data and if this is a necessary step, I suggest you do it. I heave learned over the years that the perception of your organization’s analytics team is one of the most critical things and something you should safeguard as much as you can. In our line of work, you are asking people to make changes to websites and mobile apps, partly based upon the data you are providing. That demands a high level of trust and once that trust is broken it is difficult to repair.

I also find that many folks I work with were not around when the existing implementation was done. This is mainly due to the high turnover rate in our industry, which, in turn, is due to the high demand for our skills. If you are new to the analytics implementation that you now manage, I recommend that you perform an audit to make sure what you inherited is in good shape. As described in books like this, you have a narrow window of time that is ideal for cleaning things up and asking for money if needed. But if you wait too long, the current implementation soon becomes “your problem” and then it is harder to ask for money to do a thorough review or make wholesale changes. Plus, when you first start, you can say things like “You guys were the ones who screwed this up, so don’t complain to me if we have to start it over and lose YoY data…You should have thought of that before you implemented it incorrectly or with shoddy data quality!” (You can choose to make that sound less antagonistic if you’d like!)

Avoiding a Repeat in the Future

One last point related to this topic. If you are lucky enough to be able to clean things up, reconfigure your report suites and improve your data quality, please make sure that you don’t ever have to do that again! As you will see, it is a lot of work. Therefore, afterwards, you want to put processes in place to ensure you don’t have to do it again in a few years! To do this, I suggest that you reduce the number of Adobe Analytics Administrators to only 1-2 people, even if you are part of a large organization. Adding new variables to your implementation should be a somewhat rare occurrence and by limiting administration access to a select few, you can be sure that all new variables are added to the correct variable slots. I recommend doing this through a digital analytics “center of excellence,” the setup of which is another one of the services that I provide for my clients. As they say, “an ounce of prevention is worth a pound of cure!”

Back in 2010, I wrote about a way to see how much money website visitors were adding to the shopping cart so that amount could be compared to the amount that was actually purchased. The post also showed how you could see this “money left on the table” by product and product category. Recently, however, I had a client ask a similar question, but one focused on whether the product price was possibly a barrier to cart conversion. Specifically, the question was asked whether visitors who add products to the cart that are between $50 and $100 end up purchasing more or less than those adding products valued at a different price range. While there are some ways to get to this information using the implementation approach I blogged about in the preceding post, in this post, I will share a more straightforward way to answer this question.

Capturing Add to Cart Value

In the preceding post, to see money left on the table, I suggested that the amount of the product being added to the cart be passed to a new currency Success Event. But to answer our new question, you will want to augment that by passing the dollar amount to a Product Syntax Merchandising eVar when visitors add a product to the cart. For example, if a visitor adds product # 111 to the cart and its price is $100, the syntax would look like this:

s.events="scAdd,event10";

s.products=";111;;;event10=100;evar30=100";

In this case, the $100 cart value is being passed to both the currency Success Event and the Merchandising eVar (I suggest rounding the dollar amount to the nearest dollar to minimize SAINT Classifications later). Both of these amounts are “bound” to the product number (111 in this example).

Once this is done and repeated for all of your visitors, you can use the new Merchandising eVar to see Cart Additions by price of item added to cart using a report like this:

Since the new Merchandising eVar has been bound to the product added to the shopping cart, if the visitor purchases the product prior to the eVar’s expiration (normally purchase event), the eVar value will be applied to the purchase event as well for those products ultimately purchased. Therefore, when orders and revenue are set on the order summary page, each order will be “bound” to the product price value such that you can see a report that looks like this:

Using this report, you can see how each price point performs with respect to cart to order conversion. Since you will have many price points, you will likely want to use SAINT Classifications to group your price points into larger buckets or ranges to make the data more readable:

Once you have this, you can switch to the trended view of the report and see how each price range converts over time. Of course, you can break this down by product or external campaign code to see what factors result in the conversion rate being higher or lower than your standard cart conversion rate (Orders/Cart Additions). This analysis can be used in conjunction with my competitor pricing concept to see which products you should emphasize and de-emphasize on your online store. You can also use this new eVar in segments if you ever want to isolate cases in which a specific product price range was added to the cart or purchased.

As you can see, there are lots of handy uses for this implementation concept, so if you have a shopping cart, you may want to try it out and see what creative ways you can exploit it to further your analysis capabilities.

A few years ago, I wrote an extensive post describing how to track internal search position clicks to see which internal search positions visitors tend to click on. That post showed how to track impressions and clicks for internal search positions and how to view this by search phrase. Recently, however, I had a client ask for something tangentially related to this. This client was interested in seeing the overall average search position clicked when visitors search on their website and for each search term. While the preceding post provides a way to see the distribution of clicks on internal search spots, it didn’t provide a straightforward way to calculate the overall average. Therefore in this post, I will share a way to do this for those who want to see a trended view of how far down the search results list your visitors are going.

Calculating the Average Internal Search Position Clicked

The key difference in calculating the average internal search position clicked from what I described in my previous post, is that you need to switch from using a dimension (eVar) to using a metric (Success Event). To compute the average search position, the formula we eventually need is one that divides the summation of the position numbers clicked by the number of total internal searches. For example, if I conduct a search and click on the 10th result and then another search and click on the 5th result, I have clicked on an aggregate of 15 internal search positions (10+5) and had 2 search clicks. When I divide these two elements, I can see that my average search position clicked is 7.5 (15/2). Hence, if you apply the same approach for all of your visitors, you will be able to calculate the overall average internal search position.

From an implementation standpoint, this is relatively easy. If you have internal search on your site, you are probably already setting a metric (Success Event) on the search results page to determine how often searches are taking place. If you followed my advice in this post, you would also be setting a second metric when visitors click on a result in your search result list. Therefore, the only piece you are missing is a metric that quantifies the position number clicked. To do this in Adobe Analytics you would set a new Numeric (or Counter if on latest code) Success Event with the number value of the position clicked (let’s call this Search Position). For example, if a visitor conducts a search and clicks on the 5th position, you would pass a value of “5” to the new success event. This will create the numerator needed to calculate the average search position.

Once you have done this, you have the two metrics you need to calculate the average – search position numbers and the number of search clicks. Simply create a new Calculated Metric that divides the Search Position by the # of Search Clicks to compute the average as shown here:

This will produce a metric repost like this:

Average Search Position by Search Phrase

Since you are most likely already capturing the search phrase when visitors search, you can also view this new Calculated Metric by search phases, by simply adding it to the dimension (eVar) report:

This report and the preceding ones can be used to watch your search result clicks overall and by search phrase. This may help you determine if your search results are meeting the needs of your users and whether you even need to have pages and pages of search results.

One fun way I have used this type of analysis is to take my top search phrases and hand-pick specific links that I want them to go to for the top search phrases (recommended links). Then you can see if your users prefer the organic results or the ones you have picked for them (using a new eVar!). Another way to use this analysis is to see if changes made to your internal search makes the average search position clicked go up or down. Regardless of how you use it, if you are going to use internal search on your site, you may as well track it appropriately. Enjoy!

With the latest release of Adobe Analytics, the Analysis Workspace interface now provides a way to conduct cohort analyses. The new Cohort Analysis borrows from an existing one that Adobe had previously made available for mobile implementations, but now it is available for use everywhere and with everything that you have in your Adobe Analytics implementation. In this post, I will provide a quick “how to” since I have been surprised by how few of my Adobe customers are aware of this new functionality.

Cohort Analysis Revisited

A cohort analysis is used when you want to isolate a specific event and then see how often the same folks completing that event go on to complete a future event. In the recent decade, cohort analyses became popular due to social networking tools when they were used to judge the “stickiness” of these new tools.  For example, in the early days of Twitter, people would look to see how often users who tweeted in January were still tweeting in February. In this case, the number of people who tweeted in February was a separate number from those who tweeted in January and then in February, with the latter being “cohorts.”  For more information on this topic, check out the wikipedia page here.

New Cohort Analysis Visualization

Once you are comfortable with cohort analysis as a concept, let’s look at how you can create cohort analyses in the new Adobe Analytics interface. To start, use the left navigation to access the Analysis Workspace feature of the product (note that if you are on an older version of Adobe Analytics, you may not have Analysis Workspace enabled):

In the Analysis Workspace area, you will click the visualizations tab to see all of the potential visualizations:

From here, you will drag the “Cohort Table” visualization over to your reporting canvas and should see this:

At this point, you need to select your timeframe/granularity (i.e. Month, Week, Day) using the drop-down box and then drag over the metric you want visitors to have performed to be included in the cohort. This is done by clicking on the components tab at the top-left:

Keep in mind that you cannot use calculated metrics and some other out-of-box metrics as inclusion metrics, but you can use any of your raw success events. Also, if you click on the “Metrics” link, you can see all metrics and do a search filter, which is very handy. When contemplating your inclusion metric, think about what actions you want visitors to take to be included in the cohort. For example, if you are looking for people who have ordered, you would use the Orders metric, but if you are interested in people who have viewed content on your site, you may use a Content Views success event. As an example, let’s use the latter and build a cohort of visitors who have viewed content on the site and see how many of those visitors come back to the website within x number of days. To do this, we would change the granularity to days, add a Content Views metric as the inclusion metric and then add the Visits metric as the return metric so the cohort analysis looks like this:

You may also notice that you have the option to increase the number of times each metric has to occur before people would be be added to the inclusion or return portion of the cohort. By default the number is one, meaning that the above cohort is looking for cases in which one or more Content Views took place and then one or more return Visits took place. To narrow down the cohort, we could easily increase these numbers to force visitors to have viewed more content to be included in the cohort or returned to the site more than once to be included. But in this example, we’ll keep these set to one and run the report to see this:

Here we can see that on November 3rd, we had 6,964 unique visitors who had Content Views and that of those who viewed content on that day, 13% (892 Visitors) returned to the site within one day (had a return Visit). Keep in mind that all numbers shown in cohort analyses are unique visitor counts. The color shading shows the intensity of the cohort relative to the other cohort cells. By looking horizontally, you can see the drop-off by day for each cohort starting date and as you look vertically, the days will follow a cascading pattern with the newest starting dates having the fewest return dates like this:

Changing the granularity from Day to Week, would work the same way, but have far fewer cohorts unless you extend your timeframe:

Here is an example in which I have made both the inclusion and return metric the same thing (Content Views), but made viewing two pieces of content required to be eligible for the return cohort:

Here you will notice that requiring two return content views reduced the first (Nov 3rd) cohort from 13% down to 9%. You can use these settings to identify interesting patterns. Since you can also make as many cohorts as you want using all of your success events, the amount of information you can glean is enormous.

Putting Cohorts To Use

Once you learn how to generate cohort analyses, you may ask yourself “Ok, now what do I do with these?” That is a valid question. While a blog post isn’t the best venue for sharing all you can do with cohort analyses, let me share a couple ways I would suggest you use them. The first way is to apply segments to your cohorts. For example, you may want to determine if visitors from a specific region perform better than another, or if those using your responsive design pages are more likely to return. Here is an example in which the previous cohort is segmented for Microsoft browsers to see if that makes the cohort better or worse:

In this case, our Nov 3rd cohort went from 13% to 8% just based upon browser. Since you probably have many segments, this provides more ways you can slice and dice these cohorts and adding a segment is as easy as dropping it into the top of your Analysis Workspace page like this:

Keep in mind that any segment you apply will be applied to both the inclusion and return criteria. So in the preceding scenario, by adding a Microsoft Browser segment, the inclusion visitor count only includes those visitors who had a Content View event and used a Microsoft browser and the return visits also had to be from a Microsoft browser.

But my favorite use for cohorts is using a semi-hidden feature in the report. If you have a particular cohort cell (or multiple cells) that you are interested in, you can right-click on it and create a brand new segment just for that cohort! For example, let’s say we look at our original content to return visit cohort:

Now, let’s say something looks suspicious about the Nov 3rd – Day 4 cohort, which is at 3% (top-right cell). We can right-click on it to see this:

Then clicking will show us the following pre-defined segment in the segment builder:

Now you can name and save this segment and use it in any analysis that you may need in the future!  You can also make changes to it if you desire before saving.

While there is much more you can do with cohorts, this should be enough for you to get started and begin playing around with them. Enjoy!

Over the past year, Adobe Analytics users have noticed that the product has moved to a different model for accessing/editing/creating analytics components such as Calculated Metrics, Segments, etc… In this post, I want to touch upon one aspect that has changed a bit – the sharing of calculated metrics.

Sharing Calculated Metrics – The Old Way

In the older interface of Adobe Analytics (pre version 15.x), it was common to create a calculated metric, then select multiple report suites and apply that calculated metric to multiple suites. For example, if you wanted to create a Null Search ratio, you would create the formula and then select your report suites and save it. Here is an example in which a few calculated metrics have been applied to thirteen report suites:

This approach would save you the work of creating the metric thirteen separate times, which could be a real pain, especially if you had hundreds of report suites.

However, employing this [old] preferred approach of sharing calculated metrics can actually make things a bit confusing when you switch over to the new version of Adobe Analytics. When using the new Calculated Metrics manager, the old approach will  cause you to see the same calculated metric multiple times, since it shows all calculated metrics for all report suites in the same window. Here is how the same calculated metric looks in the more updated version:

In this case, you would see the same metric for as many report suites as it was associated with in your implementation. While you could keep all of these different versions, doing so presents the following potential risks:

1. It can be confusing to novice end-users
2. If someone makes a change to one of the calculated metrics (in one report suite), it can deviate from the others, so that you lose integrity of the metric across your implementation/organization
3. If you want to make a change to a calculated metric in the future, you have to do it multiple times

In addition to these risks, in the newest version of Adobe Analytics, there are some cool new ways to share metrics that don’t require this duplication of the same metric hundreds of times.

Sharing Calculated Metrics – The New Way

If you were to make a new calculated metric now, using the latest version of Adobe Analytics, you could create the metric once and simply share it to all users or groups of users. Once you have created your metric, you use the share feature and select “All” as shown here:

Doing this allows you to see the calculated metric in every report suite, without having multiple versions of it. As shown here, you will still see the calculated metric when you click “Show Metrics” from within the Adobe Analytics interface:

Therefore, if you have twenty calculated metrics across fifty report suites, you would have twenty rows in your calculated metric manager instead of one thousand! This makes your life as an administrator much easier in the future.

Moving From The Old to the New

So what if you already have a lot of metrics and they are shown multiple times in your calculated metrics manager? If you decide you want to trim things down and go to the newer approach, you would want to do the following:

1. I suggest creating a corporate login as outlined in this blog post. This is a centralized admin login that the core analytics team maintains
2. Review all of your shared bookmarks and dashboards to find all cases in which calculated metrics you are about to remove are used
3. Copy each of the existing calculated metrics using the corporate login ID (described in step 1) and share it across all or designated users
4. Once this is done, you can delete all of the duplicate versions of the calculated metric
5. Go back to the shared bookmarks and dashboards using the old version of calculated metrics and replace them with the newly created shared version

While this may take some time, it will free up time in the future, since it will minimize the number of calculated metrics you have to maintain in the long run. I also find that it is beneficial to periodically review all of your shared reports and calculated metrics and do a clean-up. This process forces you to do this and you may be amazed how many you have, how many you can remove and how many are wrong!

When using Adobe Analytics, one of the things that has been a bit annoying historically is that when you sort by a calculated metric, you often see really high percentages for rows that have very little data. For example, if you create a click-through rate metric or a bounce rate metric and sort by it, you may see items of 100% float to the top, but when looking at the raw instances, the volume is so low that it is insignificant. Here is an example of a case where you may be capturing onsite searches by term (search criteria) and clicks on search results for the same term (as outlined in this post):

In this case, it is interesting to see that certain terms have a highly disproportionate number of clicks per search, but if each is searched only once, it isn’t that statistically relevant. To get around this, Adobe Analytics customers have had to export all data to Microsoft Excel, re-create the calculated metrics, delete all rows with fewer than x items (searches in this case) and then sorted by the click-through rate. What a pain! That is a lot of extra steps!

But now, thanks to the new Derived Metrics feature of Adobe Analytics, this is no longer required. It is now possible to use more complex functions and formulas to narrow down your data such that you can sort by a calculated metric and only see the cases where you have a higher volume of instances. In this post, I will demonstrate exactly how this is done.

Using the Percentile Function

The key to sorting on a calculated metric is the use of the new PERCENTILE function in Adobe Analytics. This function allows you to choose a percentile within a list of values and use that in a formula. To illustrate this, I will continue the onsite search example from above. While the click-through rate formula used above is accurate, we want to create a report that only shows the click-through rate when search criteria have at least x number of searches. However, since the number of unique search criteria will vary greatly, we cannot simply pick a number (like 50 or more), because we don’t know how many searches will be performed for the chosen date range. For example, one of your users may choose one day, in which greater than 5o searches is unlikely, but another user may choose a full year, which will make greater than 50 a huge number of items with a very long tail. To deal with all scenarios, you can use the PERCENTILE function, which will look at all of the rows for the selected date range and allow you to calculate the xth percentile of that list. Hence, the threshold is relative to the date range chosen with respect to the number of instances that have to take place for it to show up in the calculated metric. Since this can be a bit confusing, let’s look at an example:

To start, you can build a new calculated metric that shows you what the PERCENTILE formula will return at a specific percentile. To do this, open the Calculated Metrics builder and make the following formula:

Since there may be a LOT of unique values for search criteria, I am starting off with a very high percentile (99.5%) to see how many searches it takes to be in the 99.5% percentile. This is done by selecting the core metric (Searches in this case) and then making the “k” value 99.5 (Note: You can also figure out the correct “k” value by using the PERCENTILE function in Microsoft Excel with the same data if you find that easier). Once you are done, save this formula and add it to your search criteria report so you see this:

This formula will have the same value for every row, but this is ok since we are only using it temporarily to figure out if 99.5% is the right value. In this case, what we see is that at a 99.5% percentile, anything with over 18 searches will show us the search click-through rate and anything below 18 searches will not. Now it is up to you to make your judgement call. Is 18 too high in this case?  Too low? If you want to raise, it, simply raise the “k” value in the formula to 99.8 or something similar.

While doing this, keep in mind, that changing your date range (say choosing just one day), will change the results as well. The above report is for 30 days of data, but look what happens when we change this to just one day of data:

As you can see, the threshold changed from 18 to 6, but the number of overall searches also went down, so the 99.5% percentile seems to be doing its job!

Once you have determine what your ideal percentile “k” value is, it is now time to use this formula in the overall click-through rate formula. To do this, you need to create an IF statement and use a GREATER THAN function as well. The goal is to tell Adobe Analytics that you want it to show you the search click-through rate only in cases where the number of searches is greater than the 99.5% percentile. In other cases, you want to set the value to “0” so that when you sort in descending order, you don’t have crazy percentages showing up at the top, even though there are low values. Here is what the formula will look like:

While this may look a bit intimidating at first, if you look at its individual components, all it is really doing is calculating a click-through rate only when the number of searches is above our chosen threshold. Now you can add this metric to your report and see the results:

As you can see, this new calculated metric is no different from the existing one in cases where the number of searches is greater than the 99.5% threshold. But look what happens when we sort by this new Weighted Click-Through Rate metric:

Unlike the report shown at the beginning of this post, we don’t see super high percentages for items with low numbers of searches. All of the results are above the threshold, which makes this report much more actionable. If you want, you can verify this by paging down to the point where our new weighted metric is 0% (in this case when searches are under 18):

Here you can see that searches are less than 18 and that the previous click-through rate metric is still calculating, but our new metric has hard-coded these values to “0” for sorting purposes.

Final Thoughts

As you can see, using the PERCENTILE function can be a real time-saver. While this example is related to onsite search, the same concept can be applied to any calculated metric you have in your Adobe Analytics implementation. In fact, Adobe has created a similar metric for Weighted Bounce Rate that is publicly available for all customers to use for marketing campaigns. So any time you want to sort by a calculated metric and not see rows with low numbers of data, consider using this technique.

Product Finding Methods, is a topic that I have touched upon briefly in past blog posts, but not in great detail. Some others have also talked about it, but in a quick Google search, the most relevant post I found on the subject was this post from back in 2008. Therefore, in this post, I thought I would explore the topic and how it can be applied to both eCommerce and non-eCommerce sites.

What is Product Finding Methods?

I define Product Finding Methods as the way that website/app visitors use to find products that they ultimately purchase. For example, if a visitor comes to your website and conducts a search and then finds a product they like, then search would be the Product Finding Method that should be associated with that product. Most websites have about 5-10 different Product Finding Methods, such as:

• Internal Search
• Navigation/Browsing
• Internal Campaigns/Promos
• Wishlist/Favorites/Registries
• Collections
• Cross-Sell
• Campaign Landing Pages

These are usually the main tools that you use to drive visitors to products, with the goal of getting them to add items to their online shopping cart. Having a Product Finding Methods report is useful when you want to see a holistic view of how visitors are getting to your products, but it can also be used to see how each product or product category is found. In most cases, the KPI that you care about for Product Finding Methods is Orders or Revenue because, while it may be interesting to see which methods get visitors to add items to the shopping cart, you make money when they order products and pay you!

Why Implement Product Finding Methods?

So why should you care about Product Finding Methods? Most organizations implementing this do so to identify which method is most successful at driving revenue. Since websites can be tweaked to push visitors to one finding method over another, if you have one that works better than another, you can work with your design team to either fix the lagging one or push people to the better one. For example, if your internal search functionality rarely produces orders, there may be something inherently wrong with it. Even if you track the internal search click-through rate and that is ok, without the Product Finding Methods report, you may not know that those clicking on results are not ultimately buying. The same may be true for your internal promotions and other methods. I once had a client that devoted large swaths of their product pages to product cross-sell, but never had a Product Finding Methods report to show them that cross-sell wasn’t working and that they were just wasting space.

Another use of Product Finding Methods is to see if there are specific products or product categories that lend themselves to specific finding methods. For example, you may have products that are “impulse” buys that do very well when spotlighted in a promotion on the home page, but don’t do so well when found in search results (or vice versa). Having this information allows you to be more strategic in what you display in internal promotions. By creating a “Look to Book” Calculated Metric (Orders/Product Views) within a Product Finding Methods report, it is easy to see which products do well/poorly for each finding method.

Finally, once you have implemented Product Finding Methods, you can use them in Segments. If you have a need to see all visits or visitors who have used both Internal Search and a Registry to find products, you can do this easily by selecting those two methods in the Segment builder. Without Product Finding Methods being implemented, creating a viable segment would be very cumbersome, likely involving  a massive amount of Page-based containers.

How Do You Implement Product Finding Methods?

So let’s say that you are intrigued and want to see how visitors are finding your products. How would you implement this in Adobe Analytics?

Obviously, if you are looking to breakdown Orders and Revenue (which are Success Events) by a dimension, you are going to need a Conversion Variable (eVar). This eVar would capture the most recent Product Finding Method that the user interacted with, regardless of whether that Finding Method led directly or indirectly to a product. To do this, you would work with your developers to identify all of your Product Finding Methods and determine when each should be passed to the Product Finding Methods eVar. For example, the “Internal Search” product finding method would always be set on the search results page.

However, before we go any further, we need to talk about Product Merchandising. If you are not familiar with the Product Merchandising feature of Adobe Analytics, I suggest that you read my post on that now. So why can we not use a traditional eVar to capture the Product Finding Method? The following example will illustrate why. Imagine that Joe visits our site and clicks on a home page promotional campaign and you have your developer set the Product Finding Methods eVar with a value of “Internal Campaign.” Then Joe finds a great product and adds it to the shopping cart. Next Joe does a search on our site, so you have your developer set the Product Finding Methods eVar with a value of “Internal Search.” Joe proceeds to add another product to the shopping cart and then checks out and purchases both products. In this scenario, which Product Finding Method will get credit for each product? If you said “Internal Search” you would be correct because it was the “most recent” value prior to the Purchase Success Event firing. Unfortunately, that is not correct. In this scenario, product #1 should have “Internal Campaign” as its finding method and product #2 should have “Internal Search” as the finding method. Because we need each product to have its own eVar value, we need to use the Product Merchandising feature, which allows us to do that.

For Product Finding Methods, it is common to use the “Conversion Syntax” methodology of Product Merchandising since we often don’t know when the visitor will ultimately get to a product or which product it will be. By using the “Conversion Syntax” method, we can simply set the value when the Product Finding Method occurs and have it persist until the visitor engages in some action that tells us which product they are interested in (the “binding” Success Events). Normally, I recommend that you “bind” (or associate the Product Finding Method with the product) when visitors view the Product Detail Page, perform a Cart Addition, engage with a Product Quick View or other similar product-related actions. These can be configured in the Administration Console as needed.

Once you have navigated the murky waters of Product Merchandising, set-up your Product Finding Methods eVar and worked with your developers to pass the values to the eVar, you will see a report that looks something like this:

From this report, you can then use breakdowns to breakdown each Product Finding Method by Product ID:

If you have SAINT Classifications setup for your Products Variable, you can see the same reports for things like Product Category, Product Name, Product Type, etc… All of these reports are bi-directional, so if you wanted to see the most popular Product Finding Methods for a specific product, all you would do is open the Products report and then break it down by the Product Finding Method eVar.

What About Deep-Links?

One question you may be asking yourself is: “What happens if visitors deep-link directly to a product page on my website and there is no Product Finding Method?” Great question! If you don’t account for this scenario, you would see a “None” row in the Product Finding Methods eVar report for those situations. In that case, the “None” row can be explained as “No Product Finding Method.” But one tip that I will share with you is that you can set a default value of the referring marketing channel in your Product Finding Methods eVar on the first page of the visit. If you can identify the marketing channel (Paid Search, SEO, E-mail, etc…) from which visitors arrive to your site, you can pass that channel to the Product Finding Methods eVar when the visit begins. Doing so will establish a default value so that if a product “binding” event takes place before any of your onsite product finding methods are activated, those products will be bound to your external marketing channel. This gives you more information than the “None” row, but still allows you to quantify what percent of your products have an internal vs. external product finding method. Obviously, to use this tip, you have to be able to identify the external marketing channel of each visit so that it can be passed to the eVar. I tend to do this by some basic rules in JavaScript that analyze the referrer and any campaign tracking codes I am already using. You can see a version of this by looking at the first report above in row five labeled “external campaign referral,” and notice that no “None” row exists in that report.

Non-eCommerce Uses

So what if you don’t sell products on your website? Does that mean you cannot use Product Finding Methods? Of course not! Even if you don’t sell stuff, there are likely uses for the above implementation. For example, if you manage a research site, you probably have visitors looking for content. In that case, your content is your product and you may be storing your content ID’s in the Products variable. This means that you can capture the different methods that your visitors use to find your content and assign each Content ID with the correct Product Finding Method.

If you manage a B2B website, you have product pages, but you may not sell the actual product online. In this case, the implementation for eCommerce will work the same way, but instead of Orders and Revenue, you may make the final Success Event Leads Completed. You can also see how visitors find your product videos, pricing sheets, etc…

Similar approaches can be employed for non-profit sites, government sites and so on. If you work with a non-eCommerce site, you may just have to think a bit more creatively about what your finding methods might be, what your “products” are and which binding events make sense. As long as you understand the general concept: Figuring out how visitors make their way to the stuff you care about, you will be able to find a way to use Product Finding Methods in your implementation.

If you have questions or other approaches related to this topic, feel free to leave a comment here or ping me at @adamgreco. Thanks!

In the last year, Adobe Analytics introduced the ability to have over 1,000 Success Events. That was a pretty big jump from 100 previously. As I work with clients I see some who struggle with what having this many Success Events really means. Does it mean you can now track more stuff? At a more granular level? Should you track more? Etc… Therefore, in this post, I am going to share some of my thoughts and opinions on what having 1,000 Success Events means and doesn’t mean for your Adobe Analytics implementation.

Knee Jerk Reaction

For most companies, I am seeing what I call a “knee jerk reaction” when it comes to all of the new Success Events. This reaction is to immediately track more things. But as my partner Tim Wilson blogged about, more is not necessarily better. Just because you can track something, doesn’t mean you should. But let’s take a step back and consider why Adobe enabled more Success Events. While I cannot be 100% certain, since I am not an Adobe Analytics Product Manager, it is my hunch that the additional Success Events were added for the following reasons:

1. It is easier to increase Success Events than other variables (like eVars) due to the processing that happens behind the scenes
2. Success Events are key to Data Connector integrations and more clients are connecting more non web-analytics data into the Adobe Marketing Cloud
3. Some of the Adobe product-to-product integrations use additional Success Events
4. Having more Success Events allows you to push more metrics into the Adobe Marketing Cloud

I don’t think that Adobe was saying to itself, “our clients can now only track 100 metrics related to their websites/apps and they need to be able to track up to 1,000.”

This gets to my first big point related to the 1,000 Success Events. I don’t think that companies should track additional things in Adobe Analytics just because they have more Success Events. If the data you want to collect, has business benefit, then you should track it, but if you ever say to yourself, “we have 1,0000 Success Events, so why not use them?” there is a good chance you are going down a bad path. For example, if you have thirty links on a page and you want to know how often each link gets clicked, I would not advocate assigning a Success Event to each of the thirty links. If you wouldn’t do it when you had 100 Success Events, I would not suggest doing it just because you have more.

But there will be legitimate reasons to use these new Success Events. If your organization is doing many Data Connector integrations, the amount of Success Events required can grow rapidly. If you have a global organization with 300 different sites and each wants to have a set of Success Events that they can use for their own purposes, you may decide to allocate a set of Success Events to each site (though you can also double-up on Success Events and not send those to the Global report suite as well). In general, my advice is to not have a “knee jerk reaction” and change your implementation approach just because you have more Success Events.

Use Multiple Success Events vs. an eVar

Another thing that I have seen with my clients is the idea of replacing or augmenting eVars with multiple versions of Success Events. This is a bit complex, so let me try and illustrate this with an example. Imagine that one of your website KPI’s is Orders and that your stakeholder wants to see Orders by Product Category. In the past, you would set an Order (using the Purchase Event) and then use an eVar to break those Orders down by Product Category. But with 1,000 Success Events, it is theoretically possible for you to set a different Success Event for each Product Category. In this example, that would mean setting the Orders metric and at the same time setting a new custom Success Event named Electronics Orders (or Apparel Orders depending upon what is purchased). The latter would be a trend of all Electronics Orders and would not require using an eVar to generate a trend by Product Category. If you have fifty Product Categories, you could use fifty of your 1,000 Success Events to see fifty trends.

This raises the question, is doing what I just described a good thing or a bad thing? I am sure many different people will have different opinions on that. Here are the pros and cons of this approach from my point of view:

Pros

1. While I would not recommend removing the Product Category eVar, in theory, you could get rid of it since you have its core value represented in fifty separate Success Events. This could help companies that are running out of eVars, but still not something I would advocate because you can lose the great attribution benefits of eVars (especially across multiple visits).
2. Today, it is only possible to view one metric in a trended report, so if you want to see more than just Orders for a specific Product Category (say Orders, Revenue and Units for Electronics), you can’t do so using an eVar report. But if each of these metrics were tied to a separate Product Category event, you could use the Key Metrics report to get up to five metrics trended for a particular Product Category. But keep in mind that you would need fifty Success Events for each metric you want to see together, which can make this a bit un-scalable. Also keep in mind that you can trend as many metrics as you want using the Adobe ReportBuilder tool.
3. You can create some cool Calculated Metrics if you have all of these additional Success Events, such as Electronics Orders divided by (Electronics Orders + Apparel Orders) that may be more difficult to produce in Adobe Analytics proper without using Derived Metrics or Adobe ReportBuilder.
4. Having additional metrics allows you to have Participation enabled on each, which can provide more granular Participation analysis. For example, if you enable Participation on the Orders event, you can see which pages lead to Orders. But if you enable Participation on a new Electronics Orders event, you will be able to see which pages lead to orders of Electronics products. The latter is something that isn’t possible (easily) without having a separate Electronics Orders Success Event.
5. If you want to pass Adobe Analytics data to another back-end system using a Data Feed, there could be some advantage to having a different metric (in this example for each Product Category) vs. one metric and an eVar in terms of mapping data to an external database.

Cons

1. Setting so many Success Events can be a nightmare for your developers and a pain to maintain in the Administration Console. It may require extra time, logic, TMS data mappings and so on. In the preceding example, developers may have to write additional code to check for fifty product categories. In some cases, developers may only know the Product ID and not the category (which they had planned on being a SAINT Classification), but setting the additional Success Events forces them to write more code to get the product category. If visitors purchase products from multiple product categories, developers have to start defining rules that makes things more complex than originally anticipated. And if product categories change (new ones are added or old ones are removed), that can mean more development work vs. simply passing in different values to an eVar. While using a Tag Management System can make some of this easier, it still creates a lot more work for developers, who are normally already stretched to their limits!
2. Having different versions of the same Success Events can be confusing to your end-users (i.e. Orders vs. Electronics Orders) and can make your entire implementation a bit more confusing
3. Employing this approach too often can force you to eventually run out of Success Events, even with the increased number available. For example, if you set Orders, Revenue, Units and Cart Additions for each Product Category, you are already looking at 200 Success Events. Setting these same events for a different dimension (eVar), would require another 200 Success Events!

While I can see some merits in the benefits listed above, my opinion is that blowing out different Success Events instead of using an eVar is something that can have value in some targeted situations, but is not for everyone. Call me old fashioned, but I like having a finite number of metrics and dimensions (eVars) that break them down. If there is a short list of metrics that are super critical to be seen together in the Key Metrics report and the number of times they would have to be duplicated by dimension is relatively small, then perhaps I would consider adding an extra 10-20 Success Events for each dimension value. But I see this as a bit of a slippery slope and wouldn’t advocate going crazy with this concept. Perhaps my opinion will change in the future, but for now, this is where I land on the subject.

Derived Metrics

Tangentially related to this topic is the concept of Derived Metrics. Derived Metrics are the new version of Calculated Metrics in which you can add advanced formulas, functions and segments. The reason I bring these up is that Derived Metrics can be used to create multiple versions of metrics by segmenting on eVar or sProp values. For example, instead of creating fifty versions of the Orders metric as described above, you could have one Orders metric and then create fifty “Derived” metrics that use the Orders metric in combination with a segment based upon a Product Category eVar. This requires no extra development effort and can be done by any Adobe Analytics user. The end result would be similar to having fifty separate Success Events as each can be trended and up to five can be added to the Key Metrics report. The downsides of this approach is that these Derived Metrics will not be easily fed into a data feed if you want to send data directly to an external database and won’t have Participation metrics associated with them.

It is somewhat ironic that shortly after Adobe provided 1,000 Success Events, it also provided a great Derived Metrics tool that actually reduces the need for Success Events if used strategically with Segments! My advice would be to start with using the Derived Metrics and if you later find that you have reasons to need a native stream of data for each version of the event (i.e. Data Feed) or Participation, then you can hit up your developers and consider creating separate events.

Final Thoughts

So there you have some of my thoughts around the usage of 1,000 Success Events. While I think there can be some great use cases for taking advantage of this new functionality, I caution you to not let it change your approach to tracking what is valuable to your stakeholders. I am all for Adobe adding more variables (I wish the additional eVars didn’t cost more $$$!), but remember that everything should be driven by business requirements (to learn more about this check out my Adobe white paper: http://apps.enterprise.adobe.com/go/701a0000002IvLHAA0).

If you have a different opinion or approach, please leave a comment here.  Thanks!