Adam Greco's Blog at Web Analytics Demystified

Adam Greco is a longstanding member of the web analytics community who has consulted with hundreds of clients across every industry vertical. Mr. Greco began his web analytics career managing the website for the Chicago Mercantile Exchange, became one of the founders of the Omniture Consulting group, and was most recently Senior Director of Web Analytics at Salesforce.com.

Want to speak with Adam? Contact Web Analytics Demystified

Adam Greco Blog at Web Analytics Demystified

Adam Greco, Demystified

I am extremely excited to begin this next chapter in my career and wanted to get started at Web Analytics Demystified by describing my past, the present, and what I hope to do in the future.

The Past

I began my career in consulting working for Arthur Andersen’s technology group, first in the field of Customer Relationship Management and eventually in Marketing where I ended up managing the website of the Chicago Mercantile Exchange. It was there, as one of Omniture’s first customers, that I began to learn about web analytics and the data behind websites.

For some reason web analytics came naturally to me, and I loved figuring out fun, new ways to use the technology at my disposal to answer interesting business questions. As I had done in my consulting days, I dug into every Omniture training manual available and soon found that I knew the technology almost as well as those at Omniture. I think that is what led me to ultimately apply to work at Omniture in their newly founded Omniture Consulting group.

While at Omniture, I had the pleasure of working on many different clients, large and small, and helping them get the most out of Omniture products. As I showed Omniture clients how to use the technology, I often heard clients say “I had no idea you could do that…” so I decided to start a blog to teach people what they really ought to know.

Fast forward a few years and I decided that I wanted to go back to the “practitioner” side of the house and was given a great opportunity to head up web analytics at Salesforce.com. In the role of Senior Director for Web Analytics over the past two years at Salesforce I have had a great time reviving the web analytics program. More importantly, thanks to the generosity of the Salesforce organization, I have been able to continue writing about Omniture technology, speaking at industry events, and helping to establish and grow the Beyond Web Analytics podcast series.

The Present

While working at Salesforce.com has been one of the highlights of my career, when you are used to working on ten or more web analytics projects at a time as a consultant, sometimes working on just one for a few years in a row can be tough. Plus, despite being fully employed these past two years, I have been constantly approached by great people asking how to get the most out of their web analytics efforts — requests that I more often than not had to turn down.

Having been in consulting for most of my career, I had to face the inevitable truth; I have always been destined to become a consultant again … to work with dozens of companies at a time, sharing my knowledge of Omniture with companies large and small working to maximize their investment in web and digital analytics.

The Future

Once I decided that I wanted to go back into web analytics consulting, the difficult part was figuring out which organization would be the best fit for me. There are so many great web analytics consultancies, and over the years I have become friendly with many of the leaders of these firms. However, in my mind, Web Analytics Demystified was my first choice because of the brand that they have built, the caliber of their clients, and the overall thought-leadership their principals have displayed throughout the years.

When I think about the web analytics industry as a whole, I think about the books that helped launch the industry, the Yahoo Discussion Forum, the camaraderie found on Twitter, Web Analytics Wednesdays and most recently, the Analysis Exchange, and the new Web Analysts Code of Ethics. The common theme in all of these pillars is Eric Peterson and the Web Analytics Demystified brand he has created.

It was only last year when I first met Eric face-to-face but I have always been impressed by his ability to understand where our industry has been and, more importantly, where it is going. When John Lovett joined the organization, I enjoyed reading about all that he was doing in helping clients with their strategy, vendor evaluations, and social media efforts. In the last year, I got to spend some time with John and have been equally impressed with his passion for the industry and work he has done as a board member for the WAA.

I know there are any number of organizations that I could have joined where I could have helped teach people what I knew and managed teams of consultants. But at Web Analytics Demystified I believe that I am in a position to be both teacher and also a student, working with two of the smartest, most respected people in the field.

At Web Analytics Demystified, my hope is to help as many clients as possible get the greatest value from their investments in web analytics technology. I am excited to continue helping clients using Omniture technologies, but also look forward to branching out into other vendor tools and help their clients as well. It is my hope that the combination of Eric and John’s strategic work with my design and architecture background will have a synergistic effect, helping Web Analytics Demystified clients to further achieve their digital business objectives.

I look forward to hearing from all of you here in my new blog, and by all means if I can help your business, please don’t hesitate to call.

Posted Tuesday, January 11th, 2011 | 25 responses | Share, Save or Email

Form Submit Button Clicks

(Estimated Time to Read this Post = 5 Minutes)

At the end of last year, I spent a bunch of time showing how you could dissect your website forms to see which were performing well and not so well. While this post will be different from those, it is still related to website forms. In this post, I am going to share a concept that will let you determine which of those visitors seeing your forms have the intention to complete them and which do not. This information can be very valuable as I hope to show.

Which Forms Get Visitors to Take Action?
If you have forms on your website, I hope that you are at least doing the basics and tracking how many people View each Form and how many Complete each Form like this:

This will allow you to have a rudimentary view about how each website form is performing. However, one short-coming of this is that you only have two points of comparison. As a web analyst, I always like to have more data points to slice, dice and analyze. The report above answers the question: “How many people who see each form decide to complete it?” What if you wanted to know how many people who see each form try to complete it? That might be an interesting data point, since sometimes when you do a lot of Paid Search or Display Advertising you could be driving less qualified traffic to your website. Therefore, what I like to do is to create a new metric that I call Form [Submit] Button Clicks. This Success Event is set when website visitors click the button that you place on your form (duh!). By doing this, you have essentially created a wedge between the Form Views and Form Completes metrics shown above such that you can create a report that looks like this:

As you can see here, in the first report above we knew that only 786 of the 2,246 Form Views turned into Form Completions. However, with the second report, we now know that visitors to that specific form clicked the Form Submit button 830 times. That means that 44 times they tried to complete the Form, but were unable to for one reason or another (maybe Form Errors).

Dig Deeper With Calculated Metrics
Once you have this cool new Form Button Clicks metric, you can then create some fun new Calculated Metrics that let you dig even deeper. Here are two that I suggest: Form Button Click Rate & Form Button Click Fail Rate. The Form Button Click Rate is the number of Form Button Clicks divided by the number of Form Views. This metric shows you what percent of people viewing the Form actually click the button as shown here:

In this report you can see which forms on your website are doing a good job at getting visitors to click the button. Forms with low percentages might indicate that there are too many fields, poor content or a bad offer. You can use this report to zero in on which forms represent the biggest opportunity for improvement. I like to bubble-chart this data such that the forms with the most Form Views and the lowest Button Click Rate move to the “magic quadrant.”

The next Calculated Metric is the Form Button Click Fail Rate. This represents the percentage of times visitors click the Form Submit button, but fail to have a Form Complete. These people represent your “lowest hanging fruit” as by clicking the button, they have implicitly told you they are somewhat interested in you! You create this metric by dividing the difference between Form Button Clicks and Form Completes by the number of Form Button Clicks as shown here:

In this case, for the first form, about 5% of people who click the button don’t make it to a Form Complete, but the last form shown in the report seems to have some issues since 62% of Form Button Clicks don’t make it to a Form Complete. You may want to start doing some testing on that form!

As is always the case, whenever you create new Calculated Metrics you can see them as general metrics in addition to using them in eVar reports. Therefore you can set Alerts and see trends for both of the metrics described above:

What I like about these two metrics is that one shows you how good you are at getting people to click the button on the form (how good your offer/content is) and the other tells you how good you are at closing the deal once a visitor has decided to give you a chance. Those who have managed websites realize that there are very different tactics used to solve these two very different questions so having these metrics can really help you focus and use your precious website resources as efficiently as possible.

Don’t Forget Your Other Reports!
While the above reports hopefully get you excited, don’t forget that you already have many reports that can be combined with the information above to get even more value. For example, one of the reports I use a lot is the Traffic Driver (Unified Sources) report which shows me how each visitor got to my website. Wouldn’t it be cool if I could see Form Button Clicks and the above two new Calculated Metrics by Traffic Source? Well…you can! All you have to do is add these metrics to your existing Traffic Sources report like this:

Now you can see how each channel is doing! Looks like Paid Search (SEM) is generating lots of Form Views, but only gets 12% of these to turn into Form Button Clicks. If they do get someone to click the button, it looks like 55% of them don’t end up successfully making it to a Form Complete. This can be contrasted by SEO which seems to fare a bit better by getting 30% of its Form Viewers to click the button and of those 75% make it through to Form Completion. You can imagine how powerful this data could be and how you could use a product like Test&Target to come up with ways to improve these conversion rates by traffic source.

If you want to get even more granular, you can break this report down by the root traffic driver so you can take specific actions. In the following report, I can see the Paid Search ID’s that make up the Form Views and the other metrics and see how each performs individually:

Here we can see that there are some Paid Search keywords that are doing well (get people to click on the submit button over 20% of the time) and others that are under-performing (less than 15%). You can use these metrics to help drive your Paid Search strategy or possible automate this using SearchCenter. Finally, in this fictitious example, I have made row three have zero Form Completes, but a 32% Form Button Click Rate, which would indicate a major issue with the form that should be addressed.

One last example of leveraging an existing report would be the Visit Number report:

Here we can see that the Form Button Click Rate is pretty consistent, but up a bit in the 3rd visit, but interestingly, our Form Button Click Fail Rate appears to decrease over time. Perhaps the more time visitors take to get to know us, the more likely they are willing to deal with all of the information we are asking for on our forms!

Final Thoughts
Well there you have it. I always find it so amazing that adding one simple Success Event in the right place can open up so many new web analysis opportunities. If you have forms on your website, I hope this will help you learn more about your users and how they are interacting with your forms. Let me know if you have any questions…

Posted Tuesday, January 4th, 2011 | 4 responses | Share, Save or Email

Tracking Form Errors (Part 3)

(Estimated Time to Read this Post = 4 Minutes)

In this series of blog posts, I have been talking about how to see what types of Form Errors your website visitors are receiving so you can improve conversion. So far, we have learned how to see how many Form Errors your website is getting, which fields are causing those and how many Form Errors you get per Form and Visit. As my regular readers know, I like to go beyond the basics, so now we are going to kick it up a notch and get into some real fun stuff. Fasten your seat belts!

Which Fields on Which Forms?
In my first post of this series I shared a simplistic way to learn which form fields caused errors using a List sProp. However, correlating this to specific forms was a bit trickier. Here I will show how to do this, even if you don’t have Discover. The trick here is to set a Form Errors eVar that stores all of the fields which had an error when the above Form Errors Success Event is set. Since eVars have a longer character length, this should be possible for most forms that aren’t too long (which they shouldn’t be anyway!). I like to do this by concatenating the field values into one long string with a separator between each field. Here is an example of the report you want to have:

This report will look a bit like the one I described in the previous post, but as you will see, it is much more powerful since it is in the conversion area and can take advantage of Conversion Subrelations. Besides being able to see which combination of field errors are troubling users, you can open your Form ID reports, find a specific form and then break it down by this new Form Error eVar to see the specific form fields causing problems by form as shown here:

