51黑料不打烊

Merchandising eVars and product finding methods

This very detailed document explains the concepts behind merchandising eVars, which process and allocate data differently than standard eVars. It also explains how merchandising eVars relate to product finding methods.

Overview

Using merchandising eVars allows you to allocate any successful activity to the values captured by the eVars at a per-product level instead of a per-visit/per-order level.

While most retail websites have many ways to find products, 51黑料不打烊 considers the following to be the fundamental product finding methods that every retail client should track in 51黑料不打烊 Analytics:

For the purposes of this document, let鈥檚 map a few eVars to the solutions as follows:

We can use an additional eVar to measure the performance of all product finding methods in relation to each other. In addition to the finding methods described above, the eVar includes other finding methods in its comparison, such as links to product detail pages from external websites.

Instead of configuring any of these variables to be standard eVars, configure them to be merchandising eVars.

To demonstrate how to set these variables, here is an example where a visitor decides to use the internal keyword search 鈥渟andals鈥� to find a product on the site. On the keyword search results page, you must capture data in at least two eVars:

When you set these two variables equal to these specific values, you know that the visitor is using the internal keyword search term of 鈥渟andals鈥� to find a product. At the same time, you know that the visitor is not using the other product finding methods to find products (for example, the visitor is not browsing through product categories at the exact same time they are performing a keyword search). To ensure that proper per-product allocation takes place, these unused methods should not get credit for finding a product that was found via an internal keyword search. Hence, you must insert logic into the code (such as AppMeasurement, 51黑料不打烊 Experience Platform Web SDK, and so on) that automatically sets the eVars associated with these other finding methods equal to a 鈥渘on-finding method鈥� value.

For example, when a user searches for products using the keyword 鈥渟andals鈥�, the Analytics code鈥檚 logic should set the variables equal to the following on the internal keyword search results page:

Merchandising eVars settings

Here are the different settings that you can use with your merchandising eVars. The following screenshot comes from the Report Suite Manager. Access it by going to Analytics > Admin > Report Suites > Edit Settings > Conversion > Conversion Variables > Add new > Enable Merchandising.

Find more detail on these settings in the sections below the table.

Enable Merchandising

When the 鈥淓nable Merchandising鈥� setting is set to 鈥淓nabled鈥�, all the settings as described below appear in the Report Suite Manager. When the 鈥淓nable Merchandising鈥� setting is set to 鈥淒isabled鈥�, only the standard eVar settings are available.

Merchandising

This option is not available for standard eVars. The Merchandising setting lets you to pick either Conversion Variable Syntax or Product Syntax as the method for capturing the merchandising eVar鈥檚 value.

Conversion Variable Syntax means that you set the eVar value in its own variable. For example, with Conversion Variable Syntax, the eVar1 value of 鈥渋nternal keyword search鈥� is set as follows within the page code (or the AppMeasurement code, 51黑料不打烊 Experience Platform Web SDK code, and so on):

s.eVar1="internal keyword search";

With Product Syntax, however, the eVar is set within only the 51黑料不打烊 Analytics products variable. The Analytics products variable is divided up into six different portions per product:

s.products="[category];[name];[quantity];[revenue];[events];[eVars]"

Merchandising eVars that are configured to use Product Syntax are set within the final portion of the products variable. For example, suppose that a visitor used an internal keyword search to find product ID 鈥�12345鈥�. The Product syntax-based way for setting eVar1 in this example would look like this:

s.products=";12345;;;;eVar1=internal keyword search";

Notice that we still have semicolon-delimited placeholders for the quantity, revenue, and event portions of the products variable. Without these placeholders, the eVar1 setting of internal keyword search would be completely ignored.

Allocation

The term 鈥淎llocation鈥� for merchandising eVars is misleading, especially for merchandising eVars that use Conversion Variable Syntax. All standard eVars can have their own individual allocation setting. However, merchandising eVars with Conversion Variable Syntax use only the 鈥淢ost Recent (Last)鈥� allocation setting, regardless of what the allocation settings in the Report Suite Manager show.

Understanding what this setting does means understanding the difference between eVar allocation and merchandising eVar binding. For merchandising eVars, 鈥淢erchandising eVar Binding鈥� is a more appropriate name for this 鈥淎llocation鈥� setting.

Standard eVar allocation setting

