Introduction to traffic variables (Props)

Transcript

In this video, I’ll review traffic variables in Adobe Analytics. These are the topics I’ll cover. I’ll start with an overview, discuss characteristics, the different types, how long they persist, the metrics that can be associated with them, and common use cases. To get started, let’s look at a multi-day weather forecast. The left column contains the days, and to the right, several of the columns contain numbers associated with each day, like the high and low temperature, the chance of precipitation as a percentage, and the strength of the wind in miles per hour. These columns are referred to as metrics. They measure the different weather-related characteristics for each day in the forecast. In other words, metrics are numbers. The metrics apply to dimensions. In this case, the days in the forecast are the dimensions. There are two types of dimensions in Analytics. This video covers traffic variables, which is one type. The other type is conversion variables. Those are covered in a different video, though. As I review the characteristics of traffic variables, keep in mind that some of the details relate to implementation, while others relate to reporting. First, traffic variables can store up to 100 bytes. This isn’t necessarily characters, as some languages use multi-byte encoding. Anything passed into Analytics over 100 bytes does get truncated. Only alphanumeric strings can be set to a traffic variable. They don’t support integers or other data types. You can apply metadata to base values passed into traffic variables. This metadata is referred to as classification in Analytics. We’ll see an example of this further along. Traffic variables are non-persistent. This means the value doesn’t persist beyond the hit it’s passed in with. I’ll cover persistence in more depth coming up as well. Now, a hit is a set of data sent into Analytics with an interaction on your digital web property. If multiple traffic variables are sent in in a hit, you can run correlation reports between them. This means you can break down one traffic property by another in reporting. Values passed into traffic variables are case sensitive. So, if you send in the same value to the same traffic property, say one with title case and one with lower case, two distinct values appear in the reporting for each case variation. On the implementation side, traffic variables are referred to as props or s-props. Traffic variables come in three flavors. First, there are a set of reserved or predefined variables. They’re used for site content and error pages like 404 pages not found or other types of server errors. To the right, you’ll see a snippet of a page report. Second, there are configurable custom traffic properties you can use according to your business requirements. These are labeled and configured in the admin console. So, this is done by somebody with admin privileges. You can see in the image below that Prop 1 is used for capturing page title and Prop 2 for internal search terms. Third, list props accept multiple delimited values in the same hit. Any of the custom traffic variables can be configured for list support. I’ll cover this in more depth coming up. Now, let’s look at persistence a bit closer. I mentioned earlier that traffic variables are non-persistent, meaning the value doesn’t persist beyond the hit it was passed in with. In this visual, a visitor comes to a website and views page A, then page B, then page A again, and last page C before exiting the site. Each page represents a distinct hit and a unique page name value is passed in each time, except in the case where page A was seen twice. But this represents two distinct hits. The reporting below reflects this user behavior. Traffic variables are associated with a limited set of visit and traffic related metrics, as well as participation metrics, the latter of which is covered in a different video. Metrics like orders, revenue, lead form submissions, and other key downstream event metrics don’t apply to custom traffic variables. They’d apply to conversion variables, and that topic is covered in a different video. For this reason, you’ll want to consider the limited set of metrics available to traffic properties when using them for business requirements. Next, we’ll look at some use cases for traffic properties. First, they’re suitable and highly recommended to use for traffic reports, like the one shown here. This is a summary report for the homepage. The page variable is one of the predefined traffic variables I reviewed with you earlier. This allows you to generate reports that show you trending on page views, as well as comparing this metric across other periods of time in the past. Pathing and flow reports are quite useful in analytics. Understanding which pages someone saw before and after a specific page helps analysts understand popular journeys or obstacles with site design or usability. The list prop configuration for traffic variables is useful for analyzing things like which choices or options are selected most frequently. They are appropriate to use if you don’t need to understand how these values relate to downstream events. In my example, Prop 1 is set with the pipe delimited set of values in a single string. If I fail to configure Prop 1 for list support, the report would look like the one on the left. That wouldn’t be very useful. With list support, the report would look like the one on the right. Each of the values appear in their own row and the page view metric is calculated properly. There are two other key considerations. List props are constrained to the 100 byte limit I mentioned earlier. This means you’d need a succinct taxonomy for possible values passed in, as well as a reasonable limit for the maximum number of values. Moreover, only the page views metric is supported for traffic variables configured with list support. Getting back to the readability of list props, they do support classifications. This means you can upload a file with metadata related to the base values and each column associated with them can be run as reports and analytics. At the right you see the same report we reviewed in the previous slide, but with the full product names listed. These were uploaded as a classification file. There is also another video dedicated to reviewing classifications. Alright, on to the final use case. Traffic variables are also appropriate to use for capturing values that will help you diagnose the state of your analytics implementation. For example, you can capture the version of the analytics measurement library used on your site pages. This is useful for organizations that have many websites and development teams to ensure that everything is kept current across the board. In the example on this slide, the page URL is set in Prop 4 and the version of the analytics measurement library is set in Prop 3. Because they’re captured in the same hit, you can correlate or break down the page URL value by app measurement library or vice versa. This wraps up the introduction to traffic variables. Hopefully you have a good foundational understanding of traffic variables and how to use them. Good luck!