Using this report, we can see that for the first form shown above, 66% of the times visitors get a Form Error, they had eight form field errors (or left them blank). This data, when coupled with observational data using a tool like ClickTale can be invaluable in driving increased form conversions!

What % of Required Form Fields Have Errors?

While the above report, which shows Form Field Errors by Form, is powerful, one question it doesn’t answer is: How many of the required fields on my forms are not being filled out by users? The answer to this question can help you figure out which fields should/shouldn’t be required. So to answer this question, what you want to do is to look at each form that loads on your website and calculate how many fields the user received an error for and then divide that number by the total number of required form fields. For example, if you have a form with eight required fields, and the current user received two errors on that form, the calculation would be 2/8 or 25%. You should then pass this 25% value to an eVar when you are setting the Form Errors Success Event. Once you do this for all forms, you will have a report that looks like the one shown here. Using this report we can see that the highest number of Form Errors are cases where users are getting errors on every field (which is most likely people leaving all fields blank). Maybe our users don’t realize that these fields are required and we can do some testing to create a better experience or reduce the number of required fields?

If we want to see which forms are the ones that have the highest 100% Form Field Error Rate, all we need to do is break the above report down by Form ID:

Finally, if you are doing a good job of grouping your website forms using SAINT Classifications, you can see some super-cool reports. In the following report, I have grouped all of my website forms into high-level buckets of Demo and Free Trial. Then I broke this report down by the percentage of required fields that result in Form Errors.

You can see here that most website visitors on Demo forms are getting errors for 100% of the fields (probably leaving them blank!), while for the Free Trial, the largest percentage of required fields with errors is 10%. Interesting data indeed!

Final Thoughts
In this post, we have covered some advanced ways to see which fields produce errors on each form, see this by form and seen how to know which forms have the highest total required field error rates. These reports can provide an enormous amount of insight into what is happening on your forms with respect to errors and once you understand your visitor’s form behavior, you can apply these learnings to all forms on your site. In my next post, I will cover a tangentially related item (related to Forms, but not as much about Form Errors) that I think is super-cool.

Between this post and the last post, hopefully you have some food for thought when it comes to tracking how your website forms are doing so you improve your conversion rates…

Posted Monday, December 20th, 2010 | No responses | Share, Save or Email

Tracking Form Errors (Part 2)

(Estimated Time to Read this Post = 3 Minutes)

In my last post, I started the process of identifying which form fields were producing the most errors. In this post, I will cover some related topics that will allow you to quantify how often you are getting Form Errors and how effective, in general, your forms are at converting website visitors.

How Many Form Errors Are You Producing?
While the solution I identified in my last post showed which form fields had more errors than others, in the web analytics space, we like hard, concrete numbers! Therefore, I would recommend that you set a Success Event each time website visitors encounter at least one form error (assuming you do validation when the Form Submit button is clicked). By setting a Success Event, you will have a nice chart that shows you the overall trend of Form Errors as shown here:

If you are passing a Name or ID for each form you have on your website, you can also use this Success Event to see which forms are getting the most number of errors like this:

In addition, you can set an Alert for the overall Form Error metric or for a specific Form Name/ID:

How Is Each Form Doing?
While knowing how many Errors a form gets is cool, as is often the case, we in the web analytics field care more about ratios! In the report above, it is alarming to see that the first form had 85 Form Errors but how do we know if that is good or bad? If we create a Calculated Metric to compare Form Errors to Form Views, we can see how many Form Errors visitors had in relation to each time the same Form was viewed. Based upon the data below, we can see a wide range of Form Error percentages depending upon the form:

Some of these percentages are quite high and represent amazing opportunities to do testing to see if they can be improved! In addition, when you create a calculated metric, besides just seeing it in an eVar report like the one above, you can also see it as a standalone metric. This means that you can see the overall trend of Form Errors per Form View (or Visit) to see if we are getting better or worse over time. This might make a great KPI metric for the team focused on Forms and Form Completions:

Final Thoughts
In my last post I covered a simple way to see which fields are causing problems for your visitors. In this post, I showed you how to quantify your Form Errors, see how much of an issue you may have and even see which Forms have the most Errors. In my next post I will show you some advanced ways to see which fields are causing errors and how to break this down by Form. Stay tuned!

Between this post and the last post, hopefully you have some food for thought when it comes to tracking how your website forms are doing so you improve your conversion rates…

Posted Monday, December 13th, 2010 | One responses | Share, Save or Email

Tracking Form Errors (Part 1)

(Estimated Time to Read this Post = 3 Minutes)

Almost all websites have forms. Whether you are a B2B/Lead generation site, an eCommerce site, a travel site, etc… you most likely have forms. More importantly, you have people who don’t fill out your forms correctly and get some sort of error message. While error messages are a fact of life, in the web analytics/optimization world these are painful since you work so hard to get people to your site, to read your content and then agree to give you personal information. That is a lot of time and money spent only to have someone potentially abandon because they have problems with your forms. This represents your “low hanging fruit” so to speak – people who have already decided they like you and want to give you their information! In this series of posts, I am going to share some techniques for seeing how much of a problem your website has with form errors and in the next few posts I will cover some more advanced things you can do to diagnose these form error issues.