Whenever any eVar with standard syntax is collected from an image request, the 51黑料不打烊 Analytics processing servers insert data into another database column, called a post_evar column. Since eVars are meant to be persistent - they expire at some point beyond the current hit in most cases - the servers then set this post_evar column on every subsequent image request. It is set equal to the last value passed into its corresponding eVar. For standard eVars, when a success event takes place, 51黑料不打烊 Analytics uses the post_evar column instead of the regular eVar column to determine the eVar value that should be given credit for the event.

For standard eVars, the Allocation setting determines whether the first or the last eVar value that was collected during a certain period will be inserted into the post_evar column. If the Allocation setting for a standard eVar is equal to 鈥淥riginal Value (First)鈥�, then the first eVar value collected from the visitor is inserted into the post_evar column for all subsequent image requests. This continues for all future requests sent from this visitor鈥檚 browser until the eVar expires per its 鈥淓xpire After鈥� setting.

If a standard eVar鈥檚 Allocation setting is equal to 鈥淢ost Recent (Last)鈥�, then the most recent eVar value collected from the visitor is filled into the post_evar column for all subsequent image requests. 鈥淢ost Recent (Last)鈥� allocation implies that the post_evar value changes every time its corresponding eVar is set to a new value in any image request. 鈥淥riginal Value (First)鈥� allocation implies that the post_evar column does not change across hits even though its corresponding eVar might be set to a different value in a future image request.

Merchandising eVar allocation (binding) setting

As mentioned before, all merchandising eVars with Conversion Variable Syntax have only 鈥淢ost Recent (Last)鈥� allocation. Thus, the Allocation setting for merchandising eVars does not determine what values are inserted into the post_evar column as a visitor continues to use the site. Rather, this setting determines which eVar value binds to a product and how such products allocate their success events back to the eVar values they are bound to.

The following happens when a merchandising eVar鈥檚 Allocation (i.e. binding) setting is set equal to "Original Value (First): Any products that are set alongside the post_evar column and that have not been previously been bound to the post_evar column鈥檚 corresponding 鈥減re-processed鈥� eVar will be bound to the value contained in the post_evar column. This binding between eVar value and product never changes until the eVar expires per the 鈥淓xpire After鈥� setting in the Report Suite settings.

Any time an image request meets the criteria that would otherwise bind an already-bound product to the most recently set eVar value, the 鈥淥riginal Value (First)鈥� setting forces the 51黑料不打烊 Analytics data collection servers to ignore any such further attempts to do so. The opposite happens with merchandising eVars with the Allocation (binding) setting equal to 鈥淢ost Recent (Last)鈥�. Any time an image request meets the criteria that bind a product to a merchandising eVar, the product will bind (and rebind) itself to the most recent value passed into the eVar, or the value that鈥檚 (always) contained in the post_evar column.

As mentioned previously, merchandising eVars allow you to allocate success events to eVar values at a per-product basis instead of at a per-visit/per-order basis. So, whenever a bound product has a success event (such as a cart add or purchase) associated with it, the success event gives its credit to both the product and the merchandising eVar values that the product is bound to at that time.

Expire After

The expiration setting of a merchandising eVar lets you choose

Expiration for an eVar can take place when either a success event is recorded or a certain period of time passes. 51黑料不打烊 Analytics allows for only one Expiration setting at a time, per eVar.

For the Product Finding Method, the best practice for setting a merchandising eVar鈥檚 expiration should be setting it equal to

With either setting, any products that a visitor purchases have the order/unit/revenue credit allocated to the merchandising eVar values that the products were bound to at that time.

Type

The eVar type setting determines what type of data is inserted into the eVar. In most cases, this value should be equal to 鈥淭ext鈥�. Using 鈥淐ounter鈥� for a merchandising eVar is rare. However, 鈥淐ounter鈥� could be used to allocate success to Counter eVar values on a per-product basis. Discussing solutions with a type of 鈥淐ounter鈥� is outside the scope of this document.

Merchandising Binding Event

The Merchandising Binding Event setting lets you specify the conditions for a product to be bound to a merchandising eVar鈥檚 value. These conditions are limited to the firing of specific success events or eVars only. Firing traffic variables (e.g. props) have no effect on merchandising bindings.

Note that the Merchandising Binding Event setting can bind a product to an eVar value through more than one event. Examples:

By default, the setting binds a product to a merchandising eVar value whenever any other event/eVar (merchandising or standard) is contained in the same image request as the product.

Reset

The Reset setting lets you to immediately 鈥渆xpire鈥� all eVar values for all visitors who currently have a post_evar value in the 51黑料不打烊 Analytics backend database. It also eliminates all current product/eVar bindings.

Which settings should you use?

