Recently, I was working with a client who needed to group a bunch of dimension items for an analysis. While this would seem like an easy thing to do in Analysis Workspace, it isn’t as easy as you’d think. Therefore, I am going to share a tip I used to help this client in case it helps any of you out there.

Scenario & Options

Let’s imagine that you have a situation in which a dimension (eVar) has thousands of values and you want to see a grouping of say 25 of those values. The 25 could be based upon the text values of the dimension items or it could be completely random. There are several ways to do this in Adobe Analytics:

Option 1 – SAINT Classifications

One option is to have your Adobe Analytics team use SAINT to classify the values you want into one specific value. If you do that, you can then use the classification value in your reports and that one value will encompass all 25 items that you care about. Unfortunately, this may require work to be done by another team and at large organizations, this can take a while or require approvals.

Option 2 – Manually Build Segment

The second option is to manually build a segment that has the 25 values that you need. Once you have a segment, you can easily see metrics for that segment, which serves as an aggregation of the 25 values you desire. This can be done using the operators available in the segment builder like this:

This method works best if you can use text values to narrow down the values you want. For example, you might want all blog posts that “contain” the phrase “workspace” to be included. Unfortunately, the contains function can produce some false-positives that you might not want to be included in the segment. It also doesn’t allow you to easily pick one-offs that you might want to include. Therefore, this option is good, but not perfect.

Option 3 – Fallout

Another option for grouping dimension items is the fallout report. You can create a blank fallout report that looks like this:

Next, you can use the dimension chevron in the left navigation to view the dimension items and search for the items you want:

Unfortunately, you can only do a basic text search here, which is why I don’t love this option. But if you can isolate the items you want, you can multi-select them and drag them as a group onto the fallout report:

Lastly, you can right-click to build a segment from them grouping you just added to the fallout:

Option 4 – Dimension Filtering

The fourth approach is the one that I tend to use most often. There are great filtering capabilities available for dimensions in Freeform tables in Analysis Workspace. This filtering can be leveraged to aggregate the exact values you want. This approach provides the benefits of options #2 & 3, but offers a bit more flexibility.

To demonstrate, let’s continue with the example that I want to pick a bunch of dimension items (in this example, blog post names) and see aggregate numbers for that grouping of items. To start, I can add the dimension to a Freeform table with Occurrences as the metric to see all values:

Next, you can use the filter function in the dimension header to open the advanced filter option:

From here, you can add any criteria that will help narrow down the items. At this step, be sure to err on the side of including too many values so you don’t accidentally exclude dimension items that you might want. In this case, let’s filter for blog posts written by me (Adam) and that contain the words “workspace,” “eVar,” “training” or “campaign:”

This produces a bunch of dimension items:

If I am happy with all of these items, I can select all of them and right-click to build a segment for these specific items:

However, I could have done that with option #2 above in the segment builder. The advantage of this option is that I now have the ability to hand-pick the items that I want to group. In this case, I can manually select the items I want and again right-click to create a new segment:

After clicking, you will be taken to the segment builder with the selected items added to the segment for you:

After saving the segment, you can use it anywhere in Adobe Analytics. For example, you can view any metrics you want for that grouping of dimension items:

You could also use the new segment to create a “derived” calculated metric:

Summary

Above are a few different options for seeing groupings of items in Adobe Analytics Analysis Workspace. You may end up using all three options in different situations, but if SAINT is not an option, consider the two different ways to create segments for groupings of dimension items

Recently, one of the members of our Adobe Analytics Expert Council (AAEC) was lamenting that in the [old] Reports interface of Adobe Analytics, there is a Daily Unique Visitors metric, but that this metric is not available in Analysis Workspace. In the Reports interface, you can add Unique Visitors as a metric, which de-duplicates unique visitors for the currently selected date range, but you can also add Daily Unique Visitors which provides a sum of daily unique visitors for all of the dates in the selected timeframe. Unfortunately, in Analysis Workspace, you can only see the former (Unique Visitors) and there may be times that you want to see daily unique visitors for dimension values. As I have demonstrated in the past, I am on a mission to be able to do 100% of what could be done in the Reports interface in Analysis Workspace, so in this post, I will share a workaround that will allow you to add daily unique visitors to your Analysis Workspace projects.

Daily Uniques in Old Interface

To begin, let’s look at how daily unique visitors works in the old interface. Let’s imagine that you want to see unique visitors and daily unique visitors for a dimension (eVar) in your implementation. For example, let’s look at these metrics for my blog posts:

In this report, I am looking at just one day of data, so the two columns of data are exactly the same. But if I change the date range to be the last seven days, these metrics will start to diverge. The amount of divergence will depend on how often your site has return visitors:

In this case, for the week there have been 129 unique visitors who have viewed my UTM Campaign blog post, but that number rises to 135 if you count unique visitors on a daily basis. If you wanted to view this exact report in Analysis Workspace, you would think that it is as simple as clicking the “Try in Workspace” button shown above. But doing this does the following:

As you can see, the daily unique visitor column is stripped out because Analysis Workspace doesn’t have a notion of daily unique visitors.

Creating Daily Unique Visitors in Analysis Workspace

In order to re-create the old interface seven-day report that has both unique visitors and daily unique visitors in Analysis Workspace, we will have to do a bit of calculated metric and segment gymnastics. While the process is a bit manual, the good news is that it can be set up once and re-used with any dimension in the future.

To start, you have to choose a timeframe for which you’d like to view daily unique visitors. To keep things simple, I am going to assume that I want to see daily unique visitors for seven days. To start, I am going to create seven rolling date ranges. Adobe already provides a date range for Yesterday and Two Days Ago, so in this case, I have created the ones for 3-7 days ago.

Each of the new date ranges will be set up as rolling date ranges being X days prior from today and will look similar to this:

Once you have the seven individual date ranges created, you can create a segment for each. Each segment will simply contain the corresponding date range and be constructed like this:

When you are done, you will have these segments:

Once you have the required date range segments, the final step is to create a new calculated metric that includes a sum of all seven days. This calculated metric will use unique visitors as the metric, but will sum a segmented version of unique visitors for each day. Here is what the seven-day formula would look like:

Using Daily Unique Visitors in Analysis Workspace

So now that we have our seven-day daily unique visitors calculated metric, let’s see how we can use it to re-create the reports from the old interface. As a refresher, here is what the report looked like in the old interface when we looked at seven days of data:

Now,  Let’s add our new calculated metric to the same report in Analysis Workspace:

As you can see, we have successfully duplicated the daily unique visitor metric in Analysis Workspace!

Of course, this process is more manual than I’d like. If you want to see daily unique visitors for thirty days, you would have to create thirty rolling date ranges and thirty segments (and a long calculated metric!), but the good news is that once you have done this, you can use the calculated metric in any dimension report. For example, here is a daily unique visitor report for pages for the last seven days from the old interface:

Here is the same report in Analysis Workspace using our new seven-day daily unique visitor calculated metric:

In case it is helpful, here is a video of how I got from the report in the old interface to the one in the new interface:

In my last post, I shared how you could build segments from website paths using the flow visualization in Analysis Workspace. This was done by right-clicking on a specific path and choosing the “segment” option. In this post, I’d like to share another cool thing you can do by right-clicking within flow visualization paths – path breakdowns. Once you have created a flow report, you can pick a specific flow branch and right-click to see a host of options. In this case, we will use the “breakdown” option that is directly below the “segment” option we used in the last post as shown here:

Once you select the breakdown option, it acts like any other breakdown such that you choose if you want to breakdown the path by dimension, metric, segment or time as shown here:

To illustrate this functionality, I will breakdown the path flow of people going from the home page to my blog index page by the type of device they are using as shown here:

This will produce a table that shows the device type breakdown for the specific flow:

This table shows me that most people are viewing this flow from non-mobile devices. Keep in mind that I could have broken down this flow by any dimension, segment, etc. depending upon the business question I was trying to answer.

From here, I might want to see how this particular flow breakdown is trending over time. Is the percentage of desktop vs. mobile phone vs. tablet pretty consistent or does it vary over time? I can view this by visualizing the data in the newly created table by right-clicking again and choosing a chart type:

In this case, I chose the stacked area chart which shows me my path flow by device type trended by month…

Summary

