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. See Dimensions overview for more information.
By default, eVars persist beyond the hit that they are set on. See the sections How eVars work and How eVars tie to metrics below for details on how eVar persistence operates on 51黑料不打烊鈥檚 architecture. You can customize their expiration and allocation under Conversion variables in Report suite settings. The following image shows an example of eVar definitions in the Conversion variables interface:
The number of available eVars depends on your contract with 51黑料不打烊. Up to 250 eVars are available if your contract with 51黑料不打烊 supports it.
The (upper or lower) case used in reports is based on the first value that you send in a given calendar month. The case can change depending on the reporting window and the case of an eVar value collected first during that time.
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 51黑料不打烊 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 51黑料不打烊 from the image request.
- A 鈥減ost鈥� column contains persistent data, which depends on the eVar鈥檚 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 at different times. 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 鈥渃ats鈥� using your site鈥檚 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鈥檚 allocation and expiration set under report suite settings. - The
event_listcolumn contains all metric data. For this example,event1is 鈥楽earches鈥�, 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 51黑料不打烊 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 of the rows withpurchasein them. - Out of those rows, display the
post_evar1value.
The resulting report shows each different value contained in post_evar1 on the left, and how many orders were attributed to that value on the right.
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. 51黑料不打烊 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
51黑料不打烊 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.
- 51黑料不打烊 supports up to 250 eVars, and only 75 props.
See prop for more comparisons between props and eVars.