Top Tips to Help You Excel with Adobe Analytics Reporting

If you are an analyst using Adobe Analytics, you’d be already familiar with the marketing analytics and reporting and segmentation tools that allow you to get a real-time understanding of your business. To help you make the most of these tools, this post will walk you through some of the common reporting and segmentation challenges along with easy, hands-on tips to resolve them.

Let’s get started.

Cardinality issue

One challenge that is commonly brought up by users is the Unique Exceeded issue where only the top 500,000 rows for a particular month are shown. This happens when cardinality for a specific dimension (e.g., Page URL) is very high and Analytics outputs a string called “Low Traffic,” as shown in the following screenshot. This means that any segments leveraging Page URL will not show accurate results, as only the top 500,000 values are shown in the UI (user interface).

Solution: There are two ways to tackle this issue:

Single Page App issue

There are use cases where organizations have had a Single Page App (SPA) built using AJAX where the UI experience changes but the page doesn’t refresh. These experiences often leverage callback functions, which developers can configure to fire off “artificial” page views, even if the page doesn’t reload.

Issue: In one of the organizations, they wanted to see how many users landed on the SPA experience when the “cmpid” URL query parameter was present. They populated an Analytics event tied to this query string but observed a very high number of instances exceeding the actual page views on this landing page. The issue was the Analytics URL (highlighted in red) did not get updated when, in fact, the SPA URL changed (highlighted in green). Given that the Analytics URL is used to evaluate if the query string is present, the instances of the event kept getting inflated even though “cmpid” was not present anymore.

**Solution: **Update the Analytics URL by overriding the s.pageURL (Analytics URL variable) with document.URL using JavaScript. This will allow you to specifically track events when “cmpid” is populated.

Visitor stitching segment

A very common use case for enterprises is to stitch visitors across mobile app and mobile web, where they want to attribute downstream events to visitors coming from a mobile app to a mobile web view. An example is a conversion funnel that is embedded in a native app where there is a mix of native app screens and web-specific HTML or AMP (accelerated mobile pages). The easy way out is to define a unique variable to differentiate between mobile app and mobile web and use that in a segment as shown in the following screenshot:

Sequential segmentation

Here’s an example of a recent customer use case that makes it easy to understand the concept.

Question: How many people stayed on the “about-us” page for at least two minutes and then clicked on the “visit-homepage” link?

Answer: The answer is a simple sequential segment as shown in the following screenshot:

To learn more about sequential segments, click here.

Exclude segments work well

Exclusion segments are often used to remove users tied to a specific dimension or event. These can also be used as an option to create “inverse” segments to test results. The following is a simple example of an exclude segment, used to exclude visits with time spent less than 15 seconds on a page:

Finally, a segmentation container primer

Lastly, there’s a simple yet confusing concept of segment container that often stumps analysts. Typically, it relates to the general difference between the various segment containers (namely, visits, visitors, and hits) and when to use these. The following screenshots show how each container affects the underlying data.

Hit container: This container, when applied, yields the fewest page views and instances as it confines the data to the actual hit level. The requirement for this container to work is for the variable to be set in the image request. It will show the lowest number of page views or instances.

Use cases: Apply this when you want to get the most accurate results for a specific dimension or event (e.g., you can use this container if you want to get actual page views or video views for a specific time frame or search term). You should also use hit level segments to create virtual report suites.

Visit container: This container shows data for a specific visit where something happens without a gap or timeout of 30 minutes. This will show page views or instances that are more than that of a “hit” container and less than that of a “visitor” container.

Use cases: If you’re looking to analyze user behavior happening within the same visit such as bounces, click on a call to action on the home page, landing page, and visits tied to a marketing campaign.

Visitor container: This container will show data (typically for two years) tied to a visitor cookie and all page views and instances for the lifetime of the visitor. This will show the most number of page views or instances as the scope of this is the biggest among the three containers.

Use cases: These are helpful if you’re looking to find out total revenue captured across all visitors or to see how many visitors traversed from a mobile app to a mobile web view.

I hope these tips help you better understand some of the scenarios that often require additional investigation and can lead to unforeseen delays.