Introduction

Users of Adobe Analytics need to understand the difference between Props and Evars (and how they relate to Success Events); these are fundamental concepts and need to be fully grasped if Analytics reports are to be interpreted correctly. These items serve different use cases. This post will explain their purposes, differences, and relationships. We’ll also touch on some sample usage scenarios.


Props

The What:
Props are referred to interchangeably as ‘props’, ‘sprops’, ‘s.props’ or ‘traffic variables’ (we’ll refer to them as ‘Props’ throughout the rest of this article). Props are tools for counting and segmenting topline information about our user traffic. There are numerous such ‘traffic’ metrics in Adobe (e.g. Pageviews, Unique Visitors and Visits) that are frequently broken down and analysed using props. Adobe Analytics traditionally provides 75 slots for us to define our own props, so you can get pretty flexible!

The Why:
Say we want to measure the number of Unique Visitors, and how they interact with our site based on Site Section. We could reserve a prop – call it ‘Prop1: Site Section’ – storing within it the name of the section a given page belongs to. Therefore, ‘Prop1: Site Section’ will need to be set on all pages (as every page belongs to a section). Examples of Site Sections might be ‘Home’, ‘Menswear’, ‘Formalwear’ for a clothing retailer. When a user navigates through this sample site, each time they invoke a pageview with ‘Prop1: Site Section’, Adobe will count the number of different values a user has ‘seen’ for this prop during their tenure.
While the above example is more about segmenting traffic in general, we can also use props to ‘count’ more unique situations. For instance, if a business wishes to count the number of times a user saw a particular internal promo ad on their page they could utilise a prop. This prop – call it ‘Prop2: Internal Promo Instance’ – would only be set on pages with an internal promotion, and would be set to the name of the promo shown to the user. In this way, we can count the number of times each of our promos were seen by Visit, Unique Visitor, and so on.

Important to Note:

  • Props are not persistent, they only have meaning within the context of the tracking call in which they appear
  • We can define up to 75 custom props
  • Only certain metrics can be crossed with props in Analytics reports
  • Props tend to be processed pretty quickly by the Adobe Data Collection Servers

Evars

The What:
While props provide useful insight into general traffic characteristics, they don’t reveal much about what actually drives specific desirable outcomes (or what decreases the likelihood of undesirable outcomes). This is where Evars come into play. Props let us analyse traffic, but Evars let us analyse the granular success events pertinent to our specific business requirements. Evars are frequently interchangeably referred to as ‘conversion variables’, ‘eCommerce Variables’, ‘dimensions’, and sometimes just ‘variables’.
Evars are inextricably linked to ‘Success Events’ in Adobe. Success Events count granular positive occurrences on our sites and apps. We have available numerous builtin events, and we can also define our own (up to 1000). Likewise, we can define up to 250 (depending on contract) custom Evars if the builtin Evar set isn’t enough to meet our needs.
Success Events are often referred to as ‘events’, ‘metrics’, ‘successes’, and ‘counters’. Examples of events might be ‘Article Downloads’, ‘Stream Starts’, ‘Game Plays’, ‘Gametime spent’. Examples of Evars might be ‘hashed user ID’, ‘page type’, or ‘app name’.

The Why:
While Events count ‘interesting things’, we use Evars to ascribe facts about what we’re counting. We set data-descriptive values in Evars, and these values persist beyond the tracking call in which they are set. When a given success event takes place subsequently during app/site usage Adobe assigns credit to each value in all currently set Evars. In other words, we can measure how certain usage ‘states’ drive success; i.e., the set of Evar values that are most effectively contributing to our successes. We can then (for instance) focus on investing in favourable ‘states’ and ‘repairing’ underperforming ones.
As a concrete example, assume we are a publishing company and we want to count the number of times an article is downloaded. As a business, we want to know which entry page types are driving the most downloads. With this information we could optimise our operations (e.g. perhaps place links for other articles on high performing entry page types, or work to surface underperforming page types higher in search result listings). In this scenario, we’d use a Success Event to count article downloads, and an Evar to capture and persist the type of entry pages. This Evar would be set to the page name of a user’s landing page in their initial pageview. A user would then browse about the site, firing subsequent pageviews (note these would not set the Evar – there is no need because the value we previously set will be persisting across the visit). Finally, the user downloads our article, Adobe increments the associated Success Event, and assigns 1 ‘unit’ of credit to the page name first captured when the user began their visit.
In general when a report is run using Evars in Analytics, this is literally what Adobe returns: how credit has been assigned across the listed Evars for each listed Success Event in the report.
Note that we could not use a prop for the above example, because any prop value we set would not persist beyond the user’s initial pageview. It would therefore be impossible to assign credit for the Success Event that takes place in the future.

Important to Note:

  • Adobe have blurred the lines between props and Evars in recent releases of Analytics
    • For instance, previously we could only run pathing reports on props. We can now pull such reports using Evars
  • Common Evar lifetimes include
    • Visit – value lives for the duration of a user’s visit
    • Hit – value expires on hit and only has meaning within the context of the tracking call in which it is set. In a sense, this expiry setting ‘downgrades’ an Evar to behave more like a prop
    • Visitor – value is tied to the lifetime of an individual visitor
    • Never – value never expires
  • Regardless of an Evar’s expiry setting, if the implementation subsequently sets a new value, this value overwrites what was set previously (with some exceptions)
  • At the report level, Adobe provides functionality for changing the internal attribution mechanism used (default is last touch, but we can set to first touch, J-shaped, inverse-J, custom model, etc.)
  • Evars tend to have a longer processing latency

Summary

  • Props are for traffic reporting
  • Evars are for success event reporting
  • Recent Analytics releases blur the difference between these items
  • Prop values do not persist beyond the tracking call in which they are set
  • Evar values persist for some configurable period of time
  • In a report Evar values receive credit (per a chosen attribution scheme) for the occurrence of Success Events
  • Some prop/metric/event combinations are not valid; Adobe will either complain explicitly in the interface, or you’ll get back strange data (e.g. all report line items zeroed)
  • Out-the-box, Analytics provides various builtin Evars, Props, and Events
  • We can also define our own Evars/Props/Events
  • Props tend to take less time for Adobe to process, Evars tend to take longer