Conversion By Placement

Let’s begin with some basic stuff. Imagine you have a website and internal search is a heavily used function. You should already be setting a Success Event for every internal search and capturing the internal search term used in an eVar (for more advanced internal search tips click here). Doing this might result in something like this:

However, as you can see, in this setup, it would be difficult to tell whether the visitor clicked on the first item in the list, the second, the third, etc.. Some of my customers want to know if it is worthwhile to have more than three or four search results at all. As you can see here, the visitor was presented with almost 38,000 search results, but how many went beyond the first five? Is less more?

To answer this question, we need to tell SiteCatalyst which position the link that is clicked was in. For example, if this visitor clicked on the second search result above (the one that goes to “www.salesforce.com/chatter”), that would be considered the second spot. What would be cool is if we could see how many Internal Searches contained a “Spot #2″ and how many Internal Search Clicks took place for “Spot#2.” If we had that, we could use a Calculated Metric to see the conversion rate of each internal search result placement.

So here is how you would do this? First, you would set the Products Variable (or if you are using v15, possibly use a List eVar with expiration set to Page View or Internal Searches Success Event) value for all “spots” that took place on the search results page. For example, if there were ten internal search results shown, the Products Variable (or List eVar) would have ten values (spot1, spot2, spot3, etc…) and each would be associated with the Internal Search Success Event. Next, when a visitor clicks on a specific item in the internal search results list, you would pass the spot# to the Products variable (or List eVar) and set an Internal Search Results Clicks Success Event. Once you have done this, you now have a list of spot values and two Success Events that are associated with each. Then you create a Calculated Metric for the Click-Through Rate (Internal Search Clicks/Internal Searches) and add it to the List eVar like this:

In this fictitious example, we can see that the items with the top-most placement spot get clicked the most. However, the most interesting aspect of this report is that the first five internal search placement slots account for almost 60% of all search result clicks! If we use the 80/20 rule, we could probably get almost the same number of internal search result clicks by having seven results as if we had hundreds.

Also, keep in mind that you can add other Success Events to the above report such as Orders or Lead Forms Completed to see how internal search spot # impacts website success.  For example, if you add Orders to the above report, you will be able to see how each internal search spot # converts by dividing Internal Search Clicks by Orders as shown in this mocked-up report:

Spots & Keywords

The next questions I get from clients when I show them this are related to the combinations of internal search keywords and search placements. For example, they want to know if a specific search phrase does better or worse based upon where it is in the internal search result list (which is often determined by algorithms). The good news is that seeing this is easy using an eVar Subrelations report (keep in mind that in SiteCatayst v15 all eVars have full subrelations!). You can breakdown the report above by internal search phrase or perform the converse by first opening the internal search phrase eVar report and breaking it down by the Internal Search placement eVar as shown here:

If you are not using SiteCatalyst v15 yet and don’t have any eVars left for which you can add Full Subrelations, you can also concatenate the search term and the spot # into an eVar to see similar information as long as you don’t have too many internal search terms.

Product List\Collection Pages

Keep in mind that this same principle can also be applied to product collection pages where you highlight a few key products on a landing page:

For example, you might see a page like the one above and want to know if items in the top-left perform better than those in the middle. Doing this is easy if you leverage the concepts above. In this case, the “spots” we discussed are not vertical, but rather go left to right and row by row. You can come up with any spot labeling system that makes sense to your organization (i.e. row1-spot1, row1-spot2, etc…).

In this case, instead of breaking down the preceding report by internal search term, you could break it down by the Products Variable to see this:

Final Thoughts

If internal search and/or product lists are important to your business, you might want to try this out and see if you can learn some good tidbits about how placement affects your conversion. If you have any questions, please leave a comment here…Thanks!

About Tealeaf

