Archive for 'Conversion Variables'

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.

(Estimated Time to Read this Post = 4 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.

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:

1. 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
2. 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!

Recently, 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:

1. As a web analyst, you are now out of the loop which is not good for your program (or your career!)
2. 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:

1. 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!).
2. Transaction ID – The ID set when the initial subscription sale took place
3. Product Name/ID – Same value that was passed to the Products Variable during the original online subscription purchase
4. 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…

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:

1. 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!).
2. Transaction ID – The ID associated with the original online sale
3. Product Name/ID – Same value that is passed to the Products Variable during the original online purchase
4. 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:

1. 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
2. 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 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!

(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!

Recently, I was re-reading one of Avinash Kaushik’s older blog posts on tracking Internal Search Term Exit Rates and realized that I had never discussed how to report on this using Omniture SiteCatalyst.  In a past Internal Search post, I covered many different things you can do to track internal search on your site, but did not cover ways to see which terms are doing well and which are not.  In this post I will share how you can see this so you can determine which search terms need help…

Why Track Internal Search Term Click-Through & Exit Rates?
So why should you do this?  In the era of Google, we are all slowly being trained to find things through search.  Many of my past clients saw the percent of website visitors using search rise over the past few years.  In addition, Internal Search and Voice of Customer tools are some of the few out there where you can see the intent of your visitors.  Unfortunately, most websites have horrible Internal Search results which can lead to site exits.  In my previous Internal Search post I demonstrated how to track your Search Results Page Exit Rate, but that only shows you if you have a problem or not.  If you do have a high Search Results Page Exit Rate, the next logical step is to determine which search terms your users think have relevant search results and which do not.  Note that this is not meant to show you which terms lead directly to website exits, but rather, which terms cause visitors to use or not use the search results you offer them after they search on a particular term.

How Do You Track Internal Search Term Click-Through & Exit Rates?
Ok, so how do you do this?  Follow the following implementation steps:

• Make sure that you are setting a Success Event when visitors conduct Internal Searches on your website.  Hopefully you are already doing this so in many cases this step will be done!
• Make sure that you are capturing the Internal Search Term the visitor searched upon in an eVar variable.  Again, you should be doing this (if not, shame on you!).
• Here is where we get into uncharted territory.  The next step is to set a new Success Event when visitors click on one of the items on the search results page.  Depending upon the technology you use for Internal Search, this could be hard or easy.  Regardless of how you actually code it, the key here is to set the second Success Event (I call it Internal Search Results Clicks) only if visitors click on a search result item (not if they click on a second page of search results or go to another page through other navigation).  It is also critically important that you only set this Search Results Clicks Success Event once per search term!  Do not set it every time a visitor clicks on one of the search results after using the “Back” button.  If you don’t do this correctly, your Click-Through and Exit Rates will be off.  This could take a few iterations to get right, but stick with it!
• Once you have both the Internal Searches and Internal Search Results Clicks Success Events set, you can create a Calculated Metric that divides Internal Search Results Clicks by Internal Searches to see the Internal Search Click-Through Rate as shown here:

• From there you can create the converse metric which subtracts the Internal Search Click Through Rate by “1″ to come up with the Internal Search Exit Rate as shown here:

• After this is done, you can open the Internal Search Term eVar report and add all three metrics so you see a report like this:

In this case, it looks like the “Zune” Internal Search term might need some different search result content as it has a much higher exit rate as the others.  Another cool thing you can do is to create a report which trends the Internal Search CTR % or Exit % for specific Internal Search terms so you can see if they have been good/bad over time.  Also, if you use SAINT Classifications to group your Internal Search Terms into buckets, you can see the report above for groups of Internal Search terms.  If you vote for my idea in the Idea Exchange, you would be able to set SiteCatalyst Alerts to be notified if your top Internal Search Terms have spikes in their Click-Through or Exit Rates.  You can also segment your data to see how the Internal Search rates differ when people come from Paid Search vs. SEO, etc… and even use Test&Target to try out different promotional banners on your search results page…

Finally, don’t forget that when you create a new calculated metric like the Internal Search CTR % metric described above, you also get the bonus of seeing this metric across your entire website under the My Calc Metrics area of the SiteCatalyst toolbar.  Simply find this new metric and click on it and you can see your overall Internal Search Click-Through Rate regardless of internal search term.  Your report will look something like this:

For The True Web Analyst Geeks
If you were bothered when I mentioned above that you should only set the Search Results Clicks Success Event once per search term, then you are my kind of person (please apply for a job with me!)!  You were probably saying to yourself: “If I only count once per search term, how will I know which search terms get visitors to click on multiple search result links?”  Right you are!  That could be valuable information.  If you want to see that as well, all you have to do is set a second Success Event each time a visitor clicks on a search result [I call this Internal Search Result Clicks (All)].  Then you can compare how many times people click on any search result to how often click in total.  Here is a sample report:

In this example, you can see that the search term “api” had one click only in either scenario, but the search term “chatter” had people click on it 100% of the time and 5 times they clicked on two search result items.  If you want, you can create another Calculated Metric that divides the Internal Search Result Clicks (All) by the # of Internal Searches to see how many search result clicks each term averages.  In the case of “chatter” above, it would be 2.25 search result clicks per search!

Final Thoughts
If Internal Search is important to your site, make sure you are tracking it adequately so you can improve it and increase your overall website conversion.  Do you have any other cool Internal Search tracking tips I haven’t covered?  If so, leave a comment here…

I believe that every SiteCatalyst implementation should have a Previous Page sProp.  There!  I said it (I feel like I am channeling Avinash!).  In past blog posts I have touched upon the use of a Previous Page sProp, but I feel like I have not done it justice and wanted to take time to explain it in greater detail.  In this post, I will describe why I think this variable should always be set and provide some examples of its use.

Why You Need a Previous Page sProp
I find that in the web analytics world, I often receive the following question:

“What page was the visitor on when he/she _______?”

You can fill in the blank with many things.  Here is a list of the ones I have been asked:

• …searched for this phrase in our internal search box…
• …clicked on a button to go to a web lead form…
• …downloaded a white paper…
• …added products to the shopping cart…
• …clicked on a banner advertisement…
• …started using the ROI calculator…
• …clicked to fill out a website survey…

I could go on for days and never come to the end of these types of questions!  People want to know this information because it helps them get inside the head of their visitors.  Often times it leads to navigation or content changes.  Regardless of the reason, I assure you that you will be asked this question at some point and the truth is that it is not easy to answer with out-of-the-box functionality (i.e. Pathing).  The good news is that setting the Previous Page sProp is easy and will pay great dividends down the road…

How To Set the Previous Page sProp
Setting the Previous Value sProp could not be easier.  All you have to do is use the Previous Value JavaScript Plug-in to pass the previous page name to a new Traffic Variable (sProp).  You can even see a detailed description of the code for this in Ben Gaines’ great Summit blog post.  If you need help, call your Omniture Account Manager, Omniture Consulting or ClientCare.

Once you have your JavaScript setup to pass the Previous Page Name to the sProp, you need to enable a Traffic Data Correlation to any sProp for which you want to create a breakdown.  For example, if you want to see what pages visitors were on when they searched for a particular internal search term, you would correlate the Previous Page Name sProp with the Internal Search Term sProp…

…so you can see a report like this:

In addition, if you are familiar with correlations, you may recall that they are bi-directional, so in addition to seeing the pages people searched for specific terms from, you can also see the converse.  In this case, that would mean seeing all of the internal search terms visitors searched for on a specific page:

As you can see here, we see the same “4″ searches for the phrase “chatter” from the selected page as we saw in the first internal search term report (in this case I am just using Internal Search as an example, but if you want to learn more check out my Internal Search post).

One Is Usually Enough
However, one word of caution, I have seen many clients implement several Previous Page sProps and I am not a fan of doing this as I will now explain.  Let’s say you want to see what page people were on when the searched on a specific search term (as described above) and you also want to see what page they were on when the downloaded files on your site.  A lot of people will set two Previous Page sProps in this situation – one for the search term and one for the file downloads.  In my opinion, this just wastes a variable, wastes correlations and causes confusion for your users.  The truth is that all you need is one Previous Page sProp to answer both questions.  Since on each page there will be one and only one Previous Page value, there is really no reason to do this multiple times.

I have seen some clients who have chosen to pass the Previous Page Name to an eVar.  There are some interesting uses of this.  For example, if you want to see what pages visitors were on when they added a specific product to the shopping cart, you can pass the Product Name to the Products Variable, set the Cart Add Success Event and the Previous Page Name to an eVar.  The main issue you will run into is that Conversion Subrelations are an “all or nothing” proposition so you can only do breakdowns by eVars that have Full Subrelations.

One final tip that I will throw out there is to consider having your developer pass a value of “[NO PREVIOUS PAGE AVAILABLE]” (or something similar) to the Previous Page sProp on entry pages (or any other time no Previous Page is available).  I find that this is easier than dealing with questions around “Unspecified” in correlation reports and it is easier to remove this value using the search box than it is to hide the “Unspecified” values.

Final Thoughts
As I mentioned in the beginning, I highly recommend that you have a Previous Page sProp for all of your key report suites and add correlations as needed.  If you have any questions/comments, feel free to leave them here…

I recently received an e-mail from a blog reader who was having issues tying their Orders in SiteCatalyst to Orders in their back-end system.  Here is a snippet from the e-mail:

I have a little issue in my own SiteCatalyst setup that I recently discovered.  Sad for me I had trusted the number of Orders for each day’s Conversion Funnel and recently I decided to validate the numbers in SiteCatalyst against what our back-end system has.  SiteCatalyst is 5%-10% understated each day which makes for a heck of a difference at the end of the month!  I’d rather be understated than overstated, but can you give me some ideas where I should look first?

Unfortunately this is an all too common problem I hear out there.  In this post I am going to share some ideas on how you can tackle this Order/Revenue validation issue head-on and make sure you can trust your critical Orders/Revenue data in SiteCatalyst.

Order ID eVar
If you have an online shopping cart, you should already be setting the s.purchaseID variable with a unique Order ID when an Order takes place on the website.  This variable is used by SiteCatalyst to ensure Order uniqueness.  Unfortunately, the downside of this variable is that it is not readily available in the SiteCatalyst interface.  It is available in DataWarehouse but not in regular SiteCatalyst reports or Discover.  Carmen Sutter (@c_sutter) has submitted  an idea in the Idea Exchange to change this, but until then, I recommend that you set what I call an Order ID eVar variable.  To do this, all you need to do is set the same value you pass to the PurchaseID variable to a custom eVar.  This will allow you to see all Orders and Revenue by Order ID from within SiteCatalyst and Discover as you would any other eVar.  Once you have done this, you can open up this new Offer ID eVar and add your Orders or Revenue Success Event as needed:

In the example above, we can see that most Orders have only one Order ID, which is what we want.  However, in this case, we can see that one ID was counted twice.  That may require some research and I like to schedule a report like the one above to be sent to me weekly so I can make sure nothing strange is going on.

Data Sources Setup
However, while adding an Order ID eVar is helpful in seeing if you are over counting Orders in SiteCatalyst, it won’t tell you if you are under counting Orders or  how close your SiteCatalyst data is to your back-end systems.  To do this, I recommend you use Data Sources.  As a quick refresher, Data Sources allows you to import external data/metrics into SiteCatalyst (see post link for more details).  In this case, I recommend that you import in a file from your back-end system into SiteCatalyst which contains your unique Order ID, the number of Orders (which should always be “1″) and the Revenue Amount.  When you import data via Data Sources, you include the date that you want the data to be associated with so it doesn’t matter if you import the data on a daily, weekly or monthly basis, but the more frequently you upload it, the better so you can find issues quickly.

Here are step-by-step instructions on how to do this:

• Create the Order ID eVar described above
• Create two new Incrementer Success Events and name them “Back-End Orders” (Type=Numeric) and “Back-End Revenue” (Type=Currency)
• Create a new Data Sources upload template (ClientCare or Omniture Consulting can assist with this).  You want to be sure to map the two new “Back-End” Success Events to the Data Sources template.  Even more critical, is that you want to include the newly created Order ID eVar in the Data Sources template.  If you do not do this, then you will not be able to see these two new Back-End metrics in the same Order ID eVar report that you have in SiteCatalyst (more on this later).

• When you are done, you should have a Data Sources template that looks something like this:

• Now all you have to do is work with your developers to have this file sent via FTP to the Data Sources FTP on a regular basis.

The Payoff
So by now, you are probably saying to yourself: “That’s a lot of work!”  No argument here!  However, hang with me as I share what the ultimate payoff is for doing this.  As you recall, our primary objective was to see if our online Order and Revenue data was matching what our back-end systems indicated.  Now that we have the Order ID eVar and two new “Back-End” Order and Revenue metrics, we have everything we need.  This is where the fun begins and we put it all together!

All you have to do now is to open the new Order ID eVar report and add all of the relevant metrics.  First, we will add the SiteCatalyst Orders and Revenue so we can see online Orders and Revenue by Order ID:

Next, we will add the two new “Back-End” metrics to the report and, since we were smart enough to include the Order ID eVar value in the Data Sources upload, SiteCatalyst knows which “Back-End” Order ID and dates line up with our online data:

Cool huh!  As far as SiteCatalyst is concerned, these offline metrics are connected to your Order ID eVar values just as if they had happened online.  Using this report, we can see if there are any differences between our online and offline data.  In the example above, it looks like the “Back-End” system had an order with $2,350 in revenue that wasn’t captured online.  Having this information makes it much easier to troubleshoot order submission issues.  You can even use DataWarehouse or Discover (only if you use Transaction ID Data Sources) to break down Order ID by browser, domain, IP address, etc… to see if you can figure out what is happening.  In addition, you can export this data to Excel and look at the totals to see how far off you are in general.

Finally, for the true SiteCatalyst geeks, you can create a Calculated Metric that divides Orders by Back-End Orders and/or Revenue by Back-End Revenue to see a trended % that each is off and set up Alerts to notify you if they deviate too much!  When you take into account this level of assurance all of a sudden the Data Sources work above might not seem like all that much in the long run!

Final Thoughts
If you sell products online, nothing is more critical than believing in your key metrics.  Even if you don’t sell online, the same principles here can be applied to lead generation forms, subscriptions or any other metrics you store in SiteCatalyst and also in your back-end systems.