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.

Implementation Differences

The following are some of the SiteCatalyst areas that I have found to be most impacted by the size of the implementation:

Multi-suite Tagging
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!

Variable Conservation
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.

Uniques Issues
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.

SAINT Classifications
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.

Final Thoughts

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!

Revenue Bands

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

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

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

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

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

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

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

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

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

Establishing Your Cohorts

The first step in performing this analysis is to identify the business question that you’d like to solve. There are an unlimited number of cohort analyses that can be done, so I will use a simple retail example here. Let’s imagine that your boss wants to know how much money those who place their first order in month #1, spend on the website in month#2, #3, #4, etc. For example, how much did those who originally purchased in January, spend in February, March, etc. and how does that compare to those who originally purchased in February and then spent additional money in March, April, etc.? In this example, we will start with January 2013 as month #1. To do this, we first need to identify visitors who made their first purchase in the first month, in this case, January 2013.

If you have been reading my posts about setting a Date eVar or Segmenting on Key Dates, you may recognize that we are going to want to set a date to an eVar as part of this solution. However, in this case, what we need to do is to set the date eVar only at the point that the visitor makes their first purchase. An easy way to do this is to create a new eVar and call it “Original Purchase Date” and in the Admin Console, set it to be Original Value (First) allocation and expire it “Never” as shown here:

Once this “Original Purchase Date” eVar has been created, you would set it on the order confirmation page every time, since the allocation will tell SiteCatalyst to ignore it if a value already exists (obviously, cookie deletion will cause it to be reset, but there isn’t much we can do about that). Keep in mind that if you have an existing implementation, the “first purchase” may not be the real first purchase since visitors may have purchased before this eVar was around, but over time it should work for new visitors. If this bothers you, I suggest asking your developers to write some code to only set the eVar if it truly is a first time purchase.

Now that you have an Original Purchase Date eVar, we need another eVar to compare it to in our cohort analysis. This second eVar would be the date that each purchase takes place. This eVar is easy, as it is simply set to the current date on each visit as described in my Date eVar post and will bind to the Revenue metric when the purchase success event is set. For the first purchase, the “Original Purchase Date” eVar will be the same as the Date eVar, but as visitors make subsequent purchases, the “Original Purchase Date” eVar will stay constant while the Date eVar will contain dates in the future.

Setting Up The Analysis

After you have the two date eVars populating, the next thing you should do is to group dates into larger buckets, either weeks or months. While you can use specific days, I find that doing analysis at a weekly or monthly level is a bit cleaner and may be a bit easier to explain here. To do this, I will apply SAINT Classifications to both of my Date eVars. This is very straightforward, as you simply upload the week or month associated with each date as shown here:

Next, let’s assume that a few months have passed and that it is now early April of 2013. We will open the Original Purchase Month eVar report (classification of Original Purchase Date) and add Revenue as the success event. Once this report opens, we will make sure our date range covers January 2013 through April 2013 and then should see a report that looks like this:

Unfortunately, the preceding report isn’t terribly exciting (yet!) since it just shows revenue by the month of the original purchase. However, when we apply a subrelation to break down this report by the Month Classification of the Date eVar, something magical happens:

As you can see here, revenue for cases in which the original purchase took place in January 2013 and February 2013 is now broken out by each month in which purchases actually took place. This allows us to see our first cohort analysis and see how much $$$ those who purchased in each month spent in subsequent months. If desired, you could also add other elements to a segment to do more in-depth analysis. For example, you could add Marketing Channel = SEO to a container in the segment builder to see how this analysis changes for those sourced from SEO. You could add visit number to the segment container to see how this analysis changes for visitors whose original purchase was also their first website visit. The possibilities are truly endless.

As you can see, setting up cohort analysis in SiteCatalyst is a bit of work, but not impossible. One downside is that you need to use one eVar for every type of cohort you want to do. In the preceding example, I created an “Original Purchase” eVar, but if I wanted to see a cohort analysis around Orders, I would need to have an “Original Order” eVar. If you are running low on eVars or want to do many types of cohorts, this can be an issue. Maybe one day SiteCatalyst will allow you to see an “original” version of each eVar out-of-the-box.

Creating Your Cohort Analysis in Excel

Unfortunately, the report above doesn’t present the data in the ideal “cohort” framework. To do this, you are going to have to do a bit more work, and I recommend using Microsoft Excel. We will have to extract the preceding data to create a table that shows the current month in the “Month 1″ column and then subsequent months in the next few columns so it looks like this:

For example, if we assume that the preceding report was run in April, we can see how much is spent in each month and the subsequent months. Another way to visualize this is to calculate cohort percentages by dividing these revenue amounts by total monthly revenue to create report like this:

In this example, it looks like we may be doing a bit better in February than we did in January since a higher percentage purchased in the following two months.

But how do we extract this data in an easy, scalable way? To find out, stay tuned for my partner Kevin Willeitner’s post on how to build Cohort Analyses using ReportBuilder which will show how you can use ReportBuilder to automatically  create the above tables…

NOTE:
My friend Jan Exner wrote a related blog post about performing cohort analysis in SiteCatalyst which you can read here (if you speak German!). While I swear I wrote my post before translating his to English, you will see that our approaches begin in a similar way, but diverge thereafter. Another cohort-related post by Tim Elleston can be found by clicking here. As is often the case with SiteCatalyst, there are multiple ways to do similar types of configurations so it is beneficial to review both options. If you just can’t get enough cohort analysis reading to satisfy you, check out Justin Cutroni’s post on how to do cohort analysis in Google Analytics. In the meantime, I hope this helps and if you have any questions/comments, feel free to leave them here. Thanks!

Key Date Reporting

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

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

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

Key Date Segmentation

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

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

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

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

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

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

A Few Gotchas

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

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

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

This year’s conference will be special for me since it is the first one since my book on Adobe SiteCatalyst has been published, and I look forward to talking to folks who have read it and getting their feedback. It will also be fun since all of my Web Analytics Demystified partners will be in attendance, including our three new additions in the past year. Since we all live in different locations, it is always great to get together in person. We also look forward to meeting with our wonderful clients, many of whom use Adobe products, both at the conference and on the slopes!

Come Chat With Team Demystified

One of my favorite parts of Adobe Summit has always been the informal chats that take place in the hallways with people who are passionate about web analytics and Adobe products. I love meeting people with whom I have interacted on Twitter and helping them answer questions that take more than 140 characters. Unfortunately, since the Adobe Summit has become so massive, I have found that over the years, I don’t end up seeing all of the people I initially hoped to see. So this year I am making a concerted effort to meet with as many people as I can.

To this end, if you or folks from your company would like to spend some time with me or any of the folks at Web Analytics Demystified, we are going to try and pre-arrange times that we can chat during the multi-day conference. Have a SiteCatalyst issue you want to chat about? Have a testing dilemma to discuss? Want some strategy advice? Need tagging tips and tricks? Dashboards driving you crazy? Whatever the topic, one of us can most likely help out. To schedule time with our team, please contact me and send your name, your company and the topics you would like to discuss and I will do my best to facilitate a conversation with the right Web Analytics Demystified partner. I look forward to seeing as many of you as possible at the Summit!

Ensighten Agility

First on my list is the Ensighten Agility conference. As most people now know, Ensighten, founded by industry veteran Josh Manion, is the company that over the past few years created the tag management space. I remember a few years ago at the Washington DC eMetrics conference when Josh and his small band of employees were handing out wigs and asking people to take part in the upcoming “Tag-olution” of our industry! Back then tag management was a concept on the fringe of our industry, but time has shown that Josh and his team were onto something big. Fast-forward to now where there are an array of tag management vendors and even heavyweights like Adobe and Google have entered the space. Nowadays, it isn’t a question of whether a company will implement a tag management solution, but more a question of when it will be implemented. I would say that Ensighten is the technology that I am asked the most about by my enterprise clients and I have urged them to attend this conference so they can become more educated about Ensighten and tag management in general. The Ensighten Agility conference will provide a way to see first-hand the latest developments that Ensighten has created and hear from some of their leading customers and speakers.  Our own Brian Hawkins will be speaking about how you can use tag management to boost your testing programs. The event is taking place in San Francisco on January 31st and February 1st with a workshop day taking place on January 30th. You can register for the event by clicking here.

Webtrends Engage

As if the Ensighten conference weren’t enough of an excuse to visit lovely San Francisco, in the same week, the Webtrends Engage conference is taking place just down the street a few days before the Ensighten conference. If you are a Webtrends customer, you get a nice week-long visit to San Francisco, but even if you aren’t currently a Webtrends, there are reasons you should check out the Webtrends Engage conference. Webtrends has been transforming itself into company that offers much more than traditional web analytics. From their solutions in mobile and social to the latest release of Webtrends Streams, Webtrends is not the same company it was when I first encountered them so many years ago. Eric Peterson, Brian Hawkins and I will be at the conference so if you are coming and would like to chat, please contact us.

Coming Soon