For those of you unfamiliar with Tealeaf, it is a software product in the Customer Experience Management space. One key feature that I will highlight in this post is that Tealeaf customers can use their set of products to record every minute detail that happens on the website and are then able to “replay” sessions at a later time to see how website visitors interacted with the website. While this “session replay” feature is just a portion of what you can do in Tealeaf, for the purposes of this post, that is the only feature I will focus on. In general, Tealeaf collects all data that is passed between the browser and the web/application servers, so when someone says, “Tealeaf collects everything” that is just about right. While there is some third party data that may need to be passed over in another way, for the most part, out of the box you get all communications between browser and server. Tealeaf clients use their products to improve the user experience, identify fraud or to simply learn how visitors use the website. Whereas tools like SiteCatalyst are primarily meant to look at aggregated trends in website data, Tealeaf is built to analyze data at the lowest possible level – the session. However, one of the challenges with having this much data, is that sometimes finding exactly what you are looking for is like looking for a needle in a haystack if you have an earlier version of Tealeaf (i.e. earlier than 8.x). While the Tealeaf UI has gotten better over the years and is used by business and technical users, it was not built to replace the need for a web analytical package. It is for this reason that an integration with web analytical packages such as SiteCatalyst makes so much sense.

SiteCatalyst Integration

Since SiteCatalyst is a tool that can be used by many folks at an organization, years ago, the folks at Omniture and Tealeaf decided to partner to create a Genesis integration that leverages the strengths of both products. The philosophy of the integration was as follows:

• SiteCatalyst is an easy tool to use to segment website visits, but that it doesn’t have a lot of granular data
• Tealeaf has tons of granular data, but isn’t built for many end-users to access it and build segments of visits on the fly
• Establishing a “key” between the SiteCatalyst visit and the Tealeaf session identifier could bridge the gap between the two tools

Based upon this philosophy, the two companies were able to create a Genesis integration that is easy to implement and provides some very exciting benefits. When you sign up for the Tealeaf/SiteCatalyst Genesis integration, a piece of JavaScript is added to your SiteCatalyst code. This JavaScript merely takes the Tealeaf session identifier and places it into an sProp or eVar. That sProp or eVar then becomes the key across both products. Once the Tealeaf session identifier is passed into SiteCatalyst, it acts like any other value. This means that you can associate SiteCatalyst Success Events to Tealeaf ID’s, segment on them or even export these ID’s. However, if you go back to the original philosophy of the integration, you will recall that the primary objective of the integration is to combine SiteCatalyst’s segmentation capability with Tealeaf’s granular session replay capability. This is where you will find the most value as demonstrated in the following example.

Let’s say that you have an eCommerce website and that you have a high cart abandonment rate. In SiteCatalyst, it is easy to build a segment of website visits where a Cart Checkout Success Event took place, but no Purchase Success Event occurred:

Once you create this segment, you can use SiteCatalyst or Discover to see anything you want including Visit Number, Paths, Items in the Cart, Browser, etc… However, the one thing that is difficult to see in SiteCatalyst is the actual pages the visitor saw, how these pages looked, where the user entered data, the exact messages they saw, etc… As the old saying goes, “a picture is worth a thousand words” and sometimes simply “seeing” visitors use your site can open your eyes to ways you can improve the experience and make more money! However, watching every shopping cart session would be tedious. But by using the SiteCatalyst-Tealeaf integration, once you have built the segment shown above, you could isolate the exact Tealeaf session ID’s that match the criteria of the segment, which in this case are visits where a checkout event took place, but there was no purchase. To do this, simply apply this segment in SiteCatalyst v15, Discover or DataWarehouse and you can get a list of the exact Tealeaf session ID’s that are now stored in an sProp or eVar:

Once you have these Tealeaf ID’s, you can open Tealeaf and view session replays to see if you can find an issue that is common to many visits, such as a data validation error, a type of credit card that is causing issues, etc… Here is a screenshot of what you might see in Tealeaf:

It is easy to see how simply passing a unique Tealeaf session ID to a SiteCatalyst variable can establish a powerful connection between the two tools that can be exploited in many interesting ways. The above example is the primary method of leveraging the integration, but you could also upload meta-data from Tealeaf into SiteCatalyst using SAINT Classifications and many, many more.

One additional point to keep in mind is that for many clients, the number of unique Tealeaf session ID’s stored in SiteCatalyst will exceed the 500,000 monthly limit. As shown in the screenshot above, 96% of the values exceeded the monthly limit. This means that you may have to rely heavily on DataWarehouse, which can sometimes take a day or two to get data back. It also means that you may want to consider using an sProp instead of an eVar if you have a heavily trafficked site.