If you have specific path flows that you want to dig deeper into, using path flow breakdowns is an easy way to see how path flows differ by dimension or segment. And if you want to see the path flow breakdowns over time, you can add visualizations to the resulting data…

Recently, Adobe updated the Analysis Workspace Flow visualization to offer more flexibility, especially when it comes to repeat instances. Many Adobe Analytics users have wanted to abandon the pathing reports in the old interface and rely solely on Flow in Analysis Workspace, but were held back by the fact that repeat instances of values passed into Adobe Analytics would appear multiple times consecutively. This made using Flow difficult at times, but now Adobe has changed Flow visualizations so that repeat instances are disabled by default:

This makes Flow much more useful when it comes to pages and any other dimension for which you want to see sequences of values.

Another thing that this change enables is easier segmentation on paths. There may be times when you would like to view a specific path flow visitors are taking and build a segment for that path to learn more about that cohort of visitors in other Adobe Analytics reports. This is possible by simply right-clicking on any path in the Flow visualization. For example, if I wanted to look at how visitors were navigating from the Analytics Demystified home page to our education page (highlighting some of my upcoming training classes), I can build a simple flow report like this:

From here, all I have to do is right-click on the path I want and Adobe will automatically create a sequential segment for me:

Once I am in the segment builder, I can name it and save it. If I want, I can also tweak it a bit. For example, if I want to see visitors who eventually found the education page within the visit, I can change the sequential segment like this:

Once the segment is saved, I can apply it to any other report in Adobe Analytics. For example, if I wanted to see which companies followed that path, I can use my Demandbase eVar to see the specific companies that might be interested in my education classes (hidden here to preserve their privacy!):

As you can see, creating segments on paths is pretty simple, but can be powerful. I suggest that you pick a few of your Adobe Analytics dimensions, add them to a Flow visualization and then try creating some segment paths.

One of the lesser-known features in the old Adobe Analytics interface was Targets. Targets allowed you to upload numbers that you expected to hit (per metric) so that you could compare your actual results with your target results. While this feature still exists in the old interface, it doesn’t translate to Analysis Workspace.

Therefore, if you want to compare your current data to a target, you have very limited options. One option is to upload your target to a new Success Event via Data Sources, but since Adobe won’t let you upload Data Sources data for future dates (please vote for this idea to change this!), you can only view targets up to the current date and you have to upload a file every day (which doesn’t sound like much fun!). The other option is to use Adobe’s ReportBuilder Excel add-on. Within Excel, you can create a data block that grabs any metric and then you can manually enter your targets in the spreadsheet and compare them in charts and graphs.

But what if you want to view your targets in Analysis Workspace? That is where you are likely spending all of your time. In this post, I will show you one method, albeit a hack, that will allow you to see metric targets in Workspace that might hold you over until Adobe [finally] allows you to upload Data Sources data into the future or provides another way do targets in Analysis Workspace.

Targets in Analysis Workspace

The first step to seeing targets in Workspace is to use Data Sources. For each metric that you want to add a target, you will need to enable a new numeric Success Event in the admin console. In this example, I will set a target for Blog Post Views, so I will create a new Success Event like this:

Next, you will use Data Sources to import your target, but with a twist. Since you cannot upload Data Sources data into the future, you are going to import your target by day for a time period in the past (i.e. one year prior to the current year). For example, if you want to see a target for Blog Post Views for Jan-Feb 2019, you could upload the targets for those months (by day) using the dates 1/1/18 – 2/28/18 (or another year in the past). I know this sounds strange, but I will explain why later. Your Data Sources set up might look like this:

In this case, I want to be able to see targets by Blog Post Author, so I have also added an eVar to the Data Sources upload. Here is what the upload file would look like for 2019 Jan-Feb Blog Post View targets for the author of “Adam Greco:”

Once you have uploaded the target data, you will have the target numbers you need, but they will each be tied to dates in the past, in this case exactly one year prior:

Next, we want to compare 2019 Blog Post Views to this target. To do this, we will create a freeform table that contains Blog Post Views for this year (I will use Jan-Feb) and narrow them down to “Adam Greco” blog posts using a segment, since that is what our target is based upon:

Next, we are going to add our target to this table, but right after we do that, we are going to use the Date Ranges feature to create a date range for our target timeframe (in the past), which in this case includes the dates of Jan-Feb 2018, where we have uploaded our Data Sources data. As you may recall, when you use Date Ranges in Analysis Workspace, they supersede whatever dates are selected in the Analysis Workspace panel, so this will allow us to see our Target data directly next to our actual 2019 data as shown here:

Next, let’s view our data by week instead of day to make it a bit easier to view and then let’s add a chart to compare the data:

Finally, let’s tidy it up a bit by locking the chart, removing some backgrounds and percentages in the table and renaming the legend in the chart:

When you are done, you will have a report that looks like this:

Now you can see how you are doing for your metric against its stated target. Unfortunately, Workspace shows the dates in the column when you use Date Ranges, so some people might get confused about why it has 2018 dates, but that is beyond my control! You can also hide the table itself to avoid this issue.

Once you have this data, you can manipulate it however you’d like. For example, you can view it by month instead of by week:

Cumulative Function

As if that weren’t cool enough, you can also use the Cumulative Function to see your actual vs. target progress over time. This is my favorite view of the data! To do this, you will create two new Metrics. One will be a cumulative count of your actual metric and the other will be a cumulative count of your target. These will use your main Success Event and your Data Sources Success event respectively. The Metric formulas are shown here:

Once you have created these, you can duplicate your table above, add these metrics and then add a chart as shown here:

When you are done, you will have a report that looks like this that shows how you are doing over time against your Target:

Final Thoughts

So that is my “hack” way to add targets to Analysis Workspace. Again, if Adobe would provide the ability to upload Data Sources data into the future, much of this would be unnecessary, but that is the state of things today. While this seems like a lot of work, it is not too bad, especially if you bear in mind that you should only be setting targets for your most important metrics and you only have to do this once a year. However, keep in mind that Data Sources only lets you upload ninety days of data at a time, so you will have to do multiple Data Sources uploads for each metric.

I hope this helps as a temporary solution…

Recently, I was working with a client to explain how panels work in Analysis Workspace. Panels in Workspace allow you to embed data visualizations and each panel can have its own segments/dimension filters and/or date ranges. I often use different panels when I want to apply different segments or date ranges to groupings of data visualizations.

For example, let’s say that you have a Fallout report that you want to see for two different weeks. Here is a screenshot of two different panels, within one project, viewed side-by-side that contain different date ranges:

In this case, it looks like it is a normal Workspace project, but I have re-sized two distinct panels and put them next to each other so I could use different date ranges for each fallout. While this works, it takes additional time and project real-estate.

Therefore, I want to show an alternative method of seeing the same data within one Workspace project panel. This method involves using custom date ranges. In Workspace, you can create any custom date ranges you need. These date ranges can be fixed or rolling depending upon your analysis needs. In this case, since I want to see two consecutive weeks, I would create two new [fixed] date ranges like this:

Once I have created these date ranges, I can drag them into a fallout report that contains the dates of both date ranges. In this case, the combined date range is April 8 – April 21, 2018. Below you will see me dragging the newly created date ranges into the fallout visualization (using the hidden drop zone!) that has the dates from both weeks:

When this is done, the final fallout report looks like this:

You can see that the fallout percentages are exactly the same as the ones shown in the side-by-side panels above. But this version uses only one visualization and takes up less space. I also think this is a slightly better way to visualize the differences for each fallout step instead of having to compare them side-by-side.

Just a quick tip to streamline your fallout reports when comparing date ranges…

In last week’s post, I shared some of the areas of Analysis Workspace that confused the students of classes I provided on the product. Most of those issues were things that had to do with some larger implications of the product (i.e. having an eVar and an sProp dimension for the same thing). Many of the things I mentioned in the last post would require Adobe to make some key product changes to address, but the goal of that post was really to help you navigate some potentially tricky items if you are doing training.

In this post, I’d like to focus more on the actual user experience of Workspace itself. These are things that, with my limited experience in product design, seem like items that Adobe could address more easily. Again, I will add the caveat that I am the furthest thing there is from a designer and I don’t purport to know of better ways to create user interfaces. But, what I do know is which things in the UX of Workspace my students could not find or figure out, even after having been shown multiple times. If users can’t find features or easily figure out how to use them, that is a problem, and Workspace is notorious for “hiding” some of the coolest aspects of the product. My hunch is that these features are hidden to reduce clutter, but as I will demonstrate below, in some cases, this reduction of clutter results in confusion and lack of feature usage. Again, this is not a critique of the people making Workspace, which I have already stated I think is amazing, but rather just me being a messenger of things that I saw cause confusion during my training classes in case you are training co-workers internally.

