Analytics has the potential to be incredibly powerful for businesses. However, companies sometimes don’t know where to start, or how to take advantage of the capabilities of their digital analytics solutions.

From just getting started with the basics, through advanced segmentation, mobile, attribution, predictive analytics and data visualization, here are a few of my favorite tips for how to do more with your digital analytics program.

Click to download my free Analytics “Tips and Tricks” whitepaper (sponsored by Adobe.) 

Regardless of what type of website you manage, it is bound to have some sort of conversion funnel. If you are an online retailer, your funnel may consist of people looking at products, selecting products, and then buying products. If you are a B2B company, your funnel may be higher-level like acquisition, research, trial and then form completion. Many of my clients want to model their conversion funnels in Adobe Analytics (SiteCatalyst) so they can se where visitors fall, in what percentages and how these buckets change over time. Unfortunately, this isn’t one of Adobe Analytics’ strong suits. In this post, I will share why the out-of-box conversion funnels are not ideal and how you can use segmentation to help build your conversion funnels.

Conversion Funnel Report

As I described in my old blog post on Conversion Funnels, the Conversion Funnel report is merely a graphical representation of whatever Success Events you happen to add to the report. This works if you have discrete Success Events related to each of your conversion funnel steps, but it does not show you what percent of your population is currently at each step of the funnel. For example, if I visit an online retail website, view a product, then add a product to cart (Cart Add Success Event is set) and then order a product (Purchase Success Event is set), the conversion funnel would have a value of “1” for me in each of the rows of this conversion funnel report:

While this may be useful in the context of seeing what percent of visitors make it through each step of the funnel, what if my question is “What percent of my population reached a specific step in the overall conversion funnel this week or month versus last week or month?” In this situation, the out-of-the box conversion funnel report can show you a time-based comparison, but as I will show later, this doesn’t give you the full picture:

In the next section, I will show you how segmentation can be used to improve upon this…

Using Segments to Create Funnel Populations

To address the aforementioned questions in Adobe Analytics, it is best to use the segmentation features of the product. Using segmentation, you can place each website visit (or visitor) into one of your high-level conversion funnel buckets and then create a different type of funnel in Excel using the ReportBuilder tool. First, you have to identify what criteria you are going to use to determine if a visit is in bucket #1, #2, etc. In this case, let’s imagine that you work for a B2B company and that your first bucket is “Awareness” and it is defined as people who have come to your website, but never seen a product, attempted to download a trial of it or purchased it. The second conversion funnel bucket is “Researchers” and this includes visits where people have looked at one or more products (or clicked on demos/videos and other product-related actions), but have not added a product to the cart or purchased (or filled out a lead form if online purchase is not possible). The third conversion funnel bucket is “Interested” and this includes visits in which people have either added to cart of filled out a lead form, but have not purchased (if available online). Our last conversion funnel buckets is our “Buyers” who have successfully purchased a product or committed to the product in some way (if purchase is not available online).

With these four conversion funnel buckets in mind, your next step is to subdivide all of your visits (or visitors) into one of these four buckets. While this may seem easy, it is actually a bit tricky, because you have to make sure that the same visit is not present in more than one bucket. Doing this requires some fancy Adobe Analytics segmentation skills. To create the first conversion funnel bucket, you would want to create a Visit segment that excluded any visitors who had viewed products, added products to the cart or purchased:

Next, we want to create our Researchers segment for visits that viewed products (you can also add other research events here with an “OR” clause), but excluding visits where a cart addition or order took place:

Next, we want to create our Interested segment for visits that added products to cart (you can also add things like lead form completions here), but excluding visits where an order took place:

Finally, we have our Buyers segment to see visits where visitors completed an order:

If you add up the various Visit counts in the above segments, you can see that they are mutually exclusive and add up to the total 40,089,255 showing in the segment preview area. This is a quick way to verify that you have built your segments correctly.

Applying Conversion Funnel Segments

Now that you have your conversion funnel segments defined, there are many ways you can use them. First, you can apply each segment to see any report for visits at that stage of the conversion funnel. For example, you could look at what internal search phrases are used by Researchers vs. Awareness folks. You could view the different pathing behaviors by conversion funnel segment or see what campaign codes drove each type. But the most interesting thing you can do (in my opinion) is to create a conversion funnel report in Microsoft Excel using ReportBuilder. For example, if you were to build a Visits data block with the “Awareness” segment applied, you would be looking at Awareness visits for the specified date range. Then you could do the same thing for the other three segments and then trend the percentages over time. Once you have separate data blocks, you can use formulas to combine them into a percentage-based conversion funnel and see the progression over time like this:

In the preceding example, there is not much of a spread when it comes to the last two funnel steps, but if we use some different [fake] data, let’s see how cool the reporting of this might look:

What I like about this type of analysis, is that it provides an opportunity to see where YOUR website problems lie. Every website is different. Some websites are great at getting top of funnel visitors to get to stage three or four of the funnel, but then they struggle to get them across the finish line. Others are the opposite in that they don’t get many people to stage two or three, but when they do, they convert very well. Knowing where your website’s problems lie, allows you to identify practical ways to improve your funnel. This can be done by focusing your testing and design efforts in the right places, instead of wasting time in areas where your website is doing well. As you can see, this is a different type of approach to conversion funnel analysis, but one that I think can help your organization better understand how visitors are flowing through your conversion path at a high level and provide benchmarks of this over time. If you already have most of your key conversion funnel KPI’s set, then this solution requires no tagging, just the creation of some new segments, so there is no reason to not give it a try!

In one of my recent Adobe SiteCatalyst (Analytics) “Top Gun” training classes, a student asked me the following question:

When should you use a variable (i.e. eVar or sProp) vs. using SAINT Classifications?

This is an interesting question that comes up often, so I thought I would share my thoughts on this and my rules of thumb on the topic.

Background Information

As a refresher, SiteCatalyst variables like eVars and sProps are used to store values that break down Success Events and Traffic Metrics respectively. For example, if you have a metric for onsite searches, you should be setting a Success Event and if you want to see that Success Event broken down by onsite search phrase, you might use an eVar to see the number of onsite searches by search phrase. SAINT Classifications allow you to apply meta-data to eVars and sProps so you can collect additional data or group data values into buckets. For example, you might use SAINT Classifications to group onsite search phrases into buckets like “Product-related terms” or “SKU # terms,” etc…

However, there are many cases in which you have a choice to capture data in a variable (eVar or sProp) or to use a SAINT Classification. Let’s look at an example to illustrate this. Imagine that you have a website and many of your customers have a Login ID that they use prior to ordering products. You are passing the Login ID value to an eVar so you can see all of your Success Events (i.e. Searches, Orders, Revenue) by Login ID in your SiteCatalyst reports. One day your boss approaches you and says that she wants to see your website KPI’s by the City visitors live in and that City is one of the attributes your back-end folks have related to each Login ID. At this point, you have two choices, one is to have your IT folks pass in the City to a new eVar using the Login ID value (if they can’t do this in real-time you could also pass this to SiteCatalyst via DB VISTA). The other option is to upload the City value for each Login ID as a SAINT Classification of the existing Login ID eVar. Both of these options would meet the objective of your boss, but which one is the right approach?

If I were a betting man, I would guess that most of you mentally chose option#2 which treats City as a SAINT attribute of the Login ID eVar. Does that sound right? Why not? It saves you tagging work and helps you avoid working with IT, which usually has delays associated with it. However, would it surprise you to know that I would NOT choose option #2 in this case, and instead would pass the City to a new eVar? Before I tell you why, let me review some of the things I consider when making a decision like this:

Advantages of SAINT Classifications

• Conserves Variables – One of the key advantages of using SAINT Classifications is that they allow you conserve variables, especially eVars, which tend to run out before any others
• No Tagging Required – SAINT Classifications don’t require additional tagging
• Retroactive – SAINT Classifications are retroactive so if you mess up when assigning a value, you can always fix it later by simply updating the SAINT data or fixing your rules if using the SAINT Rule Builder. For example, if you incorrectly assign a campaign tracking code to a Campaign Name, you can easily updated this after the fact. If you had passed the campaign name to an eVar, there wouldn’t be much you could do to fix historical data. However, the retroactive nature of SAINT Classifications can also be a negative at times (more on this later)

Advantages of Variables

• Data Stored Forever – Once you pass data into a variable (eVar or sProp), it is there forever (for better or worse). This is useful if you want to forever document the value at the time a KPI took place
• sProp Pathing – If you are passing data to an sProp, you can enable Pathing on the variable to see the sequence in which values were collected. Unfortunately, Pathing is not available on SAINT Classifications in Adobe Analytics (though it is in Discover, now known as Ad Hoc Analysis)
• Data Feeds – Many companies use Data Feeds to export Adobe SiteCatalyst data to other data warehouses and Data Feeds only contain data that is organically passed into SiteCatalyst, which excludes SAINT data

As you can see, there is more than meets the eye when it comes to deciding which approach you should use when collecting data. Do you need data in a Data Feed? Do you need Pathing? Do you need to be able to update values after the fact? For each situation, I find the preceding items to be a useful checklist to keep handy.

And Now Back To Our Story…

So now that you have seen my list of considerations, can you see why I suggested using a new eVar for City in our scenario? In this case, the item I focused on was the retroactive nature of SAINT Classifications. In this case, if you were to treat City as a SAINT Classification of Login ID, things would probably work out ok initially, but might have issues in the long run. Let’s say that Adam Greco visits your site, logs-in using ID#12345 and then completes an order for $200. At some point you have uploaded a SAINT file that correctly associates Adam’s Login ID with the city of Chicago. At this point, you can use the SAINT Classification “City” report to pivot the data and see an order of $200 for the city of Chicago. However, now let’s imagine that Adam decides to move to San Francisco (something I have done twice in my life!). Your back-end data would at some point learn that Adam has changed cities, and the next time you upload your SAINT file, Adam’s Login ID will be associated with San Francisco. Since SAINT Classifications are retroactive, this will have the impact of changing all activity associated with Adam’s Login ID to look like Adam has always lived in San Francisco, even though all of his KPI’s to date were done in Chicago. This means that your “City” report is inaccurate since it is inflating metrics for San Francisco and deflating metrics for Chicago (and for those who say that the answer is to use Date-Enabled SAINT Classifications, I wish you luck as I have never seen a company have the time to keep those updated!).

This scenario shows why it is so important to review my list of considerations above. While it is a shame to have to waste an eVar for City, in this case when you can make an association between Login ID and City, using a new variable may be the right thing to do if you want to see what City the Login ID was associated with at the time that the KPI took place and lock that value in forever. In my experience, the retroactive issue is the one that I see companies make the most mistakes with and many don’t even know that they have made a mistake until I point it out to them. Therefore, I will share another rule of thumb I have learned over the years:

Consider whether the data attribute is inherent to the eVar/sProp value or whether it can change. If meta-data is inherent to the value being classified or it can change and it won’t disrupt your data, use SAINT Classifications. Otherwise, use a new variable. When I say “inherent,” I mean that it will most likely not change. For example, if one attribute you have for Login ID is “Gender,” there is a strong likelihood that this can be a SAINT Classification, since it is unlikely that this value will change for each Login ID (outside of a very complicated surgical procedure!). Another example might be birth date which will never change for each Login ID. However, if you have a loyally program and treat different Login ID’s as Basic, Gold or Silver members, that can easily change over time, so that would be a candidate for a new variable so you are documenting their status at the time that the KPI took place.

As you think about how many attributes you may currently be incorrectly storing via SAINT (it happens to the best of us), you may wonder how you will have enough variables to capture all of these attributes. Keep in mind that just because I am suggesting that you set variables instead of using SAINT for data that is affected by retroactivity, it doesn’t mean that you need to store each of these data points in their own variable. For example, if you decide to capture Member Status, City and Zip Code as variables instead of SAINT Classifications of Login ID, if they are all available on the same page (server call), you can concatenate them into one eVar (i.e. Gold Member|Chicago|60603) and then apply SAINT Classifications to that eVar. In this case, you are still capturing the actual value you need to make sure you are not burned by the retroactive nature of SAINT Classifications, but you can conserve eVars by capturing multiple values in one eVar and splitting out the data using SAINT later. In fact, if you capture the data in a methodical manner, you can even use RegEx in the SAINT Classification Rule Builder to do this automatically.

Final Thoughts

So there you have it. Some things that you should consider when deciding whether you should use a new variable or SAINT Classifications when collecting new data attributes in your Adobe SiteCatalyst (Analytics) implementation. If you would like to learn more tips like this about Adobe SiteCatalyst, consider attending my Adobe SiteCatalyst “Top Gun” training class. Thanks!

As I have mentioned in the past, one of the Adobe SiteCatalyst (Analytics) topics I loathe talking about is Product Merchandising. Product Merchandising is complicated and often leaves people scratching their heads in my “Top Gun” training classes. However, many people have mentioned to me that my previous post on Product Merchandising eVars helped them a lot so I am going to continue sharing information on this topic. In this post, I will delve into some more advanced concepts related to Product Merchandising. If you have not read my other Product Merchandising post, I suggest you do that before attempting to digest this one!

eVar Allocation

When it comes to Conversion Syntax Merchandising eVars, I see many clients make mistakes with allocation. As a refresher, allocation is an Admin Console setting in which you tell SiteCatalyst if the eVar should use the first value it receives or the most recent value it receives, if multiple values are present prior to a success event taking place. For traditional eVars, it is common to use “Most Recent” allocation as a way to ensure that the most recent value passed gets credit for all future success. However, Conversion Syntax Merchandising eVars are a bit different in that this allocation is set at the product level when the Merchandising eVar value is “bound” to the product at the specified binding event(s) dictated in the Admin Console. This means that the Allocation setting is not actually for the current eVar value, but rather, for the eVar value and product combination.

Since that can be confusing, let’s look at an example. Suppose that a visitor comes to your website and conducts an internal search for “books.” You have an internal search phrase Merchandising eVar so you can see which phrases lead to each product being purchased. So in this scenario, the visitor has searched for “books” and adds Product #100 to the cart. Now, if the same visitor searches for “novels” and adds a different product to the cart (say Product #200), it doesn’t really matter if you use “Original Value (First)” allocation or “Most Recent (Last)” allocation for the Conversion Syntax Merchandising eVar since there are two different products involved and allocation is tied to the binding event of products and eVar values. However, in the unique case in which the same visitor searches for “novels” and finds the same product #100 and decides to add it to the cart a second time, you have to tell SiteCatalyst which eVar value (“books” or “novels”) should be “bound” to Product #100. In this scenario (which admittedly may not happen too often), most clients have indicated that they would like to attribute success to the first search term for product #100 vs. the second search term that led to the same product, since it was the original way they discovered the product. The allocation setting you make (Original or Most Recent), will determine which eVar value gets credit for if the same product is used more than once (product #100 in this example). Therefore, most people decide to use “Original Value (First)” as the allocation method for Conversion Syntax Merchandising eVars.

Fake Products

The next tricky thing about Conversion Syntax Merchandising eVars has to do with non-Order/Revenue success events. As you would expect, since it is their primary purpose, Conversion Syntax Merchandising eVars do a great job of making sure that each product has its own eVar value when it comes time for the purchase event such that each eVar value is correctly associated with the right product. However, there are cases in which you will want to use eVars for more than just the purchase event (Orders, Revenue, Units). For example, if you think back to the preceding example of internal search, besides storing the internal search phrases to associate with products upon purchase, you may also want to see something more basic, like how many internal searches took place for each search phrase. In that case, you would set a success event each time an internal search takes place, and you would already be setting the Conversion Syntax Merchandising eVar with the search phrase (i.e. “books”). Naturally, you would expect that if you add the internal searches success event to the internal search phrase Merchandising eVar report, you would see the number of searches taking place by phrase. Unfortunately, you would be wrong. What you may not know, is that Conversion Syntax Merchandising eVars only associate values with success events when the Products Variable is set or when binding has already occurred. Of course, you can set the Merchandising eVar anytime you want, and it will store a value, but it will not associate that value with success events unless a product value is passed to the Products Variable. I believe the reasoning here was that Merchandising was meant for products, so the two go hand-in-hand.

So what do you do if you want to use the same Conversion Syntax Merchandising eVar to both associate eVar values to products and as a way to breakdown custom success events by its values (like a traditional eVar)? You have two choices. The first option is to set two eVars – one with Merchandising and one without. In this example, you would have two internal search phrase eVars and just have to label them correctly (i.e. Internal Search Phrases-Merchandising & Internal Search Phrases). The other option is to set what I call a “fake” product. By passing in a “fake” product when setting a custom success event, you can trick Adobe SiteCatalyst into associating an eVar value with the custom success event. The process of setting a “fake” product is not very difficult and can be automated using some basic JavaScript code. The key is to increment the fake product by one each time it is set, so that SiteCatalyst doesn’t see the same product twice for the same visitor.

This is best illustrated via an example. Let’s continue with our internal search example, only this time, in addition to seeing how many times each internal search phrase leads to orders & revenue, you want to have a custom internal searches success event and be able to break it down by internal search phrase. The way most companies attempt to accomplish this is by using a success event and eVar code like this:

However, doing this will yield some undesirable results. Here is what a report of this eVar might look like in SiteCatalyst:

You will notice an abnormally high “None” percent in this report, which represents cases in which there was no association between the eVar value and the Internal Searches success event. Since it should be impossible to have an internal search event with no internal search phrase, you would expect to have no values in the “None” row for the internal searches success event (since most companies will still populate a value of [blank search] or something similar if users search with no phrase). The “None” value for Orders is fine, since that represents cases in which no search phrase was used prior to the order.

To rectify this, you would add the “fake” product to your code so it looks like this:

Setting this “fake” product allows SiteCatalyst to set the Conversion Syntax Merchandising eVar value at the same time that event 10 (Internal Searches) is fired, so you can see one internal search for “books,” while still keeping the Merchandising eVar5 value ready to bind to a “real” product at the time of your selected binding events (normally Cart Addition and Product View). Using this code results in a more accurate report when viewed with the custom success event, which in this case is the internal searches success event:

You may also notice that the “fake” product used is a value and then a number. You can make the “fake” product any value you’d like, but most people tend to label it in a way that indicates what event was taking place. In this case, I named it “intsearch1” since the “fake” product had to do with internal search. If the “fake” product had been done as a result of an internal campaign eVar, I might have named it “intcampaign1” instead. However, it is important to note that you need to increment the “fake” product value (i.e. intsearch2, intsearch3, etc…) so that the same value is not used more than once by the same visitor. Using the same “fake” product value for all cases (every search term in this example) would negate the power of Merchandising, which is designed to attribute different values to different products. The only exception to this is a scenario in which the visitor intentionally uses the same value (i.e. searches on the same search keyword in this scenario), and in that case you would want to re-use the same “fake” product value whether the duplicate value happened sequentially or after another “fake” value has been passed. It is also important to remember to add the success event that you want to use this eVar with to the list of “Binding Events” in the Administration Console. In this case, you would add the Internal Search success event to the previous list of Binding Events (i.e. Cart Addition and Product View).

Note that this “fake” product workaround only has to be used when all of the following conditions are true:

1. You are using a Conversion Syntax Merchandising eVar
2. You want to see that Merchandising eVar’s value associated with a success event other than Orders, Revenue, Units
3. You are not setting the Products variable with a value at the time the success event is being set (this is why none of this applies to Product Syntax Merchandising eVars)

This means that you only really need to worry about this in cases where you want the Conversion Syntax eVar to do double-duty. I have found that the following situations are the main times I need this work-around:

• Internal Search Phrase eVar and Internal Searches success event
• Navigation Element Clicked eVar and Navigation Link Clicks success event
• Internal Campaign eVar and Internal Campaign Clicks success event
• Product Filter Element eVar and Product Filter Clicks

Final Thoughts

As I mentioned at the outset, Product Merchandising is a bit tricky and the detailed items here around Conversion Syntax can be even trickier. I have learned that there are some things that you just have to memorize when it comes to Adobe SiteCatalyst and this post covers a few of them.

Do you want Adam Greco to review your company’s Adobe Analytics implementation and show you how to get the most out of the product?  Many companies are only using a fraction of the functionality offered by Adobe and/or have major flaws in their implementation.  Click here to learn more about having Adam audit your Adobe Analytics implementation.

One of my newest clients is in a highly competitive business in which they sell similar products as other retailers. These days, many online retailers have a hunch that they are being “Amazon-ed,” which they define as visitors finding products on their website and then going to see if they can get it cheaper/faster on Amazon.com. This client was attempting to use time spent on page as a way to tell if/when visitors were leaving their site to go price shopping. Unfortunately, I am not a huge fan of time spent on page, since a page could have wide varieties of time spent on page due to many other reasons other than price shopping (i.e. working, going to the bathroom, yelling at kids-in my case, etc.). Because of this, I wanted to come up with an alternative way to see if price was a potential reason for lost business. However, before I share my idea, I want to add a disclaimer that there is no [legal] way to really know if people are leaving your site to buy something elsewhere due to price, but the technique I will show may shed some light on how pricing impacts your conversion rates.

Competitor Pricing – Step 1

The first part of my competitive pricing solution requires that for some or all of your products (SKU’s), you have detailed competitor pricing. Many of my clients have teams that are constantly monitoring competitive websites and documenting the current prices for some or all of their products. If your organization doesn’t have this, my solution will not work (so you can stop reading now!). If you do have this information, you will need to create a spreadsheet that has your product ID’s (values passed to the Products Variable) and your competitors’ price in the next column. If you have multiple competitors, you can add a new column for each one:

Next, you will have to talk with your Adobe Account Manager to create a new DB Vista Rule. As a refresher, a DB Vista Rule allows you to populate SiteCatalyst variables with values from a database lookup table stored on Adobe’s secure servers. This will allow you to pass in the competitor price for each product viewed and added to cart on your website via a server-side lookup. The Adobe Engineering Services team can walk you through how to upload the competitor prices to DB Vista and how to updated it over time. Keep in mind that you will need to have a process in place that updates competitors’ prices as they change, preferably within the hour so your data is accurate. This is often done by FTP’ing changes on an hourly basis. Creating a DB Vista Rule will cost you a one-time fee of a few thousand dollars, but that you can maintain it yourself thereafter. If you want to save some money, you can ask your internal developers if they can ping a similar competitor cost table in real-time as visitors are on your site, but in my experience, the work effort around that is much more than the cost of the DB Vista Rule.

Competitor Pricing – Step 2

Once you have a way to send competitor prices (by Product ID) into SiteCatalyst, where should it go? What I propose is that you pass the Product ID, your price and your competitors’ price, concatenated in a string to a new Conversion Variable (eVar). Since your visitors may view multiple products, you will also want to make this a Merchandising eVar using Product Syntax. I recommend that the data be passed when visitors view the product detail page or add a product to the shopping cart. For example, if a visitor views SKU # 10010100 and your price is $30.00 and your competitors’ price is $29.50, you would pass this:

In this case, the product ID is available on the page, as is your current price. The only data point you don’t have is your competitors’ price, which can be added to the string via the DB Vista Rule. This allows you to capture all of the key elements needed to do analysis. For example, if you add the Product Views success event to this new eVar report and filter for the above product ID, you will see all of the different pricing permutations between you and your competitor for the selected date range:

Next, you can add Cart Additions or Orders to the report to see how often each product converted with the given pricing spread:

In this fictitious example, you can see that Orders per Product View was up significantly when pricing was the same or better than the competitor for the product in question.

But there is even more information you can glean when we apply SAINT Classifications. For example, you can classify the product with just the pricing range difference to boil this data down to a finite number of rows in a way that is a tad easier to interpret:

Taking this concept one step further, you can apply another SAINT Classification that takes the Product ID out of the equation to see how the pricing spread impacts all products:

For those that really need things spelled out for them, you can use SAINT to create the highest level view of your pricing by boiling the data down to cases where you were higher, lower or the same with respect to pricing:

Obviously, the last few reports can still be viewed by Product by simply using the Products variable breakdown, but I think they show a good high-level view of pricing impact. Keep in mind that each of these rows can be trended over time in SiteCatalyst or ReportBuilder to see a long-term effect.

Product Margin

For those of you who like to kick things up a notch, you can also use the same DB Vista Rule to incorporate your product margin to the new eVar. If you upload your product costs to the DB Vista table, you can have the rule calculate the difference between your price and your cost and add the result as another parameter to the eVar. Then, via SAINT Classifications, you can split this out and see cases where your price is higher than your competitor broken down by your margin:

In this case, the product in question has a cost of $26.00 so the difference is passed as the last parameter to the eVar so we can include it in our analysis. This allows us to create new SAINT Classification where we can see Orders/Product View (or Cart Addition) for all products by the product margin amount:

Since all SAINT Classifications can be broken down by each other, this also allows us to see our conversion rates by price difference broken down by product margin amount:

Keep in mind that all SAINT Classifications are eligible for use in Segmentation, which means that you can now build a segment using pricing differential to competitors and product margin as criteria when doing web analysis! Also, if you want to learn how to add product costs as a new metric with which you can calculate product margin as a KPI, check out my old blog post from 2008 on how to do that.

Final Thoughts

As I stated early on, there is no way to make a direct connection between people looking at your site and then price shopping on another site, but my theory is that if you consistently under-perform when you are priced higher than your known competitor(s), this approach may give you some data to validate your theories. Obviously, there are other factors such as shipping, taxes, etc. that can have a major factor, but some of those can be included in this solution as well by simply adding additional parameters to the eVar shown above. Other ways to do similar competitive analysis include using Voice of Customer surveys to ask your visitors if they are price shopping, or moving all SiteCatalyst and competitive data into Adobe’s Data Workbench product. Either way, if you like the concept, you can give it a try or contact me if you want some assistance. If you have other ways to do this, feel free to leave a comment here. Thanks!

In working with a client recently, an interesting question arose around cart additions. This client wanted to know the order in which visitors were adding products to the shopping cart. Which products tended to be added first, second third, etc.? They also wanted to know which products were added after a specific product was added to the cart (i.e. if a visitor adds product A, what is the next product they tend to add?). Finally, they wondered which cart add product combinations most often lead to orders.

I had to admit that I was surprised that no one had asked me these questions in the past (a rarity for an old-timer like me!). However, I love getting new questions since it allows me to come up with cool ways to answer them. Therefore, in this post, I will share some of the ideas that I am proposing to this client in case your organization has similar questions.

Product Cart Order Sequence

To tackle the question of which products are added to the cart first, second, third, my first instinct was to try out the cool new sequential segmentation in Adobe Reports & Analytics (SiteCatalyst). This feature has been around in Ad Hoc Analysis (Discover) for a while, but is new to Adobe Reports and Analytics. However, the more I thought about this, the more I realized that sequential segmentation wouldn’t help very much. The only scenario in which I think it might help, is if you want to know exactly how often Product A was followed by Product B and then Product C and an order took place thereafter. If you know the sequence you are looking for, you can isolate it and look at any report (i.e. Visits, Orders) using sequential segmentation.

But my client is looking to do more exploration and find out which products are added first, second, third, etc. Therefore, my thoughts turned to my old friend Pathing. Pathing is a great way to see a sequence of anything happening on a website/app. In this case, the sequence I am looking to see is products added to cart. Therefore, a cool way to answer this question would be to create a new Traffic Variable (sProp) and pass the Product ID’s (or Names) of each product added to the shopping cart to the variable when a Cart Addition takes place. Once this is done, you can enable Pathing on this new “Products Added to Cart” sProp so you can see all of the available pathing reports. For example, you can open the Full Paths report to see the most popular product combinations added to the shopping cart. Obviously, the first batch of entries in this report will be cases with just one product added:

However, when you get deeper into the results, you will start to see multi-product combinations:

Of course, you can narrow these paths to a specific product in this report using the “Showing Paths containing” feature:

Or you could also use the next page flow report to see products added after a specific product (in this case an Exit means that no other products were added to the cart in the same visit):

Or you could see similar information using Pathfinder:

As you can see, by simply passing product ID’s (or names) to a new sProp, you can gain insight into which products are added the most and in which combinations.

If you have a Product Category SAINT Classifications for your Products variable, you can also see all of the above sports by Product Category in Discover (Ad Hoc Analysis) by using pathing on classifications. Or you could always pass in the Product Category to another sProp if it is known at the time as suggested in the comments by Jan Exner.

But What About Orders?

While the preceding concept may be interesting, it falls short of the original goal because it doesn’t show which of these cart addition sequences leads to orders. While you could segment on visits with an order and then look at the remaining paths, I prefer to visualize the actual paths and see exactly when the order took place. Therefore, to add this component, I suggest that you pass the phrase “order” to the same new traffic variable on the order confirmation page. By including this one new value, it will be included in the pathing reports and can be used in any of the reports above or the fall-out report. You can also use the previous page flow report beginning with the “order” value to see the most common cart addition product sequences (paths) that lead to success:

This is probably best done in Ad Hoc Analysis (Discover) where you can have unlimited branches in the report, but you can still extract value from this in Adobe Reports & Analytics.

Other Pathing Reports

While I haven’t had much time to play with this concept, I would imagine that you could also extract some useful information from the additional pathing reports that are enabled when you turn on pathing for this new “Products Added to Cart” sProp. For example, if you want the “411” on a particular product being added to the cart, you can open the Summary report:

You could also see how often each product was the only product added to the cart or abandoned in the cart by using an Exit Rate formula (Exits/Visits). Keep in mind that if a visitor adds another product to the cart, the product in question will no longer be an “exit” as far as this report is concerned, so the exit rate below is the combination of single carts + abandons per visit:

You may even be able to use the “Page Depth” (even though they really aren’t pages!) to see how often a particular product was the first one added to cart, second, etc… I say may, because this is what I think this report is showing, but I need Ben Gaines to verify this for me!

Lastly, if you care about Cart Removals (which is not something I normally care about since many people simply exit instead of removing products), you could also include them in this approach. To do this, you’d have to change the values you pass to the sProp to be “Add:[Product ID or Name]” and then use “Remove:[Product ID or Name]” instead of just passing in the product ID or name.

Final Thoughts

As those of you who have read my posts in the past know, sometimes, I come up with crazy ideas like this and they work out, but other times they don’t. If you think this concept is interesting, feel free to give it a try, but keep in mind that this is just a concept for now until I get some clients to do more experimentation…Enjoy!

I recently had a client pose an interesting question related to their shopping cart. They wanted to know the distribution of money its visitors were bringing with them to each step of the shopping cart funnel. For example, what percent of visitors have between $25 and $50 in their cart when they reach the “Billing” step of the conversion funnel? Does this percentage remain constant throughout the funnel or are there significant drop-offs? Unfortunately, this is not something that can be easily derived in SiteCatalyst, but with a bit of creativity, I will show you how you can add this data to your implementation.

Calculating Current Order Value

The first step in this process is to work with your developers to create a new Counter eVar that will hold the current order value. As soon as a visitor adds an item to the cart, pass the dollar amount associated with that cart addition to the Counter eVar (in addition to passing it to a currency event as prescribed in my “Money Left On Table” blog post). This value will be bound to the Cart Addition success event and future cart events unless it is modified. If the visitor adds more products to the cart, pass in those amounts and if the visitor removes an item from the cart, subtract it from the Counter eVar value (remember you pass values to Counter eVars using the “+” or “-” sign). I would expire the Counter eVar at the Purchase or Visit (if your site doesn’t have a persistent cart).

By having these values in the Counter eVar, you will end up with many different dollar amounts when you open the eVar report with one of your cart events. Here is an example of what the eVar report might look like:

Obviously, this report is not that readable, so the next step is to classify it into meaningful groupings, such as Under $20, $21-$35, $36-$50, etc… This will allow you to analyze the data in buckets and look for insights. Which groupings you choose are up to you and you can use SAINT to have multiple groups, such as every five dollars, every ten dollars, etc… Here is what it might look like after the SAINT Classification:

This general concept is similar to one that I described in my Revenue Bands post, but in that scenario, we were just passing the final order amount to a regular text eVar. The difference here is that we are using the Counter eVar to adjust the order value up or down as it progresses through the cart process.

Viewing Distribution

Once we have the current order values tied to each stage of the cart funnel and have grouped them accordingly using SAINT, our next challenge is to compare the distributions. There are a few different comparisons you can make with this data, so I will touch upon each of them. The first one you might want to see is whether the various percent distributions are steady or going up/down over time. In this case, you may not care about the actual raw numbers that are associated with each order value range, but rather, are most likely more interested in the percent of the total. For example, it may not be that interesting that 2,500 checkouts fell into the range of $15-$25, but it may be interesting to know that this dollar range represented 15% of all visits to the checkout step of the funnel. If you could see this percentage, then you could trend it over time and see if that $15-$25 bucket is increasing, decreasing or steady over time.

To see these percentages, you have two options, the first is to download data to Excel and create formulas to calculate the percent and trend it over time. If you want to use the SiteCatalyst interface, the best way to do this is to employ the “Total Metrics” feature. This feature allows you to create a calculated metric that divides the row value by the total at the bottom of the report. For example, if you wanted to calculate the percent of each dollar band while at the Checkout step, you would divide Checkouts by Total Checkouts using a formula like the one shown here:

This formula moves the percent shown in the regular eVar report front and center so it is the actual metric of the report. To visualize this better, let’s look at the previously shown report with this new metric column added:

As you can see, the percentages that were previously on the right side of the column (more as an FYI), are now present by themselves as a real metric in SiteCatalyst. Now you can use this percentage as a true metric, meaning that you can trend it over time and see its historical performance:

This allows you to see how each dollar amount band does and do some hard-core web analysis!

Another analysis you may want to do with this data is to see the drop-off between the dollars amount percentages added to cart, the percentages making it to checkout, etc… This is a bit more complex because you are looking at one dollar amount grouping, but seeing how it changes as visitors get further in the cart process. Unfortunately, there is no great SiteCatalyst report for comparing different percentages over time, so this analysis will have to be done in Excel.

To begin, you will want to create additional “Total” metrics like the one shown above for the other cart steps that you care about. In SiteCatalyst, this is what a report might look like, though it is limited in its use. In this case, the client has a customization step in the funnel, a billing page step and then a checkout step. Using the “Total” metrics, you can compare the changes in dollar amounts at the various steps of the funnel:

In this case, we are looking to see how consistent the percentages are across each row and seeing if we can identify any problem areas. However, to do analysis on this, Excel might be a better tool since it is easier to compare the percentages between different columns. Also keep in mind that you can break this report down by Product or Product Category to see how these percentages change by Product.

Final Thoughts

If your website has discrete steps in its funnel and if you are curious to see how much money visitors have at each step of the cart, the preceding is one way to do this. In addition to what I have shown here, having this information can be useful in other ways. For example, if you want to build a segment of all cases in which a visitor had more than $100 at the checkout step, but did not purchase, the eVar described here can be used as part of your segment criteria. I am sure there are many other ways to use this data as well, but hopefully this gives you some food for thought.

If your web analytics work covers websites or apps that span different countries, there are some important aspects of Adobe SiteCatalyst (Analytics) that you must know. In this post, I will share some of the things I have learned over the years related to currencies and exchange rates in SiteCatalyst.

Implementation

When you work for a multi-national organization, the first decision you have to make is whether you plan to have a different report suite for each country website or whether you will combine all data into one report suite and use segmentation for day-to-day analysis. For the pros and cons of this decision, I suggest you refer to this old post that covers multi-suite tagging vs. segmentation. As noted in that post, one of the downsides of using one report suite and segmentation is that you cannot have a different currency for each country. I find this very limiting, so let’s assume that you have a different report suite for each country site in your organization. When implementing each report suite, you will assign a currency that the report suite will use. For example, if the report suite is for Japan, in the Administration Console, you will make the currency Japanese Yen:

