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

Why Track Everything?

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

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

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

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

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

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

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

Focus on KPI’s

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

Consider Other Tools

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

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

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

Final Thoughts

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

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

Why Should You Care?

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

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

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

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

Example

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

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

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

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

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

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

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

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

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

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

Final Thoughts

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

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

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

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

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

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

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

Stream of Consciousness

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fallout Report Refresher

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

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

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

Welcome to the Future!

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

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

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

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

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

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

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

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

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

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

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

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

Segmentation

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

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

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

Additional Info

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

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

Capturing the Pricing State

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

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

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

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

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

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

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

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

Pricing State Metrics

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

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

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

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

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

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

Trending the Next Page Report

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

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

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

But Wait…There’s More!

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

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

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

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

Using Sequential Segmentation

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

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

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

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

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

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

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

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

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

Expanding the Participation Window

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

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

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

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

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

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

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

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

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

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

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

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

Allocation of Success Events

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scatter Plot Visualization – Step by Step

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

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

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

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

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

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

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

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

Seamless Adobe Analytics Integration

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

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

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

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

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

Venn Diagram Visualization

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

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

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

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

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

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

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

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

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

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

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

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

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

Updating the Query String Parameter Code

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

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

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

Reporting on UTM Campaign Codes

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

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

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

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

Final Thoughts

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

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

Why Are Report Suites Inconsistent?

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

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

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

Why Is Report Suite Inconsistency Bad?

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

Data in Global Data Set Can be Wrong

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

Can’t Use Virtual Report Suites

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

Can’t Re-Use Reporting Templates

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

Can’t See Aggregated Pathing

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

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

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

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

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

How Do You Avoid Report Suite Inconsistency?

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

Final Thoughts

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

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

A Brief History Lesson

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

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

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

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

Virtual Report Suites

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

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

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

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

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

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

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

Final Thoughts

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

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

Custom Variables

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

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

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

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

Segmentation

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

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

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

Final Thoughts

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

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

Auditing What You Have

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

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

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

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

Old Report Suites or New Ones?

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

Report Suite Inconsistency

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

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

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

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

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

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

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

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

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

Data Quality

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

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

Year over Year Data

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

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

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

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

Justification

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

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

Avoiding a Repeat in the Future

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

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

Capturing Add to Cart Value

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

s.events="scAdd,event10";

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

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

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

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

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

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

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

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

Calculating the Average Internal Search Position Clicked

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

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

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

This will produce a metric repost like this:

Average Search Position by Search Phrase

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

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

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

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

Cohort Analysis Revisited

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

New Cohort Analysis Visualization

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

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

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

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

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

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

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

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

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

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

Putting Cohorts To Use

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

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

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

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

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

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

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

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

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

Sharing Calculated Metrics – The Old Way

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

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

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

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

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

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

Sharing Calculated Metrics – The New Way

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

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

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

Moving From The Old to the New

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

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

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

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

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

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

Using the Percentile Function

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

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

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

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

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

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

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

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

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

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

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

Final Thoughts

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

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

What is Product Finding Methods?

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

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

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

Why Implement Product Finding Methods?

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

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

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

How Do You Implement Product Finding Methods?

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

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

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

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

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

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

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

What About Deep-Links?

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

Non-eCommerce Uses

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

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

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

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

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

Knee Jerk Reaction

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

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

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

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

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

Use Multiple Success Events vs. an eVar

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

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

Pros

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

Cons

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

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

Derived Metrics

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

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

Final Thoughts

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

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

Few features were more hotly anticipated following Adobe Summit than the arrival of the newly expanded calculated metrics to Adobe Analytics. Within one week of its release, it is already paying off big time for one of my clients. I’m going to share a use case for how these advanced calculated metrics fixed some pretty broken revenue data.

Our example for this case study is KittensSweaters.com*, an ecommerce business struggling with their Adobe Analytics data. Over the past few months, KittenSweaters has dealt with a number of issues with their revenue data, including:

• “Outlier” orders where the revenue recorded was grossly inflated or even negative
• A duplicate purchase event firing prior to the order confirmation page, that double counted revenue and
• Donations to their fundraiser counting as sweaters revenue, instead of in a separate event

For example, here you can see the huge outliers and negative revenue numbers they saw in their data:

Historically, this would require segmentation be layered upon all reports (and ensuring that all users knew to apply this segmentation before using the data!)

However, using the new Calculated Metrics in Adobe Analytics, KittenSweaters was able to create a corrected Revenue metric, and make it easily available to all users. Here’s how:

First, create a segment that is limited only to valid orders.

In the case of KittenSweaters, this segment only allows in orders where:

1. The product category was “sweaters”; and
2. The purchase was fired on the proper confirmation page; and
3. The order was not one of the known “outlier” orders (identified by the Purchase ID)

You can test this segment by applying it on the current Revenue report and seeing if it fixes the issues. Historically, this would have been our only route to fix the revenue issues – layer our segment on top of the data. However, this requires all users to know about, and remember to apply, the segment.

So let’s go a step further and create our Calculated Metric (Components > Manage Calculated Metrics.)

Let’s call our new metric “Revenue (Corrected)”. To do so, drag your new segment of “Valid Sweater Orders” into the Definition of your metric, then drag the Revenue metric inside of the segment container. Now, the calculated metric will only report on Revenue where it matches that segment.

Voila! A quick “Share” and this metric is available to all KittenSweaters.com employees.

You can use this new metric in any report by clicking “Show Metrics” and adding it to the metrics displayed:

Now you’ll get to see the new Metrics Selector rather than the old, clunky pop-up. Select it from the list to populate your report. You can also select the default Revenue metric, to view the two side by side and see how your corrections have fixed the data.

You can quickly see that our new Revenue metric removes the outliers and negative values we saw in the default one, by correcting the underlying data. (YAY!)

But why not make it even easier? Why make busy KittenSweaters employees have to manually add it to their reports? Under Admin Settings, we can update our corrected metric to be the default:

You can even use these new calculated metrics in Report Builder! (Just be sure to download the newest version.)

It’s a happy day in the KittenSweaters office! While this doesn’t replace the need for IT to fix the underlying data, this definitely helps us more easily provide the necessary reporting to our executive team and make sure people are looking at the most accurate data.

Keep in mind one potential ‘gotcha’: If the segment underlying the calculated metric is edited, this will affect the calculated metric. This makes life easier while you’re busy building and testing your segment and calculated metric, but could have consequences if someone unknowingly edits the segment and affects the metric.

Share your cool uses of the new calculated metrics in the comments! If you haven’t had a chance to play around with them yet, check out this series of videos to learn more.

* Obviously KittenSweaters.com isn’t actually my client, but how puuuurrfect would it be if they were?!

Lately, Adobe has been sneaking in some cool new features into the SiteCatalyst product and doing it without much fanfare. While I am sure these are buried somewhere in release notes, I thought I’d call out two of them that I really like, so you know that they are there.

Search Within Add Metrics Dialog Window

You can now use a search filter within the Add Metrics window to easily find the metrics you want to add to a conversion or traffic report. Simply enter the search area and begin typing:

Weekdays & Weekends in Metric Reports

A few years ago, Adobe added the ability to filter metric reports by Mondays, Tuesdays, etc. This allowed you to look at the same day (i.e. Monday) over the last few months to see how a metric changed on each subsequent day of the week. However, one gap that remained was the ability to filter by weekdays or weekends. I am pleased to report that Adobe has now added these as valid filters in metric reports as shown here:

Create Segment From Fallout Report

When Adobe added sequential segmentation to the Analytics product, another “unannounced” feature emerged related to the Fallout report. Now when you launch a Fallout report, you have the option (shown in red below) to generate a new sequential segment using the items currently in the Fallout report.

When you click on the link shown above, you will be taken to a screen that looks like this:

From here, all you need to do is make tweaks or save the segment.

I am guessing that there are a few more unknown new features so if you spot one, please leave a comment here so we can all enjoy! Thanks!