The Hidden Easter Eggs That Are Workspace

As I mentioned, some of the greatest stuff in Analysis Workspace is hidden or not super obvious to users. In Freeform tables, right-clicking opens up many great options that casual users don’t know about. While the 1980’s gamer in me loves the easter egg aspect of Workspace, especially when I can show someone a new feature they didn’t know about, I can tell you after training new folks on the product, they did not think it was as cool as I did! So the first part of this post will cover all of the “hidden” stuff that frustrated my students.

Hidden chevron in dimensions

A frequent task when using Workspace is going to the left navigation to view your dimensions (eVars and sProps) in order to find the values that have been collected within each dimension. For example, if you want to see a flow from a specific page, you would look for the page dimension in the left navigation to see its values and then drag over the desired page to the flow visualization. However, when doing exercises, most of my students could not figure out how to find the dimension values. Typically, when they looked at the left navigation and saw the dimensions (like Page), they got stuck. I told them that they needed to hover over the dimension and only then they would magically see a chevron which would then allow them to expand and see the resulting values as shown here:

Soon after, they would forget that the chevron was there and I had to keep reminding them of this. Evenutally, I began referring to this as the “hidden chevron” to jog their memory. They didn’t understand why the chevron couldn’t always be there as a reminder that there is more stuff to be found underneath it. I also had many students thinking that they were supposed to double-click on the dimension to expose its underlying values (which did nothing but select and deselect the dimension in the left navigation). So be on the lookout for this potential confusion from your users as well and you may want to just save time and introduce it as the “hidden chevron” from the start…

Hidden items in visualization header

When I began teaching students that they could copy, edit, duplicate and get links to a visualization by right-clicking, they were excited. However, they soon realized that knowing exactly where to right-click in the header of the visualization was hit or miss.

Eventually, they got it, but they often asked me why there wasn’t a gear icon for the visualization since almost every other thing in Workspace had a gear icon!

While on the topic of the visualization header, let’s discuss the “copy to clipboard” option. Many of my students assumed that this would be an easy way for them to copy the visualization and paste it into a PowerPoint slide to show others in a meeting. Unfortunately, here is what happens when you copy and paste using the Copy to Clipboard option:

It might be handy to have a copy visualization image option here in addition to copying the actual data.

Additionally, some super handy things in the header of the chart visualization include the ability to “lock” the chart to table data and/or to show/hide table data. Unfortunately, both of these options are found in a [very] tiny little dot at the top-left of the visualization as shown here:

While they would eventually learn this, I can’t tell you how many times I was asked: “where is the place that I lock data and hide the table?” Again, I am not sure why these options can’t be part of the gear icon that already exists for charts, but I just mention that you may have to tell your students a few times about the stuff hidden in the chart dots.

Hidden items in Freeform table columns

Freeform tables are often the most popular Workspace visualization. Like Excel spreadsheets, they allow you to see data in a tabular format. In Workspace Freeform tables, there is a way to customize the columns by hovering over the column header and clicking the gear icon. This was another “hidden” feature that users saw me demonstrate, but later could not find. They also could not figure out how to close the window that opened when they clicked the gear icon since there is no “X” there, so I had to tell them that they just had to click away from the box somewhere else. You can see both the hidden gear icon and the lack of a way to close the window here:

Similarly, changing the sort column in Freeform tables requires the user to know to hover their mouse in the exact right place (next to column total metric). Most folks thought that clicking the column heading would sort (as in the old “Reports” UI), but instead, they had to learn to hover in the correct spot to sort…

For both of these items (gear and sort), I assume that the icons are hidden to make the table look cleaner. However, I wonder if there might be a way to have an “edit” mode when building a project that displays all of the icons like there was an edit mode for dashboards in the older interface. Perhaps give users the option of which view they prefer and then people can have the best of both worlds?

Hidden drop zones

One of the coolest parts of Analysis Workspace is that you can drag and drop components all kinds of places and tweak your data. For example, you can drag segments or dimension values into Freeform table columns and in other visualizations. Unfortunately, there are some places that you can drop items that are so well hidden that many users don’t discover them or remember after they have been trained.

One example of this is the Fallout visualization. In this visualization, you can drag segment or dimension values to the top of the report and see the same fallout segmented as shown here:

The only problem is that there is nothing telling you that you can drop things there. I am not sure why there aren’t blank segment/dimension drop zone boxes there like there are for other visualizations (i.e. Flow, Cohort, etc.).

Similarly, in the Flow visualization, users need to know that they can drop a dimension value on top of another to replace it, but there isn’t any type of visual cue that this is possible. Also, if a user wants to add a second dimension to the Flow report, they have to know that there is another hidden drop zone to the right of the right-most column. You can see both of these here:

Don’t get me wrong, these are super-cool features, but I dare you to stand in front of a class of novice users and get them to find these and remember where they are two weeks later!

Other UX Items

Renaming Fallout Steps

When you create a fallout report, there are some cases in which the names of each fallout step can be very long. This can be due to long page names or having multiple items in each step. To remedy this, Workspace provides a way to rename each Fallout step. The weird thing here is that you only seem to be able to edit the Fallout steps if you mouse coming in the downward direction. Double-Clicking on the name, as my students tried to do, didn’t work. Here is a video of me trying to double-click and coming at the name from bottom and top:

Maybe I am just bad with my mouse, but I find it very difficult to get to the exact right spot to edit step names and my students did as well. My hunch is that there has to be a better way to let people rename steps…

Laptop Screen

I normally work on a huge monitor (three in fact!) when I am using Workspace. But when I began conducting training classes, I was on my laptop and my students were as well. I was amazed at how much harder some things in Workspace were when you were on a smaller screen. For example, as I began the class and asked my students to create their first project, they could not figure out how to do it. I couldn’t for the life of me figure out why they couldn’t do something so simple. Then I went over to their laptop and realized that the blue button they needed to click on the screen showing the templates was below the fold and they were not seeing it. They had to know to scroll down to see CREATE button they needed to click. You can see this here:

I had never seen that on my large monitor, but suddenly got it and was prepared for that in subsequent classes. I wonder if there should be a blue button at the top of the screen as well?

Another example of this was when I taught students how to use functions in the Calculated Metric builder. Students kept telling me that they didn’t have any of the functions and eventually I realized that they are so low in the left navigation on a laptop, that students weren’t seeing that they were in the left navigation as shown here:

There were more cases like this that popped up during the training and it made me wonder if those designing the Workspace interface were spending as much time using the tool on laptops as they were on large monitors?

Default Options

The last item I want to discuss is the concept of project default options. When you create a lot of Workspace projects, you tend to come up with your own little preferences on how you’d like to set them up. For me, I always begin a project by using Project – Info & Settings to make the project “compact” and whenever I add pathing-related visualizations (i.e. Flow Fallout), I tend to use Visit instead of Visitor. It would be great if I could tell Workspace that when I create a new project, I want these to be the default instead of having to update these each time. I am sure there are other items I’d like to make the default (i.e. color scheme) as well…

Summary

Once again, I’d like to stress that I love Analysis Workspace and am not a designer. My intention for sharing this information is to alert those who may be doing training of things that they might want to know about before they get the same types of questions I did. At some point, students/users have to just learn where things are and memorize it, but the above items might represent opportunities for Adobe to help everyone to more easily find and use the amazing features in the Workspace product.

Analysis Workspace, the dynamic reporting interface for the Adobe Experience Cloud, is truly an amazing piece of technology. Over the past few years, Adobe has made tremendous strides in reporting by miraculously moving the functionality from the Ad-Hoc app to a similar, but web-based experience. You know the technology is good when, given a choice between the old “Reports” interface and the “Workspace” interface, most users voluntarily migrate over to the new one (even though some Ad-Hoc users are still not happy about Ad-Hoc being sunset).

