Merchandising eVars [SiteCatalyst]

Published by Adam Greco on September 27, 2011.

After blogging about Omniture SiteCatalyst for a few years now, one of the topics I have always avoided discussing is Merchandising eVars (not to be confused with the separate Omniture Merchandising product). The reason for this, is that I find them to be very confusing and was sure that no matter how hard I tried to explain them, I would probably mess it up. For years, I have waited for someone to write about them, but seeing as no one has written extensively about them (at least according to a quick Google search!) and having been inspired by some other great blog posts I have read lately in which people have said that it is ok to not have all of the answers, I have decided to face my fears and go ahead and do my best to describe Merchandising eVars. My hope is that this post will serve as a first step in getting the SiteCatalyst community to understand these nuanced eVar and that it might spawn some good discussion and other blog posts by others who have spent a lot more time with them (like Kevin W.) so that one way or another, the topic will be adequately covered.

Why Merchandising eVars?

So why did Omniture make a special type of Merchandising eVar and why are they so complicated? If we go back in time to when I started using SiteCatalyst (version 9.x) and there were no Merchandising eVars, there were a few problems that existed. First was the Category parameter in the Products string. If you have been using SiteCatalyst for a while, someone has probably told you to NEVER use the first parameter (Category) in the Products string. They often don’t tell you why, but the reason is that if you do, the Product you pass will be forever tied to the Category in that string. That means that if you later decide to put the same product in a different product category, SiteCatalyst will ignore it and always use the first one it saw. If each of your products has only one product category and it will be that way forever, you can go ahead and use the Category parameter (or simply classify products using SAINT Classifications). But since most clients like to have products in more than one category, they asked for a way to assign the same product to different merchandising categories, hence, Merchandising eVars!

Let’s look at an example. Say that you have a retail site and that you sell ceiling fans, but those fans can be found by people going through “Lighting” or “Bedroom” product categories. Now let’s say that you would like to know how many Cart Adds or Purchases take place when people found ceiling fans through one of these product categories, but not the other. Sounds simple enough right? But it wasn’t in the past. If you had used the Products string to assign a specific ceiling fan to “Lighting,” it would always be bound to that product category. Instead, you would need a way to dynamically assign the specific product category for each product in each specific instance to get the data you were looking for. By doing this, you could see how often the ceiling fan was purchased via “Lighting” and how often it was purchased via “Bedroom.” Since then, there have been many different uses for Merchandising eVars, but I think it is important to understand the underlying problem that they were created to solve, as I find this helps to understand how they work and why they are different from traditional eVars. So when you think of Merchandising eVars just remember that their purpose is to assign a different eVar value to each product at the time Success Events take place.

Using Merchandising eVars

So now that we know a bit about how Merchandising eVars originated, let’s discuss how they are used. As you can imagine, connecting a different eVar value to each product is not a simple task. That is a lot of information for SiteCatalyst to keep straight! There would have to be some specific ways for you to implement this such that SiteCatalyst knows when you want each product to be tied to each Merchandising eVar value. Fortunately (or unfortunately!), SiteCatalyst has not one, but two methods of binding eVar values to products. One method is called Product Syntax and the other is called Conversion Variable Syntax.

Product Syntax
I find the Product Syntax method to be the most straightforward, and what I recommend most often, so I will start with that one. In this method, you use a special parameter slot within the Products string to declare which Merchandising Category you want to assign to each product. To do this, let’s re-visit the syntax for the Products string:

s.products=”category;product;quantity;price;event_incrementer;
merch_category1|merch_category2“

As you can see, towards the end of the Products string, there is a slot reserved for setting Merchandising eVars. In fact, you can set more than one by using a “|” separator. Using this syntax, if a Cart Addition occurs, you can set your Cart Add Success Event and Merchandising eVars as shown in this example:

s.events=”scAdd”
s.products=”;Fan-11980;;;;evar1=Lighting”