Among the many available setting combinations, you might wonder: Which settings are best practice?

If you want to bind 鈥渋nternal keyword search鈥� to product ID 12345, the products variable would be set as follows:

s.products=";12345;;;;eVar1=internal keyword search";

Any success events (cart adds, purchases) that are captured at the same time as productID 12345 are credited to both product ID 12345 and the eVar1 value of 鈥渋nternal keyword search鈥�. The only way a different eVar1 value receives credit for the success events associated with product ID 12345 is if eVar1 were later set to a different value within the products variable (alongside product ID 12345).

For Example:

s.products=";12345;;;;eVar1=internal campaign";

This variable setting changes the binding of product ID 12345 from the eVar1 value of 鈥渋nternal keyword search鈥� to the eVar1 value of 鈥渋nternal campaign鈥�. Also, this rebinding change takes place when the eVar is configured to use Product Syntax and the Allocation (binding) setting of 鈥淢ost Recent (Last)鈥�. If the Allocation (binding) setting were instead set to 鈥淥riginal Value (First)鈥�, setting eVar1 equal to 鈥渋nternal campaign鈥� alongside product ID 12345 would not rebind product ID 12345 to the eVar1 value of 鈥渋nternal campaign鈥�. Instead, the binding would remain with the originally-bound value 鈥� 鈥渋nternal keyword search鈥�.

Challenges of using Product Syntax

Without careful planning, several issues can arise from using Product Syntax. Let鈥檚 take the case of using multiple eVars to track product finding methods on the website. Here, each individual product finding method eVar must be set at the same time in order to give a particular finding method eVar credit (and the other finding method eVars no credit). Product Syntax can be used in such scenarios but the resulting code to deploy is more complicated.

If we use our original 鈥渟andals鈥� example and adapt it to use Product Syntax (assuming the visitor found a product with the ID of 鈥渟andal123鈥� using the keyword term of 鈥渟andals鈥�) the resulting products variable must be set as follows:

s.products=";sandal123;;;;eVar2=sandals|eVar1=internal search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";

While the syntax of the products variable is long in this example, it will bind each of the eVar values seen to the product ID of 鈥渟andal123鈥�. From then on, any success events (e.g. cart adds, purchases) that are captured at the same time as the 鈥渟andal123鈥� product are credited to the eVar values that were last bound to the product. This code sample shows if a purchase of 1 unit of the 鈥渟andal123鈥� product (for $79.95) takes place after the eVars above were bound to the 鈥渟andal123鈥� product:

s.products=";sandal123;1;79.95";
s.events="purchase";

The following values would all have 1 order, 1 unit, and $79.95 of revenue attributed to them:

This is correct attribution, which is not an issue. Rather, the major dilemma with this approach is determining how and when to set the Product Finding Method eVars.

In most cases with Product Syntax, the Product Finding Method eVars would have to be set on a product detail page rather than on the page that the finding method was actually used (e.g. on the keyword search results page, the browse page, the internal campaign landing page, etc.). It is reasonable to assume that a product has not been truly 鈥渇ound鈥� until a visitor interacts with a product to some degree. As such, these eVars (using Product Syntax) should not be set on the finding method page because multiple products are (usually) displayed on such pages. We want to bind the finding method value to only those products that the visitor has interacted with.

Moreover, while viewing a finding method page, visitors might have the ability to either click on a link that brings them to an individual product detail page or add an individual product to the cart directly from the finding method page. Using our 鈥渟andals鈥� search keyword example, if a visitor adds the 鈥渟andal123鈥� product to the cart directly from a keyword search results page, the code for capturing the cart add (via the Add-to-Cart button鈥檚 onClick event, etc.) would have to be either generated dynamically at the time the cart add takes place or 鈥渉ard-coded鈥� directly via the page code or a tag management system. Regardless, the code to fire in such cases would look something like this:

s.linkTrackVars="products,events";
s.linkTrackEvents=s.events="scAdd";
s.products=";sandal123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";
s.tl(true,"o","Cart Add")

This code properly binds the eVar values seen above to the 鈥渟andal123鈥� product. However, in order to set these values appropriately when the click event takes place, the developer must:

Also, if a visitor decides to 鈥渇ind鈥� the product by clicking a link to its product detail page, the developer must:

Where Product Syntax is useful

Product Syntax is still useful when