The Future

In the future, we’d like to see Adobe and Tealeaf  build a deeper integration that allows SiteCatalyst users to simply click on a segment and automatically be taken into Tealeaf where they could have the same segment created in Tealeaf and begin replaying sessions. This functionality exists for OpinionLab, Google Analytics and others already. It would also be interesting if one day joint customers could use Tealeaf to assist with SiteCatalyst tagging itself. Since Tealeaf has all of the data anyway, why not use this, combined with SiteCatalyst API’s to populate data in SiteCatalyst instead of using lots of complex JavaScript? Currently, the cost of API tokens make this cost-prohibitive, but technically, there is no reason this cannot be done.

Final Thoughts

So there you have it. If you have both SiteCatalyst and Tealeaf, I recommend that you check-out this integration and think about the use cases that might make sense for you. Also keep in mind that similar integrations exist with other vendors that offer “session replay” features like ClickTale and RobotReplay (now part of Foresee).  If you have any detailed questions about the Tealeaf integration, feel free to reach out to @solanalytics.

However, there are cases where I can see why having real-time data would be interesting.  Specifically, cases where you are running a social media, radio or TV campaign that is driving people to your website and you want to see how many people are coming NOW!  The main reason I see clients do this is not to act upon the data in real-time, but rather, so they can go back and attribute specific spikes in data to money being spent in social media, radio or television advertisements.  For example, let’s say that you show a TV ad locally in New York City at 8:15 p.m. EST on Tuesday night. It would be cool to see how the website lights-up in the New York area around that time.  In the past, companies like ChartBeat were available to see this, but now you can do it for free using Google Analytics.

Since this real-time capability launched in GA, some of my Omniture followers have asked me if it is possible to see real-time data in SiteCatalyst. Therefore, in this post, I will share what is and what is not possible today.

SiteCatalyst Real-Time Analytics (Sort Of…)

Unfortunately, the exact functionality that GA has just released does not yet exist in the traditional SiteCatalyst interface.  Surprisingly, after a quick check, I didn’t see that anyone has ever requested this in the Ideas Exchange.  However, what I can offer you is the next best thing.  What I have worked with clients to do, is to pass minute-level data to SiteCatalyst variables so that you can at least look back in time and see the times at which traffic spiked. In my last blog post, I described a similar topic in which we passed a Date to an eVar and an sProp.  In that scenario, we passed the date on each page of the visit. This is similar to using the Time Parting plug-in which passes in the time in 30 minute increments.

In order to see minute level data, what I am going to suggest here is that you capture the date and time (down to the minute) to an eVar or sProp on the 1st page of the visit.  This will allow you to associate all website behavior to the date and time at which the visit started. This can be done via JavaScript or via a VISTA Rule.  Here is what a sample report would look like:

As you can see, this report is pretty granular, but if you know the date and time you are interested in, you can pull the data down to Excel and sort by date/time to see spikes in traffic by the minute.  In the example below, we can see that a spike in Form Completions occurred at 8:15 P.M. precisely when the local television spot ran:

Since you have this data in an eVar, you can see any of your Success Events (like Internal Searches shown below) by minute in SiteCatalyst:

Again, it won’t help you at the minute these things are happening due to the lag in data appearing in SiteCatalyst, but it will allow you to look back an hour or two later to see the impact of an advertising campaign so you can adjust future ones.

One other note on this, As Kevin W from Adobe mentioned, you shouldn’t go lower than the minute when doing this.  In a normal month, minute-level data should produce at most 45,000 unique values per month which is del below the 500,000 SiteCatalyst can accept.  If you go beyond that (to the seconds level), you are looking at over 2.5 million unique values which is not ideal for SiteCatalyst. Technically, you could do it and just use the data in DataWarehouse, but I don’t recommend it.

So that is a quick tip that you can use if you need to do historical reporting down to the minute in SiteCatalyst.  If you feel you need real-time reporting in SiteCatalyst, feel free to add it to the Ideas Exchange.

