Dear Adobe,

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

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

How would this work?

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

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

Order #101 (the one we want)

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

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

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

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

The Bad

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

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

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

The Correct Theoretical Segment

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

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

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

Even More Specific

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

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

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

Summary

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

Sincerely,

Kevin Willeitner

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

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

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

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

Product Attributes at Time of Order

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

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

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

Differentiating Test Products

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

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

Changes to Product Attributes

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

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

Other Options

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

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

Common Theme

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

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

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

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

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

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

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

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

ACCELERATE

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

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

A quick check in the documentation showed this:

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

Using Builders in Calculated Metrics

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

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

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

Using Builders in Segments

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

Make Builder Metrics Selectively Visible

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

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

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

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

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

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

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

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

Curate Your Classifications

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

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

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

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

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

Summary

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

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

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

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

Time-Zone Virtual Report Suites

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

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

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

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

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

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

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

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

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

After The Fact Metrics

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

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

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

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

Transitioning To A New Success Event

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

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

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

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

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

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

Summary

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

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

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

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

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

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

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

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

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

What Does This Mean?

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

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

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

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

The Demystified Advantage – Ingersoll Rand – September 2018

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

Filter on Dimension Values

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

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

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

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

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

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

Other Filters

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

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

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

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

Example Use – Solution Design Project

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

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

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

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

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

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

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

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

Future Wishlist Items

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

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

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

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

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

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

Here are blog posts by year:

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

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

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

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

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

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

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

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

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

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

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

This would produce an additional Analysis Workspace visualization like this:

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

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

Implementation Setup

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

Here is what the SAINT File looks like when completed:

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

Reporting in Analysis Workspace

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

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

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

Reporting in Adobe ReportBuilder

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

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

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

This will produce the following table of data:

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

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

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

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

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

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

Updating Business Requirement Status

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

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

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

Updating Completion Percentage

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

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

Using Advanced Segmentation

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

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

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

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

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

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

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

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

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

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

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

Calculating Requirement Percentage Complete

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

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

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

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

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

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

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

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

This produces the numbers shown in the highlighted column here:

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

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

This would then produce a table like this:

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

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

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

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

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

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

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

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

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

Importing Business Requirements (Data Sources)

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

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

Importing Requirement & Variable Meta-Data (SAINT Classifications)

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

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

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

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

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

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

Project Curation

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

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

Final Thoughts

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

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

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

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

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

Living in Workspace

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

Therefore, I created this:

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

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

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

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

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

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

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

Maximum Flexibility

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

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

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

Summary

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

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

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

Did They Get Hired?

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

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

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

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

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

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

Are They Superstars?

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

Which will allow you to see a report like this:

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

Final Thoughts

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

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

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

Then she added it to the report as shown here:

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

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

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

Solution #1 – Adobe ReportBuilder

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

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

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

Solution #2 – Analysis Workspace & Calculated Metrics

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

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

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

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

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

Summary

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

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

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

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

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

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

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

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

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

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

Impact of Having Product Ratings/Reviews

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

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

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

Average Product Rating Calculated Metric

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

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

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

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

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

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

Adding Depth to Website Engagement

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

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

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

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

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

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

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

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

Website Engagement Calculation

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

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

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

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

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

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

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

Normal vs. 100% Stacked Bar Charts

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

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

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

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

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

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

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

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

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

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

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

Searching For Components Doesn’t Work

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

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

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

Search By Variable

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

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

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

Tagging to the Rescue!

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

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

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

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

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

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

This allows me to filter Segments in the same way:

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

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

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

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

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

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

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

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

Adobe Analytics Implementation Improv

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

Adobe Analytics “Ask Me Anything” Session

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

Adobe Analytics Idol

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

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

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

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

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

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

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

Adobe Summit Presentation

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

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

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

Measure Slack

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

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

Idea Exchange

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

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

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

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

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

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

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

…and combine them with other metrics:

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

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

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

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

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

Long-Term Approach (Data Sources File)

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

Short-Term Approach (Segmentation)

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

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

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

Summary

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

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

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

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

Calculating Dimension Penetration %

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

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

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

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

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

Adobe ReportBuilder Method

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

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

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

Data Sources Method

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

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

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

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

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

This will produce a report that looks like this:

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

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

Which produces this report:

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

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

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

Automated Method (Advanced)

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

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

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

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

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

Lastly, create a report like this in Analysis Workspace:

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

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

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

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

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

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

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

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

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

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

Combining Distinct Counts With Other Dimensions

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Here are some quotes from recent class attendees:

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

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

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

Adobe Summit – Las Vegas (March 27-28)

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

Adobe Summit – London (May 3-4)

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

DAA Symposium – New York (May 15)

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

Adobe Insider Tour (May & September)

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

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

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

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

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

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

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

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

DA Hub – Austin (October 18-19)

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

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

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

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

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