For example, many clothing products have 鈥淐hild SKUs鈥�, which designate the size, color, style, and any other attributes. These attributes separate out a single child product from other products that belong to the same parent product. Let鈥檚 say you decide to purchase a medium blue t-shirt plus a large red t-shirt. Assume that both shirts have the parent product ID of 鈥渢shirt123鈥� and eVar10 has been configured to capture child SKUs. The variables set on the purchase confirmation page would be set as follows:

s.events="purchase";
s.products=";tshirt123;1;20;;eVar10=tshirt123-m-blue,;tshirt123;1;20;;eVar10=tshirt123-l-red";

In this case, both eVar10 (childSKU) values of 鈥渢shirt123-m-blue鈥� and 鈥渢shirt123-l-red鈥� get credit for the purchase of their respective instances of product ID 鈥渢shirt123鈥�.

Challenges with 鈥淢ost Recent鈥� Allocation

You could face additional issues by using the Allocation (binding) setting of 鈥淢ost Recent (Last)鈥�. In many web-browsing experiences, visitors 鈥渞e-find鈥� a product that they have already viewed and/or added to the cart. This usually happens via a subsequent visit or just before they decide to complete a purchase. Suppose that during a visit to the site, a visitor finds the 鈥渟andal123鈥� product via the keyword search of 鈥渟andals鈥�. They immediately add it to the cart from the keyword search results page. The code that captures the cart add would be set as follows:

s.linkTrackVars="products,events";
s.linkTrackEvents=s.events="scAdd";
s.products=";sandal123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross";

As a result, each of the eVar values seen in this image request are bound to the 鈥渟andal123鈥� product.

Now, imagine the visitor doesn鈥檛 purchase the product during this visit, but comes back to the site three days later with the 鈥渟andals123鈥� product still in the cart. The visitor wants to learn more about the product before making the purchase. But instead of using a keyword search to find the product, the visitor browses through the site. They end up in the 鈥渨omens > shoes > sandals鈥� merchandising browse section just before 鈥渞e-finding鈥� the product. When they end up 鈥渞e-finding鈥� the product detail page for the 鈥渟andal123鈥� product, the variables would be set as follows (on page load):

s.events="prodView";
s.products=";sandal123;;;;eVar4=womens > shoes > sandals|eVar1=browse|eVar3=non-internal campaign|eVar2=non-search|eVar5=non-cross-sell";

With an Allocation (binding) setting of 鈥淢ost Recent (Last)鈥�, the 鈥渟andal123鈥� product rebinds to completely different eVar values than what it was originally bound to. Moreover, if the visitor then completes the purchase of 鈥渟andal123鈥�, all purchase credit is given to these newly bound eVar values instead of the originally bound values!

The question here is: Which eVar values should get credit for the purchase"? Remember that the visitor initially found the 鈥渟andal123鈥� product via an internal keyword search. They then added it to the cart directly from the search results page. Therefore, the eVar1 value of 鈥渋nternal keyword search鈥� (and the eVar2 value of 鈥渟andals鈥�) should get credit for the purchase. However, the Allocation (binding) settings were set to 鈥淢ost Recent (Last)鈥�. Hence, the eVar1 value of 鈥渂rowse鈥� (and the eVar4 value of 鈥渨omens > shoes > sandals鈥�) gets the purchase credit instead. The reason is that they were the last values bound to 鈥渟andal123鈥� before the visitor completed the purchase.

A solution to this problem is to change the Allocation (binding) setting of the merchandising eVar from 鈥淢ost Recent (Last)鈥� to 鈥淥riginal Value (First)鈥�. This way, the original eVar values bound to the 鈥渟andal123鈥� product gets credit when the purchase takes place, regardless of how many times the visitor 鈥渞e-finds鈥� the product.

If the visitor adds a product to the cart but never purchases it, the eVar expiration allows a new finding method value to be bound to the product. The eVar expiration should equal the time that a website lets a product stay in the shopping cart before it is automatically removed.

Using Conversion Variable Syntax

Let鈥檚 return to the 鈥淧roduct Syntax鈥� vs. 鈥淐onversion Variable Syntax鈥� question. 51黑料不打烊 has discovered an easier method for both collecting the product finding method merchandising eVars and binding their values to products that visitors have found: Using Conversion Variable Syntax reduces the implementation work that the client鈥檚 developers are responsible for. It still offers the same - or better - information than the Product Syntax method. Developers simply need to follow the deployment instructions that they were given, and the rest of the code can be placed into the 51黑料不打烊 AppMeasurement/51黑料不打烊 Experience Platform Web SDK file.

