Archive for 'Conversion Variables'

Last week I described a new way to track how much money visitors had spent on your site prior to their current visit. This week, I am going to expand on this topic and provide some other cool uses of this concept. If you haven’t read my last post, I suggest you do that before reading this one.

Revenue by Product Category

In the last post, you may recall that we were able to quantify how much money the visitor had purchased in the past and break down current reports by those amounts. In the scenario I described previously, we could only see the total revenue amount across all product categories (in the previous scenario the product categories we discussed were Electronics, Clothing and Furniture). However, there is no reason that you cannot create a separate Counter eVar for each product category (or your major product categories if you have too many!). Doing this will allow you to see how much visitors had spent on just Electronics, for example, prior to future Success Events like Cart Adds or Orders. This might be good for companies that have distinct teams focused on each product category. To do this, the code might look like this:

s.events=”purchase”
s.products=”;SKU111;1;300.00;; evar1=Electronics,;SKU222;1;400.00;; evar1=Clothing,;SKU333;1;200.00;;evar1=Furniture”
s.eVar40=+900
s.eVar41=”+300″
s.eVar42=”+400″
s.eVar43=”+200″

By doing this, there would be one Counter eVar which shows that the visitor in our example above had spent $300 (row five) in Electronics prior to his/her second visit which might result in a report like this:

You would then see a report like this for each product category, though I would still recommend one Counter eVar like the one first described, which combines revenue for all product categories combined. Keep in mind that you could also use Product Merchandising to see total previous revenue (eVar40 in our example) by product category, but since you only get two levels of breakdown in SiteCatalyst reports, splitting out each product category into its own Counter eVar provides one more level of breakdown…

Orders to Date

As long so you are going to go through the effort to see how much money the current visitor had spent on your site, why not also track how many Orders they had completed? Doing this is very similar, though it will use up more eVars. Here is how you would do it. First, set a new eVar in the Admin Console and set it to be a Counter eVar with an expiration of “Never” or possibly “1 Year” depending upon how long you want to keep the data. Once this is done, on the purchase thank you page, simply set the Order Counter eVar to “+1,” as you normally would set a Counter eVar like this:

s.events=”purchase”
s.products=”;SKU111;1;300.00,;SKU222;1;400.00,;SKU333;1;200.00″
s.eVar41=”+1″

Kind of anticlimactic huh? By doing this on every purchase thank you page, you can track how many orders each website visitor completed and can then use this in analysis efforts. Next time you want to see how many times people who have added items to the shopping cart today have ordered in the past, simply open this new “Previous Orders” Counter eVar and add the appropriate metric(s):

Here we can see that 21.13% of the Cart Additions that took place today were from visitors who had not ordered on our site in the past (ignoring those pesky cookie deleters!). If we wanted, we could also break this report down by Product to see which Products they had purchased. Also, keep in mind that this example shows Cart Additions, but that we could have just as easily added Orders, Revenue, Internal Searches or any other website metric we wanted to this report to see how many orders had taken place prior to that Success Event. If desired, we could also use SAINT Classifications to group this “Previous Orders” Counter eVar into logical buckets of say “1-2 Orders,” 3-5 Orders,” “5-10 Orders,” etc…

Final Thoughts

So there you have it! Between this post and the last one, hopefully you have some new ideas to try out on your website so you can leverage past purchase behavior when doing your web analyses. If you have any questions/comments, feel free to leave them here. Thanks!

Website visits don’t occur in a vacuum.  People who are on your site today may or may not have been there in the past and if they have been there, some have purchased items and some have not.  But how do you know if the current reports you are looking at in SiteCatalyst reflect those who have purchased in the past or not?  How do you look at SiteCatalyst reports by how much they have purchased in the past?  Having this context can greatly improve the analysis you are doing so in this post, I will share some techniques which allow you to easily segment your visitors by how much they have spent in the past…

Why Do This?

Before diving into how to do this, let’s explore the rationale. Imagine that you are a retailer selling Electronics, Clothing and Furniture. One question you might ask is “I wonder how much money all of the people who are on my site today have spent in the past?” Wouldn’t it be cool to see that 25% of the people who bought something today had purchased $500 or more in prior visits? Do people who have purchased more than $700 in the past convert at higher rates than those who have only purchased $300? Do people who have bought $400 or more in Electronics tend to only buy and look at Electronics products? As you can see, there are an endless number of analytics questions that can be studied once you know how much money current visitors have previously spent.

Surprisingly, however, there is no easy way to see this in SiteCatalyst. One way to do this is to create Segments. However, since there are so many segments that could be built, this is not always an easy option. To answer the questions above, you’d have to create different segments for each dollar amount and product category (i.e. people who have spent $100, $200, $500, etc…). Plus, you’d have to pull the data using DataWarehouse or ASI. Of course, this becomes much easier in SiteCatalyst v15 (if you are lucky enough to have access to it!), but it still requires a lot of segments to be built. Therefore, I will share a different approach that you can consider to accomplish this using a Counter eVar. As a quick refresher, a Counter eVar is a type of eVar that you increment as needed and retains a numeric value for each website visitor. This counter can be incremented by “1” each time it is set, or it can be incremented by any other number as needed. In past posts, I have described using Counter eVars to track # of Pages Viewed and Ben Gaines described how to use Counter eVars to score visitors. If you want to learn more about Counter eVars, please review this old blog post.

The Solution

With the set-up and refresher out of the way, let’s dig in. As mentioned above, in this scenario, we are a retailer selling three main product categories and want to see how much money each visitor has spent prior to the current visit. To do this, in addition to setting the Products string during the purchase event, we would set a Counter eVar equal to the amount that is being purchased like this:

s.events=”purchase”
s.products=”;SKU111;1;300.00,;SKU222;1;400.00,;SKU333;1;200.00”
s.eVar40=”+900″

Notice that we have added up the purchase amount and passed it to a new Counter eVar40. In the above example, if the current visitor hadn’t previously visited the site, the value in his/her Counter eVar after this purchase would be $900. Since Counter eVars don’t have a notion of currency, the value that will be stored in the Counter eVar report in this case would be “900.00” (I would suggest that you round numbers to the nearest dollar since having decimals will make applying SAINT Classifications difficult). Keep in mind that you should set the Counter eVar to be Most Recent (Last) Allocation and set expiration to “Never” (or something like 90 days) in the Admin Console.  That is all of that we have to do from an implementation standpoint.

So now let’s see how we use this. If the above visitor comes back to the website next week and adds a few products to the shopping cart and we pause time for a second and were to look at the resulting SiteCatalyst report, we would see something like this:

As shown here, we can now answer the question of how much money visitors had spent in the past at the time they added items to the shopping cart today. In this case, it looks like about half (49%) of people adding items to the cart today had not purchased previously. The visitor mentioned above would fall into row five in this report as part of the 1.38% of people who had purchased $900 in a previous visit. The same principle would apply to Orders and Revenue, so you could see a report like this:

When you extrapolate this principle by thousands of website visitors, you can see some interesting trends about what percent of website visitors transacting today had purchased in the past and how much they had spent. Next we can make this report more readable by applying SAINT Classifications to the Counter eVar to bucket the dollar amounts spent into logical groupings:

Now we have a new report that was previously unavailable! Pretty cool, huh?

In addition, if we wanted to take things to the next level, we could break this report down by Products to see which Products made up the Revenue in past visits:

Final Thoughts
So that is one way to see how much visitors on your site have purchased previously so you can add that to your existing web analyses. Next week, I will continue with “Part II” of this topic and go into some additional ways you can apply this concept so stay tuned…Thanks!

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 product category 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!