eVar
This help page describes how eVars work as a dimension. For information on how to implement eVars, see eVars in the Implement user guide.
eVars are custom variables that you can use however you like. If you have a solution design document, most dimensions specific to your organization end up as eVars, additional to the default dimension available with Adobe Analytics, like ‘Page Name’, ‘Referring Domain’, ‘Channel’. See Dimension Overview for more information.
By default, eVars persist beyond the hit they are set on. You can customize their expiration and allocation under Conversion variables in Report suite settings. See below for an example of eVar definitions in the Conversion variables UI.
The number of available eVars depends on your contract with Adobe. Up to 250 eVars are available if your contract with Adobe supports it.
The (upper or lower) case used in reporting is based on the first value the backend system registers. This value could either be the first instance ever seen or vary by some time period (e.g., monthly), depending on the variety and quantity of data associated with the report suite.
Populate eVars with data
Each eVar collects data from the v1 - v250 query string in image requests. For example, the v1 query string parameter collects data for eVar1, while the v222 query string parameter collects data for eVar222.
AppMeasurement, which compiles JavaScript variables into an image request for data collection, uses the variables eVar1 - eVar250. See eVar in the Implement user guide for implementation guidelines.
Dimension items
Since eVars contain custom strings in your implementation, your organization determines what the dimension items are for each eVar. Make sure that you record the purpose of each eVar and typical dimension items in a solution design document.
How eVars work
When you send data to Adobe Analytics, data collection servers translate the hit into a single row of data with hundreds of columns. Two columns are dedicated to each eVar; one for direct data collection, and the other for persisting values.
- A standard column contains data sent to Adobe from the image request.
- A “post” column contains persistent data, which depends on the eVar’s expiration and allocation.
Under almost all circumstances, the post_evar column is used in reports.
How eVars tie to metrics
Success events and eVars are frequently defined in different image requests. The post_evar column allows eVar values to tie themselves to events, showing data in reporting. Take the following visit for example:
- A visitor arrives to your site on your home page.
- They search for “cats” using your site’s internal search. Your implementation uses eVar1 for internal search.
- They view a product, and proceed through the checkout process.
A simplified version of the raw data would look similar to the following:
visitor_idpagenameevar1post_evar1event_listexamplevisitor_987Home pageexamplevisitor_987Search resultscatscatsevent1examplevisitor_987Product pagecatsprodViewexamplevisitor_987CartcatsscAddexamplevisitor_987CheckoutcatsscCheckoutexamplevisitor_987Purchase confirmationcatspurchase- The
visitor_idcolumn ties hits to the same visitor. In actual raw data, the concatenated values ofvisid_highandvisid_lowdetermine visitor ID. - The
pagenamecolumn populates the Pages dimension. - The
evarcolumn determines the hits when eVar1 was explicitly set. - The
post_evar1carries the previous value, dependent on the variable’s allocation and expiration set under report suite settings. - The
event_listcolumn contains all metric data. For this example,event1is ‘Searches’, and the other events are standard shopping cart metrics. In actual raw data,event_listcontains a comma-delimited set of numbers with a lookup table tying those numbers to a metric.
Translating data collection to reporting
Tools in Adobe Analytics, such as Analysis Workspace, work off of this collected data. For example, if you pulled a report using eVar1 as the dimension and Orders as the metric, you would see a report similar to the following:
Internal search term (eVar1)Orderscats1Analysis Workspace pulls this report using the following logic:
- Look through all
event_listvalues, and pick out all the hits withpurchasein them. - Out of those hits, display the
post_evar1value.
The importance of allocation and expiration
Since allocation and expiration determine what values persist, they are vital in getting the most value out of an analytics implementation. Adobe highly recommends that you discuss within your organization how multiple values for each eVar are handled (allocation) and when eVars stop persisting data (expiration).
- By default, an eVar uses last allocation. New values overwrite persisted values.
- By default, an eVar uses an expiration of visit. Once a visit ends, values stop copying over from row to row in the
post_evarcolumn.
You can change eVar allocation and expiration under Conversion variables in Report suite settings.
Value of eVars over props
Adobe recommends using eVars in most cases, supported through the following:
- eVars have a 255-byte limit in reports. Props have a 100-byte limit.
- Props by default do not persist beyond the hit they are set. eVars have custom expiration, allowing you to determine when an eVar no longer gets credit for a subsequent event. However, if you use report time processing, both props and eVars can use a custom attribution model.
- Adobe supports up to 250 eVars, and only 75 props.
See prop for more comparisons between props and eVars.