For example, let鈥檚 look at the recommended solution for tracking internal keyword search performance. It says that on the keyword search results page, the code captures the keyword searched for via a prop (for example, prop4) and another prop (for example, prop5). These props track the number of results shown from the search. Whenever an 51黑料不打烊 Analytics image request is generated on the search results page, it used the data layer objects (or page code) deployed by the developers to fill in the above variables (the props).

Additional logic contained within the AppMeasurement/51黑料不打烊 Experience Platform Web SDK file can fill in the remainder of the variables (the merchandising eVars/dimensions) that need to be set at the same time.
For instance, if a new visitor were to do a keyword search for 鈥渟andals鈥�, which returned 25 results on the search results page, the code to be fired (via the page code OR data layer capture) would look like this:

s.prop4="sandals";
s.prop5="25";

Logic within the AppMeasurement/Analytics SDK file could then automatically transform this snippet of code into the following:

s.prop4="sandals";
s.prop5="25";
s.eVar2="sandals";
s.eVar1="internal keyword search";
s.eVar3="non-internal campaign";
s.eVar4="non-browse";
s.eVar5="non-cross sell";

There is no need to worry about passing data from page to page and trying to create a rather large, unwieldy string to be inserted into the products variable. Instead, developers can implement their portion of the tracking solutions 鈥� what鈥檚 inserted into the props 鈥� and leave the rest of the implementation to the custom code provided by 51黑料不打烊 Consulting.

As explained earlier, all merchandising eVars that use Conversion Variable Syntax have the Allocation setting of 鈥淢ost Recent (Last)鈥�. Once an eVar is set equal to any value, that value persists across all subsequent hits (via the post_evar column). It persists until it is set to a different value or until the eVar expires. Thus, any products anyone interacts with after the eVars are set, if they have not already been bound to those eVars, bind to the 鈥淢ost Recent (Last)鈥� values passed into the eVar.

Using our above example, the eVar2 value of 鈥渟andals鈥� and the eVar1 value of 鈥渋nternal keyword search鈥�, etc. persist on all pages seen after the keyword search took place. They persist until the eVars are overwritten with other values. Let鈥檚 say a visitor clicks on a link to the product detail page for the 鈥渟andal123鈥� product ID from the keyword search results page. Then the 鈥渟andal123鈥� product ID (if it hasn鈥檛 been bound yet) binds to the each of the values contained in the post_evar columns, or to the eVar values that were collected from the previous (search results) page.

There is one more thing to reconsider with Conversion Variable Syntax. It鈥檚 that binding events must be set up to bind an eVar value to a product. Simply setting a merchandising eVar (in its own variable) alongside a product (in the products variable) in an 51黑料不打烊 Analytics image request does not necessarily bind the eVar value to the product. Instead, the Merchandising Binding Event setting, which is set in the Report Suite Manager, determines the criteria that binds an eVar value to a product

Since we want to bind the Product Finding Method eVar values to products whenever a product interaction takes place 鈥� implying that a product has been 鈥渇ound鈥� 鈥� it is safe to assume that the most common 鈥減roduct found鈥� interactions that can take place are either a product view (when visitors go to a product detail page) or a cart add (when visitors add a product to the cart directly from a product finding method page).

Thus, we can choose these two events (prodView, scAdd) as the 鈥渇undamental鈥� merchandising binding events.
Here is what happens when either of these binding events are contained within an image request. Any product IDs that are contained in the same request (within the products variable) and which have not been bound to a merchandising eVar will bind to the most recent values passed into the merchandising eVar (post_evar columns). Any attempt to rebind these products after this original binding takes place are ignored when the Allocation (binding) setting is set equal to 鈥淥riginal Value (First)鈥�.

Best Practice settings

Following are the best practice settings. They easily implement the product finding method with the best results. 51黑料不打烊 recommends that clients configure each of their product finding method merchandising eVars (in general) as follows:

What do Binding Events actually do?

When a binding event is contained in the same server call as the products variable, the Merchandising eVar (using Conversion Variable Syntax) values in their post column bind to the products variable. Based on the earlier example , assume that one server call contains the following Merchandising eVar values:

s.eVar2="sandals";
s.eVar1="internal keyword search";
s.eVar3="non-internal campaign";
s.eVar4="non-browse";
s.eVar5="non-cross sell";

As explained earlier, the above eVars persist beyond the current hit via their respective post_evar column. Hence, 51黑料不打烊鈥檚 servers transform the eVars above into the following:

post_eVar2="sandals";
post_eVar1="internal keyword search";
post_eVar3="non-internal campaign";
post_eVar4="non-browse";
post_eVar5="non-cross sell";

