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.
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:
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:
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:
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.
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:
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.
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:
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.
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!
If you are an Adobe Analytics customer, these are exciting times! At the last Adobe Summit, it was announced that Adobe Analytics products would be bundled when customers upgrade to the new “analytics suite.” While this upgrade may come with a cost increase, it allows you to gain unprecedented access to Adobe Discover and Adobe ReportBuilder. These SiteCatalyst add-on tools have traditionally only been available to some clients due to their additional cost. However, those who have used Adobe Discover and ReportBuilder know that these tools allow you to take your web analytics data to a whole new level. Discover provides unparalleled segmentation and report breakdown capabilities, while ReportBuilder allows you to build world-class dashboards by importing SiteCatalyst data into Microsoft Excel. In addition to being more available, these products (especially Discover) are also getting great new features on a regular basis.
As is often the case, with more power, comes more responsibility! I am surprised how few Adobe SiteCatalyst customers are familiar with or have mastered these critical tools. Now that Discover and ReportBuilder are working their way to the masses, you can no longer bury your head in the sand and say that the reason you aren’t an expert with them is because your company can’t afford them! Now is the time to get rid of the excuses, bite the bullet, and become a Discover and/or ReportBuilder ninja! In my Adobe SiteCatalyst book, my partner Kevin Willeitner helped me author a full chapter on ReportBuilder, which is a great primer on the tool (unfortunately, Discover was too large of a topic to cover in the book).
Adobe ReportBuilder & Adobe Discover Training!
So how can you go about learning Adobe ReportBuilder and Adobe Discover? I am pleased to announce that in September, Web Analytics Demystified is offering training classes on these tools as part of our ACCELERATE conference in Columbus, Ohio. While these classes are just a subset of the overall training we are offering, it represents an economical way to learn Adobe ReportBuilder and Adobe Discover, while also getting to attend a great web analytics conference! Classes on ReportBuilder and Discover will be led my Kevin Willeitner who knows more about these products than anyone I have ever met. You can sample the depth of Kevin’s expertise by checking out one of his recent blog posts (with video!) on Adobe Discover. These classes give you a taste of the full one-day training classes Kevin offers on each product.
As you can see in our list of ACCELERATE training offerings, I will be conducting my Advanced SiteCatalyst “Top Gun” training for those who want to learn how to translate business requirements into SiteCatalyst implementations. You can read some of the great feedback I have received on these classes by clicking here. This is by far the cheapest my “Top Gun” class will ever be as part of a special promotion with our ACCELERATE conference.
In addition to training on Adobe products, Web Analytics Demystified will be offering classes on Google Analytics, Social Analytics, Testing and Building Analytics Teams. You get to pick and choose which classes you are interested in and can attend one or two days of training. Then you can attend our one-day ACCELERATE conference with world-class speakers from companies including: Google, Nationwide Insurance, Experian, Nestle, Best Buy, FedEx and more. I encourage you to take advantage of this great opportunity and to invest in yourself to help grow your analytics career. If you have any questions, feel free to contact me at @AdamGreco.
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:
- The root eVar variable that you are classifying did not have a value
- 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.
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.
P.S. If you would like to take my advanced SiteCatalyst class or take classes related to Adobe ReportBuilder, Adobe Discover and many other web analytics topics, check out Web Analytics Demystified’s upcoming Midwest training classes: http://www.webanalyticsdemystified.com/accelerate/training-2013.asp
Over the years, I have worked on Adobe SiteCatalyst implementations for the largest of companies and the smallest of companies. In that time, I have learned that you have to have a different mindset when it comes to each type of implementation. Implementing both the same way can lead to issues. Big implementations (which can be either large due to complexity or traffic volume) are not inherently better or worse, just different. For example, an implementation at a company like Expedia is going to be very different than an implementation at a small retail website. Personally, I find things that excite me about both types. When working with a large website, the volume of traffic can be amazing and your opportunities to improve conversion are enormous. One cool insight that improves conversion by a small percentage, can mean millions of dollars! Conversely, when working with a smaller website, you usually have a smaller development team, which means that you can be very agile and implement things almost immediately.
Hence, there are pros and cons with each type of website and these are important things to consider when approaching an implementation or possibly when considering what type of company you want to work for as a web analyst. The following will outline some of the distinctions I have found over the years in case you find them to be helpful.
The following are some of the SiteCatalyst areas that I have found to be most impacted by the size of the implementation:
Most large websites have multiple locations, sites or brands and use multi-suite tagging. When you bring together data from multiple websites into one “global” suite, you have to be sure that all of the variables line up amongst the different child report suites. Failure to do this will result in data collisions that will taint Success Event metrics or combine disparate eVar/sProp values. If you have 10+ report suites, it almost becomes a full-time job to manage these, making sure that renegade developers don’t start populating variables without your knowledge. If you use multi-suite tagging and have a global report suite, my suggestion is to keep every report suite as standardized as possible. This may sound draconian, but it works.
For example, let’s say you have five report suites that are using eVars 1-45 and a few other report suites that require some new eVars. Even if the latter report suites don’t intend to use eVars 1-45 (which I doubt), I would still recommend that you use eVars 46 on for the new eVars for the additional report suites. This will ensure that you don’t encounter data conflicts. Taking this a step further, I would label eVars 1-45 as they are in the initial report suites using the Administration Console. I would also label eVars 46 on with the new variable names in the original set of report suites. At the end of the day, when you highlight all report suites in the Admin Console and choose to see your eVars, you should strive to see no “Multiple” values. That means you have a clean implementation and no variable conflicts. Otherwise, you will encounter what I call “Multiple Madness” (shown here).
If you really have a need for each website to track its own site-specific data points, one best practice is to save the last few Success Events, eVars and sProps for site-specific variables. For example, you may reserve Success Events 95-100 and eVars 70-75 to be different in each report suite. That will provide some flexibility to site owners. You just have to recognize that those Success Events and eVars should be hidden (or disabled) in the global report suite so there is no confusion. Another exception to the rule might be sites that are dramatically different than the core websites. For example, you may have a mobile app or intranet site that you are tracking with SiteCatalyst. This mobile app or intranet site may be so drastically different from your other sites that you want to have it in its own separate report suite that will never merge with your other report suites. In this case, you can either create a separate Company Login or just keep that one report suite separate from the others and use any variables you want for it. Keep in mind that the Administration Console allows you to create “groups” of report suites so you can group common ones together and use that group to make sure you don’t have any “multiple” issues. You can also use the Menu Customization feature to hide variables in report suites where they are not applicable. Even if you don’t currently have a global report suite, I still recommend following the preceding approach. You never know when you might later decide to bring multiple report suites together, and using my approach makes doing so a breeze (simply changing the s_account variable) versus having to re-implement variables and move them to open slots at a later date. The latter will cause you to lose historical trends, modify reports and dashboards and confuse your end-users.
When you have a smaller implementation, it is common to have just one production report suite. This avoids the preceding multi-suite tagging issues and makes your life a lot easier!
As if coordinating variables across multiple report suites isn’t hard enough, this issue is compounded by the fact that multi-suite tagging means that you only have ~110 success events, ~78 eVars and ~78 sProps to use for all sites together vs. being able to use ~250 variables differently for each website. This means that most large implementations inevitably run out of variables (eVars are usually the first type of variable to run out). Therefore, large implementations have to be very aggressive on conserving variables, which can handcuff them at times. As a web analyst, you can often make a case for tracking almost anything, since the more data you have the more analyses you can produce and the more items you can add to your segments. Unfortunately, when dealing with a large implementation, for the reasons cited above, you may need to prioritize which data elements are the most important to track lest you run out of variables. This isn’t necessarily a bad thing as it helps your organization focus on what is really important across the entire business and tracking more isn’t always better.
If you contrast this with a smaller implementation that has no multi-suite tagging and no global report suite, the smaller implementation is free to use all variables for the one site being tracked. This provides ~250 variables to use as you desire. That should be plenty for any smaller site, so variable conservation isn’t as high of a priority. A few times, in my SiteCatalyst training classes, I have had both large and small companies sitting next to each other, and have witnessed the big company drooling over the fact that the smaller company was only using 20 of their eVars (wishing they could borrow some)! While it may sound strange, there are many cases in which I would tell a smaller organization to set success events and eVars that I would conversely tell a large organization not to set. For example, if I were working with a small organization that had only one workflow process (i.e. credit card application) and they wanted to track all six steps with success events, I might say “go for it!” But if that same scenario arose for a large website (i.e. American Express), I would encourage them to only set success events for the key milestone workflow steps to conserve success events. This is just one example of why I tend to approach large and small implementations differently.
One final note related to variable conservation. Keep in mind that you can use concatenation combined with SAINT Classifications to conserve variables. For example, instead of storing Time of Day, Day of Week and Weekday/Weekend in three separate eVars, you can concatenate those together into one and apply SAINT Classifications. This will save a few eVars and a similar process can be replicated for things like e-mail attributes, product attributes, etc.
If you have a large website, there is an increased chance you will have issues with “uniques.” Most eVar and sProp reports have a limit of 500,000 unique values per month. I have many large clients that try to track onsite search phrases or external search keywords and exceed the unique threshold by the 10th day of the month. This makes some key reports less useful and often results in data being exported via a data feed or DataWarehouse report to back-end tools for more robust analysis. For some large implementations, since the data points can’t be used regularly in the SiteCatalyst user interface due to unique limits, I sometimes have clients pass data to an sProp to conserve eVars, since in DataWarehouse, Discover and Segmentation, having values in an sProp is similar to having it in an eVar.
Smaller implementations normally only hit uniques issues if they are storing session ID’s (i.e. ClickTale, Tealeaf) or customer ID’s.
Large # of Page & Product Names
Many large websites have so many pages on their site (i.e. one page per product and over 100,000 products) that having an individual page name for each page is virtually impossible. In these cases, you often have to take page names up a level and start at a page category level. The same concept can apply to individual product names or ID’s as well.
Smaller implementations rarely have these issues since they tend to have fewer pages and numbers of products.
Page Naming Conventions
Another area where I see those running large implementations make mistakes is related to page naming across multiple websites. If you are managing a smaller implementation, you can name your pages anything you’d like. For example, while I don’t recommend it, if you want to call your website home page, “Home Page,” you will be ok. However, this approach won’t always work with a large implementation. If you have five report suites and one global report suite and you named the home page of each “Home Page,” in the global report suite, you would see data from all five report suites merged into one page name called “Home Page.” While there may be reasons to do this, you will probably also want to have a way to see things like Pathing and Participation for each of the home pages from each site individually in the global report suite. In this post, I show how you can have both (“have your cake and eat it too!”), but this example highlights the complexity that can arise when dealing with larger implementations.
Large websites can often have a variable with more than a million SAINT classification values. Updating SAINT tables can take days or weeks unless you are methodical about your approach. Smaller sites with lower numbers of SAINT values can often re-upload their entire SAINT file daily or weekly to make sure all values are classified. Large implementations don’t have this luxury. They have to monitor which values are new or missing SAINT values so they can only upload the new or changed items so it doesn’t take weeks for SAINT tables to be updated. If you work with a large implementation, keep in mind that you can update SAINT Classifications for multiple report suites with one upload if you use the FTP method vs. browser uploads.
Time to Implement
In general, large implementations tend to move slower than smaller ones. While tag management systems are helping to remedy this, I still find that adding new variables or fixing broken variables takes much longer with large implementations (often due to corporate politics!). This means that you have to be sure that your tagging specifications are right the first time, since getting changes in after a release may be difficult.
Conversely, with smaller websites, you can be much more nimble and update SiteCatalyst tagging on the fly. For example, you may doing a specific analysis and realize that it would be helpful for you to have the Zip Code associated with a form. If you work with a smaller site, you may be able to use a SiteCatalyst Processing Rule or call your developer and have them add Zip Code to eVar30 and have data the same day!
Globally Shared Metrics, Dashboards, Reports, etc.
When you work with a small implementation, you may have a few calculated metrics, dashboards or reports that you share out to your users. This is a great way to collaborate and enforce some standards or consistency related to your implementation. However, when you have a large implementation, sometimes with 300+ SiteCatalyst users having logins, this type of sharing can easily get out of control. Imagine each SiteCatalyst user sharing five reports or dashboards. The shared area of the interface becomes a mess and you are not sure which reports/dashboards you should be using. Therefore, when you are working with a large implementation, it is common to have to implement some processes in which reports and dashboards are sent to the core web analytics team who can then share them out to others. This allows the SiteCatalyst user community to know which reports/dashboards are “approved” by the organization. You can learn more about centralizing reports and dashboards by reading this blog post.
As I mentioned in the beginning of this post, bigger isn’t always better. As shown from the items above, I often find that bigger implementations lead to more headaches and more limitations. However, keep in mind that with great volume, comes conversion improvement opportunities that often dwarf smaller sites.
One over-arching piece of advice I would give you, regardless of whether you work with a large or small implementation, is to review your implementation every six months (or at least yearly) and determine if you are still using all of your variables. It is better to get rid of what you no longer need periodically than to have to do a massive overhaul one day in the future.
While this post covers just a few of the differences between large and small implementations, they are the ones that I tend to see people mess up the most. If you have other tips for readers, feel free to leave a comment here. Thanks!
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.
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!
One type of web analysis that you hear about from time to time is cohort analysis. In general, the concept of a cohort analysis is that you look at a population of visitors and see how that population performs over time. Unfortunately, there is no out-of-the-box way to perform cohort analysis in Adobe SiteCatalyst, but in this post, I will share the steps you need to take to perform this analysis using SiteCatalyst (and which will also work in Discover).
Establishing Your Cohorts
The first step in performing this analysis is to identify the business question that you’d like to solve. There are an unlimited number of cohort analyses that can be done, so I will use a simple retail example here. Let’s imagine that your boss wants to know how much money those who place their first order in month #1, spend on the website in month#2, #3, #4, etc. For example, how much did those who originally purchased in January, spend in February, March, etc. and how does that compare to those who originally purchased in February and then spent additional money in March, April, etc.? In this example, we will start with January 2013 as month #1. To do this, we first need to identify visitors who made their first purchase in the first month, in this case, January 2013.
If you have been reading my posts about setting a Date eVar or Segmenting on Key Dates, you may recognize that we are going to want to set a date to an eVar as part of this solution. However, in this case, what we need to do is to set the date eVar only at the point that the visitor makes their first purchase. An easy way to do this is to create a new eVar and call it “Original Purchase Date” and in the Admin Console, set it to be Original Value (First) allocation and expire it “Never” as shown here:
Once this “Original Purchase Date” eVar has been created, you would set it on the order confirmation page every time, since the allocation will tell SiteCatalyst to ignore it if a value already exists (obviously, cookie deletion will cause it to be reset, but there isn’t much we can do about that). Keep in mind that if you have an existing implementation, the “first purchase” may not be the real first purchase since visitors may have purchased before this eVar was around, but over time it should work for new visitors. If this bothers you, I suggest asking your developers to write some code to only set the eVar if it truly is a first time purchase.
Now that you have an Original Purchase Date eVar, we need another eVar to compare it to in our cohort analysis. This second eVar would be the date that each purchase takes place. This eVar is easy, as it is simply set to the current date on each visit as described in my Date eVar post and will bind to the Revenue metric when the purchase success event is set. For the first purchase, the “Original Purchase Date” eVar will be the same as the Date eVar, but as visitors make subsequent purchases, the “Original Purchase Date” eVar will stay constant while the Date eVar will contain dates in the future.
Setting Up The Analysis
After you have the two date eVars populating, the next thing you should do is to group dates into larger buckets, either weeks or months. While you can use specific days, I find that doing analysis at a weekly or monthly level is a bit cleaner and may be a bit easier to explain here. To do this, I will apply SAINT Classifications to both of my Date eVars. This is very straightforward, as you simply upload the week or month associated with each date as shown here:
Next, let’s assume that a few months have passed and that it is now early April of 2013. We will open the Original Purchase Month eVar report (classification of Original Purchase Date) and add Revenue as the success event. Once this report opens, we will make sure our date range covers January 2013 through April 2013 and then should see a report that looks like this:
Unfortunately, the preceding report isn’t terribly exciting (yet!) since it just shows revenue by the month of the original purchase. However, when we apply a subrelation to break down this report by the Month Classification of the Date eVar, something magical happens:
As you can see here, revenue for cases in which the original purchase took place in January 2013 and February 2013 is now broken out by each month in which purchases actually took place. This allows us to see our first cohort analysis and see how much $$$ those who purchased in each month spent in subsequent months. If desired, you could also add other elements to a segment to do more in-depth analysis. For example, you could add Marketing Channel = SEO to a container in the segment builder to see how this analysis changes for those sourced from SEO. You could add visit number to the segment container to see how this analysis changes for visitors whose original purchase was also their first website visit. The possibilities are truly endless.
As you can see, setting up cohort analysis in SiteCatalyst is a bit of work, but not impossible. One downside is that you need to use one eVar for every type of cohort you want to do. In the preceding example, I created an “Original Purchase” eVar, but if I wanted to see a cohort analysis around Orders, I would need to have an “Original Order” eVar. If you are running low on eVars or want to do many types of cohorts, this can be an issue. Maybe one day SiteCatalyst will allow you to see an “original” version of each eVar out-of-the-box.
Creating Your Cohort Analysis in Excel
Unfortunately, the report above doesn’t present the data in the ideal “cohort” framework. To do this, you are going to have to do a bit more work, and I recommend using Microsoft Excel. We will have to extract the preceding data to create a table that shows the current month in the “Month 1″ column and then subsequent months in the next few columns so it looks like this:
For example, if we assume that the preceding report was run in April, we can see how much is spent in each month and the subsequent months. Another way to visualize this is to calculate cohort percentages by dividing these revenue amounts by total monthly revenue to create report like this:
In this example, it looks like we may be doing a bit better in February than we did in January since a higher percentage purchased in the following two months.
But how do we extract this data in an easy, scalable way? To find out, stay tuned for my partner Kevin Willeitner’s post on how to build Cohort Analyses using ReportBuilder which will show how you can use ReportBuilder to automatically create the above tables…
My friend Jan Exner wrote a related blog post about performing cohort analysis in SiteCatalyst which you can read here (if you speak German!). While I swear I wrote my post before translating his to English, you will see that our approaches begin in a similar way, but diverge thereafter. Another cohort-related post by Tim Elleston can be found by clicking here. As is often the case with SiteCatalyst, there are multiple ways to do similar types of configurations so it is beneficial to review both options. If you just can’t get enough cohort analysis reading to satisfy you, check out Justin Cutroni’s post on how to do cohort analysis in Google Analytics. In the meantime, I hope this helps and if you have any questions/comments, feel free to leave them here. Thanks!
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…
For those of us who work in web analytics and use Adobe SiteCatalyst, the Adobe Marketing Summit has become a yearly pilgrimage to Utah to see old friends and learn about new product developments. As we enter February, the Adobe Summit is now upon us and I look forward to attending my 10th Summit (yes I am old!). As I mentioned in my last post about conference season beginning, Adobe (formerly Omniture), always puts on an amazing conference in terms of organization, food and entertainment. Outside of the Salesforce Dreamforce conference, I would say Adobe Summit’s are the best vendor conference in the digital space.
This year’s conference will be special for me since it is the first one since my book on Adobe SiteCatalyst has been published, and I look forward to talking to folks who have read it and getting their feedback. It will also be fun since all of my Web Analytics Demystified partners will be in attendance, including our three new additions in the past year. Since we all live in different locations, it is always great to get together in person. We also look forward to meeting with our wonderful clients, many of whom use Adobe products, both at the conference and on the slopes!
Come Chat With Team Demystified
One of my favorite parts of Adobe Summit has always been the informal chats that take place in the hallways with people who are passionate about web analytics and Adobe products. I love meeting people with whom I have interacted on Twitter and helping them answer questions that take more than 140 characters. Unfortunately, since the Adobe Summit has become so massive, I have found that over the years, I don’t end up seeing all of the people I initially hoped to see. So this year I am making a concerted effort to meet with as many people as I can.
To this end, if you or folks from your company would like to spend some time with me or any of the folks at Web Analytics Demystified, we are going to try and pre-arrange times that we can chat during the multi-day conference. Have a SiteCatalyst issue you want to chat about? Have a testing dilemma to discuss? Want some strategy advice? Need tagging tips and tricks? Dashboards driving you crazy? Whatever the topic, one of us can most likely help out. To schedule time with our team, please contact me and send your name, your company and the topics you would like to discuss and I will do my best to facilitate a conversation with the right Web Analytics Demystified partner. I look forward to seeing as many of you as possible at the Summit!