Currently, I am in the midst of training approximately five-hundred people on Analysis Workspace for a client. When you conduct training classes on a product, you gain a new perspective on it. This includes being amazed by its cool parts and frustrated by its bad parts. You never really know a product until you have to stand up in front of thirty people, two times a day, five days a week and try and teach them how to use it. Since I have done a lot of training, when conducting a class, I can easily see in people’s faces when they get something and when they don’t. I also make mental notes of things that generate the most questions on a consistent basis. As a power user myself, there are many things in Workspace I take for granted that are confusing for those newer to the product and those casual users who may only interact with it a few times per week.

Therefore, the following will share things I observed while training people on Workspace in case it helps you when training your team on Workspace. The items that my students found confusing might also confuse your co-workers, so think of this as a way to know where potential land-mines might be so you can anticipate them. This is by no means meant to be critical of Adobe and the Workspace product, but rather simply an accounting of areas my students struggled with.

So what follows is a laundry list of the things that I noticed confused my students most about Workspace. These were the times I was explaining something and I either got questions, saw confused looks on faces, or had students unable to easily complete hands-on exercises. While I don’t have time in this post to document how I explained the items below, what you find below is just meant to highlight things that you may encounter.

Difference between segments and dimension values

There are many cases in Workspace where you can use segments or specific values of a dimension to narrow down the data you are analyzing. For example, you can apply both to the drop zone at the top of a project panel or within columns of a freeform table. Unfortunately, it isn’t easy to explain to novices that using a Segment can narrow down data by Visitors, Visits, or Hits, but that filtering using a dimension value is limited to applying a Hit filter (unless you edit it and turn it into a segment). This is especially true when using dimension values to create cross-tabs or within Venn visualizations.

Difference between using dimension and dimension values

There are some cases where your users may be confused about whether they should drag over the dimension or the dimension values (using the hidden dimension chevron-more on this next week!). For example, when you use a Flow visualization, even though it is labeled in the boxes, I found many users were confused about the fact that they could only drag the dimension to the Entry/Exit box, but could drag either a dimension or a dimension value to the middle box.

It was also confusing to them that dragging over the dimension picks a dimension value for them, which then has to be replaced with the actual dimension value they want by dropping it on top of the focus value of the flow (with no type of indicator letting them know that it was even possible to drop a page value onto the existing page value).

Pathing visualizations with Visit or Visitor radio button

While on the subject of the Flow pathing visualization, I also received numerous questions about whether they should use the Visit or Visitor option (radio button) for Flow and Fallout. If using Visitor, does it matter if the same visitor repeated steps or took slightly different paths in their second/third visit? Why does Workspace default to Visitor? Is there a way to make Visit the default for all new visualizations?

Count Instances

In the Project – Info & Settings, there is an option to count instances or not. This was very confusing to people and it would be good if Adobe could provide more context around this and what it impacts.

I also tried to avoid conversations about “Repeat Instances” in Flow reports for my novice users since I learned early on that this concept was only really understood by more experienced users.

Default Occurrences Metric

If you make a new freeform table in Workspace and start by dragging over dimensions before metrics, the table defaults to the Occurrences metric.

As you can imagine, explaining what an Occurrence is versus a Page View can be tricky for people who only casually use Adobe Analytics. While I use it as a good interview question, everyday users can find this confusing, so it may be better to default new tables to Page Views or Visits. I also recommended that my students always add metrics to tables before dimensions to minimize seeing the Occurrences metric.

Time Dimensions/Components

When I was doing exercises with students, I would often ask them to make freeform tables and show me the data by day, week or month. So, they would use the left navigation to search and see this:

At this point, they would ask me whether they should use the “orange” version of the week or the “purple” version of the week. This led to a discussion about how Time components alter the dates of the project and usually was a downward spiral from there for novice users! One thing you can do is to use Workspace project curation and share a project that has fewer items to limit what novice users will see.

Viewing the same dimension as eVar and sProp

While this is not really a Workspace issue, I often got questions about cases in which doing a search in the left navigation produced multiple versions of a dimension:

Putting aside the awkward conversation about eVar Instances and the Entry/Exit versions of sProps, this forces a conversation about when to use the eVar version and when to use the sProp version that very few novice users will understand. This is why I encourage my customers to remove as many of their sProps as they can to avoid this confusion. In the “Reports” interface, eVars and sProps are segregated, but in Workspace, they can be seen next to each other in many situations. Again, you can use Workspace project curation and share a project that has fewer items to limit what novice users will see.

Filtering & Column Totals

When I explained how users could use the text filter box in the column header of Freeform tables (which they can only see if they hover) to choose the specific values they want to see, users didn’t understand why the column totals didn’t change to reflect the newly filtered values.

They expected that the column totals and the row percentages would change based upon what was filtered. When I explained that this could be done through segmentation versus filtering, I got a lot of head scratches. Perhaps one day, Workspace will add a feature to let users choose if they want to have filter impact column totals and row percentages.

Temporary Segments & Metrics

There are a few places in Workspace where you can quickly create segments or new metrics. The former can be done in the segment area at the top of each panel and the latter can be done by right-clicking on columns. Unfortunately, in both of these cases, the segments/metrics created are “temporary” such that they don’t appear in the left navigation or in other projects (unless you edit them and choose “make public” option). I am sure this feature was added to reduce clutter in the left navigation component area, but as a trainer, it is hard to explain why you should create segments/metrics one way if you want them to be “public” and another way if they are “temporary.” I am not sure of the solution here, but I will tell you that your users may be confused about this as well.

Fallout with Success Events vs. Calculated Metric with Success Events

When doing classes, I often asked students to show me the conversion rate between two Success Events. For example, there might be a Leads Started event and a Leads Completed event and I wanted them to tell me what percent of Leads Started were Completed. To me, this was an exercise to have them show me that they knew how to create a new Calculated Metric. However, I was surprised that on multiple occasions students chose to answer this question by creating a Fallout report that used these two Success Events instead. Unfortunately, the resulting conversion rate metric will not be the same since the Fallout report is a count of Unique Visitors and the Calculated Metric divides the actual Success Event numbers. Sometimes they were close, but I got questions about why the numbers were different. This is just an education thing, but be prepared for it.

Derived Metrics & Cohorts

One of the things I love the most about Adobe Analytics is the ability to create derived metrics. These are Calculated Metrics that have a segment or dimension value associated with them. When I explained Cohort tables to students, they thought they were cool, especially when I showed them how to apply segments to Cohorts. Unfortunately, you cannot use Calculated Metrics (of which derived metrics are a subset) in Cohort reports. Upon learning this, my students astutely pointed out that you can add a metric and a segment to a Cohort table, but you cannot add a derived metric, which is just a metric and a segment combined. They didn’t understand why that would be the case. I am sure there is a valid reason for this, but I just wanted to highlight it as another question you may receive.

Segmentation and Containers

Ever since segmentation was created in Adobe Analytics, it has been something that confused novice users. Since you can add so much to a segment and use so many operators, it can be overwhelming. Teaching segmentation is typically the hardest part of classes on Adobe Analytics and since it is front and center in Workspace, it is unavoidable.

One particularly confusing area is the topic of containers within segments. Most people can [eventually] understand why they need containers when different operators are being used, but what I found in my classes is that understanding that each container can be set to Visitor, Visit, or Hit level can push novice users over the edge! If users add a container, it defaults to a “Hit” container which can produce no data in certain situations like this:

Summary

To summarize, the above items are ones that I found generated the most questions and confusion consistently across many classes with students of varying degrees of experience with Adobe Analytics. When these types of questions arise, you will have to decide if you want to tackle them and, if so, how deep you want to go. For now, I just wanted to share my experience as something to consider before you train your employees on Workspace. In next week’s post, I will outline some of the Workspace UX/Design things that my students struggled with in classes.

One of the concepts in Adobe Analytics that confuses my customers is the notion that each sProp has a normal value, an entry value, and an exit value. When using Analysis Workspace, you might see something like this in the left navigation when filtering:

As you can imagine, this could freak out novice users. More often than not, when I ask users “What do the Entry and Exit version of sProp X represent,” I hear this:

“The Entry version of the sProp is only counted when the sProp is sent a value on the first page of the visit and the Exit version is only counted when the sProp is set on the last page of the visit…”