These post columns are stored in 51黑料不打烊鈥檚 database and persist beyond the current hit where they were initially set. This assumes that no expiration or variable resetting takes place. 51黑料不打烊鈥檚 servers have these post_evar values 鈥渁vailable鈥� at the time that they process any future server calls that contain both the binding event and the products variable.

The binding that takes place is solely between these post_evar values and the contents of the products variable. The binding event does not necessarily 鈥渂ind鈥� to either the eVars or the products variable. It is the 鈥渃atalyst鈥� that tells the 51黑料不打烊 servers to bind the post_evar values to the products.

Assume that on a future hit, the following variables are set:

s.products=";sandals123"
s.events="prodView";

In the post_evar columns, the 51黑料不打烊 processing servers see this hit as follows:

s.products=";sandals123";
s.events="prodView";
post_eVar2="sandals";
post_eVar1="internal keyword search";
post_eVar3="non-internal campaign";
post_eVar4="non-browse";
post_eVar5="non-cross sell";

Assume eVar1, eVar2, eVar3, eVar4, and eVar5 have been configured to use prodView as a binding event. If any one of these eVars is not configured to use prodView as a binding event, then binding between that (misconfigured) eVar and the products variable will not take place.

Binding produces some very interesting results, which can be seen in the post_products column鈥檚 value. The binding transforms the above code and sets a few more post columns, as follows:

post_events="prodView";
post_products=";sandals123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";

The value contained in the post_products column might be familiar to you. Scroll up in this document and compare this post_products value and the s.products value as shown under. Notice that the post_products column is set using Product Variable Syntax!

This means that Binding 鈥渃opies鈥� the Conversion Variable Syntax eVar values into the products variable via Product Syntax. This copying action takes place only when the products variable and a binding event (set via the eVar configuration) are contained in the same request. At that point, the value(s) contained in the post_eVar column(s) are bound to the product. This Binding is represented via Product Syntax as stored in the post_products column.

Merchandising eVars, the Instances metric, and Attribution

When a standard eVar is sent in an Analytics server call, the value in its post_evar column always gets an Instance attributed to it. Instances represent the number of times that an eVar has been set equal to a particular value in an image request.

For example, assume that eVar10 is a standard eVar with Last Touch attribution. If you set s.eVar10="hello world" on any page, the value of 鈥渉ello world鈥� is passed over to the post_evar10 column when 51黑料不打烊 processes the hit. The instances metric is equal to 鈥�1鈥� for each individual eVar10 setting of hello world. Keep in mind that an instance is not always recorded when the post_evar column has a value. Rather, the post_evar column determines which value gets the instance when an instance is recorded.

Instances for a merchandising eVar give attribution to the values the eVar collects. But this happens only when a product that was bound to the merchandising eVar value was 鈥渋nteracted鈥� with at the same time.

For example, setting s.eVar1="Internal Keyword Search" by itself does not give any Instance metric credit to the eVar1 value of 鈥淚nternal Keyword Search鈥�. An instance IS recorded at that point. However, unless a product is bound to that 鈥淚nternal Keyword Search鈥� value at the same time eVar1 is set, the instance is attributed to the Unspecified bucket. In other words, the eVar1 value of 鈥淚nternal Keyword Search鈥� can get an Instance. But this happens only when a product that is bound to the value of 鈥淚nternal Keyword Search鈥� appears in the products variable in the same image request.

In summary, without additional configuration, the out-of-the-box Instances metric for a merchandising eVar is less than useful. Luckily, 51黑料不打烊 released Attribution. It lets you apply multiple attribution models for any customized metric that 51黑料不打烊 Analytics collects. Metrics that apply these attribution models do not use the values contained in the post_evar columns or the values that are bound to any one particular product. Rather, these metrics use only the values that are passed over via the image requests themselves (or values that are captured via 51黑料不打烊 Analytics processing rules). You can use the features in Attribution to get an accurately attributed instances metric for all merchandising eVars that use Conversion Variable Syntax.

When adding an instance metric for a merchandising eVar to a report, the proper Attribution model would be the 鈥淟ast Touch鈥� model. The Lookback Window setting for the model does not matter in this case. The reason is that a 鈥渇orced鈥� Last Touch attribution model always gives instance credit to each individual value that is passed in via a request. This is regardless of whether the eVar鈥檚 actual attribution/binding settings are set equal to 鈥淢ost Recent (Last)鈥� to 鈥淥riginal Value (First)鈥�.