Here we can see that we are manually assigning the product category of “Lighting” to the product “Fan-11980″ at the time of Cart Addition. However, there are some back-end settings that also need to be made to allow for this to function properly. First, we need to call Omniture Client Care and ask that Merchandising be enabled for the appropriate eVar (eVar1 in this case). Once Merchandising has been enabled, we need to go to the Admin Console and select the Product Syntax option under the new Merchandising setting that will now be visible. When using Product Syntax, the second Merchandising setting (called Merchandising Binding Event) is disabled (but for some reason looks like you can use it!) so my advice is to just ignore that setting altogether. Here is what the settings should look like when you are done:

As with other eVars, you still have to decide what Allocation you’d like (First or Last) and how long the eVar should retain its value before it expires. But beyond that, you are good to go and the hardest part is making sure your developers are keeping track of which product categories should be associated with each product. If you know the value that you want to pass to the eVar for each product on the page (product category in the preceding example), I recommend you use the Product Syntax approach.

Conversion Syntax
The second approach to setting Merchandising eVars is the Conversion Variable Syntax. This approach is a bit more confusing and is normally used when you want to associate a different eVar value to each product, but the value you want to set in that eVar is only known prior to the Success Event taking place, instead of on the same page. The only way I can think of to explain this is through an example. Let’s imagine that your boss wants to know which internal search phrases were used prior to each product being purchased. Now, let’s pretend that a visitor comes to the website and searches on “ceiling fans,” finds Product 123 in the list and adds it to the cart. Next, the visitor searches for “bathroom vanities,” again scans the list, finds Product 789 and adds it to the cart. Then the visitor purchases both items a few pages later. In this example, if we were to use a traditional eVar (with Most Recent allocation), each Cart Addition would be correctly associated with the correct search phrase – “ceiling fans” = product 123 and “bathroom vanities” = product 789. So far so good. But when the visitor purchases both products, guess which internal search phrase would get the credit? If you said “bathroom vanities” you are correct! Since that was the last search phrase SiteCatalyst saw, it would get credit for both products. This is because a traditional eVar cannot associate a different value for each product.

However, by using the Conversion Syntax and Merchandising, in this scenario, each product would be associated with the specific search phrase that was used to find it for both the Cart Add and Purchase Success Events. So how do we configure this? First, we would work with Client Care to declare eVar1 to be a Merchandising eVar. Next, we would decide when we would like to have Omniture bind the internal search phrase to the eVar value. For most clients, the default is to bind at the Product View (prodView) event and the Cart Add (scAdd) event (though you can choose from any Success Events you’d like). By binding to the Product View and Cart Add, you are telling Omniture that if one of those two events happens, you want Omniture to bind the last value passed to the Merchandising eVar (internal search phrase in our example) with the product being viewed or added to cart. This is how these settings would look in the Admin Console:

Well…there you have it. My first attempt at facing my fears and explaining about Merchandising eVars. Hopefully I got most of it right and if so, will maybe write another post in the future on the more advanced uses of Merchandising. In the meantime, for more detailed info on Merchandising eVars, please check out this Omniture white paper (login required). Please comment here and I will do my best to get any question answered. Thanks!

About Adam Greco

Adam Greco is a longstanding member of the web analytics community who has consulted with hundreds of clients across every industry vertical. Mr. Greco began his web analytics career managing the website for the Chicago Mercantile Exchange and then became one of the founders of the Omniture Consulting group. While at Omniture, Mr. Greco managed accounts large and small and helped clients maximize their use of Omniture technologies. In 2012, in partnership with Adobe, Mr. Greco is publishing the first-ever book on Adobe SiteCatalyst - The Adobe SiteCatalyst Handbook: An Insider's Guide.

Want to speak with Adam? Contact Web Analytics Demystified

Adam Greco Blog at Web Analytics Demystified

Posted Tuesday, September 27th, 2011 | 13 responses | Share, Save or Email

http://www.fuelinteractive.com Melissa Kavanagh

Thanks for this post! We are having a heck of a time trying to get our merchandising eVars to work. We have an online clothing retailer client, and are trying to capture size and color of the product. Apparently, this is rocket science, because even with ClientCare help, we still haven’t been able to get it to work.
http://adam.webanalyticsdemystified.com Adam Greco

Melissa,

There are many “gotchas” with Merchandising eVars…Feel free to ping me if you want any help…

Adam
Elías Nuevo

Hi Adam,

Thanks for this post!