That seems logical, but unfortunately, it is wrong! In reality, the Entry version of the sProp simply stores the first value that is passed to the sProp in a visit and the Exit version stores the last value that is passed to the sProp in a visit. Instead of Entry and Exit, Adobe should really call these First and Last values of the sProp (but that is probably not high on their list!). If a visit contains only one value, then that value would be the same in the Entry version, the normal version and the Exit version of the sProp. But if the sProp contains several values in the visit, one will be designated as the first (entry) and one will be the last (exit). Here is Adobe’s explanation in the documentation:

However, the larger question is why the heck does Adobe even store all of these extra values? How can you use them? These Entry and Exit values are typically used in pathing-related reports, but in this post, I will share some other ways to take advantage of the confusion that these extra sProp values create.

Example: Internal Search Keyword Analysis

Let’s imagine that you have a site that has a lot of internal searches and keyword activity. You are trying to determine which keywords are doing well and which are not. While you may already be tracking the internal search click-through rates, internal search placement and average internal search position clicked, in this scenario, you want to see how often each internal search keyword used was both the first one searched and the last one searched and what the exit rate was for each keyword. This can all be done using the aforementioned derivatives of the internal search keyword sProp.

To start, let’s create a table that captures the top five internal search keywords (FYI: for an sProp, Occurrences is the same as an Internal Searches success event):

Next, let’s breakdown the top keyword by the Entry version of the sProp to see how often the most popular keyword was also the entry keyword:

Here we can see that 68.5% of the time, the top keyword searched was also the entry (first) keyword. Next, we’d like to isolate the 68.5 % and use it as a metric, so I created a new calculated metric that pulls it into its own column. This is done by dividing Occurrences by the column total using a calculated metric function:

When saved and added to the table, it looks like this:

Next, I am going to create a summary number based upon the cell that contains the 68.5%:

Then I am going to repeat all of these steps for the Exit Search term so I have an additional table that looks like this:

In this case, our most popular internal search keyword was also the last keyword used 87% of the time so I will add that as another summary number (I collapsed the first table so you could see it more easily):

Next, I want to see how often the keyword is used and then visitors exit the site on the search results page (similar to what I described in this old post). I do this by creating a new calculated metric that quantifies how often the search results page is the exit page:

Then I can add this to my table and create another calculated metric to divide Occurrences by Search Page Exits:

Here I can see that the top search keyword is an exit 34.6% of the time. Again, I create a summary number so I have all three at the top of my Workspace project:

Build For Scale

So all of that was pretty cool! In one row, I can see the keyword’s first use, last use, and exit %. However, there is one problem. All of this is hard-coded to my top internal search keyword. That is not very scalable. What if I want to see the same numbers for any internal search keyword?

To make this a bit better, the next step is to pick a bunch of internal search keywords and drag them to the segment area, using the shift key to make them a picklist:

Once you do this, you can pick one of your keywords and all of the tables will focus on that keyword like this:

Even better, now that we are narrowing down to just one keyword, we can lock in the Exit Keyword % Summary Number since it will always be the top-right cell:

Now, we can simply change the drop-down value and all of our numbers should re-adjust as shown here:

This works by default because many times the chosen keyword will also be the first and last keyword, so the highlighting of the top-right % in each table works and updates the summary numbers. However, that will not always be the case. Sometimes, the most popular first/last keyword will not be the same as the chosen keyword itself (Note: You can vote for my idea to make cells references to other cells in Analysis Workspace like you can in Excel!). In that case, you may have to manually select the First and Last keyword to see the correct summary numbers as shown here:

Therefore, I have finished this dashboard by putting a text box explaining this potential warning and need for adjustment:

Summary

As stated at the beginning of this post, understanding the “Entry” and “Exit” versions of sProps can be a bit confusing. But once you understand the concept, you can identify ways to leverage them to do additional analysis. In this post, I covered a way to utilize the First and Last sProp values to quantify the percent of the time the same internal search keyword was used first and last. This concept can be applied to any sProp, not just internal search keywords. Anytime you want to compare values stored in sProps with the first and last entries received, you can try this out.

While I spend 99% of the time I use Adobe Analytics in Analysis Workspace, there are still a few things that haven’t migrated over from the old interface. One of them is the Page Summary Report. While I can’t believe that I still use a report that was around in version 9.x, at times, it is handy to get an overview of a specific web page. Here is what it looks like:

As you can see, there is a lot of information packed into a small space and it offers links as launching off points for several key reports.

Unfortunately, there is really no equivalent to this report in Analysis Workspace. Therefore, I decided to see if I could re-create it. While I was able to do most of it, it wasn’t as straightforward as I thought it would be (though it did spawn a few Workspace feature requests!). While “the juice may not be worth the squeeze” in this case, in the name of science, the following will show you how I did it…

Creating the Page Summary Report in Workspace

The first step is to create a trended view of the page you want to focus on. To do this, you can create a table that shows Page Views and use Time components to view this month, last month and last year like this:

You will notice that I have six columns of data here instead of three. This is because you can look at the data for the current month or a past month. In this case, I am looking at May 2019 data but I am currently in the month of June. To view last’s month’s page summary data, I highlight the left three columns. If I were still in May, I would highlight the right three columns. Regardless of which month I am interested in, the next step would be to add a chart for the three highlighted columns like this:

Next, you can apply a page filter with a bunch of pages like this (remember to hold down the Shift key!):

Next, you can pick the page you want to focus on from the list and your table and chart will be filtered for that page:

Once you have this, you can hide the table that underlies the chart to save room in your project.

Next, we have to add a Flow visualization to see where people are going before and after the page of interest. Unfortunately, we can’t add a Flow visualization to our existing Workspace panel because that is being filtered for only hits where the Page equals our page of interest (the default nature of filters). Therefore, we need to add a new panel and add the Flow visualization to it and drag over the page we care about as the focus of the Flow visualization. In this case, that page is the Adobe Analytics Expert Council Page:

To view that we are on the right track, we can compare the old Page Summary Report to the Workspace one to see how we are doing so far…Here we can see that our chart looks pretty similar (the old page summary report shifts dates slightly to line up days of the week):

And we can see that our flow looks similar as well:

Next to tackle is a list of detailed metrics that the old Page Summary report provides that looks like this:

To replicate this, we need to make some summary metrics in Workspace, which means that we need a table that has the metrics we need with a filter for the page we are focused upon:

A few things I discovered when doing this include:

• Page Views and Occurrences are the same, so you can use whichever you prefer
• Single Page Visits only matches the old page summary report number if repeat instances are on for your Workspace project
• There is no “Clicks to Page” metric in Workspace, but I found that this is really just Average Page Depth. Therefore, you can use that or do what I have done and created a new Calculated Metric called Clicks to Page that has Average Page Depth as the formula.
• Workspace shows Time Spent in seconds vs. the minutes version shown on the old page summary report. You can create a new calculated metric to divide by 60 if you’d like as shown above. However, I am finding that the numbers for this metric don’t always match perfectly (but who really cares about time spent right?)

The only metric we are missing from the old page summary report is the percentage of all page views. This one is a bit tricky due to the fact that you cannot divide metrics from different Workspace tables by each other or divide Summary Metrics (please vote for this here!). To view this, we will create a new calculated metric that divides Page Views of our focus page by the total Page Views for the time period. To do this, we create a “derived” metric that looks like this:

This can all be done from within the calculated metric builder like this:

Once we have our new metric, we create a new table that looks like this:

From here we can add some Summary Numbers using the totals of the columns in our two new tables:

You will see that these numbers match what is found on the old Page Summary report:

As you can see, these numbers are spot on with the old page summary report.

Viewing Page Summary for Another Page

Unfortunately, when you want to focus on a different page, this Page Summary Workspace project will not auto-update by simply changing the page name in the top filter area. There are a few changes you need to make due to the fact that you cannot currently link segments/filters in Workspace projects (here is my idea suggestion on how to make this a bit easier). Until then, I have added a text box at the top of the project that explains the instructions for changing to a new page:

While this may seem cumbersome, here is a short video of me changing the entire project to use a new page (in under one minute!):

When this is done, the summary metrics look like this:

And the Page Summary report looks like this:

So other than the time spent metric being a bit off, the rest of the numbers are an exact match!

Finally, when you are finished, you can clean-up the project a bit by hiding data table and curating so the end result looks something like this:

