Custom Conversion Variables (eVars) in Adobe Analytics

If props are the page-level descriptors of Adobe Analytics, eVars are its attribution engine. The crucial difference is persistence. A prop fires once and is forgotten, but an eVar sticks to a visitor for a configurable period and collects the credit for any conversion that happens while it is active. That single property, persistence with attribution, is what makes eVars the tool for answering “what actually drove this conversion?” This article covers how eVars work, the ways to set them for internal campaign tracking, the list-variable extension for multiple simultaneous values, and the merchandising eVars that solve the hardest attribution problem of all, crediting the right section when a product was found in one place and bought after browsing several others.

How an eVar works

When a visitor encounters a value you care about, a search term, a campaign, a site section, you capture it in an eVar, and that value then persists on the visitor’s profile until it expires. Every time a success event fires within that window, the credit flows back to the eVar value still attached to the visitor. The value does not need to be present on the conversion page at all. As long as it has not expired, it still receives attribution.

Page 1 — s.eVar10 = "[search term]"   // value set, begins persisting
Page 2 — browsing
Page 3 — browsing
Page 4 — s.events = "purchase"        // credit flows back to the search term

The single most important configuration decision is expiration, which should match the natural conversion cycle. A search term typically expires at the end of the visit, while a campaign might persist for thirty days. Get that window wrong and you either lose attribution or assign it for too long.

The use cases follow directly from persistence and attribution. Internal search terms, so you can see which search drove a purchase. A/B test assignments, so a visitor stays in their variant for the whole visit. Campaigns and promotions, attributed across days. Merchandising categories, bound to a product at the moment it was found. And user types, segmenting registered against guest visitors across visits. Each of these needs an eVar specifically because a prop would forget the value before the conversion arrived.

A/B testing with eVars

eVars suit A/B testing well because they hold the variant assignment for the duration of the visit, so every later action is attributed to the correct variant. You choose an eVar to store the identifier, code it into each variant page, randomise traffic to the versions, and let Analytics hold the value and report conversion by variant.

// Variant A
s.eVar30 = "Home page A";
// Variant B
s.eVar30 = "Home page B";

The resulting report breaks orders, page views, and product views down by the two variants, giving you a direct conversion comparison without any external testing tool.

Tracking internal campaigns three ways

Internal campaigns are the calls to action on your own site, banners, buttons, promotional links, pop-ups, and you want to know which internal creative drove conversions. The golden rule is to use a separate eVar from the external s.campaignvariable, so internal promotions never overwrite the external campaign that brought the visitor in. There are three ways to set the value.

The recommended method is a query string parameter on the destination URL of each creative, read with getQueryParam in doPlugins.

s.usePlugins = true;
s.doPlugins = function(s) {
    s.eVar1 = s.Util.getQueryParam('intcmp');
};

A URL like summitoutdoors.com/chargecardapp?intcmp=hp-cc-ad carries the code, and the plug-in reads it on arrival. The detail that matters is using a different parameter name for internal campaigns than for external ones, intcmp for internal and srcfor external, so the two never conflict.

The second method hard-codes the value directly on the landing page, which you use only when query strings are not acceptable, such as for offline creatives that need a clean URL.

s.eVar1 = "hp-cc-ad";

Its limitation is obvious: if several creatives point to the same landing page, this method cannot tell them apart.

The third method fires the tracking at the moment of the click, before the visitor navigates away, sending the eVar and event in the same image request as the click rather than waiting for the next page. Launch handles this through its interface, but in custom code you must declare linkTrackVars and linkTrackEvents explicitly.

<a href="https://www.summitoutdoors.com/chargecardapp/"
   onClick="
   var s=s_gi('summitprod');
   s.linkTrackVars='eVar1,events';
   s.linkTrackEvents='event3';
   s.events='event3';
   s.eVar1='hp-cc-ad';
   s.tl(this,'o','Home Page CC Ad');
   "><img src='../images/charge_card_ad.jpg'/></a>

Here s.tl fires a custom link request of the “other” type, carrying just the variables and events you whitelisted. Whichever method sets the eVar, remember that persistence is governed by the expiration setting in Admin, not by how the value was set.

List variables for multiple values at once

List variables are the eVar equivalent of list props. They take several pipe-delimited values in a single hit, split each into its own report line item, and, unlike list props, can receive attribution from conversion events. The catch is scarcity: there are only three of them, against seventy-five list props.

s.list1 = "Outdoor Living|Travel Gear|Special Offers|Newsletter";
s.events = "event13";

