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.