Have you ever wanted to run a specific scenario in Adobe Analytics, but couldn’t find the exact page flow or variable combination in your own data? This happens to me often. I want to view visitors going down a specific path or setting a specific eVar, but even after spending a lot of time building granular segments, I still can’t mock up or test the scenario I want. If I could isolate the right traffic, I could test out specific website paths, test to see if eVars are behaving as I’d expect and so on. While there are a few “techy” ways to do this with JavaScript, if you are not super-technical (like me), this post will show how you can do this yourself with no tagging required.

Query String & Processing Rule

One way you can mock-up or test the data you want is to use query strings and an Adobe Analytics processing rule. Query strings are parameters appended to page URL’s and you can set them to whatever you want. Adobe Analytics processing rules allow you to set Adobe Analytics variables using rules instead of JavaScript code. When you combine the two, you can pick and choose what data you want to capture in Adobe Analytics later on through an easy application of segmentation.

To start, you will want to come up with a query string parameter that you will use for the times you want to make your own data. In this case, I will use the query string of “?qa_test=” in the URL. For example, if I want to count an instance of the Analytics Demystified home page in my data set, I would make the URL look like this:

https://analyticsdemystified.com?qa_test=XXX

Next, you can set up a processing rule that will look for this query string and pass anything found AFTER the equals sign to an Adobe Analytics variable. In this case, I have created a new sProp called QA Test [p11]. Here is what the processing rule using the query string and this new sProp looks like:

Once this processing rule is active, any URL that has a “?qa_test=” query string will pass the value to the sProp which means that I can run as many test scenarios as I want. To demonstrate this, let’s go through an example. Let’s say that I want to view a specific website path. The path I want is one in which a visitor enters on the home page, views a blog post of mine talking about my Sydney Australia class and then exits on the Eventbrite link to register for the class.

To start, I would copy and paste the URL of my home page and append the appropriate query string (“EntryHomePage:AustraliaPost:LinkOutEventbrite” in this case) like this:

Next, I would repeat this for the URL of the Australia blog post, making sure to append the same query string parameter and value:

Lastly, I would click the link to Eventbrite, which would count as an exit link (so it doesn’t need the query string parameter):

In this scenario, we have sent two hits into Adobe Analytics and then had one exit link. Depending upon how you build your segment later (Hit vs. Visit), it doesn’t even matter if you click on other pages in between the ones you care about. If you later use a Visit segment, it will include all hits, but if you use a Hit segment, it will only include the ones you have designated (more on that later). If you want to test that your hits are coming through, you can use the Real-Time reports to view your QA Test sProp values in near real-time (Note: Processing Rule data will not appear in the Experience Cloud Debugger):

Using Your Data

Once you have passed the data you need, the next step is to build a segment that isolates this data. As mentioned above, a Hit segment will show only the pages that had the query string parameter, but a Visit/Visitor segment container will bring back other pages viewed in the same session or by the same browser. In this case, let’s use a Hit container so we only see the specific data we intentionally added. To do this, you simply make a Hit segment with the sProp11 equal to the value you placed in the query string:

Here we can see that there is 1 Unique Visitor, 1 Visit and 2 Page Views for the segment. This looks correct, so we can save it and begin applying it to reports. With the segment applied, we can check out the results. In this case, I will add a Pages and Exit Links table to see if the data looks as I expect (which it does):

Obviously, this is a very simple example, but it still illustrates that you can use a query string and processing rule to isolate whatever traffic you want.

Advanced Uses

If you want to get a bit more sophisticated with this approach and you don’t want to spend your life setting query strings on each page, another way to use this concept is to simply begin a visit with a query string and then use an “entry” segment to include all data taking place after the initial query string. To do this, I suggest that you begin by clearing your cookies or use a private or incognito browser window. Once you have that, paste in the entry page URL with the desired query string like this:

Once you have done this, you can surf the site however you want to generate the traffic you want to see in your reports. Watching the sequence below, you can see that I have chosen to view the Demystified home page,  then a page detailed some training days we are doing in Chicago later this year, then a page about the AAEC, then a page showing when Demystified folks are speaking at events and then back to the home page.

Once you have completed this, you can create a new segment that looks for Visits that began with the chosen query string parameter. This can be done a few ways using a URL variable or using the Entry version of the QA Test sProp as shown here (note that the query string doesn’t have to be the first page of the visit):

When that segment is applied, you will see the pages and paths that took place accordingly:

Test New Flow Instances

This concept can also be used to test out specific Adobe Analytics features. For example, let’s pretend that you don’t trust that Adobe has really addressed the “repeated instances” in Flow visualizations described in this post. To test this, you can use the entry query string concept again to model a specific path. In this case, I am using ?qa_test=EntryPageTest2″ on the first URL of the session and, in the session, I am visiting a few pages on the Demystified website. You will notice in the page sequence below that I am purposely refreshing two pages in my session (Adobe Analytics Expert Council and Adobe Analytics Audit):

Once that session has processed, I can create a new segment that looks for pages where the entry value in my QA Test sProp equals “EntryPageTest2” per the description above. Next, I can apply this segment to a Flow Visualization. In the video below, notice that I am first looking at the path flow where repeat instances are disabled. In that case, I see the pages in the order I viewed them and the page refreshes don’t appear. But once I change the setting to include the repeat instances (as was always the case prior to last week’s ADobe release), I can once again see the same page repeated three times for the AAEC page and two times for the Audit page.

Therefore, using the query string parameter, I can do some very detailed tests and make sure that everything in Adobe Analytics is working as I would expect.

Summary

As you can see, this technique can be used whenever you want to be prescriptive about the data you are viewing in Adobe Analytics. And since it requires no tagging, anyone [who has Admin rights] can do it. I have found this especially useful when I want to test out the differences between Hit, Visit and Visitor segments and testing segments in general. The above has mainly shown how the technique can be applied to pathing/flow sequences, but it can also be used to test out any type of Adobe Analytics tagging.

Recently, while working with a new client, I noticed something that I have seen a few clients do related to Once per Visit Success Events. These clients set a bunch of Success Events with event serialization set to Once Per Visit as seen here in the Admin Console:

In these situations, the client tends to have the same Success Event unserialized in a different variable number. For example, they might have event10 set to Form Completions and then event61 set to Form Completions Once per Visit.

So why would a company do this? In most cases, the company wants to have a count of cases in which at least one instance of the event took place within the session. While there are some good reasons to use Once per Visit event serialization, in most cases, I feel that duplicating a large swath of your Success Events in order to have a Once per Visit version is unnecessary. Doing this adds more data points to your implementation, causing the need for more QA and potentially confusing your end-users. In this post, I will share an alternative method of accomplishing the same goal with less tagging and work in general.

Derived Metrics Alternative

As I have discussed in previous blog posts, it is easy to use the Calculated Metric builder to make brand new “derived” metrics in Adobe Analytics. In many cases, this is done by adding a segment to another metric in a way that makes it a subset of the metric. As such, derived metrics can be used instead of duplicating your Success Events and making a Once per Visit version for each. To illustrate this, I will use an example with my blog.

In this scenario, let’s imagine that I have a need to view a metric that shows how many website visits contained a blog post view. I already have a Success Event that fires whenever a blog post view occurs, so I can see how many blog post views occur each day, but that is not what is desired in this case. Instead, I want to see how many visits contained a blog post, so using the method described above, I could create a second Success Event that fires each time a blog post view occurs and serialize it as Once per Visit. This second Success Event would only count once regardless of how many blog post views take place in the session. If I compare this new Success Event to the raw Blog Post Success Event metric, I might see something like this:

Here you can see that the serialized version is less than the raw version, with the difference representing visitors who viewed multiple blog posts per visit.

But as mentioned earlier, this required creating a second Success Event which I don’t really want to do. I can get the same data without any additional tagging work by leveraging derived metrics in Adobe Analytics. In this example, I will start by building a segment that looks for visits in which a blog post view existed:

Next, I will add this new segment to a new Calculated Metric along with Visits as shown here:

Now I have a new derived metric that counts visits in which a blog post took place. If I add this new metric to the table shown above, I see the following:

As you can see, the new derived metric is exactly the same as the Oncer per Visit Success Event, but any user can create it with no technical tagging or additional QA needed! Sometimes, less is more! You can create as many of these derived metrics as you need and share them with your users as needed.

Caveats