Once you do this, you just need to make sure that when you pass Revenue and currency success events that you set the s.currencyCode variable to the appropriate currency code for that country (i.e. JPY). This will tell SiteCatalyst that the numbers you are passing should be stored as Japanese Yen. If you are using multi-suite tagging and sending a second copy of data to a global report suite, then Revenue and currency success events will be translated into the currency of the global report suite (i.e. US Dollars) using the currency exchange rates found on xe.com. This allows your users in one country to see data in their own local currency, while letting executives see data rolled-up in a master suite in one unified currency.

One-Report Suite Only

As mentioned above, if you don’t have a separate report suite for each country site, either having just one report suite for the entire organization or a report suite for a region that contains multiple currencies, you cannot take advantage of the preceding currency translation feature. In this case, you have two choices. Your first choice is to use the same currency for all countries and pass data in that currency at the time of data collection. For example, if you have a European report suite, you may choose to use Euro as the primary currency and translate British Pounds and other non-Euro currencies into Euros at the time data is passed into SiteCatalyst. The second option is to pass currency amounts into a Numeric Success Event in a way that is currency agnostic. In this approach, you would not use the out-of-box Revenue event and instead would create a custom Numeric success event and pass in the raw numbers in the currency of that country. For example, if a 200 Euro order takes place in Germany, you would pass in a value of 200 and if a 300 British Pound order takes place, you would pass in a value of 300 to the Numeric success event. At the same time, you should pass in the currency the order took place in to an eVar. Once you have the raw transaction amount and the currency type, you can download the data to Excel using Adobe ReportBuilder and translate the raw Numeric success event numbers into the appropriate currency using a lookup table and referencing the eVar that indicates the currency. While this will not provide a way to see local currencies within the native SiteCatalyst interface, you can at least have your Excel dashboards show local currencies. Obviously you can use both of these approaches concurrently, using a master currency for the region and then providing local currencies in an Excel dashboard.

Pegged Exchange Rates

Over the years, I have worked with several clients that use “pegged” exchange rates. In this scenario, their organization uses one set of currency exchange rates for the entire fiscal year instead of using the daily exchange rates. This causes a problem for Adobe SiteCatalyst, since its default behavior is to use the daily exchange rates found on xe.com. Keep in mind that the local currencies in country-specific report suites will be fine since they are not being translated into a master currency. In this scenario, the only figure that is negatively affected is the currency amount in your global report suite, since that is when currency translation occurs. For example, if you collect an order for 300 Euro in Germany and the German report suite is set to Euros, everything will be fine. However, when that 300 Euro order is sent to the global report suite (let’s assume it is a US-based organization), it will be translated into US Dollars by default using today’s exchange rate instead of your pegged exchange rate (which can be quite different).

Unfortunately, there isn’t a way to override this default behavior, so I recommend using a DB VISTA rule to have SiteCatalyst lookup the pegged exchange rates published by your organization. As currency data is collected, you can use DB VISTA to bypass or overwrite the exchange rate translation done by SiteCatalyst with the rates approved by your organization. Unfortunately, DB VISTA rules cost a few thousand dollars, but in this case, it is probably worth it to have your global currency figures reflected correctly.

Interface Currency Setting

The last area related to currencies I want to cover is the currency setting found within the SiteCatalyst interface itself. I call this out because it can be very dangerous if you do not understand it. In the Report Settings area of the left navigation, there is a way to change the currency that you see when using SiteCatalyst. Here is what it looks like:

From this screen you can change the currency setting you use. Here is an example of me changing it from US Dollars to Euros:

Doing this will now show currency reports in Euros:

The dangerous part of this feature is that it seems like it does more than it actually does. How awesome is it that we instantaneously converted all of our data from US Dollars to Euros? Unfortunately, this is a mirage. Using this feature simply translates all historical data into the new currency (Euros in this case) using the current exchange rate. This means that historical data is not converted using the exchange rate that was present at the time the data was collected. Therefore, if the exchange rate has changed significantly, our data will be off. This is why it is important that you educate your users about this feature before they start using it and present inaccurate data to people in your organization.Once you understand how this feature works, you may re-think using this feature and proactively discourage its use!

In the last few years, people have become accustomed to using multiple digital devices simultaneously. While watching the recent winter Olympics, consumers might be on the Olympics website, while also using native mobile or tablet apps. As a result, some of my clients have asked me whether it is possible to link visits and paths across these devices so they can see cross-device paths and other behaviors. This type of linking has long been available using advanced tools like Adobe Data Workbench (formerly known as Visual Sciences or Discover on Premise or Adobe Insight), but in this post I wanted to share some things you can do in SiteCatalyst (Adobe Reports & Analytics) as well.

Authenticated Visitors Only

The first thing to note, is that it is not easy to link visitors hitting your website and native apps if they are not authenticated via some sort of identifier (ID). As you probably know, visitors have different SiteCatalyst Visitor ID’s on each device, so it is hard to know which ID’s represent the same person. However, if your website/native app allows visitors to login using a customer ID or loyalty ID, you have more options available to you. Adobe has one approach called “visitor stitching” that you can read about here, but I have not seen many clients use that successfully. The reason I don’t see this working is that it requires a large change to your SIteCatalyst implementation involving replacing the out-of-the-box Visitor ID with your own Visitor ID. This can have some major ramifications (i.e. distorted unique visitor counts) and many of my clients aren’t ready for that type of risk.

However, this solution can be modified a bit to be a bit more useful and that is what I am going to discuss here. Instead of replacing the Visitor ID on your main report suite, I advocate creating a new “Authenticated Only” report suite in SiteCatalyst in which you send only authenticated traffic. This new report suite would most likely be populated using a VISTA Rule. When data is sent to this new report suite, the s.visitorID would be set to your own authenticated ID so it matches up across any device.

Let’s look at an example. Imagine that Joe Smith visits your website and views a few pages as an anonymous (non logged-in) visitor. Then on the fifth page of the visit, he authenticates. From that point on, you can send all of his traffic to a multi-suite tagged Authenticated Only report suite as a secondary server call. Next, let’s assume that Joe takes a break from your website and begins using one of your native mobile apps. Upon using the native app, he authenticates so all of his data also goes to the Authenticated Only report suite as a secondary server call. Since both of these actions are time-stamped, in the Authenticated Only report suite, you would see activity from both of Joe’s sessions, and in the order they took place. For example, in a path report you might see a series of pages Joe viewed while on the website and then in the next page flow report, see a path from a page on the website to a page found in the native app. Obviously, there is no direct link between these pages, but by passing both data elements to the same report suite, SiteCatalyst sees them as being consecutive. This can provide insights into when people are moving between different devices and what content they view on each. When it comes to pathing, you might want to consider setting a new version of the page name variable in which you pre-pend the digital channel to the page name (i.e. web:home page vs. app:home page) so when you see pages in pathing reports, you know which device the visitor was on when they viewed the page:

Seeing paths across multiple devices is cool, but that is only the tip of the iceberg! Since data coming from both platforms have the same Visitor ID, all eVars that you set will retain their values across devices since eVar values are tied to the Visitor ID. For example, if a visitors’ City is passed to eVar4 on the website, its value will persist for all actions taking place on the native app. This means that any Success Events set on the native app can be attributed to the visitor’s City, even though they never input the city within the mobile app! The same is true in reverse, as eVars captured in the native app will be available to the website. This eVar persistence can be very powerful when you think about things like Campaign Tracking Codes, which can be collected in either platform and extended to the other.

Another cool aspect of this solution is that you can do cross-device Segmentation. For example, you might want to build a “Visit” segment in which visitors viewed more than one device and XYZ actions took place. This would now be possible using the Authenticated Only report suite since the behavior on both devices looks to SIteCatalyst as if it all took place in one session (which it did!).

Another bonus of this solution is the ability to use the SiteCatalyst feature of Participation. Participation is only visit-based, so you can only see which pages within the visit led to Success Events (i.e. Orders). But when visitors switch devices, they are creating a new visit, which breaks Participation. But with this solution, any pages viewed on one device would show as having contributed (Participated) to success taking place on the other device, since both devices are included in the same visit!

Caveats

As always, there are a few caveats to any solution. The following are a few things to keep in mind before getting overly excited:

• Sending traffic to another report suite will use additional secondary server calls which has a cost implication. To estimate how much this solution would cost, look at how many page views you have for authenticated pages (pages viewed by people who are logged in) and you will get a good approximation of how many additional server calls you will have to pay for
• VISTA Rules also cost a few thousand dollars so that is another cost you would have to incur
• Using this solution assumes that all of your report suites are set-up consistently, meaning that the same Success Events, eVars and sProps are used for your website and native app suites. You should be doing this as a best practice anyway for creating global report suites, but in case you are not, be sure to only pass in the variables that are common to both via the VISTA rule or you will get different numbers or values in the Authenticated Only report suite. Keep in mind that you can use VISTA rules to change the Event/eVar/sProp numbers on the fly if it is too difficult for you to sync up your implementations right away (though I don’t recommend doing this in VISTA as a long-term solution since it can be easily broken)
• Any pages view before visitors authenticate will not be captured in the new Authenticated Only report suite. This means that you will not be getting the full picture of the visit in this new report suite. For example, you may not get the accurate entry page or miss the passing of some campaign tracking codes, but there are some more advanced techniques you can use to store this information and pass it on the first authenticated page
• Using this approach with native mobile apps that store offline data is not recommended since the offline data timestamps can mess up your data collection and eVar attributions

Outside of these few caveats, if you want to see cross-device behavior, this is a relatively simple (and cheap) solution. Obviously, if you want to get much deeper into cross-channel behavior, you may want to investigate Adobe’s Data Workbench or tools like Causata (now owned by NICE). If you are interested in seeing how your visitors float between your digital channels/devices, feel free to give this approach a try…

Recently, I have had a few clients ask me the following question:

How can I determine which onsite search terms have the highest exit rate on the search results page?

This question also appeared on the Adobe Analytics message board. While it is easy to see how often visitors exit from your search results page, that analysis won’t show you which specific onsite search terms had higher or lower exit rates. Of course, you could pick one specific onsite search term and segment on that to see exit rates from the search results page for that term, but that is a non-scalable approach if you want to see this for multiple search terms or for all of them in descending order. So I thought I’d share some ideas on how you can tackle this type of analysis in Adobe SiteCatalyst.

Option #1 – Search Term Exit sProp

The first thing that comes to my mind to solve this problem is Pathing. Once pathing is enabled on an sProp, you can see entries and exits. In this case, you can pass in the onsite search term to a new Traffic Variable (sProp) on the search results page. You are probably already storing onsite search terms in an sProp so you can see search term pathing (seeing search terms used before and after other search terms). However, this sProp will be a bit different. For this sProp, all you want to know is whether they exited or not. To accomplish this, have your developers pass a value of “[did not bounce]” to the sProp if the visitor reaches any page on your website after the search results page. By passing this “dummy” value, you are ensuring that SiteCatalyst won’t see an exit if they reached a page beyond the search results page.

Once this is done, you can open this new sProp and add the Exits metric and see a list of search terms with the most exits in descending order:

If you see the “[did not bounce]” item, you can simply exclude that from the report using a search filter.

Option #2 – Pages After Search Terms

There may be cases in which you also want to see where visitors went after seeing search results for a specific onsite search term if they did continue their path. There are a few ways to do this. One way is to build a segment that isolates visits in which the onsite search term you care about was used and then look at the path reports for that segment. A downside of this approach is that it will include paths taking place before and after the search term was used unless you use Discover (Ad Hoc Analysis). Therefore, the way I would approach this is to continue building upon the concept above, but tweak it a bit.

The tweak you will make is to not pass the “[did not bounce]” value on the page after the search results page, but rather, to pass the s.pagename value to the new Search Term Exit sProp described above. Since this can be confusing, here is a recap of the tagging steps you’d want to tell your developer. On each page of the site except for the search results page, pass the value being passed to s.pagename to your new Search Term Exit sProp. When visitors are on the search results page, have your developer pass the onsite search term to the new sProp (I recommend inserting the phrase “term:” to make it clear which items in the new sProp are search terms and which are page names). Believe it or not, that is it! For example, if a visitor is on the Greco Inc. home page and then searches for “boots” and then goes back to the home page, here are the three values that you would pass to the new Search Term Exit sProp respectively:

grecoinc:home:homepage

term:boots

grecoinc:home:homepage

By doing this, your end-users can open the Next Page Flow report for this new sProp, choose the onsite search term (“term:boots” in this case) and then see the path flows after the search term. The way pathing works, it will only show paths taking place after “term:boots” and the exit percent will be people who exited right from the search results page. Here is what the report might look like:

In SiteCatalyst, you can only see two levels of paths from the onsite search term, but if you have access to Discover (Ad Hoc Analysis), you can see an unlimited number of paths emanating from the onsite search term. As you can see, this version of the solution provides everything that option one provided, but also shows you the specific pages visitors viewed after each onsite search term. It is up to you to decide how much analysis you want to do and what questions you want to answer.

Another side-benefit of this approach is that you can take advantage of fall-out pathing reports. Let’s say that you want to know how often visitors searching for “boots” make it to the shopping cart or to the order confirmation page. To do this, you can create a fall-out report that starts with “boots” and then add your cart and order confirmation pages to the fall-out report as checkpoints.

In Discover, you can even group onsite search terms into buckets using the grouping feature and do a similar fall-out report from a group of terms leading to carts or orders!

I am sure there are many more ways to answer these types of questions, but for those focusing mainly on SiteCatalyst, I hope that this is helpful.

If you are an online retailer, it is likely that your orders that contain shipping, discounts and/or taxes. Over the years I have seen some good and bad ways to track shipping, discounts and taxes in SiteCatalyst so I thought I would share some tips that I have found helpful.

The Basics

To start, let’s talk about why you might want to track shipping, discounts and taxes in SiteCatalyst. If you sell products in retail stores and online, your customers have an opportunity cost associated with shipping. Customers can often save money by coming to your physical store to get a product, but there may be a convenience factor associated with having products shipped. By tracking the total shipping dollars associated with each product, it’s possible to see which products are commonly shipped and the associated dollars. You can also look at shipping dollars as a standalone metric to see if shipping dollars per order are going up or down over time. The same concept applies to product discounts. You may have co-workers who want to see which products have been discounted and the amounts of the discounts. Tax amounts tend to be less meaningful from a web analytics perspective, but I will demonstrate how to track them in case your organization needs to track them for some reason.

The general method of tracking shipping is to use a Currency Success Event to store the amount the visitor spends on Shipping and the Products variable to connect that shipping amount to the Product ID. This is done through the product string syntax and might look like this:

s.events="purchase,event30";

s.products=";111;1;400;event30=5"

In this case, you have a scenario in which a visitor has purchased one unit of product ID#111 for $400 and is paying $5 in shipping. The latter is stored in success event 30 and can be viewed trended or broken down by Product.

If you also want to track discounts associated with the purchase, you can dedicate another currency success event to discounts. Discounts would work the same way as shipping in that it would be set in the products string using another currency success event. If there was a $10 discount for the product shown above, the syntax might look like this:

s.events="purchase,event30,event31";

s.products=";111;1;400;event30=5|event31=10"

Tax amounts are tracked in a similar manner. The syntax you might use if the preceding order had a tax amount of $32 is as follows:

s.events="purchase,event30,event31,event32";

s.products=";111;1;400;event30=5|event31=10|event32=32"

When this is done, if the preceding order were the only one to take place on your website, you would end up with a report that looks like this:

As you can see, tracking shipping, discounts and taxes is not that difficult and only involves using three new currency success events and the products string. However, things can get a bit trickier as I will show in the next section.

Fake Products?

One strange thing I have seen over the years related to tracking shipping, discounts and taxes is treating these as separate products. I am not quite sure why companies do this, but I am not a fan of this approach. This method adds a fake product called “shipping” or “taxes” to each applicable order and attributes the full shipping or tax amount to these fake products. Here is what the syntax might look like:

s.events="purchase,event30";

s.products=";111;1;400,;shipping;;event30=5.5"

This results in a Products report that looks like this:

As you can see, all shipping dollars are associated with the fake product of “shipping” instead of the products that drove shipping.

This approach can also wreak havoc on reports that use the Orders metric, like Merchandising reports, which will often show greater than 100% due to these fake products. Here is an example:

If you break down the above report by Product, you can see that the culprits are these fake products:

For all of the above reasons, I am not a fan of this “fake product” approach.

Multiple Products

Tracking shipping, discounts and taxes gets more difficult when visitors purchase multiple products concurrently. For example, there may be cases in which a visitor purchases three products and two have a shipping cost or discount, but the third product does not. I have a feeling that the multiple product scenario is what causes people to implement the preceding “fake product” method, but I think this is a lazy approach.

The more precise way to track shipping and discounts for multiple products is to associate the exact dollar amounts for each to each of the products being purchased as shown in the first examples above. If multiple products are purchased and we cared about tracking shipping and discounts, the resulting syntax might look like this:

s.events="purchase,event30,event31";

s.products=";111;1;400;event30=5|event31=10,;222;1;200;event30=2|event31=5"

In this example, two products were purchased and each has its own shipping and discount amount, correctly lined with the the product that drove these amounts.

However, there may be cases in which you cannot identify the exact amounts by product. In this case, you have a few options. The first (and preferred) option is to proportionally allocate shipping/discount amount based upon the purchase prices. For example, if someone purchases three products of amounts equal to $250, $100 and $50 and the shipping is $40, you could assign shipping amounts of $25, $10, $5 respectively. The same proportional approach would apply to discounts and taxes. While this isn’t perfect, it may be the best that you can do without working with IT to get the exact amounts per product. It is also something that can be done with some fancy JavaScript so you don’t have to get time with your IT folks. Another approach I have seen used is to simply put all shipping into the product with the largest revenue amount, but this will make your shipping data pretty inaccurate.

To summarize, tracking shipping, discounts and taxes is something you should consider for your SiteCatalyst implementation if you sell products online. However, the approach you take may depend upon what data you can get from your IT folks. Hopefully this post help outline some of the choices you have so you can determine which approach is the best for you.

