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!
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:
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.
As someone in the web analytics field, you probably hear how lucky you are due to the fact that there are always web analytics jobs available. When the rest of the country is looking for work and you get daily calls from recruiters, it isn’t a bad position to be in! At Web Analytics Demystified, we have more than doubled in the past year and still cannot keep up with the demand, so I am reaching out to you via this blog post. As you may have read in Eric Peterson’s blog post, earlier this year we have begun placing qualified web analytics folks at great clients and started a staffing business. This business grew out of requests by our clients and other friends in the industry for good people they could either hire or “rent” for long term projects. Since we know the folks at companies looking for people and also know many of the people in the industry, it seemed to make sense that we would help play match-maker.
However, what is most exciting to me, is our Team Demystified staffing area. Through Team Demystified staffing, we make you a virtual member of our Demystified team and place you on long-term engagements with us and our clients. This means that you get to work side-by-side with me and my partners. Through our online collaboration tools, you have a direct line into everyone at Demystified when you have questions or want advice on how to handle a situation at a client. In addition, we provide free training on web analytics tools like Adobe SiteCatalyst, Adobe ReportBuilder, Adobe Target and Google Analytics. If you are an independent contractor or at a job that is not satisfying, Team Demystified offers an opportunity to work with the best people in the industry, at amazing clients and help boost your career. Consider it to be an MBA in web analytics, only you get paid instead of paying for it!
Therefore, if you have business or technical skills related to web analytics, we want to hear from you. Even if our current opportunities aren’t right for you, we’d like to have you in mind as new opportunities arise. You can find my contact information on our website or send an e-mail to Wendy Greco.
Additionally, if you happen to be attending Adobe Summit in Utah, the Demystified team will be there. If you are interested in learning more about Team Demystified, please contact Wendy and she can arrange a time for you to meet with one of us to learn more.
Happy new year to you! Hopefully your new year has started better than mine as I have been hibernating to avoid the -40 degree temperatures here in Chicago! Since the new year is a time to start new diets, exercising and the like, it seemed like a good time to share some upcoming web analytics training classes that Web Analytics Demystified will be offering. Hopefully these classes will help you do more with your web analytics tools in 2014.
Adobe SiteCatalyst “Top Gun” Training – London, UK
Last year, I sojourned back to merry old England to host my one-day advanced SiteCatalyst class and it was a blast! We had a packed room with some super-smart web analysts and I put them through their paces. Those who thought they were a five out of a ten left feeling like they were sevens or eights and, unfortunately, some who thought they were nines or tens, left realizing they might have been more like fives or sixes! But in the end, it was fun to meet people from several European countries who all had a passion for Adobe SiteCatalyst. This month, a client project brings me back to London so I decided to put on a repeat class for those who weren’t able to attend last time. This will be a similar class, consisting of me teaching the behind the scenes stuff related to SiteCatalyst. The morning of the class covers all of the core features of the product and the afternoon session has exercises to see how well attendees can bend and manipulate SiteCatalyst to answer real-world SiteCatalyst implementation scenarios. While this class does not focus on the day-to-day SiteCatalyst interface, those who have attended have told me that it helped them understand how SiteCatalyst works and how they can better figure out how to explain to their developers what needs to be done to get them the reports they need to get data to internal stakeholders. Think of it as a bit of product implementation (minus the tagging) and part SiteCatalyst product owner class.
You can see many positive reviews for the class here on our corporate LinkedIn page: http://bit.ly/sitecatalysttopgun
If you are interested in attending the class you can register using this link: https://www.eventbrite.com/e/web-analytics-demystified-adobe-sitecatalyst-top-gun-training-tickets-9868103764
(Note: I apologize in advance that purchase must be made in US dollars. I know this is bad form, but Eventbrite didn’t offer us many options here)
Adobe “Intensive” Training Classes – Portland, OR
For those not in Europe, Web Analytics Demystified will be offering a two day intensive class on Adobe’s core web analytics products in April, 2014. During these two days, we will be covering SiteCatalyst (Analytics), Discover (Ad Hoc Analysis), ReportBuilder and Test& Target (Target). I will be doing an abbreviated version of my “Top Gun” training, followed by Kevin Willeitner doing half day classes on Discover and ReportBuilder. Brian Hawkins will then conduct a half-day class on Adobe Target. These two days will be jam-packed with useful information for those using the Adobe Analytics suite and we are offering these classes at unheard of prices! This is a great opportunity to mingle with other Adobe clients and to learn from the three of us who have either written books on the subject or are in the process of doing so!
To learn more about this two-day “Adobe Intensive” class, please check out this link: http://www.webanalyticsdemystified.com/education/index.asp
While we are just in the beginning stages of the planning, now is a good time to mark your calendar for our annual ACCELERATE conference. This year it will be held in Atlanta, GA and the dates are September 16-18. Like last year, we will be offering our advanced web analysis training classes during the days leading up to the conference. So if you are not near Portland, you will still have another chance to get advanced training this year should you so desire. Please mark your calendars now and look for more information to be coming soon.
Hopefully whether you are in Europe, west coast or east coast, you will have an opportunity to get some training from the Demystified team in 2014. I wish you a great start to the year and hope to see you at one of our events this year!
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!