There is one important thing to remember when considering whether to set additional Oncer per Visit Success Events or use derived metrics. Derived metrics are a form of Calculated Metrics and Calculated Metrics cannot be used everywhere within Adobe Analytics. For example, Calculated Metrics cannot be used in segments (i.e. Calculated Metric X is > 50), cohort analyses, histograms, DataWarehouse, etc. Therefore, it is important for you to think about how you will use the metrics before deciding whether to make them actual Success Events or derive them via Calculated Metrics. My advice is to begin with the derived metric approach and see if you run into any limitations and, only then, create new Once per Visit Success Events for metrics that need it.

Yesterday, Adobe released a new update to the Analysis Workspace Flow visualization that [finally] has the long-awaiting “no repeat instances” feature. This has been something that has prevented many Adobe Analytics users from abandoning the [very] old pathing reports in the old interface. In the old interface pathing reports, if a visitor had a sProp that received the same value multiple times in a row, the path reports would ignore the repeat values and only create a new path branch when a new value was received. When the Analysis Workspace Flow visualization was introduced, it came with the ability to view paths for sProps and eVars, which was super exciting, but when people starting using the new Flow reports they would see the same value over and over again like this:

This was due to the fact that the Flow visualization was based upon persisting values instead of instances. As of yesterday, Flow reports are based upon actual instances of values being passed and the new checkbox gives you the ability to view or not view those repeat instances. Therefore, the initial Flow visualization report was like taking one step forward, but another step back. The duplicative values would appear for a number of reasons:

1. eVar persistence;
2. Page refreshes;
3. Visitors getting an eVar value, then going to another page and then coming back to a page where the same eVar value was set (in the example above, the blog post title is set each time the blog post is viewed);
4. Visitors having sessions time out and then restarting the session on a page that passes the same value.

This problem was exacerbated if you chose to have your flow based upon “Visitor” instead of “Visit” since the visitor could return the next day and receive the same values. The end result was that people like me would continue to use sProps for pathing to avoid the messiness shown above since it isn’t fun explaining the inner workings of Adobe Analytics “Instances” to business stakeholders!

However, with yesterday’s release, you now have the ability in the settings panel of the Flow visualization to toggle off repeat instances:

When you uncheck the repeat instances setting, the above report will look like this:

In this view, only different values will create new flow branches, like is the case in the old pathing reports. But since you can use the Flow visualization with eVars and sProps, you no longer need to reply on the pathing reports of the old Reports interface.

In case you are curious, I also tested what happens with a sProp. In this case, I store the blog post title in both a sProp and an eVar, so I can easily see the flow visualization for the sProp version. As you can see here, it is identical to the eVar:

The same is true for the version that hides repeat instances:

Use Cases

So how can you take advantage of this new Flow visualization feature? As I stated, the most obvious use case is to cut back on any sProps you were using simply for pathing purposes. As I have mentioned in the past, casual users of Adobe Analytics can easily get confused when there are multiple versions of the same variable since they don’t really understand the differences between an eVar and a sProp (nor should they!). For example, if you are tracking internal search terms in an eVar, but want to see the order in which search terms are used, you can now do both with the eVar instead of having to create a redundant Internal Search Term sProp.

Other use cases might include:

• Ability to view Marketing Channels used including and not including cases where the same marketing channel was used in succession
• Ability to see which top navigation links are used including and not including cases where the same nav link was clicked in succession
• Ability to view clicks on links on the home page including and not including cases where the same link was clicked in succession

Fine Print

There are a few cases called out in the documentation for which it is not possible to use this new “no repeat instances” functionality. Those cases involve variables that have multiple values such as list eVars, list sProps, the Products variable and merchandising eVars:

This makes sense since there is a lot going on with those special variables, but if you use them in the Flow visualization, the new “repeat instances” option will be grayed out indicating that it cannot be used:

BTW, if you try to beat the system and add a multi-valued dimension to an existing flow report, you will get the following warning (Ben, Jen & Trevor think of everything!):

Summary

Overall, this new Flow visualization feature will make a lot of people’s lives easier and I encourage you to check it out. If you want to learn more about it, you can check out Jen Lasser’s YouTube video about it. Enjoy!

If you work at an organization that does a lot of digital marketing campaigns, there may be occasions in which you or your stakeholders want to see activity in real-time. In this post, I will demonstrate how to do this in Adobe Analytics.

Campaign Tracking – eVar

If you are using digital marketing campaigns, you should already be tracking marketing campaign codes in the Adobe Analytics Campaigns variable. This involves passing some sort of string that represents each different advertising spot down to the most granular level. These codes can be numeric or you can structure them in a way that makes sense to your organization. I use the UTM method that Google has made a common standard.

However, even if you are tracking your campaigns correctly in the Campaigns variable, there is another step you need to take in order to view people accessing the campaign codes in real-time. Adobe Analytics real-time reports work best with Success Events and sProps. The Campaigns variable in Adobe Analytics is an eVar and eVars don’t work super-well with real-time reports because they persist. If you attempt to select the Tracking Code (Campaigns) eVar from within the real-time report configurator, you will see this:

This scary warning is basically telling you that using an eVar might not work. Here is what the real-time report looks like if you ignore the warning:

As you can see, that doesn’t produce the results you want. Therefore, once you have your campaign codes in the Tracking Code (Campaigns) variable, there is one more step you need to take to view them in real-time.

Campaign Tracking – sProp

Since real-time reports work better with sProps, the next step is to copy your campaign tracking code values to a sProp. This can be done via JavaScript, TMS or a processing rule. Here is a simple Processing Rule that I created to copy the values over to a sProp:

To be sure the data is copying over correctly after you have some time for data to collect, you can open the new sProp report and view the data:

Next, you can go back to the real-time report configurator and choose to base your report on this new sProp dimension. Once you save and refresh, you will see your campaign codes stream in as visitors hit your site:

Filtering

One last tip related to using the real-time reports. In this campaign code scenario, you may find cases in which the real-time report contains codes that are from older campaigns that don’t apply to your current analysis. For example, you might want to see how the various “exp-cloud-aud” campaign codes are performing, but there are others appearing as well:

Luckily, there is an easy way to filter the real-time report values to focus on the exact ones you want (assuming you have named them in a way conducive to text filtering). This can be done by adding a text filter in the search box as shown here:

Summary

While I am not often a huge fan of “real-time” data, there may be some cases in which you want to see how different advertising units are performing quickly so you can make some adjustments to hit your conversion targets. This simple method allows you to easily see how campaign codes are being used in real-time. Lastly, if you use processing rules for your marketing channels, you can follow the same approach to see marketing channel usage in real-time as well.

In my last blog post, I showed an example of how you can create a segment in Adobe Analytics, push it to Adobe Target and then use Adobe Target to show personalized content on your website. It was a relatively basic example but showed how you could begin to leverage the power of the Adobe Experience Cloud audience sharing feature. In this post, I will build upon what was done in the last post and show some additional ways you can integrate Adobe Analytics and Adobe Target.

Sharing Converse Segment

In the last blog post, the scenario involved showing a cross-sell promo spot when visitors meet a specific segment criterion, which in that case was viewing two or more “Adam Greco” blog posts. We built a segment looking for those visitors and sent it to Adobe Target as a shared audience and then showed a cross-sell promo to the audience. But what if we wanted to show something different to the visitors that didn’t meet the targeting criteria? In that case, we could have default content or we could use a “converse” (opposite) segment to push something different to visitors who didn’t meet our segment criteria.

To illustrate this, let’s look at the segment we used to identify those who had viewed 2+ of my blog posts, but not viewed my services pages:

Now, if we want to show a different promotion to those who don’t meet this criterion, we can create a “converse” segment that is essentially the opposite of this segment as shown here:

To test that we have our segments setup correctly, we can build a table and make sure that the numbers look correct:

If you create your “converse” segments correctly, you should see the numbers in the right two columns add up to the first column, which they do in this case. Of course, you can create different segments and show different promos to each segment as needed, but in this simple example, I just want to show one promo to people who match the first segment shown above and another promo to those who don’t. Once both segments have been pushed to Adobe Target, the appropriate content can be pushed to the page using the “mbox” shown in my previous post.

In this case, I have decided to push a promo for my cool Adobe Analytics Expert Council (which you should probably apply for if you are reading this!). All those who aren’t targeted to learn about my consulting services will see this as the fallback option.

Track Promo Clicks and Impact