The “None” row in SiteCatalyst. You either love it or hate it. It is amazing how far I have seen some companies go to avoid it and banish it from their reports. Personally, I love the “None” row and often try to explain to people its uses. In this post, I will review what the “None” row is and explain why not using it for Campaign Tracking can hurt your SiteCatalyst implementation.

The “None” Row Re-Visited

Way back in 2008, I explained the “None” row (apparently before images were allowed in blog posts ;-)) as part of my explanation of Conversion Variables (eVars). For those unfamiliar, eVars store values that are collected along the way and when a Success Event takes place, the current value of each eVar gets credit for the Success Event. For example, if eVar 1 captures the zip code of 60035 and a form completion Success Event takes place, that form completion would be attributed to the zip code 60035. But what if no zip code had been passed to eVar 1? In that case, the Success Event would be attributed to the “None” row so that the total of the rows in the eVar report matches the total of form completions for the same time period. That is really all the “None” row is used for in SIteCatalyst. However, in the next section, I will show you the most common “None” row mistake I see and how to avoid it.

“None” Rows Gone Bad – Campaigns

The tracking of marketing campaigns is one of the most important uses of the “None” row. When visitors come to your website, it is customary to track their arrival with a marketing campaign tracking code. This might be a paid search keyword identifier, a friendly URL name or a tracking code associated with a social media campaign. More advanced companies (a.k.a. my clients) go even further and pass unpaid referrals a tracking code for things like SEO or external websites. Therefore, in the Campaigns (s.campaigns) SiteCatalyst report, the “None” row either represents the unpaid visits to your site or, if you are tracking paid and unpaid referrals, it represents your “Typed/Bookmarked” traffic.

So let’s imagine that in your implementation, you have tracking codes for all paid and unpaid referrals to your website and that the “None” row truly represents traffic that is typed/bookmarked. Let’s also suppose that you decide to have two versions of your Campaigns report in which the Campaigns variable (s.campaigns) expires at the Visit and another custom Campaign eVar expires after 30 days. The latter is common as many marketers want to see if the same visitor who came to the website from a specific tracking code comes back in the next 30 days and if so, to attribute success to that tracking code.

However, now let’s say that your new mean boss tells you that he/she doesn’t like seeing the “None” row in the two Campaign reports. They say to you:”If it represents Typed/Bookmarked, why don’t we just pass that into SiteCatalyst so it is easily understood by everyone” (Since executives are great at simplifying things right?). So you have your developer write some code that passes in “Typed/Bookmarked” in the s.campaigns and the custom eVar variable if no known referrer is found. There is no more “None” row and everybody is happy.

Unfortunately, I have seen this scenario play out too many times. If you do what I just described, you have just ruined your Campaign eVar that has a 30 day expiration. By passing in a catch-all value of “Typed/Bookmarked” in the 30 day expiration eVar, you have forced SiteCatalyst to replace its current value with a new value of “Typed/Bookmarked.” In the previous example, if the visitor who came from the paid search keyword comes back a week later and types in your company’s URL, the paid search keyword will be overwritten. This means that you are taking away credit from paid campaigns and punishing them in cases where visitors actually remember your brand and come back to you a second time (and decide not to cost you money both times!). Passing in a catch-all value of “Typed/Bookmarked” turns your 30 day expiration into a Visit expiration. In this scenario, we already had a Campaign variable that had Visit expiration, but thanks to your boss, who doesn’t understand SiteCatalyst, you now have two of them!

This example illustrates the magic of the “None” row. It provides a way to see what percent of your success can be attributed to a specific value and what percent cannot. In the case of marketing campaigns, the “None” row represents the Typed/Bookmarked segment, and since no value is being passed, it has the added benefit of allowing your Campaign eVars that expire beyond the Visit to attribute success as intended. The same principle applies to all other eVars, but I find that Campaigns is the area in which my clients make this mistake most often. Therefore, my advice is to not be afraid of the “None” row, but rather, to embrace it and bask in its glory!

If Your Boss Really Hates The “None” Row

Lastly, if for some reason, you cannot convince your boss to live with the “None” row, there is one more trick I can show you to appease them. Unbeknownst to many SiteCatalyst users, it is possible to classify the “None” row. When building a SAINT file, if you use the value “~none~” as shown here, you can put whatever value you’d like for the “None” row in the classification report. Here I am showing renaming the “none” row with “Typed-Bookmarked” in a Marketing Channel classification of the Campaign variable.

However if you really wanted to, you could create a new “Cleaned Campaign Code” classification of the Campaigns report and assign a different value to the “None” row. Personally, I think this is cumbersome and would never do it, but it is technically possible if you really need to have a version of your low level camapign codes and don’t want to see a “None” row.

Hopefully this post will help those who may have inadvertently fallen into the trap described above, or at the very least, help others avoid it in the future. If you have any questions or comments, feel free to leave a comment below. Thanks!

Editor’s Note: Despite the fact that Adobe is retiring the name “SiteCatalyst,” it will take me a while to adjust to that change so I will continue to refer to the product as such.

If you sell products on your website, there is a good chance that you try to cross-sell products. Made famous by Amazon.com, the concept of “People who like this product also like these products…” is forever ingrained in our heads. While SiteCatalyst isn’t a merchandising or recommendations tool in of itself (Adobe and others have products that specialize in that), it can be used to see how well each product is cross-selling other products. This type of cross-sell reporting can be useful from a web analysis perspective to answer the following questions:

• How often does cross-sell occur (in general)?
• Which products are added to the cart via cross-sell?
• Which products cross-sell each other?
• Which product categories cross-sell each other?

In this post, I will share some ways you can answer these questions using SiteCatalyst.

Tracking Cross-Sell During Cart Addition

The first step in tracking product cross-sell is to set-up your implementation in a way that can report upon Cross-Sell Cart Additions and capture which products are being cross-sold. To do this, let’s go through an example. Let’s imagine you work for AVG. As shown below, a visitor has just added the AVG Security 2013 product to the shopping cart. While there, the visitor sees a cross-sell for the Backup DVD product. If the visitor clicks the Add to Cart button for the Backup DVD product, it should be counted as a Cross-Sell Cart Addition. We would also want to capture which product drove the DVD Backup Cross-Sell Cart Addition.

To capture this in SiteCatalyst, when the visitor clicks on the blue “Add to Cart” button for the Backup DVD product, in addition to the normal Cart Addition success event for the DVD Backup product, you can pass the product ID of the referring product to a Merchandising eVar. The syntax might look something like this:

Using this syntax, we are telling SiteCatalyst that a Cart Addition took place for the Backup DVD product, and that it was driven by the Security 2013 product through eVar 10, which might be named in the Administration Console something like “Cross-Sell Product.” Keep in mind that in this sample code I am using actual product names only because it is easier to explain, but that in reality, you would want to pass product ID’s to the Products variable and eVar 10 instead and then use SAINT Classifications to add the friendly product names, category, etc…

So now let’s see what this ends up looking like in SiteCatalyst reports. If we were to open the Products report and add Orders and Revenue, we can see how often each product was purchased. But if we break this report down by our new Cross-Sell Product Merchandising eVar, we can see how often each product was purchased as a result of a Cross-Sell and even which product cross-sold it:

In the report above, we can see that the Backup DVD was sold without cross-sell approximately 95% of the time. For the remaining 5%, we can see which products drove its addition to the cart and ultimately its purchase. Here we can see that the AVG Security 2013 product is the top cross-seller of the Backup DVD product. Obviously, we can view the converse of this report by opening the Cross-Sell Product report and breaking it down by product to see what other products the AVG Security 2013 product cross-sold.

Another thing you may notice is that I set an additional success event (event30) in the above syntax. I did this so that I can have a metric that captures how often Cross-Sell Cart Additions took place. The scAdd success event captures all Cart Additions, but you would only set event 30 when the Cart Addition is the result of a Cross-Sell. This event 30 allows you to trend Cross-Sell Cart Additions and you can add it to the Cross-Sell Product eVar report to see how often each product drove visitors to click the Cross-Sell button. This can then be compared to Orders to see Cross-Sell conversion by product.

You can also use this additional Cross-Sell Cart Additions success event is to create a Calculated Metric to quantify what percent of all Cart Additions are Cross-Sell Cart Additions (Cross-Sell Cart Additions/Cart Additions). This is easily trended and you might have merchandisers set internal targets or goals to increase this via Test&Target or other tools.

You can also add both the Cart Additions and Cross-Sell Cart Additions success event to the Products report to see Cross-Sell Cart Addition % by Product:

If desired, you can also see cross-sell of product categories. If you are a good SiteCatalyst administrator, you should already be using SAINT Classifications to group products into product categories. If you are doing this, then you can view the above product cross-sell report by product category to see how well one product category is doing at cross-selling another product category. Using the example above, if we classified the AVG Security 2013 product into the Security product category and the Backup DVD product was classified into the Backup product category, we could see how often the Security Category cross-sells the Backup Category.

As an aside, if you are using a Merchandising variable to capture “Finding Methods” (capturing the method that visitors used to find products they ultimately purchase), you want to be sure that when the Cross-Sell Cart Addition Click success event you set a value of “Cross-Sell” to the Finding Methods eVar. This will allow you to bind each product driven by cross-sell appropriately.

So there you have it. Some ideas of you to ponder as you think about product cross-sell on your website. If you have any questions or additions, feel free to leave a comment here. Thanks!

Recently, the Adobe SiteCatalyst product team “hit it out of the park” (to follow Ben’s analogy) with the latest SiteCatalyst point release! There are many awesome features that people like me have been waiting for. This release has things like segment comparisons, increased self-service capabilities via the Admin Console, Classifications on List Variables, Hourly Trending and improved test search filtering. Probably the biggest point release I have seen going back to version 9! Kudos to all involved!

However, the biggest feature enhancement was the SAINT Classification Rule Builder. This has been a long time coming and I am excited to start using it. I highly recommend you read more about this in the SiteCatalyst help section (login required). This new feature will go a long way towards helping clients maintain and clean up their SAINT Classifications. While I was giddy about the concept of SiteCatalyst customers having updated SAINT Classifications, I decided to share some other tips I have used to help clients minimize their missing SAINT data. When I work with clients to audit their Adobe SiteCatalyst implementations, one thing I review is how many of their eVars and sProps are missing SAINT classification data. Hopefully, these tips, combined with the new SAINT Classification Rule Builder, will lead you into SAINT Classification bliss!

The “None” Row in SAINT

In the past, I have explained how the “None” row in SiteCatalyst is annoying (at times), but actually a good thing, and not something to be feared. The “None” row can be extremely useful in Campaign reports and many others. If you see a “None” row in any eVar report, it simply means that when the chosen Success Events took place, there was no value for the current eVar. After a while, most SiteCatalyst users begin to understand this. Traffic variable (sProp) reports don’t have “None” rows since if there is no data, it just doesn’t show it instead of lumping the reminder into a “None” row.

However, when it comes to SAINT Classifications, for the most part, the “None” row tends to be a bad thing. The reason is that when you see a “None” row, it can mean one of two things:

1. The root eVar variable that you are classifying did not have a value
2. You are missing SAINT Classification data, causing unclassified data to appear in the “None” row for the eVar (or sProp) classification

To better illustrate this, let’s look at an example. Let’s say you work for a company that sells video games. You are passing Product ID’s to the Products variable and also have a few SAINT classifications of the Products variable including the one shown here (Game Genre):

As you can see, there is a significant percentage of Orders and Revenue appearing in the “None” row of this classification report. But how do you know if the cause is #1 or #2 above or a mixture of both? Did someone launch new products and forget to pass in a Product ID to the products variable and is that why there is no assigned Game Genre? Or do we have all of the Product ID’s correctly assigned to the Products variable, but forgot to add the Game Genre meta-data via SAINT? Unfortunately, it is difficult to know the answer to this question without doing some research.

Isolating the True “None” Row

If you are a SiteCatalyst guru, you probably know that the fastest way to figure this out is to do what I call the “breakdown by the root” trick. What I do is to click the breakdown icon next to the “None” row and choose to break that row down by the variable that it is a classification of (its root). In this case, you would break down the Game Genre “None” row by the Products variable to see if there are any product ID’s that show up. If you see Product ID’s in the breakdown report, you know that you are missing SAINT classification data. If you only see a “None” value, then you have done all that you can do via SAINT and have to figure out why such a high percentage of Orders and Revenue are not being associated with a Product ID. The latter is often a tagging issue.

In this example, when you create this breakdown, you can see that both problems exist. About 4% of the Orders taking place are missing a Product ID in the Products variable, which means that we have no way of knowing which Game Genre they would fall into. However, the rest of the items appearing in the breakdown report have Product ID’s. This means that they are simply unclassified. Therefore, if we were to successfully classify all of these Product ID’s, we could bring our overall percent of unclassified Orders down from 22.1% to 0.8% (1,095/128,916 Orders), which makes a huge difference! I have found that having large “None” rows for classifications can confuse your users and lead to the perception that your data isn’t sound. To stay on top of this, another trick I suggest is that you schedule the preceding breakdown report to be mailed to you weekly for your most important variable classifications.

Using a “Dummy Value”

Next is what I call the “dummy value” trick. There are sometimes cases in which you know that you will be missing meta-data. For example, in the gaming scenario above, there could be a case in which you know the Product ID, but for some reason don’t yet have the Game Genre right away. Looking at the second report above, there may be a legitimate reason why Product ID 7777 and 7767 don’t yet have a Genre assigned. If that is the case, my suggestion is that you set a “dummy value” in your SAINT file to act as a placeholder for the actual value that will be coming later. To do this, simply add the “dummy value” in any blank spots of your SAINT file. For example, let’s say that you download your products SAINT file and it looks like this:

All you have to do is fill in the blanks with a “dummy value.” I like to put “dummy” values in all caps and/or brackets so they are easy to identify and filter out of reports if needed. The preceding SAINT file would now look like this:

Once this file has been uploaded and processed, you can re-open the first report shown above and see this:

Obviously, not much has changed since all we did was move most of the “None” values to a new “dummy” row. However, we now can see that the actual “None” row is only about 0.8% and more importantly, this report communicates to SiteCatalyst users that it is known that 21.3% of the Game Genre’s are currently missing (so don’t call and pester us!). You can put any message you want in the brackets such as “[GAME GENRE COMING SOON…]” or whatever you think makes sense to your users. Additionally, it is easy to see this report without the “dummy value” by simply using a search filter to remove anything with a “[” or “]” symbol, which is easier than removing the “None” row from reports.

Final Thoughts

If you have to deal with SAINT classifications on a regular basis, knowing how to do the following can make your life a lot easier:

• Isolate the true “None” values from those missing SAINT classifications
• Get a report of those SAINT items that are missing meta-data through scheduled reports
• Communicate which SAINT values are known to be missing vs. ones that are true “None” values through a “dummy value”

Together these tips should save you some time and headaches when it comes to SAINT. If you have any questions on these tips or additional ones, feel free to leave a comment here.

When it comes to tracking online purchases in SiteCatalyst, there are many different ways to report on Orders, Units and Revenue. There are the standard shopping cart metrics and an easy way to create calculated metrics using those cart metrics, such as Average Order Value (AOV). However, a question I get from time to time is related to looking at website data by how much money visitors spend in an Order. In this post, I will share some thoughts on how to add Revenue Bands to your SiteCatalyst implementation.

Revenue Bands

So what do I mean by Revenue Bands? I think of Revenue Bands as groupings of revenue amounts by which you can view any of your SiteCatalyst Success Events. For example, let’s say that your boss comes to you and wants to know what percent of Orders taking place last week were between $200 and $300. That seems like an easy question for SiteCatalyst to answer right? But how would you actually answer it? In the past, I have shown how you could use a Counter eVar to store and accrue Revenue to Date, but that answers a related, but different question than the one at hand.

One way to answer this question would be to use Segmentation. You could create a segment in which Orders were greater than $300 and less than $400 and then apply this to any SiteCatalyst report. However, you may get future questions asking for different amounts, such as Orders greater than $400 or greater than $500, etc. This would necessitate creating multiple different segments, which might be annoying after a while.

Another approach would be to classify your Order ID eVar report. As a best practice, you should be storing each unique Order ID an a custom eVar as described in this blog post. Once you are doing this, you could classify all Orders into buckets so items in each of the rows shown here would be grouped into the correct Revenue Band using SAINT Classifications:

However, this would be a pain to keep updated so I would steer away from this option.

So what would be the easiest way to see SiteCatalyst data by Revenue Bands? My advice is to simply identify the Revenue Bands that you care about, and use some tagging (or a processing rule) to pass these Revenue Bands to an eVar on the order confirmation page. For example, let’s say you want one Revenue Band for “Under $50,” another for $51-$100 and then after that for each one hundred dollar range. You can work with your developers to map this out and then set the appropriate value to an eVar on the order confirmation page. Regardless of how it is set, the end result is an eVar with various Revenue Bands such that you have a report like this:

Obviously, you can also capture the raw revenue amounts in an eVar and use SAINT Classifications to group into Revenue Bands. This would provide more flexibility, but also adds a bit more work. If you are set with your Revenue Bands, I would use the preceding approach, otherwise just pass in the raw Revenue Amounts. However, if passing in raw Revenue amounts, I highly suggest you remove the “cents” portion of the revenue amount so your SAINT Classifications are much easier!

Regardless of which approach you choose, by simply adding the Orders metric to the resulting report, you can see Order percentages for each Revenue Band. Since this is an eVar, we can also break this report down by any other eVar such as Visit number, Product or Marketing Channel. Conversely, we might want to take a report like Marketing Channel and break it down by this new Revenue Band eVar to see a report like this:

This new eVar can also be used for segmentation purposes and actually makes the building of segments a bit easier (in my opinion).

So there you have it. A simple way to add Revenue Bands to your SiteCatalyst reporting…Enjoy!

