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. 

Saturday, September 15, 2018

Adobe Audience Manager Billing Overview

Every paid digital analytics tool and platform in the market has a structured revenue model and Adobe Audience Manager is no different. Audience Manager's revenue model is essentially based on the number of records ingested and the cost clients pay is tied to usage. Similar to AAM, Adobe Analytics is another platform whose revenue model is based on usage. Here's a link to some documentation that shows how Adobe Analytics reports its server calls which has now been updated to a visual format embedded within in the Analytics UI. 

Audience Manager now displays client server call data in the AAM UI and this post will cover what each of the types of AAM server calls mean. Let's dive into the details!

Types of AAM Server Calls

AAM server calls are divided into four types of activities as outlined below:
  • Onsite Server Calls: As the name suggests, these are Audience manager server calls captured either on mobile apps and websites. Essentially all page views and clicks are captured as server calls so any hit that's considered a server call by Analytics is considered an AAM server call if data is forwarded is enabled. These server calls are captured whether a site/app has a client side Data Integration Library (DIL) or Server Side Forwarding (SSF) AAM implementation.
    The other category of onsite server calls are also captured via Adobe Target calls to AAM to get segment information about users to personalize the experience. Customers are billed when Target makes a call to AAM to retrieve AAM segments.
  • Pixel Calls: This is data collected from ad or email impression/click calls made to Audience Manager. An example of how this is captured is outlined here.
  • Ingested Log File Records: This type of server call is incurred when you ingest ad server log files in AAM that populate the Audience Optimization Reports (AOR). The way clients typically get these enabled is by leveraging Actionable Log Files (ALF).
  • On-boarded Records: These server calls are incurred based on records ingested from CRM or an offline data file (e.g. call center, customer demographic data etc).

How to Avoid Extra AAM Server Calls

Recently, I came across a scenario where my client burnt through ~75% of their AAM server calls allocated for a year in the first 5 months. One of the reasons for that was the lack of understanding and visibility of what their server call usage was by activity. Given that majority of their server calls were exhausted early, they had to turn off data collection in the DMP for some time. Below are some easy steps to avoid exhausting server calls earlier than anticipated:

  • Monitor Server Calls Regularly: "Prevention is better than cure" is one quote that comes to my mind to explain this point. I cannot stress how important it is to proactively monitor your server call usage to avoid a scenario similar to what our client faced. Your AAM consultant should be able to pull server call data for you so it might make sense to ask your consultant to schedule a monthly pull of your server calls to avoid any surprises.
  • Collect Onsite Server Calls Only Via One Method: There are two main methods of AAM onsite data collection which are client side DIL and Server Side Forwarding. It's recommended to forward Analytics data to AAM using either client side DIL OR SSF to avoid being charged twice for onsite activities. My preference is the SSF method as it forwards Analytics data to AAM using one call and can be selectively turned on per report suite.
    Last year, a change was added to SSF Adobe Analytics data to AAM using Analytics report suites. This method allows clients to selectively forward data ONLY to those report suites whose data you want to forward to AAM. Previously, data for all report suites used to be forwarded over to AAM. Below are screenshots of how Analytics data is forwarded now and how it used to be forwarded before. 
Latest method of selectively forwarding Analytics data to AAM.

This method used to forward data for all report suites to AAM. It's recommended to turn it off which can only be done by your AAM or AA consultant.

  • Collect Media Data Either Via Pixels or Logs: Campaign media data collection is another area which can contribute to server call inflation if not done correctly. Last year, the AAM product team introduced Actionable log files (link above) which is a programmatic way to ingest DCM logs and create audience traits without deploying pixels. This method is widely used across AAM to ingest DCM log data for Non-EU markets. The other method is to manually deploy media pixels to capture impression or click level data.
    It's highly advisable to capture media data using ONLY one of these methods to avoid being charged twice.

Finally, What Do I Want to See Added?

Given that one of my client has called AAM billing a black box, I'd like to see the following items added to the AAM UI and billing reports:

  • Display Server Calls in the AAM UI: Like Adobe Analytics, I'd like to see Audience Manager server calls being displayed in the AAM UI so that clients can regularly monitor AAM server calls themselves and make necessary adjustments. UPDATE: As of 2/5/2020, this feature was added to the AAM UI! Here's a link.
  • Add Report Suite Breakdown in AAM Billing: I don't believe there's a way to see a drill down by report suite ID so I'd like to see that level of granularity added to AAM onsite server calls even though clients now have the ability to control that.

Hopefully this post provides you a general understanding of how AAM server calls are categorized and how to be better prepared moving forward.