We have used Merchandising eVars in one of our clients for a few months and they are very useful if you want to pass different values in the same eVar to different products (altough I recognize we have had a few problems with configurations before this with Client Care). Specifically, we are using it in the “Products Syntax” way.

So far we haven’t found any limitation with subrelations and other stuffs, and we sure would encourage to use it to other customers.

In which cases would you use the “Conversion Variable Syntax”? to pass some values in an eVar to the same product?

Elías
http://www.diy.com Kai Zhang

Hi Adam,

Thanks for the post.

By looking at the examples you’ve given individually, I understand how each method works. However, i.e if we use internal search example to explain product syntax, I got totally confused. Would you mind giving me some help on understanding this by swapping the examples under each method?

Thanks

Regards

Kai
http://adam.webanalyticsdemystified.com Adam Greco

Kai – Sent you an e-mail…I will probably do more posts on this to add more examples…Stay tuned…

Adam
Martin

Hi Adam,
Could you explain if one needs to set the eVar for Merchandising eVars within the product string EVERY-TIME you set the s.products variable or only on the first occurrence of the s.product variable.

So would I set the eVar only when the prodView event is fired and not again when scAdd, scView, checkout and purchase are set? If I set it only on prodView, will all other success events be tied to this variable such as revenue?

Thanks
http://adam.webanalyticsdemystified.com Adam Greco

Martin – It is my understanding that you only have to set it once and that it will persist. I don’t believe that setting it again will harm you though…
Martin

Thanks Adam,

I’ve done some tests and it appears that one would need to set the eVar each time the product string is set because in a normal retail site, one product could be found in different categories or departments. If the same product is viewed but in different sections of the site, the success events will be associated to either the first value of the eVar or the last, depending on your Allocation (last or first).

However this will cause issues when you have 100s of products within your cart. How would the developers persist the value of the merchandising eVar to the purchase page in the event that they have the same product in the cart but from different sections of the site. they will not be able to persist the eVar for each product until the final confirmation page.

I hope I have explained my issues clearly. I feel this is a limitation with SC on retail sites. As Marketers would very much like to know what merchandising category generated the most revenue
http://adam.webanalyticsdemystified.com Adam Greco

Martin – My response to your comment would differ if your merchandising eVar is a product syntax or conversion syntax merchandising eVar. If it is product syntax, then: you should be setting the merchandising eVar category along with the prodView in every case. If using product syntax – it is ok to set your allocation to last. This is the cleanest approach and should not have any drawbacks. If you are using conversion syntax things are much more complicated: first off – “first” and “last” allocation for conversion syntax do not work they way you’d think. The most dangerous combination with merchandising eVars is conversion syntax + all events bind + last allocation. This can lead to a situation where ALL your merchandising eVar values across all your products are clobbered or overwritten on the final thank you page because each combination of product and merchandising eVar value do not have their own “persistence column” if you will. To avoid this mess – it’s usually best to keep allocation as first when using conversion syntax. By carefully picking the right binding events you should be fine (or mostly fine) with the scenario described above.
Martin

Thanks Adam, that make sense.

Just one thing I have struggled with in my testing with regards to the product syntax eVar, is that if you have 2 of the same product that are viewed and added to the cart from different part of the site, then either using first or last allocation, wouldn’t the revenue (or other success events) be associated to only one of the eVar values?

“If using product syntax – it is ok to set your allocation to last” – would this not just allocate revenue to the last eVar value?

eg:
s.events = “prodView”;
s.products = “;12345;;;;evar2=PDAs”;

s.events = “prodView”;
s.products = “;12345;;;;evar2=phones”;

if we now checked out and purchased these 2 products above, for $100, we would see $200 against “PDA’s” if first allocation is used or $200 against “phones” if last allocation is used and not $100 for PDA and $100 for “phones”

Am I missing something?
http://adam.webanalyticsdemystified.com Adam Greco

Martin,

Unfortunately, there is no concept of “linear” allocation for Merchandising eVars. In other words – yes – either $200 will go to PDAs or phones. It is not possible to give $100 to each because a single eVar cannot have multiple values for a single product. feel free to suggest it in the Idea Exchange…

Adam
http://www.digitalbalance.com.au Tim