After these two conferences, the next conferences I’ll be attending are the Adobe Digital Marketing Summit in Salt Lake City and the big San Francisco eMetrics conference in April. The Adobe Summit is always a great time, as Adobe hosts some of the best vendor conferences I have ever attended. eMetrics San Francisco should be fun as this is usually the most attended eMetrics conference of the year. All of my Web Analytics Demystified partners will be there and looking forward to catching up with our web analytics friends from across the country. Once again, the DAA is hosting its annual DAA Gala which is always a good time. If you haven’t attended a DAA Gala in the past, you should consider it. There have been great speakers, food and a chance to unwind a bit and get to know your web analytics peers in a fun, social environment (plus you get to witness the geeks’ version of the academy awards!).

Finally, at the San Francisco eMetrics conference, I will be offering my advanced “Top Gun” Adobe SiteCatalyst training class. This workshop has been a blast and received rave reviews in Boston and London. I encourage you to check it out and if you have any questions about it to contact me.

Conversion Flow eVar

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

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

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

Concurrent Flows or Tests

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

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

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

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

The Product vs. SKU Dilemma

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

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

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

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

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

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

Solution #1 – Product ID Only

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

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

Solution #2 – SKU Merchandising

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

During the Product View:

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

During the Cart Addition:

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

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

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

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

Final Thoughts

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

What is ClickTale?

For those unfamiliar with ClickTale, it is an in-page analytics tool that allows you to record website sessions, filter them and play them back. It is often used to see heat maps of pages and to “watch” website visitors and includes even their mouse movements. It is pretty cool technology since often times the best way to get internal stakeholders to understand website issues is to have them watch real users encountering issues.

In a similar manner to what I described in my previous Tealeaf post (which I suggest you read before continuing with this post!), it is possible to pass a ClickTale ID to SiteCatalyst via an sProp or eVar:

Having this ClickTale ID in SiteCatalyst allows you to use the standard segmentation capabilities of SiteCatalyst to isolate visits or visitors who exhibit specific behaviors in which you are interested. For example, you might be interested in isolating visits where visitors reached checkout, but didn’t purchase:

Once you do this, it is possible to open the preceding ClickTale Session ID eVar and see a list of all of the ClickTale session ID’s that match this segment.

Adobe Genesis Extend (BETA) Integration

But as I noted in my preceding Tealeaf post, one of the frustrations of this type of integration is that once you isolate the session ID’s that you want to watch, you are stuck. You have to copy each one individually and then switch to the other application (i.e. Tealeaf) and then start the process of watching the session. My wishlist item in my previous post was that this process could be simplified so you can simply click and view the session, right from within SiteCatalyst. Believe it or not, doing this is now possible! Thanks to the creation of Genesis Extend (still in Beta), you can add a Genesis Chrome browser extension to your version of Chrome and get the ability to streamline this process for ClickTale (not Tealeaf unfortunately).

To do this, simply search for the Genesis Chrome browser extension and install it. When that is done, you will see a new icon in your Chrome browser which you can click to see the settings:

You will notice that there is a ClickTale box you can check (and also one for Twitter which allows you to see actual Tweets in referrer reports). From here you can enter your ClickTale authorization credentials and you are ready to go.

Back in SiteCatalyst, there is a free Genesis “labs” area you can visit to launch the wizard that helps you generate the code you need to capture the ClickTale ID in an eVar of your choice:

After you have completed the wizard and are collecting ClickTale recording ID’s in an eVar, you can open that report in SiteCatalyst, you will see a new link in each row…

…which allows you to click to view the actual recording in ClickTale:

It is also possible to use this new SiteCatalyst eVar to copy a list of ClickTale ID’s and paste them right into ClickTale to create a segment and look at heat maps for just those ID’s.

Final Thoughts

As you can see, this is a cool interface integration that is possible since both SiteCatalyst and ClickTale are “cloud” products. I would expect that you will see more of this in the future in more browsers or even natively as part of SiteCatalyst. If you are a ClickTale customer and use SiteCatalyst, you should definitely try this out!

However, given its geographic distance, one group of folks that I have not had many opportunities to meet are the folks in India. As I have learned over the years, India is a country that has a large population interested in web analytics. In my own personal networks, I think I am connected to more folks in India than most countries I am able to visit regularly. Since I have started conducting more training and with the publishing of the book,

I have received a steady stream of requests from folks in India who want to learn more about Adobe SiteCatalyst and other topics related to web analytics. Based upon these requests, I had a conversation with our Indian-based partner eClerx about the possibility of doing training classes in India and we have decided to investigate the possibility.

Bearing in mind that it may end up not being logistically or financially feasible, Web Analytics Demystified and eClerx are conducting an exploratory exercise to see how many in India would be interested in live web analytics classes and what types of training classes would be desired (since we are data people!). Therefore, if you are in India and in the web analytics field (or want to be!), please go to this web page and tell us the types of training would interest you the most. Based upon this feedback, we will determine if we want to take this initiative to the next level. Thanks!