As a follow-up to Adam’s Cohort Analysis post for SiteCatalyst I wanted to provide an example of how you can easily translate a standard output from Adobe ReportBuilder into the cohort view. I have seen some other posts on how to create a cohort analysis in Adobe ReportBuilder but they all seem to require a lot more work than you should have to put into a dashboard if you use a few more Excel tricks. The following dashboard shows you how you could create a cohort view without having to create a gazillion segments or a bunch of different ReportBuilder requests in the same workbook. Keep in mind you may still have to do some of that extra work if you aren’t implemented correctly but hopefully you have implemented in such a way that doing important analysis like this is easy for you.

What This Report Gives You

I think the coolest thing about this example, and the real value that the data provides, is that you can see the average attrition for each cohort over time. The cohort table below gives you the revenue attrition for each cohort for every month that cohort has been alive. However, I like to end it all with a simple output that is easy to understand. So you’ll notice that I stuck an Average Attrition column at the end which gives a single number representing the cohort’s performance over time. You can see in this example that the Feb-2012 cohort has had the most attrition (click for a larger view).

Once you have identified a bad or good cohort you can then investigate what kind of promotions or programs may have been in place for that group. Those may all contribute to the poor repeat business.

How to Make This Report

Before starting, keep in mind that there is a lot of date recognition going on in this example using custom American dates. The way Excel recognizes dates varies by local so you may have to adjust your classifications to work better for your region if it gives you trouble.

First, insert your ReportBuilder request. In Step 1 of ReportBuilder pick the Original Purchase Month classification and ensure that the time range encompasses all the data you want to look at.

On step 2 add the Month dimension from the “Dimensions” tab and include Revenue from the metrics tab. Insert the request into cell A5 of the worksheet. Notice that I also adjusted the report to include the“Top 1-10000” values. This is much more than I need but shouldn’t hurt if you have your date ranges correct.

With the ReportBuilder request inserted in the workbook and if you are using the same sort of data as shown in the example then that may be all you need to do. Continue reading, though, if you want to learn about the rest of the formulas.

1. Start creating the table by setting up your start date in cell G6. This formula looks at all the dates under Original Purchase Month and takes the minimum date (the oldest date). This will establish the starting point of our table which will update automatically as you pull in different dates. Note that this is an array function which you have to press control+shift+enter to input. I’m using an array function here to evaluate every date individually otherwise the MIN function doesn’t work. If you are using a more standard date format for your classification you might not need the DATEVALUE in the array function.
2. In cell G7 I use this formula to increment the month up for each row as it is copied downward.
3. In cell H6 is where the real magic happens. This is another array function (remember to use control+shift+return) and it will match the Original Purchase Month on the same row with the Month that is X number of months ahead. X is determined by taking the column number that the cell is in and subtracting the column number at the beginning of the table. This is a good trick for making an auto-incrementor right in the formula. It will count up the months as you drag the formula over. The thing that really makes this an array function is the two MATCH criteria we have since we need to look for the right Original Purchase Month and Month.
4. I hate doing manual work so I dragged the formula from cell H6 across the whole table. Then, to account for any cells that generate an error (because there is no data for that month) I applied conditional formatting to make the “#N/A” a super light gray so you know it is there but it isn’t in the way.
5. The last part is the easiest part. You now make a similar table below (cell H22), calculate the change from month to month (see cell I22), stick an average on the end (column T), and apply some quick conditional formatting. As you apply the formatting be sure to apply separately to the body of the table and the averages since those are really different sets of data to evaluate.

Final Thoughts

This was an example around monthly time ranges. Keep in mind that you could do week or other granularities. Just make sure you have a classification in place that matched that granularity.

Another thing I would only do for this example is include the final table on the same sheet as the source data. For a real dashboard I would move the data and intermediate steps to a different tab and just show the final report on the first tab.

We’ll, there you have it…a workbook that easily translates a typical ReportBuilder output into a cohort table. Enjoy!

Recently, while working with a client, I got into an interesting discussion about doing web analysis around key dates in their marketing program. There are many cases in which milestone marketing events take place on specific dates and clients ask me if there is an easy way in SiteCatalyst to slice and dice data by those key dates. What web analyst hasn’t had a situation where metrics spike up or down on a date or date range and you have no idea why! This is a topic I have dabbled with over the years, but this situation forced me to think about it a bit more deeply. The following will share some ideas I had related to this in case this is a question your organization has as well.

Key Date Reporting

As I thought about this scenario, it dawned on me that there is not a great way to report on key dates in SiteCatalyst. Obviously, you can look at any metric report and see spikes in website activity by date. For example, when I worked at Salesforce.com, around the time of our Dreamforce conference, we would see a tremendous spike in Form Completions around the conference dates that might look like this:

From this report, we can surmise that something happened around these dates. If you work in Marketing at Salesforce.com, I guarantee that you would know that these dates coincide with the Dreamforce conference, but what if the marketing event is something much smaller. A targeted e-mail blast or a social media campaign? What if there were only a modest increase in traffic and metrics on a specific date? I think back to how many times I was called into some executive’s office asking why a particular metric or conversion rate changed on a specific date. I also remember how many times we had to copy a SiteCatalyst chart to a PowerPoint presentation and annotate it with a bubble indicating why there was an increase or decrease. Eventually, SiteCatalyst began adding some ways that you could annotate charts in SiteCatalyst using the Calendar Events feature. This feature allows you to specify a date or date range and add a note to reports in that time period as shown here:

However, adding notes to reports doesn’t allow you to do much in terms of reporting data. Let’s say that you wanted to see the Average Order Value (AOV) for your website during the Black Friday period and compare it to the AOV during other key shopping periods (i.e. Valentine’s Day). Unfortunately, Calendar Events won’t help you very much. It isn’t even easy to compare conversion rates for two date ranges using Segmentation since it is difficult to create a segment on date ranges in SiteCatalyst (unlike Adobe Discover) and even if you could, there is no easy way to compare segments or compare date ranges for Success Events or Calculated Metrics in SiteCatalyst (can only be done for eVars and sProps). Your best bet would be to use Adobe ReportBuilder and pull a data block for the Valentine’s date range and a separate one for the Black Friday date range and compare the two. But what if you want to do this type of comparison natively within SiteCatalyst? Are you out of luck? Have no fear, Omni-Man is here to show you how to do this!

Key Date Segmentation

Back in 2011, I wrote a blog post recommending that each SiteCatalyst implementation have a Date Stamp eVar. The purpose of this eVar was to record the date that Success Events and eVars were set and its primary use was for segmenting on dates. At the time, I was using this eVar to look for actions that took place in the past within SiteCatalyst since only Discover provided the way to segment on dates natively. As I thought about the preceding key dates issue, the idea struck me that my client could leverage this Date eVar to enable additional web analysis for key dates. To do this, you can apply SAINT Classifications to the Date eVar and denote key marketing dates for items normally found in a marketing campaign calendar. Once these items have been uploaded to SAINT, you have an eVar value that can be used to segment data by date ranges of your choosing.

Let’s walk through the creation of this solution. First, you would set the current date to an eVar in each website visit as described in this post. Next, you would use the Administration Console to apply a SAINT Classification to this Date eVar. In this case, we will do just one classification and call it “Key Marketing Dates.” Next we will fill out the SAINT Classification file with some of our key marketing dates. Note that you can leave non-key dates blank or set a dummy value of “No Key Events” on dates having no key marketing events. Here is a sample SAINT file:

Once this SAINT file has been uploaded and propagated to the SiteCatalyst servers, you can open the classified report:

In this report, we now can see a row for each “Key Marketing Date” which is an aggregation of the specific dates associated with that key marketing date label. From here, we can add any metrics we’d like and can compare metrics for those dates. Keep in mind that these rows can contain one or multiple dates depending upon how you have classified the Date Stamp eVar. In addition to the above “ranked” report, you could switch to the trended view to see one metric trended by up to five Key Marketing Date values. It is also possible to break this report down by any other eVar report using Subrelations. For example, you might like to see the above report broken down by Products.

Another powerful use of this concept is the ability to filter Conversion Funnel reports for these key date ranges since it is now treated like any other eVar:

Finally, you can use these Key Date ranges as segmentation criteria since all SAINT Classifications can be used as segmentation criteria:

A Few Gotchas

As is often the case, no solution is perfect. If you have marketing campaigns or key dates that overlap, things get tricky. One way to address key date overlaps is to list both values in the classification value. Alternatively, you could also create more than one SAINT classification and have each SAINT column designated for a specific type of campaign. For example, the first column might be reserved for e-mail campaigns, the next column might be reserved for social media campaigns, etc. That would allow you to have multiple “Key Dates” for the same date stamp value. However, my hunch is that the above solution will work for most companies.

Another potential issues is that you will only see data in the Key Marketing Date report if the date range you have selected includes the dates that were classified using SAINT. Therefore, when running these types of reports, it would be advantageous to use a longer timeframe (i.e. year).

Well, there you have it. What do you think? Have you done something similar? If so, please share your ideas here as a comment…

Many online marketers have a desire to test out different conversion flows on their website. Whether those flows are for an alternative checkout process or a new application process, the overall desire is the same. By testing out an alternative conversion flow, you can see how website conversion differs and find opportunities to optimize your website and boost conversion. In this post, I will share how you can track these alternative conversion flows in Adobe SiteCatalyst.

Conversion Flow eVar

Luckily, tracking alternative conversion flows is easy in SiteCatalyst. As you probably already know, SiteCatalyst provides Conversion Variables (eVars) that area meant to be set and used to break down various website conversion events (Success Events). Therefore, eVars can be used to store the names of your various conversion flows. For example, let’s imagine that you work for a credit card company and have a standard 4 step application process, but want to test out a streamlined 3 step process. To do this, all you need to do is create a new “Conversion Flow” eVar and pass the appropriate value to it at the start of each process flow. If the current website visitor has been shown the 4 step process, you would pass in a value of “credit-card:4-step” and if the visitor was shown the 3 step process, you would pass a value of “credit-card:3-step” to the eVar. This simple action allows you to segment your website success events into two buckets and see how each conversion flow plays out with respect to conversion:

In this example, we can see that the 3-step process looks to be converting better than our default 4 step process. As always, this new conversion flow eVar can be broken down by other eVars (i.e. Campaigns) and can be used as part of a segment in SiteCatalyst. If you want the results of the test to be limited to one visit, you would set the eVar expiration to “Visit” but if you have cases where you want to retain which flow they were in beyond the visit, set the eVar expiration accordingly (i.e. Month).

Another thing to keep in mind when using this conversion flow eVar is that it can be used over and over again. Once you are done with the preceding conversion flow test, you can re-use the same eVar for other conversion flow tests. When re-using this eVar, you will just want to make sure that preceding tests are completed. I have seen some clients who try to cram too much into a conversion flow eVar and forget that subsequent values will overwrite preceding ones if values are passed to the same eVar.

Concurrent Flows or Tests

So what do you do if you have multiple conversion flow tests taking place simultaneously? For example, let’s say that in addition to the 3 vs. 4 step conversion flow test above, you are also testing landing page A vs. landing page B? This presents a real quandary, since SiteCatalyst does not have a great way to deal with this.

The easiest way to track multiple conversion flows or tests is to use multiple eVars. I suggest that you identify the general types of flows or tests you will have and assign an eVar to each. For example, if your website routinely does landing page tests and conversion flow tests, you might reserve one eVar for each. Each visitor would be assigned a value in both eVars and you can break one down by the other. For example, in the preceding example, if visitors were assigned a landing page value in an additional eVar, the above report might look like this when broken down:

Obviously, this approach has some limitations since, if you do a lot of different types of tests, you will use up many eVars, but this is probably the most straightforward approach.

The other approach, albeit one that I have not yet tried with a client, is using a List Var to store the various test values. As you may recall, SiteCatalyst provides three List Vars that allow you to store multiple values in one eVar. I don’t see why you could not use a comma-separated list of values and put all of the various tests that a visitor is part of in that eVar. However, since I have not yet tried this, there may be some unforeseen downsides to doing this. For example, there may be cases in which you need to remember which flows/tests visitors have been in and persist those values to the List Var to avoid a string of two or three test values being overwritten by a single test value deep within your website. If you are going to try this approach, I suggest you pre-pend each value with the type of test it relates to such as “landing:control” and “app-flow:4-step” so you can differentiate each in the List Var report. However, for now, I suggest that you begin with the multiple eVar approach.

When I work with retailers who use Adobe SiteCatalyst, one topic that often emerges is the best way to handle the tracking Product ID’s and SKU’s. In this post, I will outline the challenges that exist and share some ways to handle product and SKU tracking in SiteCatalyst.

The Product vs. SKU Dilemma

The primary challenge that arises when it comes to Products and SKU’s is that there are often cases in which you have to set conversion Success Events at the point you know only the Product ID and other cases in which you know the Product ID and the detailed SKU. This is best illustrated by an example. Imagine that you are a retailer and one of the products you sell is a sweater. At the point that a website visitor views the product page for the sweater, you would want to set a Product View Success Event and the Products Variable (s.products). In this case, you most likely have a Product ID for the sweater being looked at by the visitor so you might pass that to the Products Variable such that your tagging looks like this:

s.events="prodView,event1";
s.products=";ProductID-111";

So far so good. However, now let’s assume the website visitor chooses a color for the sweater (i.e. blue) and adds it to the shopping cart. In this case, you probably still know the Product ID, but also have a more detailed SKU that represents the sweater with the color being “blue.” Now you have two tagging choices. During the Cart Addition (scAdd) Success Event, should you pass the Product ID # (ProductID-111) or the more detailed SKU as shown below?

s.events="scAdd";
s.products=";SKU-111_2";

The issue with the preceding code is that your Products report will be disjointed since Product Views will be tied to Product ID’s and Cart Additions (and presumably Orders and Revenue) will be tied to the SKU ID. Here is what a sample Products report would look like if the above visitor were the only visitor to the website:

This is clearly not ideal since you’d like to see a full funnel report for each Product or SKU. While we have the option of cleaning up this report by applying SAINT Classifications to roll it up by Product ID, this can be time consuming. Therefore, let’s look at a few ways to improve upon this reporting.

Solution #1 – Product ID Only

If our goal is to produce a clean Products report such that metrics are consistent for each Product ID, one approach is to only pass the higher-level Product ID to the Products variable for all shopping cart Success Events. In the preceding example, this would mean passing a value of “ProductID-111” with the Product View event and all other shopping cart events. This will allow you to see drop-off between these shopping cart Success Events by Product ID as shown here:

This is the most basic solution, but has one major drawback – it is not possible to see detail below the Product ID. Since you are only setting Product ID’s, there is no way for SiteCatalyst to magically allow you to breakdown the shopping cart Success Events by SKU since you haven’t provided the SKU. This approach works if your products don’t have detailed SKU’s, but if they do, you might find this option limiting and consider moving onto the next approach.

Solution #2 – SKU Merchandising

If your organization subdivides Products into SKU’s at the Cart Addition step, I suggest you use a different approach. In the past I have discussed Product Merchandising, which is a way in SiteCatalyst to associate an eVar value with a specific Products Variable value. Product Merchandising can be used in this situation to bind a SKU to each Product ID using a new SKU Merchandising eVar. In this case we will ask ClientCare to enable a new Merchandising eVar using the “Product Syntax” approach. Once this is done, we can pass the Product ID to the Products Variable as shown in the above solution, but additionally pass the SKU to a new Merchandising eVar whenever it is present:

During the Product View:

s.events="prodView, event1";
s.products=";ProductID-111";

During the Cart Addition:

s.events="scAdd";
s.products=";ProductID-111;;;;evar10=SKU-111_2";

Keep in mind that if we wanted, we could pass in the actual SKU value (i.e. “Blue” as the color) instead of using the SKU #, but passing the SKU# is ok since we can use SAINT to classify it later.

So far this may not seem to get us much further than we were previously, but as I will show, this set-up does make a big difference. First, you can see a complete funnel by Product ID as shown above by using the Products Variable. But now we have an additional eVar that can be used to see the conversion funnel by SKU. To do this, simply add shopping cart metrics to this new SKU eVar report and you can see everything except Product Views (since those don’t have a SKU):

Since you have two different variables, you can also use Conversion Subrelations to break the Product ID down by the new SKU eVar to see the Product ID metrics broken down by SKU for all shopping cart metrics except Product Views:

Final Thoughts

As always, there are many different approaches to things in SiteCatalyst, but hopefully the preceding gives you some things to consider when dealing with Products and SKU’s. If you have other cool approaches you have used, please leave them as a comment here. Thanks!

When working with SiteCatalyst clients, I often see them ask questions related to how often a particular Success Event takes place at least once during a visit. Examples of this might include the following questions:

• In what percent of visits do visitors add an item to the shopping cart?
• How often to visitors who add items to the cart reach checkout?
• What percent of visits do visitors conduct an onsite search?

At first glance, these seem like easy questions to answer, but I see clients making mistakes with these questions. For example, let’s say that you want to answer the first question above and see the percent of all visits that add items to the shopping cart. Most clients would approach this question by creating a calculated metric that divides Cart Additions (scAdd) by Visits. While this seems logical, it will not give you the correct answer, since visitors can add multiple items to the shopping cart within the visit. If Visitor X adds three items to the cart in the visit, the formula in our calculated metric would be:

The issue is that since most people look at this metric for all visits, the individual Cart Addition numbers are obfuscated and you are often seeing an inflated percentage for Cart Add/Visit %. In fact, the same issue applies to all of the questions listed above. If you are looking to compare Cart Additions to Checkouts, multiple Cart Additions or Checkouts taking place in a visit could inflate your ratio.

So how would you resolve this issue? There are several ways in SiteCatalyst to accurately report on the preceding questions so I will share the various methods at your disposal.

Using De-Duped Success Metrics