This functionality is cool since you can use it to limit your population to folks who took some action in a specific time period and then observe their subsequent behavior across a future time period. Another example might be the desire to see purchase behavior of people in Q4 who looked at products in Q3.

However, the challenge facing this client is that very few people in the organization had access to Discover so they wanted to have the ability to apply this date-based segmentation to their SiteCatalyst reports to which everyone had access (and take advantage of the new v15 segmentation capabilities).  I hadn’t thought about doing this in SiteCatalyst due to its segmentation limitations (see below), but after contemplating a bit, I came up with a cool trick that should allow SiteCatalyst users to take advantage of this Discover functionality.  If this is of interest to you, please read on…

Date Stamp Variable
In order to build a segment that crosses multiple visits, the obvious starting point is the Visitor container within SiteCatalyst’s Segmentation tool.  If you want to select a Visit in one time frame, but look at data for another time frame, you will need to use a Visitor container and nest a Visit container and/or Success Event container within it.  In the preceding example, we would want to create a Visitor container, but nest a Visit container within it in which the visitor had a Visit where a Form was completed in a specific week of the month of January. Sounds easy right?

Unfortunately, it isn’t as easy as you’d think, because there is no way to segment on a date or month within SiteCatalyst like you can in Discover. Therefore, the trick is to pass the date to a SiteCatalyst variable within each Visit.  I suggest you add one new eVar and one new sProp and set the date on every page. In addition, you can easily create a SAINT Classification for each date which rolls these dates up into weeks, months or years as needed.

Once we have set the date to a variable, let’s see an example of how we would create the aforementioned segment from within SiteCatalyst.  First, we grab the Visitor container, then we nest a Visit container and within that Visit, we nest a Form Completion Success Event.  To narrow down the Form Completion to a specific week in January, we can use our new Date Stamp variable (eVar or sProp version):

Of course, as I mentioned earlier, it may be easier to classify these variables and segment on them by week or month.  This process would be identical to the segment shown above, but instead, would use a Classification of the Date Stamp variable.  Here is an example of a SAINT Classification of the Date Stamp variable:

If you’ve read my past blog posts, you will soon realize that this trick is similar to the Time-Parting plug-in I described years ago. In fact, it is really just a variation on that, but without the time of the day.  However, limiting the values to just the date makes the data much more manageable and more easily classified.  The use of this, plus segmentation allows you to mimic what has been possible in Discover for a while so if you have lots of SiteCatalyst users, give this workaround a whirl…Enjoy!

Multi-Suite Tagging Review
As a quick refresher, if you have multiple websites, it has traditionally been common to send data to more than one SiteCatalyst data set (known as report suites). The benefits of this multi-suite tagging were as follows:

1. You could have different suites for each data set (i.e. see Spain data separately from Italy data)
2. If you sent data to many sub-suites and one global (master) report suite, you could see de-duplicated unique visitors from all suites in the global report suite
3. If you wanted to, you could see Pathing data across multiple sites in the global report suite to see how people navigate from one website to another
4. You could create one dashboard and easily see the same dashboard for different data sets in SiteCatalyst or in Excel
5. You want to see metrics at a sub-site level, but also roll them up to see company totals in the global report suite

As you can see, there are quite a few benefits of multi-suite tagging and most large websites tend to do this as a best practice. Of course, where there is value, there is usually a cost! Since you are storing twice as much data in SiteCatalyst, our friends at Omniture (Adobe) have always charged extra for doing this, but normally these “secondary server calls” are charged at a dramatically reduced rate.

Along Comes Instant Segmentation
However, once SiteCatalyst v15 came out, it brought with it the ability to instantly segment your data. Suddenly, you have the capability to narrow down your focus to a specific group of visitors. Therefore, many smart people started asking themselves the following question:

“If I track the website name on every page of every one of my websites, why can’t I just send all data to one global report suite and build a segment for each website instead of paying Omniture extra money to collect my data twice through multi-suite tagging?”

If you look at the list of multi-suite tagging benefits above, you can see that you can accomplish pretty much all of them by simply creating a website segment. For example, if you currently pass data to a global report suite and an Italy report suite, you could simply pass the phrase “Italy”  or “it” on every page and build the following Italy segment:

Doing this would narrow the data to just Italy traffic and you don’t have to pay Omniture any extra money! Most clients I have spoken to are very interested in this concept since it will allow them to move some budget to other things they might need (like more analysts or A/B Testing). I think many companies are taking a “wait and see” attitude to this while they get comfortable with SiteCatalyst v15. However, I expect that in the next twelve months, many large enterprises will decide to go this route in order to save a little money and simplify their implementations (one can only dream about not having to keep 50-100 report suites consistent in the Admin Console!). To date, I have not heard Omniture’s stance on this, but I expect that they are not opposed to companies doing this, but will probably not broadcast this concept too loudly since they will lose some recurring revenue as a result.

Any Downsides?
While it is still early days for SiteCatalyst v15, I have tried to think about what, if any, the downsides might be from throwing away multi-suite tagging in favor of an instant segmentation approach. While I hate to rain on the parade of those who want to move forward with this, I have found a few potential downsides that I think you should consider. I don’t think any of these will dissuade you, but I like to present both sides of the story so you can make an informed decision!

The first downside I can see is that moving to one global report suite will make the creation and usage of segments inherently more difficult. For example, let’s say that you create an Italy segment as shown above. That works well if you are in Italy and want to see all Italy traffic. But what if you are in Italy and want to see all first time visitors from a specific list of keywords who have abandoned the shopping cart. That is a semi-complex segment and you have to be careful to include the Italy part of the segment at the same time! Creating segments is tricky enough, but if you use segments to split out countries (or brands), you have to build even more complex segments to take these into account. Should you use an AND clause, an OR clause, combine Visit containers, use a Visitor container, etc? These are tricky questions for everyday end-users, while having a separate report suite (data set) for each country allows you to simplify your segments and just segment within that report suite and not worry about the additional country container. For advanced SiteCatalyst users, this nuance shouldn’t be a showstopper, but it can definitely trip up novice users and is something that should be considered.

The next downside is the loss of the ability to compare websites using the “Compare to Site” feature. In this post on comparing data based upon dates and sites, I showed how you can look at a specific report (say conversion by day of week) and compare the US to Italy. This is a very handy feature when you have multiple geographies or multiple brand websites. Unfortunately, if you choose to abandon your multiple report suites and rely on v15 segmentation, you will lose this capability. This is due to the fact that SiteCatalyst v15 does not allow you to compare two segments in a comparison report (yes I know you can do this in Google Analytics!). I think this was a big oversight in SiteCatalyst v15 and hope people will vote for it in the Idea Exchange. In the past, even if you didn’t have multiple report suites, you could create ASI segments and add these to comparison reports, but alas, ASI segments have been removed from SiteCatalyst v15 due to the new instant segmentation capabilities. Therefore, if you feel that you will want to look at reports side-by-side for different segments, you are currently out of luck (unless you have Discover).

The last downside is just the inherent complexity that comes with building segments. When I was at Salesforce.com we had some pretty intense segments and at times, we doubted whether SiteCatalyst was always moving the right Page Views and Visits to the right data sets. If you get rid of your individual report suites and rely on just one global suite, you are doubling down on SiteCatalyst’s segmentation capabilities, and have no way to check if they are working properly. At a minimum, I recommend that you keep your multi-suite tagged suites around for a while while you implement your segments and compare the traffic and metrics until you feel confident that the data matches. However, keep in mind that once you turn off your old report sites, you will no longer have a baseline to which you can compare your segments so you better make sure they are right!

Final Thoughts
So there you have it.  Some of my thoughts on this monumental decision that many large SiteCatalyst customers will have to make over the next year. What do you think? Will you take the plunge? Have you thought of any other benefits and/or downsides of making the switch? If so, leave a comment here…

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!

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!

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!

• Simplifies the process of making Campaign tracking codes (SAINTBernard Pup)
• Allows you to work with outside partners/agencies on creating Campaign tracking codes (SAINTBernard Pup)
• Automates the process of adding SAINT Classification data to campaign tracking codes (SAINTBernard Pup)
• Provides a cool interface for updating massive amounts of SAINT Classification data including the ability to filter/sort massive amounts of SAINT data

