Experts are supposed to know everything about a certain topic. And not only are they suppose to know things, they also are expected to behave in the best way possible. Their past decisions are the benchmark for how to assess future situations and judge what to do. But all experts have their little secrets, where they deviate from the gold standard and do something that is outdated, unpopular, or straight-out embarrassing.
This post is about one of the things that I still do today and only talk about seldom because it became unpopular a while ago. So here it is: I still use Props in all my Adobe Analytics implementations. But not only do I use them, I secretly love them! Both Adobe themselves and veterans like Jan “Props must die” Exner advise on not using them any more in the future. So this is my confession to the world and my pledge to Adobe to let them live. At the end of this post I included my wishlist on how I would like dimensions in Adobe Analytics to work in the future.
Reasons to love Evars
Let me start by pointing one thing out: Loving Props does not mean I don’t like Evars, quite the contrary. It’s just that I don’t prefer one over the other because they each provide a lot of value, both in their own way. But since Evars get a lot of attention already, I will just quickly list some of the reasons I also like them:
- Number of variables: While we only have 75 Props available, we get up to a whopping 250 Evars (depending on your contract)
- Variable length: Again, Props are at a disadvantage with 100 Bytes (100 characters) length compared to 255 Bytes with Evars. This point is especially important to me because I like to use classification rules
- Allocation and Expiration: Evars can be persisted beyond the Hit they were set on to map the user journey. Since the value can be added to the Visitor Profile this feature is even better to me than Attribution in Workspace (thinking about “Visitor First” setting)!
- Counter Evars: Evars can be configured to act as a counter that increments with the value set in the Evar. This makes it very easy to analyze things like “the third video watched for a user”
- Merchandising: If you are doing E-Commerce, you want to use Merchandise Evars. They allow to set certain Evars only for certain products in the product string, making the Product variable the most powerful variable in Analytics
- List Variables: The second most powerful variable type in my opinion. With List Vars, we can set an Evar to more than one value on the same hit. Hard to understand and implement correctly, but potentially very valuable. I will never understand why we only have three of those available
I think I covered about every advantage I can think of. Evars can provide a lot of value, just like Props. But now let’s get to the meat of this post. Here are the three reasons why I still love Props today!
Making little lists
As I said above, List Variables are the second most powerful type of variable, but we only have three of them. With Props on the other hand, we can have 75 little lists! All we have to do is enable List Support in the Admin Settings. Once we activate this feature and define a separator, we can send multiple values in the same hit, just like with List Variables:
With this setting enabled, we can send in values like
s.prop1 = "Value1;Value2;Value3";
and have them show up in Analytics as three different items like this:
That’s amazing! Whenever an item has multiple properties, I like to put them in a prop with List Support enabled to save on List Evars. This only works as long as there is a limited number of properties an item can have, otherwise we need to use the List Evars.
That is because there are some differences between List Props and List Evars. Since we are dealing with Props, we don’t have Allocation or Expiration settings like with Evars. That means we can’t persist values to later hits. Also, we still only have 100 Bytes to spent on the whole list, not 255 Bytes for every list item like with List Evars.
In Practice this could mean we might have to use classifications on List Props to “translate” abbreviated values to longer ones. For example, we could track a value like “fav;first” and upload a classification file to translate them to values like “Item is favorite” or “Item is first to be viewed”. You can read up on List Props here.
Clever Time Spent Calculation
From my experience this is a little known feature of props. When you set a prop with a Page Tracking call using s.t(), consecutive Like Tracking calls via s.tl() will count towards the time spent value on the Page Tracking call, even if the Prop has no value set on those following calls. So for the page dimension (which is a prop), all activity on a page that is measured via Link Tracking counts as Time Spent on Page for that page. That’s very convenient!
With an Evar this behavior would be much harder to achieve. We would either need a HIT level Evar and set it on both the Page and Link Tracking calls or use a VISIT level Evar and persist it beyond the Page Tracking call. So using an Evar for the same use case would mean more complexity in your implementation.
While I think this is a very convenient feature, it’s hard to explain in a short section of a post. There are some great examples on the Adobe Analytics documentation. Now to the main act.
Pathing > Attribution
I feel like writing this will get me on a naughty list at Adobe. But I can’t do anything about it: Pathing is just so much better than Attribution in Analytics. I hear you shouting: What could be better than Attribution? Please, let me explain…
Before we start, what exactly is Pathing for Props? In the Admin Section of Analytics, we can enable Path Reports for any Prop:
Once we do this, we see that every enabled Prop shows up three times in our components list:
Now we not only have our Page dimension but also the “Entry” and “Exit” dimension for that Prop. In those dimensions, Analytics remembers the first and last value for that Prop of a Visit for us and makes it available for usage with any other dimension for the whole Visit. That way we can analyze User behavior in relation to the first and/or last thing a user did across the session. Let me give you some applications.
First I want to show you a use case I really love personally. My marketing folks love approaching me with questions like “We’ve built this landing page. What do users do after they landed there?”, which is a highly relevant question to them. With a Pathing enabled prop, this is trivial to analyze:
All we have to do with a Pathing enabled Prop is break down Entry Page by Page. In the screenshot above, we can see that users who landed on the homepage went to the second breakdown page in 32% of cases in the same session. And even if we wanted to see the last Page for that Visit, we would only have to break down Entry Page by Exit Page. That’s so easy! With Evars we would need a second variable with a Visit/First setting and couldn’t even do the Exit dimension at all! And since Pathing also works for classifications we can have some really creative use cases. And I even have another real example for you.
I currently work for a Media & Entertainment company. Since we have a lot of different assets and series, we need to know what role those play along the user journey. So tables like this are very important for us:
This gives us a clear picture on how different series bring back users along their individual journey. But what if we want to track users who initially came because of one specific series? All we need is a Segment like this:
Look at how elegant this is! All we need is a Visitor Segment with a Visit Container to segment the first Visit and the Entry series for that Visit. Now we apply this to our table and can clearly see how users who started with this specific series move over to other series over time:
I can’t overstate how important something like this is to my business. Just being able to apply the Entry dimension to any table is so super valuable and saves so much headache when building segments. If you want to torture yourself, try rebuilding that segment with a HIT level Evar. Don’t say I didn’t warn you!
Accepting the future
I hope I made it clear how Props still provide a lot of value to me even today (and I didn’t even cover Real Time Reporting, which is quite important to us as well.) But let’s be realistic: Having Props and Evars doesn’t really seem necessary. Instead, I tried to come up with a list of feature proposals for the future of Analytics dimensions. Here it is, with no specific order to the items:
- Only one type of dimension with all the features of Props and Evars combined. I want Expiration, Allocation, and Pathing as a feature on all dimensions!
- More dimensions, like 500 or 1000. Just because, duh.
- Longer dimensions, like 1kB (1024 characters), for the same reason.
- Selectable data types, like String, Number (like the builtin Visit Number), Date, or Counter, so we can use them in Date Ranges, Segment on numerical values (greater than or less than comparison), sort a table, or have a good old Counter dimension.
- List support available on all dimensions, but like List Evars, with unlimited items!
- For every dimension or list, being able to assign an Event value to only a certain dimension, like “dim1=’some string|event1=10′” or event “dim2=’some string|event1=10;another string|event2=9′”, just like with the product variable.
- Pathing IQ! Or some other form of Pathing reports (or even Full Path) in Analysis Workspace.
I know this is a big wishlist, but it is what I would need to be able to say goodbye to Props and Evars as they are today. Since a lot of those features are already available in some form today I’m cautiously optimistic that this is at least not entirely impossible.
What are your thoughts on this? Did I forget anything? In any case, let me know!
Props (also called Traffic Variables) are a type of dimension next to Evars (also know as Conversion Variables). It can capture text values of up to 100 characters and supports lists with a custom separator. There are 75 Props available for use, not counting Entry- and Exit dimensions and classifications.
While both hold text values and support classifications, Props can not persist for more than one Hit as Evars can. Instead, they support list values and pathing, so they can be super useful.
It depends. Many people say Evars are the universal answer to every question, but I like to object. Pathing and list support are a good example for why you might want to use a Prop instead of an Evar. But as soon as you need to remember (persist) a value you need to use an Evar.