Hi Adam
Great post. We’ve just implemented merchandising eVars for an ISP to be able to break down the overall revenue by plan values (bundles) and contract lengths, upfront costs, ongoing costs etc…

e.g.
ADSL1 $1000 (total revenue)
12 mths $700 (value from contracts over 12 months)
24 mths $300 (value from contracts over 24 months)
…which enables them to see which contract lengths are driving the most purchases etc

We’ve currently got them set as Product Syntax, based on ClientCare recommendation.

However, I’m wondering whether they should in fact be Conversion Syntax. The reason being we set all of the product string values, evars and events, when the cart is actually checked out (so s.events=”purchase”)

There are multiple products in the string, with each one having extended information. For example, I can buy, from the same cart, a 12 month broadband contract for $679.35 and a 24 month phone plan for $1758.75 (examples only), so my product string, on purchase, looks like:

s.products=”;adsl;1;679.35;event35=79.95|event36=49.95|event37=12|event38=599.4;eVar40=12 months|eVar41=49.95,;phoneABC;1;1758.75;event35=79.95| event36=69.95| event37=24|event38=1678.8;eVar40=24 months|eVar41=69.95″;

where:
;total_cost – total revenue by product
;event35 – upfront cost
|event36 – ongoing monthly cost
|event37 – contract length in months
|event38 – contract revenue (contracted months * monthly fee)
;eVar40 – contract length, with ” months” added to the end
|eVar41 – plan type, same as event36

Given the values are all passed at the same time, is Product Syntax correct?
The eVars are set to Original Value, expire on Visit.
I want to make sure that there is no chance for the Phone to show as a 12 month contract, because that particular eVar was set first.

Does that make sense? Keen to hear your thoughts.
Thanks
Tim
http://www.linkedin.com/in/kevinw Kevin Willeitner

For Tim:

You most certainly want product syntax in the case that you provided. In general, you will always use product syntax when you are trying to assign different values of the merchandising evar to multiple products at the same time. When you use conversion syntax only a single value will be applied to all the products in the product string.

For Melissa:

You can set size and color with product syntax on the add to cart like this

s.events=”scAdd,scOpen”
s.products=”;[model number];;;;eVar1=[child sku]”

Don’t set this on the product view or quick view since the customer has not selected a size and color yet. This will give you an additional report that provides the sku-level reporting for that product. Now, it is often the case where retail companies want to see color selections in aggregate to see sales of color change through the season. To do this you can either classify the child sku or you can add another merchandising evar that is just for color like this:

s.events=”scAdd,scOpen”
s.products=”;[model number];;;;eVar1=[child sku]|eVar2=[color code]”

Note that these evar values will tie to the product and any future success events for the product. To insure that at the time of the confirmation page that the sku selected by the user still matches what they are actually ordering you can reset the sku and color on the confirmation page as well.

For Elías:

Conversion syntax is mostly useful for companies that need to persist a value across pages before binding to a product. For example, if you take the merchandising category example that Adam provided, it is common for companies to not know precisely what category you are in when you are looking at a product detail page. If you are looking at a page for a belt you may have arrived at that page through Men’s>Accessories or Men’s>Belts. You can set the merchandising evar on the Accessories or Belts page and then it will persist over to the product detail page to bind with the product.

For Martin:

You can set the merchandising evar once per product per visitor. This applies to product and merchandising syntax. You will be able to see how one product differs from another product but you can’t see how multiple occurrences of the same product differ. This is because the same product ID for the same visitor isn’t unique so it doesn’t give the evar anything new to latch onto. To account for this, I once created a plugin that does a special kind of “category stacking” at the product level which was interesting but complicated and had potential cookie size limitations. For you I would recommend that you consider how likely it is that that same person would find a product through multiple categories. If it isn’t likely then I wouldn’t worry about it. If it is likely then you can reset the category on the confirmation page like so:

s.events=”purchase”
s.products=”;productA;1;10.00;;eVar1=catA,;productA;1;10.00;;eVar1=catB”

This approach would use product syntax and most-recent allocation and would assign $10 to each eVar1 value. Also know that this will inflate the order count in your products report (if you are using SiteCatalyst version 14) since you will now have multiple occurrences of the same product in the product string.