Each value becomes its own row with occurrences and conversion metrics, exactly like a list prop but with event attribution attached. The constraints are worth knowing: three variables only, each delimited value capped at 255 bytes, and the whole image request bounded by the roughly 2,083-character URL limit that older browsers impose, beyond which values can be silently truncated.

The hardest problem: cross-category attribution

Standard eVars hold one value at a time, and that creates a real attribution failure on multi-section visits. Picture a visitor who enters Electronics and sets the section eVar, adds a stereo to the cart, then wanders into Jewellery, which overwrites the eVar with “Jewellery”, and finally checks out buying only the stereo. The credit for the stereo sale goes to Jewellery, where nothing was bought, while Electronics, where the stereo was actually found, gets nothing. With a standard eVar the last value always wins, so the most recent section sweeps up all the revenue regardless of where the product came from.

A merchandising eVar fixes this by binding a value to a specific product at the moment a binding event occurs, so the value travels with that product through the cart and the purchase no matter what the visitor does next. The mental model is a label on a roll of tape: a cashier cannot know which aisle you found the tape in, so you stick a “where I got it” label on it as you pick it up, and that label stays put wherever you go. Merchandising is that label.

There are two ways to write it. The product syntax sets the value directly in the products string at the moment a product-level event fires, which is best when different products in the same hit need different values.

// On the product detail page, binding happens here
s.events   = "prodView";
s.products = ";Sport Jacket;;;;eVar6=New Gifts";

The sixth field of the products string binds “New Gifts” to the Sport Jacket specifically. The conversion-variable syntax instead sets the value in the eVar itself and relies on a binding event configured in Admin, so the value sticks to whatever product fires that event while the eVar is active.

// Earlier, when the visitor enters the section
s.eVar6 = "New Gifts";
// On the product page, the binding event fires
s.events   = "prodView";
s.products = ";Sport Jacket";

The binding event is configured per eVar in Admin, with options like purchase, product view, cart open, or cart checkout. Setting merchandising up is a three-step job: enable merchandising on the eVar, choose product or conversion syntax and the binding event, then implement the matching JavaScript. Because a merchandising bug produces permanently wrong attribution that cannot be corrected after collection, always test it in a development report suite before going live.

Two more eVar configurations

Two settings change what an eVar does. You can store your own visitor identifier in an eVar and designate it the Unique Visitor Variable in Admin, which lets Analytics identify visitors by your internal ID rather than relying solely on Adobe’s cookie-based one. And you can set an eVar’s type to Counter, which changes it from storing text to incrementing a number, so you can count how many times an action happened before a conversion.

s.eVar1 = "sensible shoes";   // text eVar, records the search term
s.eVar9 = "+1";               // counter eVar, adds one to the running total

The counter report then shows, for each conversion, how many searches preceded it, enabling analysis like whether visitors who searched three or more times before buying converted at a higher rate. The detail to get right is the plus sign: "+1" increments the existing value, whereas "1" resets it to one on every hit.

Choosing the right feature

The decision flows from what you are tracking. If a visitor can have multiple values at once, use a list variable. If the same product sells across several sections and you need section-level attribution, use a merchandising eVar, choosing the product syntax when different products in one hit need different values and the conversion-variable syntax otherwise. If you need to count actions before a conversion rather than capture text, use a counter eVar. Otherwise a standard text eVar is the right tool. It also helps to keep the three variable types straight: a prop persists only for the page and carries no attribution, an eVar persists for a configurable window and carries attribution, and a list variable does the same as an eVar but holds many pipe-delimited values, with only three available against a hundred eVars and seventy-five props.

Things that can happen

A few mistakes recur. Sharing one query parameter between internal and external campaigns lets them overwrite each other, so internal campaigns need their own parameter like intcmp. Forgetting linkTrackVars and linkTrackEvents on a custom link call sends the wrong set of variables, so always whitelist what you need. Setting a counter eVar to "1" instead of "+1"resets the count on every hit rather than incrementing it. Relying on a standard eVar for cross-category attribution lets the last section overwrite the one where the product was found, which is exactly what merchandising eVars exist to prevent. Skipping the binding-event configuration for the conversion-variable syntax means the value is set but never binds to a product, so no merchandising attribution appears. Assuming list variables are unlimited risks silent truncation past 255 bytes per value or the URL cap. And deploying merchandising without testing in a development suite risks permanently wrong attribution that cannot be fixed after the fact. Respect those, document each eVar’s expiration, allocation, and binding settings in the SDR, and eVars become the dependable attribution backbone of your Adobe Analytics implementation.

See you soon.