The easiest way to resolve the preceding dilemma is to set an additional “de-duped” version of metrics that you want to see in calculated metrics like the ones above. Personally, I wish Adobe provided an easy way in SiteCatalyst to see a de-duped version of every Success Event, but that is not currently available. Therefore, you will have to create a second Success Event for those metrics that you want to use in these types of Calculated Metrics. Keep in mind that you are limited to around one hundred Success Events so you won’t want to do this for all of your Success Events, so use your best judgment.

In this case, let’s assume that you are interested in seeing an accurate percent of visits in which a Cart Addition took place. To do this, every time you set the normal Cart Addition Success Event (scAdd), you should set a second, custom Success Event and call it something like “Cart Adds (De-Duped).” For this second Success Event, you will want to apply Success Event serialization to prevent the event from being counted more than once in a visit. I would recommend using “Once per Visit” serialization since it requires less tagging and can be enabled by ClientCare. By setting this new Success Event, you will have a count of how often visitors add items to the cart, but it will only be counted once, regardless of how many times the visitor adds items to the shopping cart within the visit. When this is complete, you can create a calculated metric that divides this “Cart Adds (De-Duped)” metric by the Visits metric to see an accurate ratio for visits in which at least one Cart Addition took place:

To see the impact of this, let’s imagine that you had five website visitors that performed the following actions:

In this scenario, if we used a calculated metric that used Cart Additions and Visits, our ratio would be 120% for these five visitors. Obviously, this isn’t representative of what really happened. However, if we use our new “Cart Additions De-Duped” Success Event, we will only count one Cart Addition per Visit and see the following data:

Doing this provides a more accurate representation that 60% of visits contained at least one Cart Addition. And since you now have a Calculated Metric that is trustworthy, you can see the answer to this question trended over time using a report like the one shown here:

This Calculated Metric can be easily added to a SiteCatalyst Dashboard and can be used like any other Calculated Metric.

Note: Some companies implement the Carts (scOpen) Success Event at the first shopping cart addition and de-dup it using “Once per Visit” serialization. This is a similar approach, so if you are doing this, you can use the Carts Success Event divided by Visits to see the same cart rate.

As you can see, the addition of one more Success Event allows us to greatly improve our reporting for cases in which you want to see if something happened at least once in a website visit. If you look at the other questions posed above, you will see that the same concept can be applied. For example, if you want to see an accurate ratio of times that visitors do at least one Cart Addition and one Checkout, you might create a “De-Duplicated” version of Cart Additions and Checkouts and use those versions in your Calculated Metric.

Keep in mind that these new “De-Duplicated” metrics will not be accurate when used in Conversion Variable reports (i.e. Products Report, eVars, etc…) since they will only be counted the first time the Success Event takes place. This means that if a visitor adds three products to the shopping cart, only the first product will be associated with a value in the conversion variable (i.e. Product XYZ). These new “De-duplicated” metrics should only be used in global website calculated metrics and the normal metrics (i.e. Cart Additions) should be used in detailed Conversion Variable reports.

Segmentation Approach

If you are averse to using more Success Events to answer the questions above, it is possible to answer them using Segmentation. I think this method is more cumbersome, but will describe how to do it for educational purposes.

To use Segmentation to answer any “how often did X happen in a visit” question, you will have to create a Visit-based segment that isolates visits in which the Success Event in question took place. Using the preceding example, if you wanted to see how often visits contained a Cart Addition, you would create a Visit segment and add the Cart Addition Success Event to the segment as shown here:

Once you have this segment, you can open the Visits report and see how many Visits took place in the desired timeframe. For this example, let’s use the data for the five visitors we described above. In this case, three of the five visits would qualify to be included in the segment so our Visits report would show a total of three. Now you can write that number down and then remove the segment (go back to “All Visits”) and look at the same Visits report for the entire population. In this case, you would see a total of five visits, so you can divide the three Cart Addition visits by the total visits to get the same 60% we saw above. If this is something you will be doing on a recurring basis, you can automate this process using Adobe ReportBuilder. To do this, you would create two different data blocks in Excel – one for all Visits and one for Visits with the above segment applied. Then you can create a formula that divides the totals of these two data blocks and trend it over time using a custom graph.

As I mentioned previously, I think this approach is more time consuming, but it does save Success Events if that is a concern.

Page Name Approach

In theory, there is another way to answer these types of questions, though I don’t recommend it. This approach involves using Page Names. To do this, you can use Adobe ReportBuilder to isolate the specific page on which a Success Event takes place (i.e. Cart Addition page) and look at that pages’ Visit count and divide it by total Visits. However, since page names can be unreliable and it still requires work in Adobe ReportBuilder, I don’t recommend this approach.

Final Thoughts

If you ever have questions in which people ask you how often something took place at least once in a website visit, I hope that you will think about these concepts and make sure that you are accurately answering them for your organization. While some of these concepts are a bit complex, they can save you the embarrassment of reporting inflated conversion metrics to your organization.

You have always been able to use segments and calculated metrics in Adobe Discover but now you can include segments WITHIN your calculated metrics! This greatly increases the flexibility of your metrics and will enable you to do more comparison work within Discover which historically has been very difficult.

As we walk through this feature let’s use an example. Assume that you are interested in understanding the mobile vs non-mobile breakdown of your campaigns. Previously you could segment to get the same data but now we can build out metrics that make this easier and help to differentiate mobile from everything else. This is useful since, by default, there is only one mobile-specific metric in Discover–mobile views.

To start, access the new metric builder by going to the Metrics pane on the left-hand side, select the options icon, and then select “Calculated Metric Builder”:

You will then see the Metric Builder which allows you to drag metrics and operators over to the formula field. Below is how you would build a simple Order Conversion metric:

Adding Segments to Your Discover Metrics

Now we can make it really fun by adding segments to the mix. The segments are hiding behind the metric tab on the top left. For our mobile example, let’s say that we want to build a metric that gives us the percentage of visits that were from a mobile device. To do this you would drag over and divide two visits metrics, apply a “Visits from Mobile Devices” segment to the numerator (as shown in the screenshot below), and adjust your metric name and formatting as needed:

After you save this metric you can then include it in your campaigns report to see the percentage of the campaign that came from mobile. You can also sort by this metric to see what campaign has the highest percentage of mobile usage.

Include Calculated Metrics in Other Calculated Metrics

After you start building your calculated metrics you may want to include an existing calculation in another metric. The new builder lets you do that as well. Once you create a metric, as we did with our “% Visits from Mobile” metric it will appear in your metric list with a small chart-looking icon next to it. We will build on this to get the percentage of traffic NOT from mobile. We do this by entering a number field of “1” (red arrow in screenshot below) and then subtract the previously-created “% Visits from Mobile” metric as shown here.

Other metrics you could build for our mobile report may include:

Mobile Conversion 

Non Mobile Conversion (you have to make the Non Mobile segment first)

Tablet Visits as a percent of all Mobile Devices (you have to make the tablet segment first)

Return Mobile Visits as a percent of all Mobile Devices (you have to make the return mobile segment first)

You can go on an on but hopefully that gives you an idea of what you could do.

Comparisons using Metrics

If you think about comparison, they are just an extension of the new formulas that we can now make. All you have to do is create a metric that compares the data points you are interested in. To make this easier, Discover lets you select two columns that are already in your report and you can right click on the column header to select some of the quick calculation options. I wish it had an (A-B)/B option in the list but for now we will use an A/B Percent comparison to quickly see the percentage change between our Mobile and Non-Mobile Conversion metrics. Here is where you select the option:

This will then give you a new column with the comparison as shown here:

That makes for an easy comparison. If you would like to tweak the comparison you can right click on the column header and select edit. I would then modify the comparison as follows to get an (A-B)/B comparison instead of just A/B.

Be careful to keep track of what is in your comparison and use meaningful names since the metric doesn’t dynamically reference the columns that it was built from. If you were to switch out one of the original metrics the comparison would not automatically update. That would be a cool feature, though.

Final Thoughts

While this functionality has been in tools like Adobe Insight for a long time I am happy to see it available in Discover. It provides much more flexibility in creating metrics and comparisons. I had a client once in the theme park business that liked to segment their orders by the many different checkout types they had. They could use this to create specific metrics for each type without having to burn up a lot of events. Hopefully this makes its way into SiteCatalyst.

I was recently working with a client who had some interesting questions. In general, he wanted to see different derivations of how long products had been in the shopping cart prior to being purchased. Some of his detailed questions included:

1. Of all visitors hitting my website today, how many already have items in their Shopping Cart (which is persistent on this website)?
2. For those visiting the site today, for how long have they had items in their Shopping Cart? (i.e. 1 Day, 10 Days, etc…)?
3. At the time visitors purchase items, for how many days had they had items in the Shopping Cart?
4. Is it possible to see cart duration by product?

While it is easy to see why this might be interesting to know, after some reflection, it turned out to not be a very straight-forward thing to understand/report upon using Adobe SiteCatalyst. I wrestled with a few different ways to answer these questions, but ran into a few roadblocks. In the end (and after bouncing some ideas off some friends), I settled on an approach that seemed to work (by no means the only one), so thought I would share it in case it is helpful to others out there with the same questions. If you have the Adobe Insight product, solving this question is much easier, but this post will deal with answering it for those of us who only have SiteCatalyst.

Establishing Cart Addition Date

The first challenge is to identify the date on which each visitor added items to the Shopping Cart. This is similar to an earlier post I had about Date Stamping, but with a twist. In the Date Stamping post, we just set the current date of each visit, but in this case, we want to set the date that a Product was added to the Shopping Cart (I suggest you use an eVar with original value, expiring at the Purchase event). Once you have done this and have data processing for a while, you can open the new Persistent Cart Date eVar report and add the Visits metric and see a report like this (in this example using the current date of 3/3/12):

Here we can see that we have answered our first question. By looking at the “None” row, we can see that approximately 92% of the time, Visits are from people that have not previously added items to their Shopping Cart (does not include those pesky cookie deleters!). If you broke this report down by the Products variable, you would be able to see the actual products that were associated with each date:

Identifying Duration in Cart

Our next challenge is to determine exactly how many days products have been in the shopping cart. As mentioned above, there are actually two flavors of this question. The first is to see how long ago products were added to the shopping cart at the time the current visit takes place, and the other is to see how long ago products were added to the shopping cart at the time a purchase takes place. We’ll start with the former.

With the preceding report and its breakdown by the Products variable, we have all of the key elements needed to figure out how long items have been in the shopping cart. However, to calculate this, it’s easier to use Microsoft Excel so I suggest you move the data to a spreadsheet using ReportBuilder or Data Extracts and then adding some formulas to break out the data as shown here (I have replaced the None row with the value “NO CART” in Excel):

Once this is done, you can create a pivot table to group like items together and build a report like this (for illustrative purposes, I only created a few rows but in reality there would be many more rows of dates in this report):

In this pivot table, we can still see our same 8% of Visits with no items in the shopping cart, but now we can see that our largest percentage is tied to cases where visits had items in the cart for 6 days. If you had more data, the next logical step would be to group the number of days into meaningful buckets using SAINT Classifications or directly in Excel. Also, note that instead of moving data to Excel, another way to create a report like the one shown here would be to create a SAINT Classification file that maps the current date to the number of days in the past (i.e. 3/2/12 = 1 Day), but we’d have to update the SAINT file each time to adjust for the current date which would be a pain!

Next, since we have the report data by product ID, we can also break down the above pivot table by product to see which products are associated with each # of Days in the cart:

Conversely, if your organization is more product-focused, you can flip the pivot table and look at Product ID’s by days in shopping cart like this (which will have more values per product ID when the data is real!):

You will note that these reports help us answer the first cart duration question which is how long products were in the shopping cart at the time a Visit took place, but the same process can be used to answer the second question which is how long products have been in the shopping cart at the time of purchase. To do this, all we need to do is modify our original SiteCatalyst report to show Orders instead of Visits like this:

Note that in this case, we should no longer see a “None” row since to complete an Order, something must have been added to the shopping cart prior to purchase. It’s likely that you will also see that the majority of the rows are for the current date (which in this case is 3/3/2012). Once you create this report, you export it to Excel and create the table and pivot table in the same manner described above. This might result in a report that looks something like this:

Product-Specific Cart Duration

The last question to be answered is related to the duration in cart of each product. In the examples above, we have set a date when products were added to cart, but this date was a general one or the date that the first product was added to the shopping cart. There will be cases when you want to get more granular and know the date for each product since visitors can add a product to the cart on 2/28/12 and then add different products to the cart on 3/1/12. If you desire this level of detail, in addition to setting the Persistent Cart eVar described above, you can set an additional Merchandising eVar (with “Original Value” allocation and expire at the “Purchase” event). This will “bind” the date to the specific product that is being added to the shopping cart. Since this is more complex, I won’t go into all of the intricacies here, but if you have questions, feel free to contact me.

Final Thoughts

As you can see, this is a somewhat complex solution, but should get you the answers you need. There may be other ways to answer these questions, so if you have tackled this, feel free to leave a comment here. Thanks!

Every once in a while, especially when I am working with large clients, I ask them a simple question that befuddles them. The question I ask is this:

“Do you know much money you are spending each month on paid advertising that is being used by your own internal employees?”

After they pause for a moment, and realize that they don’t in fact know the answer to this, I sometimes see a spark of panic in their eyes. If I could read their minds it might go something tike this:

“Why is he asking this? Should I know that? I’m sure our employees are smart enough to not use paid advertising like paid Google keywords or display ads to get to our own website right? I hope so… But what if 10% of our ad spend is on lazy employees coming to our website through paid search? Urghhh!!!”

At this point, I assure them that they are probably not wasting a huge amount of their marketing budget on their own employees, but the reason I ask is that it is very easy to know and make sure that you don’t have an issue. Therefore, in this post, I thought I’d show you a simple way to quantify this.

Excluding Employee Traffic

The first step in seeing how much you are spending in advertising on your own employees is to isolate your own internal employee traffic. The good news is that this is something you should already be doing today. If you aren’t, you should start doing this right away. The easiest way to exclude employee traffic is to identify the corporate IP address ranges that your company uses. While this is not perfect, it should be close enough. Even if you have remote employees, hopefully they are using a secure VPN which will route their traffic through your corporate IP ranges (one hint for Adobe SiteCatalyst customers is that if you have IP ranges that change frequently I would suggest implementing a DB VISTA rule that has all of your IP address ranges since that will allow you to add/remove them as needed). Once you know these IP ranges, you can either move that traffic to a different data set (i.e. report suite for Adobe SiteCatalyst customers) or tag them as “employees” in a web analytics variable and build a segment to isolate this traffic. Regardless of how you do this, the ultimate goal is to have a data set or segment that you are pretty sure represents your employees.

External Campaign Reports

Once you have your employee traffic, the next step is to look at your campaigns report for this employee segment. If you are doing a good job with your external campaign reporting, you should have a way to see how many visits you are getting from each paid advertising element or from each marketing channel as a whole. For example, here is a sample SiteCatalyst report showing how many Paid Search (SEM) Visits took place as seen in a report suite that contains only employee traffic:

As we can see here, we’re getting a few hundred visits each week. Next we can compute an average cost for Paid Search advertising and get a rough estimate of how much money we are spending on employees for Paid Search. In this example, for the week of September 25th, we had 372 visits from Paid Search and if our average cost per ad was $3.50, our estimated cost would be $1,302 which annualized would be around $65,000. Depending upon the size of your advertising budgets, that could be good or bad. But let’s say that you work for American Express and have over 60,000 employees. It could be the case that you have 20,000 paid search visits from employees in a given month. If the average cost of paid search keywords were $.50, you could be spending $120,000 of your marketing budget on employees! That could get you a few extra web analysts on your team!

Also keep in mind that the same principle applies to display advertising and other marketing channels that cost you money. Finally, if you need to isolate the specific advertisements that are being used, you can do this by looking at the detailed tracking codes in your campaigns report. I have found that it is normally the branded advertisements that are the top culprits.

Next Steps

Hopefully, after doing this quick analysis, you’ll find out that you don’t have any major issues. But if you do find that your employees are being a bit lazy and eating up large portions of your marketing dollars, there are some simple ways to rectify this. I have found that at large companies, most of the time, employees aren’t aware that they are actually costing their employer money. While people like us live and breathe online marketing, your employees may have no concept of how online advertising works. By using the data you create in your analysis, you can spread the word through company newsletters or intranets and educate the company no how much money is being wasted and ask employees to use free tools like SEO links if they need to get to the website.

Besides saving your company a little bit (or a lot!) of money, this is a fun way to show executives at your company the power of web analytics. If the amount of money you save by doing this analysis is significant, feel free to use the data to get you some additional headcount or tools that you have been longing for!

Each year at the Adobe (Omniture) Marketing Summit, customers are given an opportunity to “vote” for new product features while Brett Error reviews them (and cracks a few jokes!). From the rumor mill, it sounds like Brett may no longer be around (??), but even if he isn’t, hopefully the session will live on. Each year around the time of Summit, I like to look back at the past year and think about what SiteCatalyst features are not available that would have helped me and my clients the most. The SiteCatalyst product team is always swamped with great ideas from the Idea Exchange and have been doing a great job of pounding them out. Therefore, this list is not meant to mean that my requests are more important than others they are working on, but rather just ones that I have personally experienced pain for not having (some of them were on my last year list as well which you can read here). All of these ideas are in the Idea Exchange, so if you have experienced similar cases where they would help you out, please vote for them there (shortcut links to items in the Idea Exchange are provided for each) and possibly in the Summit session should they arise…

Segmentation Enhancements

In a recent post, I went through some of the reasons why companies might decide to abandon multi-suite tagging and just rely on v15 Segments instead. Currently, there are a few features holding me back from going “all in” on v15 Segmentation. These are:

1. The ability to compare segments in reports (http://bit.ly/yERLbr). As I mentioned in my previous post, it is easy to compare the same report for two report suites or ASI slots, but it is not yet possible to do the same for two (or more) segments without using Discover.
2. The ability to have security for segments so you can assign who can see data for a segment (http://bit.ly/yh0djM). As Ben Gaines astutely pointed out, many people use report suites for security reasons to determine who at an organization can see which data. It would be great if this could somehow be duplicated using segments. However, I think that this is not possible until my next feature request is addressed.
3. The ability to lock down eVars like you can Success Events and sProps (http://bit.ly/wSMLU3). For years, I have asked the SiteCatalyst team to provide the ability to add User/Group security to eVars. Currently, it is possible to prevent a user or group from seeing a specific sProp or Success Event, but for some strange reason, you cannot do this with eVars. Once you can lock down eVars and you can lock down segments, you can truly secure your data set and cease to rely on multi-suite tagging or additional company logins to enforce security.
4. One item that is unrelated to v15 segmentation and multi-suite tagging, but still related to segmentation, is the ability to segment on a path (http://bit.ly/xzkeTr). There are many cases in which you would want to isolate visitors or visits where visitors navigated in a certain way. Hence, it would be great if you could add a 3 or 4 step flow as a valid way to segment. Since Pathing is available on all sProps, my hope is that this functionality would work for any sProp that has Pathing enabled, not just Pages and Sections.

Multi-Session Enhancements

One of the limitations of SiteCatalyst is that there are many aspects that are only session based. In the future, I would like to see this restriction lifted. Here are a few examples of what I’d like to see:

1. Ability to see multi-session Paths (http://bit.ly/zimT2O) so you can see how visitors navigated the website across multiple sessions.
2. Ability to see multi-visit campaign code attribution (http://bit.ly/yzBTUE) in a way that is better than just first touch and last touch or the Cross Visit Participation plug-in. Even if the current option for “Linear” allocation worked cross-session, that would be a great step forward.

Report Sorting Enhancements

If you spend a lot of time in SiteCatalyst reports, you are familiar with the fact that you can only sort by metric columns. I would like to have the following sorting enhancements:

1. The ability to do a weighted sort so you can easily filter only the top X number of rows before sorting (http://bit.ly/zsJNps). I am sure the following scenario has happened to you at some point. You add a calculated metric like Bounce Rate to a report and then you choose to sort. You end up getting items with a 100% bounce rate, but when you dig deeper you see they have only a few values. What you really want is the ability to filter the report for only the top 50 values and then to apply a sort (like Google Analytics provides). Currently, this has to be done in Excel, but should be native to SiteCatalyst.
2. The ability to sort by the value column (http://bit.ly/ylULpS). There are some cases in which you would like to sort by the actual values passed into SiteCatalyst instead of by a metric column. Currently, you can work around this by using search filters, so this isn’t a super-high priority, but it would be nice to simply have the ability to sort by the value column for times it is advantageous.

Final Thoughts

Obviously, I could list many more, but the above list of items are the ones that I have run into the most. If you have others that you would like to see elevated in priority, feel free to list them here. Thanks!

Every now and then, I run into a unique situation with a client that requires what I call an “Über” Success Event. It isn’t possible to define this easily, so in this post, I will illustrate what it is and when you might want to use it…

eVar Expiration Limitation

For those who faithfully read my SiteCatalyst blog posts, you will have heard me lament two major eVar expiration limitations. The first limitation is that you cannot expire an eVar at either a Success Event taking place OR a time frame (whichever comes first). This limitation can be rough, since there are some cases in which you’d like to expire an eVar when Success Event X takes place, but if it doesn’t take place after three months, you might want to clear out the existing eVar value. Not cleaning out this value could result in that eVar value receiving credit for a Success Event that takes place a year later when it really shouldn’t. I have suggested this change in the Idea Exchange (http://bit.ly/yXqtqS) so feel free to vote for it there.

However, this post is focused on the second eVar expiration limitation, which is that you cannot expire an eVar at one Success Event OR another Success Event. In this case, you basically want to tell SiteCatalyst to expire the eVar when Event X or Event Y or Event Z takes place. Unfortunately, this isn’t possible in the Admin Console, since you can only pick one expiration item (Event or Time Period) from the list. This may not sound like too much of a limitation, but the following example will illustrate how it can cause problems.

Let’s imagine that you are a B2B Lead Generation website that sells its products online or allows its visitors to fill out a form and work with a sales rep to complete the purchase. You have a standard conversion flow with three steps (Event 1, Event 2, Event 3). Each of these steps has an associated Success Event. So far, so good. However, when visitors reach the third step of the process, they can proceed to purchase on line (scCheckout, purchase) or view and submit a form (Event 4, Event 5) to have a sales rep call them and finish the sale.

In this situation, a website visitor can be viewed as successfully completing the conversion funnel two different ways. One way is to purchase online and the other is to submit a form. It’s as if there is a fork in the road, but both paths can lead to a successful conversion. Obviously we can track each of these steps using Success Events, but the following quirky situations arise as a result of this:

1. It is easy to combine both of the final Success Events (Orders and Event 5 in this case) in a regular eVar report by creating a Calculated Metric that adds Orders to Lead Form Submissions (Event5 ).
2. However, it is not possible to use a standard SiteCatalyst Conversion Funnel report since you cannot include Calculated Metrics in Funnel reports (to help me change this, vote for this: http://bit.ly/zl3bUs). There are also a host of other issues with Calculated Metrics that you can read about in the Idea Exchange (i.e. Not available in DW, Can’t segment on them, No Participation, Can’t see totals in reports, etc…) so they are not really meant for “heavy lifting,” so to speak.
3. But the biggest issue is the one I raised earlier. What if we want to expire a bunch of eVars when the visitor Orders OR they submit a Lead Generation Form to a sales rep? We are pretty much out of luck since we can only pick one Event in the Admin Console to use for eVar expiration purposes. Bummer!

As I stated previously, this isn’t an everyday occurrence, but I have seen it wreak havoc on some clients so I wanted to share an easy workaround to solve this last point.

The “Über” Success Event

So now that we have framed the problem, here’s how you can solve it. In the scenario above, what we would want to do is set a new Success Event at the same time that we set both the Order (purchase event) and the Form Submission (Event5). This new Success Event (let’s say that it is Event 20), would be set with every Order and Form submission so it should add up to the total of both. Doing this one simple thing has some wonderful consequences:

1. There is no need to create the Calculated Metric described previously since this new “Event 20” would add up to the same figure of Orders + Lead Generation Form Submissions
2. Unlike the Calculated Metric, you would be able to use this new “Event 20” in a Conversion Funnel so you can have a funnel of Event 1, Event 2, Event 3 and then Event 20 which would represent ALL success (obviously we don’t know if the people filling out forms were truly successful, but for this scenario, let’s not worry about that an assume you know how to do this by reading this post!). This also removes all of the shortcomings of Calculated Metrics I mentioned earlier.
3. But most importantly, if we wanted to expire any eVars when one of these two Success Events takes place, we now have a way to do that. All we have to do is to go to the Admin Console and set the eVars to expire at Event 20!

Hence, setting this extra Success Event that sits on top of the other two Success Events is what I affectionately call my “Über” Success Event! This is just one example of how you can use this concept, but I have seen many more. Enjoy!

If you sell products on your website, you will often find the need to provide detailed information to those browsing your products. For example, below you can see a product detail page for a Gas Grill. As you can see, there are tabs for Specifications, Ratings & Reviews, etc…

One of the things I have been asked by clients is to provide a way for them to see how often each of these pieces of information (usually in the form of tabs) is used. Specifically, I am usually asked the following questions:

• Which tabs are used the most?
• Which tabs are used the most for each product?
• In what order are these tabs clicked in general and for each product?
• Are there certain tabs that lead to conversion more than others?

Therefore, in this post, I will share some tips on how to answer these questions…

Tracking Tab Usage

To start, let’s focus on the easiest question – which tabs are being used most often. To do this, we need to capture the name of the tab each time it is accessed. While I normally use eVar variables over Traffic (sProp) variables, this is one case in which I prefer to use sProps for reasons you will see below. Therefore, when a visitor clicks on one of the tabs on a Product Detail Page (PDP), I like to pass the name of the tab and the product to which it is related to an sProp. For example, on the Product Detail Page shown above, if the visitor clicks on the “Ratings & Reviews” tab while on the “Kenmore 4-Burner LP Gas Grill,” I would pass the following:

s.prop60=”Kenmore 4-Burner Gas Grill:Ratings & Reviews”

By concatenating these values, I know that I had one instance of the combination of this particular product and the specific tab that was clicked. If the page doesn’t reload when the tab is clicked, you may have to use Custom Link tagging to set this sProp. In addition, it is important that you also capture the default tab item, which is normally some variation of “Overview.” In this case, when the Product Detail Page first loads, the value passed to the sProp would be “Kenmore 4-Burner Gas Grill:Overview.” By setting these values to an sProp, you can easily see how often each Product/tab combination is viewed and if you have unique visitors enabled for the sProp, you can see uniques for each combination as well:

Next, you can use SAINT Classifications to group all similar tabs together to see a rollup of use across all products. In the preceding example, we might want to group all cases of “Ratings & Reviews” across all products to see which types of tabs are getting the most action:

Product Tab Pathing

Now that we can see a general idea of which tabs are being used and which tabs are used for each product, the next question we want to answer is in which order are tabs being used. Whenever you want to see sequence in SiteCatalyst, you will want to use Pathing reports. This is the reason why I chose to use an sProp instead of an eVar for this setup since Pathing only works on sProps. In this case, once you have implemented the sProp described above, you can enable Pathing and you will be able to see the order in which tabs are used for each product like this:

However, this sProp and its Pathing capabilities will only allow you to see how visitors used tabs at the product level. What if you want to see a Pathing report that shows how tabs were used regardless of product? Unfortunately, this isn’t as easy as it should be. If you have the Discover product, you can see Pathing on the SAINT Classification we created above, but if you don’t have Discover, you will have to create a second sProp that captures only the tab name and also has Pathing enabled.

Product Tab Influence

Another question I get from clients related to Product Tabs has to do with the impact they have on conversion. For example, they want to know if visitors who view the Specifications tab are more likely to convert than those who do not. In SiteCatalyst, there are a few ways to accomplish this. First, once you have implemented the items above, you can create a Segment to filter sessions or people using specific tabs and see how that segment of visits/visitors compares to those who did not use the tabs. Keep in mind that you can segment on both detailed values (product+ tab) or the classified value (tab only) in the segment builder or Discover.

Another way to see the influence of tabs on KPI’s is to use Success Event Participation. By enabling Participation on the sProp described above for your key Success Events, you can see which ones have the most influence over time. For example, if we turn on Participation for the sProp shown above related to Orders, we can see a report like the one shown here:

In this report, we can see how many Orders each product/tab combination was in the flow of across weeks or months of visits. Then we can create a calculated metric which divides this Order Participation by the number of times each product/tab combination took place to see how influential it was as compared to other product tab combinations (since the numbers are small, in this example, I multiplied by 100 to make the differences easier to see). Obviously, the same principle can be applied to the sProp that does not contain the product as long as you are passing the values natively to an sProp and not creating it via a SAINT Classification. Finally, you could also pass the tab names to an eVar and set the allocation to Linear to spread credit across all tabs that are used, but since you may already be setting the sProp decried above for pathing purposes, Participation may be the logical way to go.

Final Thoughts

Keep in mind that the same principles described here can be applied to other items related to products – not just product detail page tabs. For example, you might have 360 degree views of products, product images, etc. that can all have an influence on conversion. You can treat these items the same as product tabs and capture them as shown above. Therefore, if you are curious about how website visitors are using tabs on your product detail pages or any other supplemental product information you provide, give the techniques shown here a try. If you have other tips on tracking this type of product content, leave a comment here.

When it comes to searching on the Internet, where a particular search result appears in the list of results can make an enormous difference. Companies pay big bucks to SEM and SEO experts to tell them how they can be ranked higher for specific search keywords. While you cannot control all that happens to you on Google or Bing, when it comes to your own website, you have more control over which internal search results you choose to show to your visitors. In the past, I have shown several ways to track what is happening with your internal search, but in this post, I will explore a new internal search topic – how to see if placement matters. After reading this post you will be able to see how each search result placement performs and even be able to break it down by internal search term.

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 ListCollection 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!

I was recently working with a client that had a unique situation arise. This client is well-versed in the usage of the Adobe Discover product and frequently takes advantage of its ability to segment by date. For those unfamiliar with this feature, you might use it to address the following scenario: “I’d like to build a segment of people who filled out a form in the third week of January 2011, but I want to see their behavior for the months of February, March and April.” Here is how this segment could be built using Discover:

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!

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 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. I have also written a more advanced post on Merchandising you can check out. Please comment here and I will do my best to get any question answered. Thanks!

This week the Demystified Partners forfeited our weekly meeting to hang out with our fellow #measure peeps on Google+. We felt that the thread about web analytics technologies and where innovation would surface in our industry needed a deeper discussion. If you haven’t seen the original thread yet, make sure you go check it out. Also, if you need a G+ invite, let us know we’ve got plenty to share. But our exercise was as much about continuing the conversation as it was testing out a new social medium.

Before going live on G+, we practiced for about a half hour, where all of our browsers crashed and we experienced various video connection in’s and out’s as we tinkered with and tuned our machines. By showtime, we had a few stalwart veterans join, including Tim Wilson who was dialed in on a 4G connection while driving home with his wife from camping. As our discussion grew, We added up to nine people, which didn’t quite push the limits of G+ as we had hoped, but it was an all-star #measure cast including: @erictpeterson @adamgreco @mymo @Exxx @tgwilson @joestanhope @OMlee @keithburris and yours truly.

Our conversation began with quips from each of the participants about how we’re still grappling with digital measurement technologies. Despite most of us being in this web analytics industry for years, and in some cases decades. Time passed quickly as we debated from all sides of the vendor/consultant/practitioner perspective. After a brief privacy sidebar, we asked each other where innovation would emerge from in analytics and really why we were pursuing these digital data anyway? I think we edged the needle just a little bit by agreeing that what we do matters because we’re educating our employers and clients on the power of data; and just possibly making the Internet a slightly better place. Ok, when I chatted this in the G+ hangout mid discussion, I warned everyone not to throw up on their keyboards, so I’ll do the same for you. But as cheesy as that sounds, our quorum agreed that wasn’t such a bad goal. What do you think?

So, the technology of G+ did prove that it was up to the task of handling this type of group discussion. People could talk and share their ideas on video or contribute to the conversation using the chat functionality. But we’re curious to know if you’re interested in joining us for a future G+ hangout?

If you are and willing to hang out with us to discuss the hottest topics is digital analytics, let us know because we’ll plan another one soon. Heck, we’ll even make this a regular event if you’re interested. What do you all say?

Over the years, when I have consulted clients who use the SiteCatalyst product, I have encountered some strange implementation items that made me scratch my head. In the beginning, when I saw these odd implementation quirks, I was mildly entertained, but as I saw them more and more, they were soon elevated to “pet peeve” status. Therefore, I thought I’d share some of these items with you to make sure that you are not doing any of them, and also because I am curious to see what other “pet peeves” you may have. Please check out my list (which is by no means exhaustive!) and if you have items that you have seen that bug you, please leave them here as a comment!

Tracking Every eVar as an sProp

I would say that my biggest pet peeve is when clients have an sProp for every eVar they have set (or vice versa). When I see this, it is an early warning sign that the client doesn’t fully understand the fundamentals of SiteCatalyst. While there are definitely cases where you would capture the same data in both an eVar and an sProp, they are usually few and far between. As a rule of thumb, I only set an sProp if:

• There is a need to see Unique Visitor counts for the values stored in the sProp
• There is a need for Pathing
• You have run out of eVar Subrelations and need to break one variable down by another through the use of a Correlation (which will go away in SiteCatalyst v15)
• There will be many values (exceeding the unique limits and you just want data stored so I can get to it in DataWarehouse or Adobe Insight

For the most part, that is it… Beyond that, I tend to use eVars and Success Events for most of my implementation items.

This is why I shudder when I see 40 eVars set and the same 40 sProps set. I find that this only confuses users since most don’t really understand the difference between the two variable types to begin with! Therefore, my advice is to make sure you understand the difference between eVars and sProps and make sure you use the right variable for the right purpose.

Pathing Enabled Unnecessarily

Another item I have seen a lot is when a customer will have Pathing enabled on an sProp that doesn’t change in a session. For example, let’s say you have people log into your website and you store the Customer ID in an sProp. That Customer ID is designed to be the same for each visitor during the entire visit. However, I often see clients who enable Pathing on this Customer ID sProp. My hunch is that they think this will show them the paths of that Customer ID, but the truth is that it will show no paths for each Customer ID so it is a complete waste of time. Keep in mind that pathing is only useful if values change in the same session. If you pass the same value in on every page of the session, SiteCatalyst will see that as a Bounce of 100% for every Customer ID! Since Adobe (Omniture) will only let you have so many variables with Pathing enabled, you need to make sure you are using them wisely!

No Friendly Page Names

The next pet peeve is when clients don’t pass any values to the Page Name variable and use the default of the URL. This really makes my blood boil! There are so many downsides to doing this when it comes to the Pages report since it impacts Page Views, Unique Visitors and Pathing. For better or worse, the Pages report tends to be a very popular one and I feel that, even if just for the perception of the integrity of your web analytics implementation, you need to take the time to make sure this report is accurate and understandable. For more information on this topic, please refer to my Page Naming Best Practices post by clicking here.

Passing Query Strings to Page Name Variable

On a related note, I have another gripe related to the Page Name variable and it has to do with query string parameters. Many times I find that companies are including query string parameters in the Page Name variable. This is a really bad idea. Here are two common things I see:

• When a visitor arrives to the website from a campaign, the URL will have a campaign code in the query string parameter and pass this to the Page Name variable (i.e. zyz corp:home:homepage:cid-12345)
• A company will have a search results page and include the keyword/phrase that the user searched upon to get to that page in the Page Name (i.e. zyz corp:search:searchresults:user manual)

Both of these examples involve the company having one page name essentially split out into hundreds (or thousands) of versions of the Page Name due to the query string parameter. Creating many versions of the same page has the effect of losing Visits, Unique Visitors and Pathing for the true Page Name. Most of the time this situation can be solved by using one Page Name and passing the query string parameter to another variable and using a Correlation. If you really need to have these extra query string parameters associated with pages, I recommend using another sProp instead of the Page Name variable…

Reports with No Data

Another thing I see quite often are implementations that have tons of variables labeled, but that have no data. As a rule of thumb, I recommend you disable any variables that have no data or at a minimum hide them from the menus using the Admin Console. There is nothing more frustrating to an end-user than opening up a report, getting excited to see the data and then realize that there is none! Besides being annoying, it hurts the credibility of your web analytics program. When I am in the midst of a new implementation and things are in flux, one thing I do is to put all reports that are coming, but have no data in ALL CAPS or I add the phrase “(COMING SOON)” after the variable name. This helps me see which variables are left to do and which ones I can begin to QA. However, once the implementation is semi-stable, I urge you to hide variables that are not coming for a while so you don’t annoy people unnecessarily!

No Menu Customization

On a related note, how many SiteCatalyst implementations have you seen where they use the default menu structure? Why would you want to tell users to look in “Customer Conversion 1-10” to find the report they are looking for? Not very helpful is it?

Instead, you should customize your menus so they make sense for your users. This will help in your adoption and make training much easier. For some great tips on how to customize your menus, check out Brent Dykes’ post by clicking here.

No Variable Standardization

The next one is when you have a situation where you have multiple report suites that are really the same website, just for different business units and/or locations and none of them are set-up consistently. I see many clients who are tracking some things in the US, but not in the UK or Japan, even though the websites are identical. When this happens and you select multiple report suites in the Admin Console, here is what you see in the variable screen:

I call the “Multiple Madness” due to what you see in the Admin Console and it is not a good thing! You should make sure that as many of your report suites are as consistent as possible so you can minimize your development time and roll-up data into higher-level report suites.

Wasting of Variables

This next one is a minor one but it is related to wasting variables. Even though there are more variables available now, it doesn’t mean that you should track everything or that every piece of data requires its own variable. For example, I recently ran into a client that was tracking Salutation (Mr., Mrs., Dr., etc…) in an eVar. This makes very little sense. How are you going to do cutting-edge analysis on that? Gender maybe, but I don’t think Salutation is worthwhile. Just because you know it, doesn’t mean you need to track it.

This leads to the other type of waste I see – not using SAINT Classifications to save variables. There are many cases where you can accomplish the same analysis objectives by using SAINT Classifications and save variables along the way. Using the prior example, instead of storing Salutation as an eVar, if you really need it, why not store a Customer ID value and then add Salutation as a classification value of that Customer ID? That saves you one eVar and if you happen to have Full Subrelations on that eVar, you get them on the classification of that eVar as well (which will be less of an advantage when using SiteCatalyst v15 since all eVars will have Full Subrelations).

But here is my favorite example since I see this all of the time! One of Omniture’s common JavaScript Plug-ins is the Time Parting plug-in. This allows you to see data segmented by Day of Week and Hour of Day. However, many clients also store an sProp and/or eVar for Weekday/Weekend through this plug-in. It makes sense that you might want to segment data by Weekday/Weekend, but why use an entirely new variable just to track the binary values of Weekday vs. Weekend? You can easily do a one-time classification of Day of Week and lump Mon-Fri into “Weekday” and Sat-Sun into “Weekend.” That will allow you to achieve the same goal, but saves a variable. Again, this is a minor annoyance, but it is the principle that counts. You can extrapolate this concept by thinking back to the Customer ID example I mentioned above. What if there were ten data points related to a customer that you chose to store in ten separate eVars? You might be able to make these classifications and save ten eVars!

My advice here is to just be thoughtful when assigning variables and if you have cases where there is a direct relationship between two variables that won’t change very often, consider using a SAINT classification and also think about whether you will ever use that data point for an analysis before tracking it in the first place.

VISTA Rule Chaos

The final pet peeve I will mention is related to VISTA Rules. Let me start by saying that VISTA and DB Vista rules are not bad. They can be very powerful, but it is also true that they can be easily misused and wreak havoc on a SiteCatalyst implementation. When using VISTA rules, it is critical that you and your entire team understand WHEN the rules are being used and WHAT they do in terms of setting variables. I have seen many cases where a developer will change a variable not knowing that there are VISTA rules impacting it. You need to make sure VISTA rules are heavily documented and as you change your site or implementation, they need to be factored into the equation. One suggestion I have is to add the phrase (SET VIA VISTA) in the name of any variable that is set via a VISTA rule in your documentation so there is no missing it!

The other pet peeve I have related to VISTA rules is when they are used as a “band-aid” to avoid doing real tagging. In the long-run, this always comes back to haunt you. I see many clients creating band-aids on top of band-aids until things fall apart. I am ok with companies using Vista rules to get things done quickly, but I recommend that, over time, you phase out as many VISTA rules as you can and move their logic to your regular tagging so you have all of your logic in one place.

Final Thoughts
Well, there you have it. Not all of my implementation pet peeves, but a bunch of them that popped into my head. I am sure you have seen some fun ones out there and I’d love to hear about them…Please leave them as comments here!

NOTE: For more details on these points, check out my follow-up post here.

A few weeks ago I was at the European Adobe (Omniture) Summit in the UK and had the pleasure of being in another one of Brett Error’s “what features are we missing” sessions. I find these sessions to be good and bad at the same time. The good part is that people are expressing what they need and others can validate or invalidate ideas in real-time. The bad part is that I often feel that the features that get voted up are the ones that are easy to understand (like Bounce Rate as a standard metric!), but that there are many features that people SHOULD want, but don’t know it yet. I don’t mean that to come out as sounding pretentious, but the fact is that many people have been using the product for only a few years and it is natural that the needs of those who have been using the product for many more years will have some more advanced feature requests. Unfortunately, many of these advanced features, no matter how important, will be trumped by more basic, globally understood feature requests.

The creation of the Ideas Exchange has been a great help in getting ideas big and small into the product and I am so pleased to see that many of the ideas in there have been added to the product and for that I commend Adobe (Omniture). I think the positive feedback around SiteCatalyst v15 is a direct result of people seeing their ideas manifested in the release.

In this post, I wanted to highlight a few ideas that are in the exchange that might not get as much “play” as they should and why I think they should be undertaken. If you agree and have a Login ID to SiteCatalyst, please feel free to login and vote for them!

SAINT Auto-Classifications
One of the ideas that came up in the UK session I mentioned earlier (and received the most votes!) was the notion of SAINT Auto-Classifications. This idea was submitted by Ben Gaines (probably as an initial test of the Idea Exchange!) the day the exchange came online. As most users know, SAINT Classifications are a way to add meta-data to values you have already captured in SiteCatalyst. It is similar to a pivot table in Microsoft Excel. However, SAINT Classifications have to be uploaded manually and it becomes very tedious over time. The feature request is to provide a way where administrators could set-up rules to auto-classify items or classify them on the fly (as reports open up). For example, if I have a report of campaign tracking codes and a bunch of them start with “seo|,” I could set something up where these would all be automatically classified as “SEO” in the Marketing Channel classification I have set-up. This is just one example, and the possibilities are endless.

The great news is that this idea has recently been changed to “Under Review” and geniuses like Sean Gubler have started playing around with tools to do this so I feel like it is only a matter of time before we see this. Keep your fingers crossed and vote for the idea by clicking here.

Multi-Session Attribution (Allocation)
The next idea is related to eVar attribution. Currently, you can attribute success to eVar values for First Touch, Last Touch. There is an option for Linear allocation, but that only works within one session so it is rarely used. The closest thing available for multi-session attribution is the Cross-Visit Participation plug-in which is really just a “hack” that concatenates eVar values into one string. This plug-in can be useful at times, but has some serious drawbacks.

In today’s world of people bouncing between websites and social media, you cannot count on the visit that people convert being the same one in which they came from a marketing campaign. Therefore, you often have cases where a visitor comes from an SEO keyword, does some product research, leaves the site, comes back the next day from a paid search ad, leaves the site and then comes back a third time just typing in the URL and then converts. This string of traffic sources is difficult to track and analyze using the eVar allocation feature set available today. What I feel is needed is a way to simply have SiteCatalyst extend its Linear Allocation feature to include multiple visits and make that a legitimate setting in the Admin Console. I’d even pay more for it if needed, since not everyone will need that level of sophistication. I personally think that attribution will become a bigger issue in the future as the current browser model fractures so I think this will be an important feature for all web analytics vendors going forward. You can read some of my partner Eric Peterson’s thoughts on appropriate attribution in this white paper. If you’d like to see SiteCatalyst go deeper with attribution, please vote for this idea by clicking here.

Multi-Session Pathing
Along the same lines, the next idea I’d like to suggest is the notion of multi-session Pathing. I suggested this to the Ideas Exchange over a year ago and was surprised to see that it only has 7 votes! Currently, pathing reports are limited to one session. However, it is often the case that visitors come to your website multiple times before they convert. Wouldn’t you want to see paths that span multiple visits for the same person? I realize that this can be data intensive, but even if it is for a subset of data, I think it would be interesting to pick a subset of visitors and see what they do over multiple visits. Currently, you can’t even do this in Discover. While I am not sure of the exact way the feature should be implemented, I feel that having some insight into multi-session pathing is important and should be somewhere on the roadmap. If you agree, you can vote for this idea by clicking here.

Expire eVars Based Upon Event or Time
The last feature request I’ll mention has to do with expiring eVars. Currently, you can expire an eVar based upon a time period (like Visit or 30 Days) or a Success Event but not both. So why is this important? Imagine that you have a situation where you have an eVar set to expire at the Purchase event. A person could come to your website from a specific campaign code and then not return for an entire year and then convert. In that scenario, the campaign code they came from a year ago would get credit for the conversion. However, there are cases in which you would not want that to happen so it would be great if it were possible to have SiteCatalyst expire the eVar at the Purchase event or after 30 days – whichever comes first. That would offer much more flexibility and tighten up eVar attribution across the board. Someone also added a comment to this idea with the idea of allowing an eVar to expire at Success Event X or Success Event Y. That would also be helpful. If you’d like to see this implemented, please click here to vote for it.

Final Thoughts
As I mentioned at the beginning of this post, there are some features that could have a big impact if added to SiteCatalyst, but they are ones that only those who have been through some big battles would know are needed. My hope is that you will think about these features and support them with your votes so we can all benefit. Thanks!

If you have any questions or want to learn more, feel free to contact me for more information.

The folks over at Thoughtlead have put together what they’re calling a Digital Influence Collaborative. It’s innovative and exciting and a new way to consume content in microbursts. If you haven’t gotten wind of these events yet, you’re missing out.

They typically feature 60 influencers on 60 topics in 60 seconds. Topics vary from Social Media to Enterprise Marketing Management.

Here’s a mashed version of the one I delivered for Mtech 2011:

5 Secrets for LEARNING from Social Media

EDITOR’S NOTE:
Since joining Analytics Demystified, the most common email/comment I have received goes something like this:

“When are you going to get back to blogging about cool, advanced stuff you can do in SiteCatalyst?”

While in my new role, I am vendor-agnostic, I will do my best to keep sharing the SiteCatalyst tips & tricks I used to on my old blog. My hope is that as I work with clients using all web analytics vendors, I will branch out and share tips & tricks for all technologies. However, as I always tell people, the goal of my blog posts are to introduce concepts that can be applied to all web analytics tools…

Now on with a new tip/trick…

Dealing With Time of Day (Time Parting)

One of the analyses that I have done from time to time is Time Parting Analysis. Time Parting Analysis consists of looking at the time of the day (or day of week) that website success takes place in order to better understand its importance. While I don’t usually put a whole lot of stock into the time of day, there can be times where websites do much better/worse in the morning vs. evening. Knowing this can be used when planning advertising so you can “strike while the iron is hot,” so to speak.

If you think Time Parting might be important to your business, you should capture the time of day in some manner into variables in your web analytics tool. For example, if you use Omniture SiteCatalyst, you might use the Time Parting Plug-in to pass the time of day (in half-hour increments) to an eVar or sProp. Doing this allows you to look at a report that might resemble the one shown here:

As you can see, this report allows us to see what the action is taking place on our website down to the half-hour increment. If you are not already doing this type of analysis, it may be worthwhile since you can glean some new insights and use this data point for visitor segmentation.

Time Zone Hell!

However, inevitably you will run into a few problems with the above report. First, someone at your organization will ask you which time zone the above report is related to. Therefore, the first thing I recommend is that you clearly label your Time Parting reports with the time zone that the JavaScript file is using to capture the data. In the example above, the “Hour of Day” report was labeled do be PST (Pacific Standard Time) so it can be easily interpreted by everyone using it.

The next problem you will encounter is that of multiple time zones. If you work at a global organization and have people focusing on business in various locales, the above report is pretty much useless to many of your internal customers. If they happen to be good at math and can calculate time zone differences in their head, then you’ll be ok, but most people have trouble interpreting web analytics reports without the added labor of doing on-the-fly time zone translation!

Want to see this problem in action? Take a closer look at the report above. Do you notice anything strange? If you look closely, most of the Visits and Form activity took place in the evening. People might like your product(s), but not so much that they are willing to spend their evenings looking at them! The reason the above report looks strange is because it is for an Australian website, but the time zone is Pacific Standard Time. If you are a web analyst in Australia, seeing your website success events in the Pacific Time Zone is not super-helpful!

So how do we fix this? All it takes is a bit of creativity and meta-data. Keeping in mind that there is a direct relationship between time zones, you can take the above report and apply meta-data to it to adjust for alternative time zones. If you are using Omniture SiteCatalyst as in the example above, this means using SAINT Classifications. By applying a different SAINT Classification for each time zone you care about, you can create new reports for each time zone. Here is an example of what the SAINT file might look like for a few additional cities:

As you can see here, we took the data that was already being collected (the Key column, which in this case is PST) and added meta-data for four additional cities. You can add as many cities as you want and each column you add will create a new report for that city time zone. Once you have done this, you can see a new version of the report above adjusted for each time zone. Now if we look at the same report above, but use the Sydney Time Zone classification report, we see a report like this:

You will notice that now we are seeing the same exact data as the first report, but now the times of the website successes are adjusted for the Sydney time zone. This makes the report look a bit more normal for the Australian web analyst as the success events are now shown as taking place during more realistic business hours. The best part of this solution is that anyone using the standard Time Parting plug-in Omniture provides can use the same SAINT Classification file. It just needs to be adjusted so the “Key” column is the time zone for which you are collected the data. If you are using the PST time zone, you can download the file I showed above. If you are in a different time zone, you can still download the file and adjust it as necessary.

Caveats

As always, there are a few caveats with any “hack,” so here are mine:

• I take no responsibility for daylight savings time which can wreak havoc on time zone translations, but even in that worst case, your data will be an hour off…
• Time Parting reports can also be used to track Day of Week. This is harder to adjust for than is time zone unless you are time stamping using the actual date and are willing to have a massive, multi-year SAINT Classification file. This is not a bad approach, but is much more involved. Contact me if you’d like to explore this.
• It is possible to collect time zone data using different time zones for each report suite. For example, it may be better for you in the long run to have your Sydney data collected in the Sydney time zone and your London data in the London time zone, but I have often seen clients have issues with this and if you don’t start doing this from the onset, you can have issues going to it later. Please consult your account manager for more details.

Final Thoughts

So there you have it, a few thoughts on Time Parting and a fun trick to make it more useful if you do business in multiple time zones. Give it a whirl and let me know what you think…

If you have any questions or want to learn more, feel free to contact me for more information.

Phew. It’s been crazy weeks for me lately. At the moment, we just put up the tree, kids are all quiet and I’m drinking a glass of red. It’s one of the rare moments these days that I have in solace…and it’s gone…the littlest one is squirmy with hiccups.

Okay, I’m back. Made a bottle and made the hand off to Mommy. I haven’t blogged in a long while and there so much to say but I just haven’t had time. So here’s the johnlovett highlight reel for Fall 2010:

• We welcomed a new baby into our home. And that makes three. Three boys that is. I always thought the jump from one kid to two was really no problem. But, I can tell you that increasing the number of kids another 33% 50% is a big jump indeed. [The 33% designates the percentage of quantitative reasoning skills I’ve lost in the past month.] Our house is busier than ever with an 18-month old climbing the walls and an eldest brother at five running the show. Everybody is happy and healthy so I’m immensely grateful for the lack of sleep and craziness.

• I’m writing a book for Wiley on Social Media Metrics. And it’s one of the hardest things I’ve ever done. I’ve got the story in my head and know what I want to write, yet cranking out 40 page chapters every other week is really tough. I’m nearly half way through my manuscript and I love the way its coming together. Although, if you’ve got a social analytics story of smashing success, miserable failure or sheer brilliance, I’d love to talk with you. I could always use more.

• My business is off-the-charts busy. Looking back on twelve months since joining Demystified and I couldn’t be happier. It’s been a great year and the work I’m doing is motivating me to maintain work-a-holic proportions. Since Labor Day I spent 8 weeks on the road visiting clients, working on changing our industry and speaking at events from coast to coast with a business trip to Italy as a big November finale. I made it home with four days to spare before the baby was born. Whew.

• And I’m happier than I’ve ever been. Who knew that chaos could be so rewarding? I always knew this was the case, but I love my job and I truly love the #measure industry. As measurers of digital medium, our roles are about to become indispensable. We’re on the precipice of a big data explosion and we’ll have the skills to float to the top. Big data is going to rush like a flood over enterprises and marketers alike and we measurers will be ready to slice and dice our way to sensibility. I like our chances.

More to follow on all these topics as I’m working three concurrent projects, writing two white papers and working through book chapters at present… Oh, and it’s my turn to change diapers, so I’m out.

Talk to y’all soon.
John

In my last post, I started the process of identifying which form fields were producing the most errors. In this post, I will cover some related topics that will allow you to quantify how often you are getting Form Errors and how effective, in general, your forms are at converting website visitors.