eVars and props

In Adobe Analytics, props are traffic variables that describe a single hit, while eVars are conversion variables that persist across a visitor's activity and can receive credit for success events that happen later. The distinction - and its limits - shaped fifteen years of implementations, and disappears entirely in Customer Journey Analytics.

The practical difference

A prop answers "what happened on this hit": page name, section, internal search term as typed. An eVar answers "what deserves credit for what happened afterward": the campaign that brought the visit, the search term that preceded a purchase. eVars carry expiration (visit, hit, custom windows) and allocation (first, last, linear) settings; props carry none.

Limits

A standard Adobe Analytics report suite allows up to 75 props, 250 eVars, and 1,000 success events. The numbers sound generous until an enterprise implementation meets them - variable slots become contested real estate, and reusing a retired eVar without cleaning its history quietly corrupts trends.

What replaces them in CJA

Customer Journey Analytics has no props, no eVars, and no fixed limits. Any field in an XDM schema becomes a dimension or metric through a data view, and persistence/allocation are settings applied at analysis time - retroactively - rather than collection-time decisions locked into the data. Migrating from Adobe Analytics means mapping each meaningful prop and eVar to a schema field, which is a design exercise, not a rename.

Frequently asked questions

Should new implementations still use eVars and props?

Only if they target traditional Adobe Analytics. Implementations built on the AEP Web SDK and destined for Customer Journey Analytics should design XDM schema fields directly and treat eVar/prop mapping as a compatibility layer, not the foundation.