I applaude Omniture for finally providing some much needed enhancements to things like SAINT Classifications, which power users spend lots of time updating and wrestling with (you knew it was bad when the @SAINTHamsters Twitter account began!).  It looks like a great tool and I am sure many Omniture clients will like it.

However, this post isn’t really about this particular SAINTBernard tool.  I heard about the tool and recommended that one of my clients check it out only to discover that the pricing of the SAINTBernard tool was (in my opinion), pretty steep.  I had expected the tool to be priced based upon API calls (which Omniture charges for and seems fair), but from what I heard, it has a fixed set-up and an annual maintenance fee (I am not going to share the actual costs so don’t ask me!).  When I found this out, I was a bit frustrated.  While I can imagine that a significant amount of work went into making this tool, as a SAAS company, I have come to expect companies like Omniture and Salesforce.com to periodically update products as part of the annual license agreement.  In fact, Omniture recently released its v15 version of SiteCatalyst, which contained a massive amount of improvements including an entirely new back-end architecture to allow for instant segmentation!  I assume that much more work went into v15 than did SAINTBernard!  How much did upgrading to v15 cost customers? Nothing!  You keep paying what you have paid and you get new features, as it has been since I started using SiteCatalyst (version 9.x).

I can see when Omniture develops new products like SearchCenter or SocialAnalytics, that it is reasonable to expect that you will have to pay for those additional products.  That makes sense to me, but as I thought about SAINTBernard, it does add some awesome new functionality and will definitely save people time, but I don’t feel like it should be considered another separate thing you have to pay for (beyond server/API calls).  The truth is that SAINT is a feature that hasn’t been updated in several years and was due for some improvements, but I am not sure why SiteCatalyst customers should have to pay extra for those improvements.

So why does SAINTBernard come with an extra surcharge?  Having been an Omniture employee in the past, I think I know the answer.  There are some things that are built into SiteCatalyst by the Product team and there are some things that are developed one-off by Engineering Services.  I suspect that the improvements contained within SiteCatalyst v15 were from the product team, and that things like SAINTBernard originated from Engineering Services. Now let me get one thing straight – I LOVE the Engineering Services team!  They are amazing folks who build and do incredible things.  I want them to keep building tools like this, but I think it is confusing to SiteCatalyst customers as to why some features come for free and others cost money. In my opinion, the litmus test for free vs. paid features should not be which department the person writing the code belongs to.  The normal SiteCatalyst customer doesn’t care if code is developed by the Product team or Engineering Services.  As was seen recently by the Qwikster/Netflix debacle, when you expose your internal organizational departments at the expense of your customer’s point of view, it annoys people.  I hope that the Omniture product folks will keep this in mind and figure out a way to provide the awesome functionality we SiteCatalyst customers want, but in a way that is seamless to the customer.  If you don’t do this, it can be perceived as “Nickel and Diming” your customer, and no one likes that.  Just because you can charge for something, doesn’t always mean you should.

That’s just my opinion, but what do you think?  Am I wrong?  Are you happy to pay “a la carte” for cool new SiteCatalyst functionality?  If so, how much would you pay Omniture for SAINTBernard (as an example)?  Please leave a comment here or add your thoughts on this Google+ thread.  Thanks!

Therefore, we are looking to capitalize on this momentum and are already planning our next ACCELERATE events for 2012. Since we had many people register from outside the San Francisco area, we’d like to get your input on where we should have the next series of events.  Please click on the link below and fill out the form to indicate your interest and city.  While we can’t make any guarantees, we will use the responses we get to help us plan our next events.

We encourage you to use Twitter, LinkedIn, Facebook, Google+ and E-mail to spread the word to folks in your city so you can increase the chances of us making it our next ACCELERATE venue (“I think #ACCELERATE 2012 should come to _____ in 2012! #measure”).  We will also give special consideration to the comments you add to the form as to why you think your town would be a good spot for us to host the event!

As always, thanks for your support and we look forward to seeing you at one of our events in the near future!

Eric, John & Adam