Which Fields Produce the Most Errors?
The first step in diagnosing form error issues is understanding which form fields are causing issues. Unfortunately, since a user might receive more than one error message, you have to pass in multiple values to a SiteCatalyst variable. This can be done using the Products variable, but since that is often already being used for more important purposes, I will suggest that you use a List Traffic Variable (sProp) to capture these values. Unfortunately, List sProps are not well documented and have some specific limitations (see Knowledge Base ID# 2305). All you need to know is that List sProps allow you to pass in delimited values and when you view them in the sProp report, these values will be split out. Let’s look at an example. Here we see a form in which a user has attempted to submit the form without filling out some required fields. What we want to do is capture which fields this user messed up (could mean incorrect value or leaving blank) so we can see which ones are messed up the most often. In this case, we see that the form errors are related to Job Title, E-mail Address, Phone #, Company Name and the MSA checkbox.

So in this case we can use a List sProp to capture the fields giving us errors. Here is how it would look in the JavaScript Debugger:

Unfortunately, List sProps are still constrained to the 100 character limit so if you have long forms you are out of luck or you can select the most important form fields to capture. Once you have captured the fields, you can open the sProp report and you will see something that looks like this:

In this case, we can see that we are getting the greatest number of errors on the Phone Number form field on the US website (I have added the site since forms exist in multiple sites). I could also filter this sProp report for just US or Japan form fields by using a text search of “us:” or “jp:” as needed. This report should help steer you in the right direction when it comes to fixing basic form field issues.

Correlating Form Field Errors to Forms
Once you have seen which form field errors, the next logical question is to see which forms had which errors. Unfortunately, one of the limitations of List sProps is that they cannot be used in Traffic Data Correlations. Therefore, if you want to breakdown form field errors by Form, you will need to use the Discover product as shown here:

If you don’t have access to Discover and seeing this type of breakdown is important to you, you may want to consider using the Products variable instead of a List sProp since the Products variable comes with full Subrelations by default (though this implementation will be significantly more difficult). I will also be covering a different way to approach this in my next post so stay tuned!

Final Thoughts
If you are not currently tracking form field errors, hopefully this will give you some ideas on how you can start the process of seeing where you are tripping up your visitors. Keep in mind that this post is just a start and that the next few posts will go into more advanced stuff you can do and how you can identify your biggest opportunities for improving conversion.

Posted Monday, December 6th, 2010 | 6 responses | Share, Save or Email

A/B Test Bounce Rates

(Estimated Time to Read this Post = 4 Minutes)

In the past, I have written about Bounce Rates, Traffic Source Bounce Rates , Segment Bounce Rates and Site Wide Bounce Rates. In the latter, I even promised I was finished writing about Bounce Rates, but, alas, I have yet another Bounce Rate installment. I was recently in a conversation with a peer and she asked me how they could see the bounce rates of the various landing page A/B tests they were running via Test&Target. I told her that this was easy to do if you follow my instructions in the Segment Bounce Rate post, but she asked if I could write a brief post with more specifics so here it is…

Why A/B Bounce Rates?
Before getting into the solution, let’s re-visit why this is of interest. Test&Target (and other tools like GWO) are wonderful when it comes to optimizing landing pages. They allow you to alter content/creative elements and see what works and what doesn’t. I have seen many cases where clients have used tools like Test&Target to change content based upon when brought the user to the website (i.e. Search Keyword) or demographic information (i.e. Location). Regardless of the reason you want to test, if it is a landing page, one of the questions you often get asked is related to Bounce Rate. Understanding how many people saw “Version A” of a test and bounced vs. those who saw “Version B” and bounced usually comes up for discussion. To answer this question using Omniture/Adobe tools you have the following options:

Create a unique page name for each test variation and use the regular Pages report and Bounce rate metric. However, this can get very messy, so unless your website is small, I don’t recommend this approach.
Use ASI or Discover to build a segment for people coming from “Version A” or “Version B” and then compare the bounce rates. This is a viable option if you have access to these tools and are well versed in Segmentation.
Attempt to track Bounce Rates from within Test&Target. This does not come out-of-the-box, but if you have mboxes on all of the pages the landing page links to, I have heard of some people setting conversion events on the landing page and the subsequent pages, but I don’t think this is for novices (if you are interested, I’m sure @brianthawkins could figure out a way to hack this together!)
Do what I suggest below!

Implementing A/B Bounce Rates
Luckily, implementing this in SiteCatalyst is relatively simple. All you need to do is the following:

Enable a new Traffic Variable (sProp)
In this new sProp, concatenate the Test&Target ID and the Page Name on each page of your website
Enable Pathing on the new sProp

That’s it! By concatenating the Test&Target ID and the Page Name, you create a unique join between the two and can find the combination of the Test ID you care about and the page name that you expect them to have landed on. Once you find this combination in the report, you can add your Bounce Rate Calculated Metric (Single Access/Entries – which hopefully you already have as a Global Calculated Metric) and you are done. Here is an example of a report:

In this report, you have all of the ID’s associated with the US Home Page, how many Entries each received and the associated Bounce Rate. If you wanted, you could perform a search for the specific Test&Target Test ID you care about and then your report would be limited to just those ID’s. In the example above, we have multiple tests taking place on the US Home Page. However, in the following example we can see a case where there is just one test taking place on the UK Home Page and the associated Bounce Rate of each:

Other Cool Stuff
But wait…there’s more! Since you have enabled Pathing on this new A/B Test sProp, there are some other cool things you can do. First, you can look at a trended view of the report above to see how the Bounce Rate fluctuates during the course of the test. To do this, simply switch to the trended view and choose your time frame:

Another benefit of having Pathing enabled on this sProp is that you can see how visitors from various tests navigated your site using all of the out-of-the-box Pathing reports. Here is an example of a next page flow for one of the tests:

You can run the preceding report for each test variation and compare the path flows to see if one version pushes people more often to the places you want them to go. Another report you could run is a Fall-Out report which can show you how often people from a specific test made it through your desired checkpoints:

In this example, instead of seeing how the general population falls-out from the Home Page to a Product Page and then to a Form Page, we can limit the funnel to only those people who were part of Test ID “18964:1:0.” I like to run this report and the corresponding one for the other test version(s) and add them all to a SiteCatalyst Dashboard where I can see the fall-out rates side by side.

Final Thoughts
As you can see, by doing a little up-front work, you can add an enormous amount of insight into how your A/B tests are performing on your site including Bounce Rates, Next Page Flows, Fall-Out, etc…Enjoy!

Posted Monday, November 29th, 2010 | 3 responses | Share, Save or Email

Tracking Lead Gen Forms by Page Name

(Estimated Time to Read this Post = 5 Minutes)

Every once in a while, as a web analyst, I get frustrated by stuff and feel like there has to be a better way to do what I am trying to do. Many times you are able to find a better way, often times you are not. In this case, I had a particular challenge and did find a cool way to solve it. You may not have the same problem, but, if for no other reason than to get it off my chest, I am writing this as a way to exhale and bask in my happiness of solving a web analytics problem…

My Recent Problem
So what was the recent problem I was facing that got me all bent out of shape? It had to do with Lead Generation forms, which are a staple of B2B websites like mine. Let me explain. Many websites out there, especially B2B websites, have Lead Generation as their primary objective. In past blog posts, I have discussed how you can track Form Views, Form Completes and Form Completion Rates. However, over time, your website may end up with lots of forms (we have hundreds at Salesforce.com!). In a perfect world, each website form would have a unique identifier so you can see completion rates independently. That isn’t asking too much is it? However, as I have learned, we rarely live in a perfect world!

Through some work I did in SiteCatalyst, I found that our [supposedly unique] form identifier codes were being copied to multiple pages on multiple websites. While this causes no problems from a functionality standpoint – visitors can still complete forms – what I found was that the same Form ID used in the US was also being used in the UK, India, China, etc… Therefore, when I ran our Form reports and looked at Form Views, Form Completes and Form Completion Rate by Form ID, I had no idea that I was looking at data for multiple countries. For example, if you look at this report nothing seems out of the ordinary right?

However, look what happened when I broke this report (last row of above report) down by a Page Name eVar:

At first, I thought I was going crazy! How can this unique Form ID be passed into SiteCatalyst on eleven different form pages on nine country sites? This caused me to dig deeper, so I did a DataWarehouse report of Form ID’s by Page Name and found that an astounding number of Form Pages on our global websites shared ID’s. Suddenly, I panicked and realized that whenever I had been reporting on how Forms were performing, I was really reporting on how they were performing across several pages on multiple websites. In the example above, I realized that the 34.669% Form Completion Rate I was reporting for the US version of the form in question was really reporting data with the same ID for forms residing on websites in Germany, China, Mexico, etc… While the majority was coming the the form I was expecting, 22% was coming from other pages! Not good!

The Solution
So there I was. Stuck in web analytics hell, reporting something different than I thought I was. What do you do? The logical solution was be to do an audit and make sure each Form page on the website had a truly unique ID. However, that is easier said than done when your web development team is already swamped. Also, even if you somehow manager to fix all of the ID’s, what is preventing these ID’s from getting duplicated again? We looked at all types of process/technology solutions and then realized that there is an easy way to fix this by doing a little SiteCatalyst trickery.

So what did we do? We simply replaced the Form ID eVar value with a new value that concatenated the Page Name and the Form ID on every Form Page and Form Confirmation Page. By concatenating the Page Name value, even if the same Form ID was used on multiple pages, the concatenated value would still be unique. For example, the old Form ID report looked like the one above:

But the new version looked like this:

With this new & improved report, when I was reporting for a particular form on a particular site/page, I could search by the form pagename and be sure I was only looking at results from that page. Also, a cool side benefit of this approach is that you could add a Form ID to the search function to quickly find all pages that had the same Form ID in case you ever did want to clean up your Form ID’s:

Implementation Gothca!
However, there is one tricky part of this solution. While it is certainly easy to concatenate the s.pagename value with the Form ID on the Form page, what about the Form Confirmation page? The Form Confirmation page is where you should be setting your Form Completion Success Event and that page is going to have a different pagename. If your Form ID report doesn’t have the same Page Name + Form ID value for both the Form View and Form Complete Success Event, you cannot use a Form Completion Rate Calculated Metric. For this reason, you need to use the Previous Value Plug-in to pass the previous pagename on the Form Confirmation page. Doing this will allow you to pass the name of the “Form View” page on both the Form View and Form Complete page of your site so you have the same page name value merged with the Form ID.

A Few More Things
Finally, while the Form ID report above serves this particular function, it is not very glamorous and it might not be the most user-friendly report for your users. If you want to provide a more friendly experience you can do the following with SAINT Classifications:

Classify the Form ID value by its Page Name so your users can see Form Views, Form Completions and the Form Completion Rate by Page Name
Classify the Form ID value by the Form ID if for some reason you want to go back to seeing the report you had previously

Final Thoughts
Well there you have it. A very specific solution to a specific problem I encountered. If you have Lead Generation Forms on your website, maybe it will help you out one day. If not, thanks for letting me get this out of my system!

Posted Monday, November 15th, 2010 | No responses | Share, Save or Email

Tracking Recurring Revenue

(Estimated Time to Read this Post = 5 Minutes)

When I was at the XChange conference, I had the pleasure of meeting a web analyst whose business relied on a subscription model. In a subscription model, you often sell a product initially and then there is a subsequent Recurring Revenue stream (normally monthly). During the conversation, I explained how I would address this in SiteCatalyst and since it is a somewhat advanced concept, thought I would share the same info here in case there are blog readers out there who also have Recurring Revenue models.

Why Is Recurring Revenue A Challenge?
So why is tracking Recurring Revenue in SiteCatalyst difficult? As always, I like to explain through an example. Let’s imagine that you sell a popular CRM product that has an initial sale price and then a monthly subscription. A visitor comes to your website from a Bing keyword of “CRM” and they end up purchasing your product for $10,000. You can track this $10,000 sale online and attribute it to the Bing keyword. However, what do you do after one month? Let’s say the customer pays $1,000 each month after the initial $10,000. How do you attribute the recurring monthly $1,000 to the Bing keyword that originally brought the customer? Many clients I have seen stop at the initial sale, but this is problematic. What if there are some marketing campaigns that bring in a lot of initial sales, but those campaigns produce customers who quit the subscription after two months? Perhaps there are other marketing campaigns that generate lower initial sale amounts, but result in customers who are retained for several years. How do you compare “apples to apples” in this case if you cannot tie both initial and subscription revenue to the original marketing campaign?

The answer for most clients is to simply pass the original marketing campaign to their back-end system and do all of the reporting outside of a tool like SiteCatalyst. However, this has the following negative consequences:

As a web analyst, you are now out of the loop which is not good for your program (or your career!)
There are hundreds of online web-only data points that you know about the original sale (i.e. visit number, internal search terms used, internal promos used, etc…). Are you going to pass all of these data points to your company’s data warehouse and do analysis there? If you are a big company that may be possible, but what if you are a small or mid-sized business?

If you are like me, at a minimum, I like to have all important data in SiteCatalyst so I can have a seat at the table. With this in mind, the following section will describe what you need to do if you want to get Recurring Revenue into your SiteCatalyst implementation so it can be tied to the same data points as the initial sale.

Recurring Revenue in SiteCatalyst Reports
If you have read my past blog posts or even just my last post on Product Returns, you may know that one of my favorite SiteCatalyst features is Transaction ID (I suggest re-reading this post!). At a high level, Transaction ID allows you to set an ID associated with a transaction and later upload offline metrics that are dynamically associated with any Conversion Variable (eVar) values which were active at the time the Transaction ID was set. Just as Transaction ID was important to solving our Product Returns issue, it can be used similarly to solve the aforementioned Recurring Revenue challenge.

When visitors make their initial subscription purchase, you can set a Transaction ID value on the confirmation page. Doing this allows you to establish “key” that can be used later to upload Recurring Revenue and tie it to all of the eVar values associated with the original sale. Keep in mind that you will have to work with your Adobe account manager to get Transaction ID set-up. Additionally, Transaction ID is normally only used for 90 days, but in this case you will need to work with your account manager to get it extended perpetually (or for as long as you want to include Recurring Revenue). For example, if you want to associate two years of revenue with the eVar values that contributed to the original sale, then your Transaction ID data must persist for two years.

Once you have Transaction ID enabled and have started passing Transaction ID’s for online purchases, the next step is to create a new “Recurring Revenue” [Currency] Incrementor Event. Transaction ID uploads are similar to Data Sources and, as such, can only import data as Incrementor Success Event. Setting up a new Incrementor Event is easily done through the Admin Console.

Once you have Transaction ID set-up and your new Recurring Revenue currency Success Event, you need to generate a Data Sources template file that you can upload on a monthly/weekly/daily basis. This file will consist of each subscription account that is still active and the amount of [monthly] Recurring Revenue that should be recorded for each date. Normally, you will have subscriptions that expire at varying dates so you may decide to upload a file on a daily basis which represents all those who are starting a new subscription cycle on that date. The Data Sources template that you will create should have the following columns:

Date – Use the date that the new subscription cycle starts, not the date of the original sale. This date will determine which month the Recurring Revenue will appear in when using SiteCatalyst. NOTE: Please keep in mind that there is currently a SiteCatalyst restriction that you cannot upload a Transaction ID file that has dates spanning more than 90 days. You can upload dates that are more than 90 days old, but the date ranges for the entire file upload cannot be more than 90 days (kind of lame in my opinion!).
Transaction ID – The ID set when the initial subscription sale took place
Product Name/ID – Same value that was passed to the Products Variable during the original online subscription purchase
Recurring Revenue – Amount that the client will be charged for the next subscription cycle

When you are done, your Data Sources upload file might look something like this:

Seeing Recurring Revenue in SiteCatalyst Reports
Once you have successfully uploaded some Recurring Revenue data, it is time to see how all of this looks in SiteCatalyst. To do this, open the Products report and add Revenue and our new Recurring Revenue metrics. The report should look like this:

Next, you can create a Calculated Metric which combines the two metrics to create a “Total Revenue” metric as shown here:

Finally, since Transaction ID allows you to apply the eVar values that were associated with the original transaction to the new Recurring Revenue data, you can use Subrelation break downs for the Products report by Campaign and see both Revenue and Recurring Revenue (and the Total Revenue Calculated Metric)!

In the above report, we can see an example of the quandary I described in the beginning of this post. When we break down our first product (Sales Cloud) by marketing campaign, if we look at the Revenue column, it looks like we should be focusing our marketing spend on Bing Branded Keywords. However, when we add our Recurring Revenue, we can see that the majority of our Recurring Revenue and the most of our Total Revenue is coming from E-mail. Perhaps that is the best place to concentrate our marketing budget…

Final Thoughts
So there you have it. A simple, yet [hopefully] effective approach for making sure that you show all Revenue you are helping generate whether it takes place during the initial sale or subsequently… If you have comments/questions, please leave a comment here…

Posted Monday, November 1st, 2010 | 4 responses | Share, Save or Email

Tracking Product Returns

(Estimated Time to Read this Post = 5 Minutes)

If you sell products or services on your website, you are probably working diligently to be sure that you are tracking the appropriate Orders, Units and Revenue associated with each product sold (you may even be doing some advanced stuff like I described here). Doing this allows you to see all sorts of wonderful things, like what pages lead to sales and what online campaigns have better ROI than others. However, one formidable challenge that web analysts don’t like to talk about is Product Returns. How often have you bought something online only to ship it back or return it to a brick & mortar store associated with the website? If customers return products in significant enough numbers, all of the great online data you have collected may be inaccurate.

I have seen some companies apply a “rule of thumb (dumb?)” in which they discount sales by 20% across the board to account for returns, but how does that help you determine if a specific marketing campaign is good or bad when your SiteCatalyst reports only show the good? By not tying product returns directly to their corresponding online sales, your web analytic reports will be inherently flawed. The truth is that I have seen very few clients who have adequately addressed this issue, so I thought I would suggest an idea that I think is an appropriate way to deal with Product Returns. Even if you don’t sell things through a shopping cart, I encourage you to read this post as its principles are applicable to any situation in which you have an online success that later is retracted in some manner offline.

Tracking Product Returns
The best way to understand the tracking of Product Returns, is through an example. Let’s pretend that are a web analyst for Apple and a first time visitor comes to the website from the Google paid search keyword “ipod” and purchases two iPods for $50 each. In SiteCatalyst, when we open the Products report, we would see $100 for the Product labeled “ipod” and if we broke it down by visit number, the same $100 would be attributed to visit number one. So far, so good…

However, let’s imagine that one of these iPods was returned to a local Apple Store. Now our reality has changed. The paid search keyword and first visit combination has now only led to $50, but SiteCatalyst still shows $100. If we create calculated metrics to compare our Revenue per Marketing spend, suddenly our ROI just got cut in half, but this is not reflected in SiteCatalyst. This might cause us to misallocate marketing dollars to campaigns that look to be good at first, but in reality are not as profitable as others when Product Returns are added to the mix (especially if we automate Paid Search using SearchCenter!). I don’t know about you, but I certainly wouldn’t want to be the one telling my boss to invest in marketing campaigns that turn out to be “duds!”

So how do we fix this mess? In order to track Product Returns, you’ll need to re-familiarize yourself with the Transaction ID feature of SiteCatalyst (I suggest re-reading this post!). At a high level, Transaction ID allows you to set an ID associated with a transaction and later upload offline metrics that are dynamically associated with any Conversion Variable (eVar) values which were active at the time the Transaction ID was set (phew!). In this case, you need to ensure that you are setting a Transaction ID value when the original online sale takes place. By doing this, you create a “key” that will allow you to upload Product Return data later and back it out of its corresponding online sale. Keep in mind that you will have to work with your Adobe account manager to get Transaction ID set-up and you’ll want to be sure that the Transaction ID table persists for as long of a time frame that you require to upload return data (default is 90 days, but this can be extended).

Once you have Transaction ID enabled and have started passing Transaction ID’s for online purchases, the next step is to create a new “Product Return Amount” [Currency] Incrementor Event. Transaction ID uploads are similar to Data Sources and, as such, import data as Incrementor Success Events. Setting up a new Incrementor Event is easily done through the Admin Console.

Once you have Transaction ID set-up and your new Product Return Amount currency Success Event, you need to use Data Sources to generate a Product Returns template which you can populate and upload on a daily/weekly/monthly basis. This file will contain the following columns:

Date – I suggest you use the date that the original purchase took place, not the date of the return, so there is no lag time. NOTE: Please keep in mind that there is currently a SiteCatalyst restriction that you cannot upload a Transaction ID file that has dates spanning more than 90 days. You can upload dates that are more than 90 days old, but the date ranges for the entire file upload cannot be more than 90 days (kind of lame in my opinion!).
Transaction ID – The ID associated with the original online sale
Product Name/ID – Same value that is passed to the Products Variable during the original online purchase
Product Return Amount – This is the total $$ amount per product that is being returned

When you are done, your upload file might look something like this:

Using Product Returns in SiteCatalyst Reports
Once you have successfully uploaded some Product Return data, it is time to see how all of this looks in SiteCatalyst. To do this, open the Products report and add Revenue and our new Product Return Amount metrics. The report should look like this:

Next, we can create a Calculated Metric which subtracts the Product Return Amount from Revenue to create a “Net Revenue” metric as shown here:

Finally, since Transaction ID allows you to apply the eVar values that were associated with the original transaction to the new “return” transaction, you can even use Subrelation break downs for the Products report by Visit Number and see both Revenue and Returns (and the Calculated Metric) by Visit Number (pretty cool huh?)!

Orders & Units (Advanced)
For those that are a bit more advanced, I wanted to let you know that the above solution does not back out Orders or Units for Product Returns. Backing out Orders is a bit tricky since you may only want to remove the Order if the entire Order is returned. Units is a bit easier as you can simply create a second Incrementor Success Event for “Returned Units” as we did above. However, I suggest that you start with Revenue since most of your questions around Product Returns will be related to Revenue.

Finally, SiteCatalyst does provide an out of the box Data Sources template for Product Returns which can be found in the Data Sources Manager:

However, I have not used this template myself and I would have the following potential concerns:

I don’t believe that this template uses Transaction ID which can be problematic as you will be unable to use the Product Return metric with all of your pre-existing eVar reports
It looks like this template uses the same Revenue, Orders and Units Success Events to back out Product Return data. I feel like this can be a recipe for disaster if something goes wrong. With my approach, the worst case scenario (if you upload some bad Product Return data) is that your new Product Return metrics are temporarily off. If you use the standard Revenue, Orders and Units metrics, a mistake can be fatal and hidden amongst your normal online metrics (I never mess with Revenue, Orders or Units!).

For these reasons, I suggest you talk to your Adobe Account Manager or the Omniture Consulting Group if you want to pursue this route.

Final Thoughts
So if Product Returns are something that you have to deal with, the above is my suggested way to handle them. Those of you who work in Retail day in and day out may have come up with some other ways to deal with Product Returns, so if there are other best practices out there, please leave a comment here. Thanks!

Posted Monday, October 18th, 2010 | 9 responses | Share, Save or Email

Hidden SiteCatalyst Features

(Estimated Time to Read this Post = 4 Minutes)

One of the funny things about SiteCatalyst (you will notice I can’t yet bring myself to call it Adobe SiteCatalyst!) is that there are some really cool features that are hidden. In some cases, it almost seems like someone has gone out of their way to hide them, but I like to look at these “hidden gems” as a sort of rite of passage. In this post I will share some of the ones I have found and hope that maybe you know of others so that all of us can learn! Also, if you haven’t read my old blog post on SiteCatalyst Time Savers, I encourage you to do so!

The Magic Triangle and Checkboxes
If you are like me, it may seem like you spend most of your day adding/removing metrics from reports! This can be a very time consuming process, so you might as well be as efficient as possible. However, I often find that new SiteCatalyst users add extra steps to the process because they don’t know a few easy tricks in the Metrics window. The first trick is that you can change the column that is used for sorting by clicking the [very] little triangle next to each metric. It amazes me how many people add metrics, wait for the report to load and then click on a column to sort and wait for the report to load again! Multiply that by twenty reports and it becomes a real time suck! Instead, simply click the triangle until it turns green (soon to be Adobe red?) and you are done!

But wait! There’s more…You will also notice that there are a bunch of check boxes next to each metric. Those check boxes are used to choose which metrics you want to graph with your report. You don’t have to graph every metric in the report, which may confuse your audience. Also, I find that many clients don’t take advantage of the fact that you can display two graphs per report. To do this, all you need to do is check off one of the boxes on the left and right side. This is helpful if some of your metrics are numbers and them are percentages. It is the closest SiteCatalyst comes to a secondary axis you may be used to in Excel.

Remove Subrelation BreakDowns
If you frequently use eVar Subrelation reports, you may find that after breaking one eVar down by another eVar, you want to go back to the report before it was subrelated. For example, let’s say you have opened aTraffic Driver report and broken it down by Offer Type as shown here:

Now let’s say you change the date range and some other report settings and then decide you want to just see Traffic Driver Type by itself again. Unfortunately, if you use the trusty “Back” button in your browser, you will have to re-do all of those customized settings. However, there are actually two ways to remove this subrelation without losing any work.

The first way to do this is to click on the “Broken Down by:” link shown in red above. Once you click on this, you will see a list of all of your variables and you can choose the bottom-most one labeled “None.” The other way is to click the green magnifying glass icon you used to create the Subrelation and do the same thing as shown here:

Double Your Searching Pleasure
Another thing I have noticed that a lot of SiteCatalyst users don’t know is that you can add search criteria to two different variables if you are using a Subrelation report. To do this, click on the Advanced Search link and then you can use the drop down boxes to choose which variable/search term combination you want:

In this case, I have chosen to filter for all Traffic Driver Types containing “SEO” and can proceed to enter my search criteria for Offer Type…

Inherit Segments
If you use DataWarehouse or ASI, you probably spend a lot of time creating Segments. If so, you may find times where you want to re-use some parts of a segment you have already created. When I first started using SiteCatalyst, I did this by printing out my segments and re-creating them manually. This is both time-consuming and prone to error, so I found the trick to do this more efficiently:

There it is! See how easily you can copy an existing segment? Do you see it? If not, would you believe me if I told you that there are actually two different ways to re-use segments on the above screen?

The first way to do this is to click the icon to the right of the Segment title. This will pop-up a new window which allows you to pick an existing segment you want your new segment to be based upon.

The second way to do this is to use the Segment Library. You can access the library by clicking its name next to the “Components” item. The Library is used to store commonly use segment building blocks. In the example below, I have created a Page View container that looks for Pages where the IP Address Geography is in the United States. By dragging this over to the Library, I can re-use this anytime I am creating a new segment.

Filter Report Suites
If you have Admin rights to your SiteCatalyst implementation and deal with a lot of report suites, the Admin Console quickly becomes one of your best friends. One of the most time consuming Admin Console tasks is finding the report suites you are looking for among all of your report suites. I frequently see people scanning up and down over and over hunting for the report suites they need. Fortunately, there is a much better way that is somewhat hidden – using the “Saved Searches” feature of the Admin Console. Using this feature you can create a filter to find report suites such that even if you add new ones, they will be added to your saved search if they meet the criteria.

Here is a real-life example. When I joined Salesforce.com, we had a lot of report suites and I began creating new report suites. When I created the new report suites, I simply added the phrase “New” to my new report suites titles. Once I did this, I clicked on the “Add” link within the Saved Searches area of the report suite manager and created a “Saved Search” rule like this:

Keep in mind that this is a very basic rule. You can actually add multiple criteria items and can build rules that take into account any of the following report suite criteria:

Lastly, if you are an Admin, be sure to read my past blog post with even more Admin Console Tips.

Final Thoughts
So there you have it. As you can see, none of these items are critical showstoppers, but I have found that knowing them can help speed up your day and give you SiteCatalyst bragging rights! Do you know of others? If so, please share them here as comments!

Posted Monday, October 4th, 2010 | 6 responses | Share, Save or Email

« Previous Entries

Next Entries »