Showing posts with label web analytics reporting. Show all posts
Showing posts with label web analytics reporting. Show all posts

Sunday, September 30, 2018

Adobe Analytics Reporting Issues and Tips

It's been a while since I've been a full time analyst but I do get to dabble in data in my current role as Technical Consultant. This post covers some of the reporting/segmentation challenges I've faced with Adobe Analytics and some tricks I've learnt in my role. My primary purpose of writing this post is to share it with other technically focussed users and capture it for my own documentation. Let's get started!

  • Cardinality Issue: One issue that has caused me some strife is the Unique Exceeded issue where only the top 500,000 rows for a particular month are shown. This happens when cardinality for a particular dimension (E.g. Page URL) is very high and Analytics outputs a string called "Low Traffic" as shown below where it's the most popular data point. 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.
    • How to Address the issue: I can think of 2 solutions to tackle this issue:
      • Add Dimensions with Low Cardinality: In your implementation, define a unique page name or sub sections for a combination of URLs and capture query string in a separate variable to keep the URL clean. Basically, look at alternative dimensions that have a low cardinality.
      • Leverage DataWarehouse: DataWarehouse (shown below) allows you to export more than 500K rows so you can essentially, export as many rows and then filter the data offline.

  • Single Page App Issue: In a recent client scenario, we had a situation where they had a Single Page App (SPA) built using AJAX and the UI experience changed but the page didn't refresh. These experiences often times leverage callback functions which developers can configure so that we can fire off "artificial" page views even if the page doesn't reload. 
    • Issue: My client 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 saw a very high number of instances which exceeded the actual page views on this landing page. The issue was tied to the fact that the Analytics URL (highlighted in Red) did not get updated when in fact, the SPA URL changed (highlighted in Green) for additional steps in the flow. Given that the Analytics URL is used to evaluate if the query string is present, the instances of the event kept getting inflated despite the fact that "cmpid" was not present anymore.

    • Solution: The solution was to update the Analytics URL by overriding the s.pageURL (Analytics URL variable) with document.URL using JavaScript. This allowed us to ONLY track events when "cmpid" was populated.

  • Visitor Stitching Segment: A very common use case for enterprise clients 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 pages. It will make sense to define a unique variable to differentiate between mobile app and mobile web and use that in a segment as shown below.

  • Sequential Segmentation: Sequential segments are explained very well here and I highly recommend you read this but my example is much simpler and deals with a recent question I got from a client.
    • Question: How many people stayed on the "about-us" page for at least 2 minutes and then clicked on the "visit-homepage" link?
    • Answer: The answer is a simple sequential segment which did take me a few tries and it's shown below:

  • Exclude Segments Work Well: I've used exclusion segments quite extensively to remove users tied to a particular dimension or event. I've also used exclusion as an option to create "inverse" segments to test my results. Below is a simple example of an Exclude segment that worked really well for me recently where I had to exclude visits who spent less than 15 seconds on a page:

  • Finally, a Segmentation Container Primer: I'll wrap up by covering a simple yet confusing concept of segment container which has often stumped me. It's the general difference between the various segment containers (namely Visits, Visitors and Hit) and when to use these. In the following screenshots, we see 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 particular dimension or event. E.g. You can use this container if you want to get actual page views or video views for a particular 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 particular visit where something happened without a gap or timeout of 30 minutes. The 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 that can only happen within the same visit such as Bounces, Click on a Call to Action on the Homepage, Landing page Visits tied to a marketing campaign etc.          

    • Visitor Container: This container will show data tied to a Visitor cookie (typically 2 years) and will show 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: 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 will help you answer some simple, yet confusing concepts that often requires additional investigation and can lead to unforeseen delays. 

Tuesday, February 26, 2008

Page View Metric – Is it really dead?

I read an interesting post regarding the Page View KPI no longer being part of the Web Analytics metrics in the future as Nielsen/NetRatings have decided to scrap Page views from their rankings. The article alleges that the Page View metrics is incapable of telling us about the overall user experience as nowadays most websites make use of widgets, videos , flash, AJAX content etc and it is impossible to measure those attributes with the use of Page Views. The article mentions “If you have widgets, you don't really have page views. If you do videos, you don't have page views.”

Will Page Views suffer the same fate as the Hits metrics? In the nascent stage of Web Analytics, Hits used to be the key metrics tracked in place of Page Views but as the Web Analytics community became mature, the Hits metrics was found wanting. This is because Hits measured everything from loading of images, CSS to JavaScript which meant that Hits will count all the individual requests and report them seperately which in turn was termed as inaccurate. One of the reasons why Hits noticed a quick exit was due to the fact that it could only be tracked via Server Logs and with the advent of conventional Web Analytics tools, it was easier to find a replacement in the form of Page Views.

Are Page views dead? Personally I think it is too early to say that. I say this because around 90% of the companies today would be using Page Views in their day to day reporting/dashboards and also all the major Web Analytics tools report this as a prime metrics. Page Views have been widely accepted as an industry standard and it would be really difficult to replace it immediately as a suitable replacement would not be easy to find. Though we have noticed in the past that Visits and Unique Visitors have been considered a better metrics than Page Views but it doesn’t really mean that we can totally discount Page Views as they have their own value in Web Analytics.

What can be the possible replacements for Page Views? I don’t think the existing prime metrics like Visits, Visitors would replace it but I agree with what was written in the article about User Engagement. User Engagement according to me is the Visitor experience on a webpage ranging from clicks on specific links, interaction with the embedded applications like Videos, Widgets etc and most importantly Time Spent. Based on my experience, I’ve noticed that majority of the exits on a website happen within the first 15 seconds and it is crucial for us to decrease the exit rate for this time range. Ideally in case of eCommerce websites, a user session should range between 5-10 minutes as I think by this time the user is well adept with the website interface. He would then decide to perform the appropriate task like filling a form to buying something. Similarly the user engagement metrics would be different for a content, classifieds and News website. So the Time Spent metrics is in a way a subset of User Engagement.

All in all I think it is too early to totally discount Page Views from Web Analytics but sooner or later the industry will decide to replace it. But whenever that happens, I sincerely hope that Page Views would be given a graceful exit unlike it’s predecessor Hits.