Another way to build upon this scenario is to track the use of internal promotions in Adobe Analytics. For example, when visitors click on one of the new promo spots being served by Adobe Target and shared audiences, you can set a click Success Event and also capture an internal tracking code in an eVar. The Success Event will tell you how many times visitors are engaging with the new targeted promo spots and the internal campaign eVar will tell you which ones were clicked and whether any other website conversion events took place after the internal promo was used.

Here is an example of an internal campaign clicks Success Event:

Here is an example of those internal campaign clicks broken down by internal campaign in the eVar report:

This report allows you to see which of these new promos is getting the most clicks (to see impressions and click-through rates of each promo is more involved and described here). It is relatively easy to see how often each promo leads to website Success Events since their values persist in the eVar. For example, in the screenshot shown above, when visitors click on the AAEC promo, I am setting a Success Event on the click, an internal campaign code in an eVar and if the visitors clicks the “Apply” button on the post, I am setting another Success Event. Therefore, I can view how many clicks the AAEC promo gets and how many AAEC Applications I get as a result:

In this example, we can see that the AAEC promo got twenty-five clicks and that four of them resulted in people beginning the application process (and there was one case of someone applying for the AAEC without using the promo). If I wanted to get more advanced, I could have multiple versions of the AAEC promo, use Adobe Target to randomly show each and use different internal campaign codes to see which version had the best conversion rate.

Summary

As you can see, the combination of Adobe Analytics shared audiences, Adobe Analytics and Adobe Target can be very powerful. There are countless ways to leverage the synergies between the products and these are only a few of Adobe’s suite of products! I recommend that you start experimenting with ways you can combine the Adobe products to improve your website/app conversion.

One of the advantages that Adobe Analytics offers over other digital analytics tools is that it is part of a suite of products. Analytics integrates with AEM, Adobe Target, and other Adobe Experience Cloud products. Adobe has been transitioning more and more of its features to the “core” level so users can share things between Adobe Experience Cloud products. One of the most interesting things that can be shared are audiences (segments). However, I have not seen as many of my customers take advantage of these types of integrations. So in this post, I am going to share a simple example of sharing audiences in the Adobe Experience Cloud using Adobe Analytics and Adobe Target that my partner Brian Hawkins and I created as an experiment. While the example we use is very simplistic, it does a good job of demonstrating how easy it is to share audiences/segments between the various Adobe products.

Scenario

Since our Analytics Demystified website doesn’t have much other than blog posts, the best scenario we could come up with was to promote our B2B services through internal promotions. The idea is to find website visitors who have viewed a bunch of our blog posts and see if we can get them to engage with our consulting services. In reality, that isn’t why we write blog posts and we don’t expect people to actually click on the promotion, but this is just a demo scenario. In this scenario, I will be the guinea pig for the integration and look for people who have viewed at least two of my blog posts but never viewed any of the website pages that explain my consulting services. Once I isolate these folks, I want to target them with a promo that advertises my services.

Adobe Analytics

To implement this, you need to start in Adobe Analytics and make sure you have data being collected that will help you isolate the appropriate website visitors. In this case, since I want to identify visitors who have viewed “Adam Greco” blog posts, I need to have a way to identify different blog posts (Blog Post Title) and the author of each blog post (Blog Post Author). I already have these setup as eVars in my implementation, so I am set there. Next, I need a way to identify each page separately, which I do by using the Page sProp.

With all of these elements in place, the next step is to build a segment in Adobe Analytics. The segment I want is one that includes visitors that have viewed “Adam Greco” author blog posts and viewed two or more different blog posts (this uses the new Distinct Count segmentation feature I blogged about last week). I also have an “exclude” portion of the segment to take out visitors who have viewed some pages that promote me and my services. Once I am happy with the segment, I can use the checkbox at the bottom of the segment to make it a shared Experience Cloud audience.

Adobe Target

Once the segment has been shared and propagates to the Experience Cloud (which can take a few hours), it is time to set up the promotional area on the website using Adobe Target. This is done by leveraging our “global mbox” and the URL of the pages where we wish to have the content displayed. We chose the right-rail of all blog pages:

Next, within Adobe Target, you can set up a test and target it to the audience (segment) that was created in Adobe Analytics (Called “Adam Greco Consideration, But No Intent”):

Next, you can set up a goal in Adobe Target to monitor the progress:

Once this test is live, Adobe Analytics will continuously update the segments as visitors traverse the site and Adobe Target will push the promotion as dictated by the segment. For example, if a user has not met the segment criteria (viewed less than two Adam blog posts or has viewed Adam services pages), they would see a normal blog post page like this:

But if the visitor matches the segment, they would be targeted with the right-rail promo as highlighted here:

We are also able to validate that we are in the test using this free Adobe Target Chrome Extension from MiaProva:

Summary

As mentioned above, this is just a silly example of how you can take advantage of Experience Cloud integrations. However, the concept here is the most important part. The better your Adobe Analytics implementation, the more opportunities you have to build cool segments that can be turned into audiences in other Experience Cloud products! I encourage you to look for situations in which you can leverage the synergistic effects offered by using multiple Adobe Experience Cloud products concurrently.

In last week’s Adobe Analytics release, a new feature was added within the segmentation area. This feature is called Distinct Count and allows you to build a segment based upon how many times an Adobe Analytics dimension value occurs. While the names are similar, this feature is very different from the Approximate Count Distinct function which allows you to add distinct counts to a Calculated Metric. In this post, I will describe the new Distinct Count segmentation feature and some ways that it can be used.

Segmenting on Counts – The Old Way

When doing analysis, there are often scenarios in which you want to build a segment of visitors or visits that have done X a certain number of times. For example, you may want to look at visitors who have viewed more than two products but never added anything to the shopping cart. Or you may want to identify visits in which visitors read more than three articles.

This has been somewhat possible in Adobe Analytics for some time, but building a segment to do this has always relied on using Metrics (Success Events). For example, if you want to build a segment to see how many visitors have viewed more than three blog posts, you might do this:

You could then use this segment as needed:

The key here is that you need to have a Success Event related to the thing that you want to count. This can be limiting because you might need to add extra Success Events to your implementation. But the larger issue with this approach is that a visitor can make it into the segment even if they viewed the same blog post three or more times because it is just a count of all blog post views. Therefore, the segment isn’t really telling you how many visitors viewed three or more distinct blog posts.

At this point, you might think, “well that is what I use the Approximate Count Distinct function for…” but, as I mentioned earlier, that function is only useful for creating Calculated Metrics. As shown below, using the Approximate Count Distinct function tells you how many unique blog posts titles were viewed each day or week and doesn’t help you answer the question at hand (how many visitors viewed three or more blog posts).

Segmenting on Counts – The New Way

So you want to accurately report on how many visitors viewed three or more different blog posts and have realized that segmenting on a metric (Success Event) isn’t super-accurate and that the Approximate Count Distinct function doesn’t help either! Lucky for you, Adobe has now released a new Distinct Count feature within the Segmentation area that allows you to build segments on counts of dimension (eVar/sProp) values. Before last week’s release, when you added a dimension to the segment canvas, you would only see the following operator options:

But now, Adobe has added the following Distinct Count operators that can be used with any dimension:

This means that you can now segment on counts of any eVar/sProp value. In this case, you want to identify visitors that have viewed three or more different blog post titles. This can be done with the following segment:

The Results

Once you have created your segment, you can add it to a freeform table to see how many unique visitors viewed three or more blog posts:

In this case, over the selected time period, there have been about 2,100 visitors that have viewed three or more blog posts on my site and I can see the totals by day or week as shown above.

As a side note, if you did try to answer the question of how many visitors viewed three or more blog posts using the old method of segmenting on the Success Event counts (Blog Post Views >=3), you would see the following results:

Here you can see that the number is 3,610 vs. the correct number of 2,092. The former is counting visitors who viewed more than three blog posts, but not necessarily three or more different blog posts. All of the visitors in the correct table would be included in the incorrect table, but the opposite wouldn’t be true.

Again, this functionality can be done with any dimension, so the possibilities are endless. Here are some potential use cases:

• View Visitors/Visits that viewed more than one product
• View Visitors/Visits that used more than three internal search terms
• Check potential fraud cases in which more than one login ID was used in a visit
• Identify customers who are having a bad experience by seeing who had multiple different error messages in a session
• Identify visitors who are coming from multiple marketing campaigns or campaign channels

To learn more about this new feature, check out Jen Lasser’s video release video.