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

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

Establishing Cart Addition Date

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

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

Identifying Duration in Cart

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

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

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

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

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

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

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

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

Product-Specific Cart Duration

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

Final Thoughts

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

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

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

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

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

Excluding Employee Traffic

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

External Campaign Reports

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

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

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

Next Steps

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

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

Web Analytics Announcements

I think the biggest difference in this year’s Summit was the focus on the suite of Adobe products. To say that web analytics was downplayed this year is an understatement. During the opening session, it was clear that diversification was the theme and only a few announcements related to web analytics were made (i.e. Discover 3). It was clear that this was no longer an Omniture Summit, but rather a venue to show all attendees the breadth of the full Adobe Digital Marketing Suite including CQ, Efficient Frontier and others. While I understand the rationale here, part of me was sad to see an event so heavily focused on web analytics in the past morph into a new type of Summit, but that’s what happens as a result of acquisitions (for me it was kind of like when you see an actor who you loved in leading roles relegated to a supporting role later in their career!). But I do think that the integration of analytics into the other Adobe products is exciting and the wave of the future.

Obviously, the announcement of Discover 3 is exciting for us web analysts. This release has been a long time coming and provides some much needed cross-visit pathing and attribution improvements. While I had hoped these features would be part of SiteCatalyst, for now, I will gladly use Discover 3 to take analyses to the next level. Tim Lott and his team have done a complete overhaul of the product and the new “table builder” features look really cool (especially to those of us who love Excel Pivot Tables!).

I was encouraged by the announcement of the planned “virtual analyst” feature that was shown at the closing session. While this feature is really playing “catch-up” to Google Analytics (Intelligence), it’s great that SiteCatalyst will help web analysts identify some areas to investigate when doing web analysis. I find that many clients are not sure where to start and this feature will go a long way to nudging people in the right direction. I also liked the ability to see when web analytics data is exceeding standard data ranges. While it has been somewhat possible to do this using Alerts, I think the proposed visualizations will be much easier for people to use and understand.

Another cool item shown was the proposed geo-mapping feature that JD Nyland demonstrated. Now, instead of exporting SiteCatalyst data to a tool like Tableau, it will be possible to view web analytics data on a map and even build segments by dragging across states and cities. I think this would be very handy, especially for those who sell online and through brick and mortar stores.

Analytics Action Heroes Session

It was great to be able to present again this year at the conference. Once again, I joined Brent Dykes as part of a panel and this year we shared stories related to his new Web Analytics Action Heroes book. Our session was a fire hose of information and followed the progression of Brent’s book. I shared examples of how you can avoid spending too much time in “Setup Land” by monitoring your data quality through ReportBuilder (which Adobe announced is free for ten people at every customer now!), why I think knowing how to use SiteCatalyst is important and why segmentation is important to success. These are all topics I have discussed in past blog posts, but they appeared to be as relevant as sever as the audience seemed to resonate with the themes.

My Question For You…

One interesting thing did happen to me at this year’s Summit that hasn’t in the past. I had a number of people come up to me and discuss the fact that there wasn’t a lot of depth when it came to educational sessions related to SiteCatalyst. In year’s past, there have been many practical breakout sessions in which people like me, Adobe consultants and Adobe customers have demonstrated specific things they have done with SiteCatalyst such that you could go back to your office and implement new things to spurn new analyses. For one reason or another, outside of Kevin Willeitner’s “Shopalytics” session, many folks seemed to think the Summit was a bit light in this area. Perhaps it was due to the downplaying of web analytics I mentioned above, but, I for one, still think that there is a need for us web analytics folks to walk away from conferences like this with more actionable tips and tricks that can help us in our daily lives. Back when I worked at Omniture, I was fortunate to get an entire Summit session to myself and share tons of advanced SiteCatalyst tips and tricks and these sessions were always very well attended and highly rated. Unfortunately, it seems that each year the breakout sessions tend to get a bit more higher-level (or “sales pitchy” as some referred to it). I think Adobe might be missing a great opportunity here and that they may need some sort of “advanced” track for people who want to go deep into web analytics at the conference.

This leads to the question I have for you. If you are a frequent reader of my blog, you will know that it is normally a one-way street with me sharing tips and education and that I rarely ask for interaction or feedback. However, at the Summit, I had many folks come up to me and ask if I would consider doing a 1-2 day session like the ones I used to do at Summit in which I provide advanced product education and a bunch of tips and tricks related to SiteCatalyst I have performed over the years. I have considered doing this from time-to-time, but, being busy consulting clients, haven’t explored it in depth. Please consider the following:

• Would you like to attend a 1-2 day class that teaches advanced SiteCatalyst features?
• Would you like to see examples of SiteCatalyst tips and tricks to create new types of web analyses?
• Would you like to explore topics I have blogged about in more detail and have the ability to ask questions?
• Would you be willing to fly somewhere to do this and pay $$$ for this?

If the answer is “Yes” to these questions for enough of you out there, I might consider doing a 1-2 day class on the above topics. Therefore, I am asking you to e-mail me at adam@webanalyticsdemystified.com and let me know if you would attend and pay for this (and feel free to pass this message around to generate interest!). If I get enough e-mails, I might give it a whirl (we like testing right?).  Thanks!

Segmentation Enhancements

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

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

Multi-Session Enhancements

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

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

Report Sorting Enhancements

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

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

Final Thoughts

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

eVar Expiration Limitation

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

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

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

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

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

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

The “Über” Success Event

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

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

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

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

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

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

Tracking Tab Usage

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

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

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

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

Product Tab Pathing

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

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

Product Tab Influence

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

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

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

Final Thoughts

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

Conversion By Placement

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

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

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

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

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

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

Spots & Keywords

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

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

Product List\Collection Pages

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

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

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

Final Thoughts

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

About Tealeaf

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

SiteCatalyst Integration

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

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

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

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

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

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

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

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

The Future

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

Final Thoughts

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

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

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

SiteCatalyst Real-Time Analytics (Sort Of…)

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

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

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

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

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

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

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

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

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

Date Stamp Variable

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

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

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

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

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