Conversion Variables — Part II [Inside Omniture SiteCatalyst]
As was previously discussed, Conversion Variables are persistent such that as visitors to your site get assigned a value for a Conversion Variable, it stays with them for a designated time frame. For example, if a visitor fills out a form on your website and indicate that they live in Chicago, we may pass the value of “Chicago” to Conversion Variable 1 for that user. You don’t need to worry about where that data is stored, but rather just understand that it can be stored and applied to Success Events that take place thereafter. However, this ability to store persistent values brings with it some complications. What happens if two values are passed to a Conversion Variable before a Success Event takes place? Who decides which should get credit for Success Events? Who decides how long SiteCatalyst should store the Conversion Variable values? Great questions and the answer is that you get to decide! SiteCatalyst provides an Administration Console where you can adjust the settings of your Conversion Variables. This tool allows you to specify the Conversion Variable Name, Allocation, Expiration, Type and Status as shown here:
Name represents what your users will see as the “friendly” name for Conversion Variable in SiteCatalyst. In this preceding example, we would name Conversion Variable 1 to “City” so SiteCatalyst users would know that anytime they want to view Success Event metrics by City, they should open that report.
Allocation is a way that you can tell SiteCatalyst if you want the first Conversion Variable value, the last Conversion Variable value or all Conversion Variable values to be associated with subsequent Success Events. If you would like the first value that gets passed to a Conversion Variable to get credit for subsequent Success Events you would choose “Original Value (First).” If you wanted the last value passed to the Conversion Variable to get credit for subsequent Success Events, you would choose “Most Recent (Last).” Finally, if you want multiple values passed to a Conversion Variable to get credit for subsequent Success Events, you would choose the “Linear” option (However, please note that the linear option does not allocate across multiple visits so it is only dividing credit amongst values passed to the Conversion Variable within one visit).
Once a value for a particular user is stored in a Conversion Variable, you use the “Expire After” setting to specify how long it should remain there. If your website is very Visit-focused, you may leave the default of “Visit” for many of your Conversion Variables. Conversely, you may decide that once you capture the visitor’s Age in a Conversion Variable, you’d like to keep it as long as possible so any future Success Events can be broken down by Age. Finally, you may decide that you want to keep Conversion Variable values only until the point at which a user completes a specific Success Event. All of these options are available to you in the Expiration area.
Since Type, Status and Reset are a bit more advanced and are seldom changed, I will cover those in a future post.
When Should Conversion Variables Be Set?
Another important thing to understand related to Conversion Variables is when they should be set. In order to associate a Success Event with a Conversion Variable, the Conversion Variable must be set at the same time or before the Success Event. For example, if you set a Success Event on the third page of your site, but don’t store the visitor’s City to a Conversion Variable until the fifth page, you will not be able to see that relationship in SiteCatalyst reports (you can, however, in Data Warehouse and Discover).
The “None” Row
One of the most frequently asked SiteCatalyst questions I get is: What is the “None” row in Conversion Variable reports and how can I get rid of it? If there is no value stored in a Conversion Variable for a user at the time a Success Event is set, SiteCatalyst gives credit to that event to “None” so that the Success Event metric total at the bottom of the Conversion report will match the same total as the Success Event report. An easy way to remember this is to substitute the phrase “Instances in which SiteCatalyst didn’t know the [Conversion Variable Name]” for “None” in each report. In the preceding paragraph where the City value wasn’t set prior to the Success Event, that instance of the Success Event would be attributed to the “None” row in the City Conversion Variable report since SiteCatalyst didn’t know to which City it should give credit. To reduce the numbers in the “None” row of Conversion reports you can set Conversion Variables early in the visit and/or keep values stored for longer periods of time using the Expiration setting described above. However, keep in mind that the “None” row can be extremely useful. For example, you may get a question in which someone wants to know what percentage of time people completed applications without having come from any online marketing campaigns. The answer to this question can be found by simply adding the Applications Completed Success Event metric to the Campaigns report and looking at the percentage of the “None” row (14.61%) as shown here:
So let’s go through another real-world example. Our fictitious client, Greco Inc. has a website where it places many internal promotional banners. Each time visitors click on a promotional banner, they capture the ID# of that promotion in a Conversion Variable that is set to expire at the end of the Visit and gives credit to the Most Recent (Last) ID# the user clicked. They use this Conversion Variable to see which promotional banners, clicked within a Visit, get site visitors to convert. However, one of the marketing managers believes that visitors who click on a promotional banner may convert a few weeks later. To test this theory, she wants to learn which promotional banners are the first ones clicked by users and give credit for all Success Events taking place for the next 30 days to that promotion. So how would she do this?
First, she must create a new Conversion Variable (let’s call it “First Internal Promotion”) in the Admin Console. Using the settings mentioned above, she would set the Expiration to be “30 Days” and change the Allocation to be “Original Value (First).” Next, she would work with IT to pass the same value passed to the previously mentioned Internal Promotion ID# Conversion Variable to this new First Internal Promotion Conversion Variable. Even though many different values will be passed to this new First Internal Promotion Conversion Variable, due to the settings chosen, SiteCatalyst will ignore all of them except the first value it receives until 30 days have passed (after which it will reset and then accept the next value passed to it). After this is complete and data has been collected, the marketing manager will be able to open up the “First Internal Promotion” Conversion Variable Report, add any relevant Success Event metrics and see the results as shown here. In this case, it looks like “promo456” is the internal promotion clicked most often prior to Lead Form Submissions and that “promo122” is the internal promotion most often clicked first prior to Application Completions.
In future posts I will cover more topics related to Conversion Variables such topics as:
- Conversion Variable Subrelations
- Standard Conversion Variables (i.e. Search Engine, Search Keyword, Entry Page)
Hopefully these initial posts about SiteCatalyst Variables provide you with a good foundation on the different SiteCatalyst Variable types so that subsequent posts can be easier to understand…
Have a question about anything related to SiteCatalyst? Is there something on your website that you would like to report on, but don’t know how? Do you have any tips or best practices you want to share? If so, please send me an e-mail at firstname.lastname@example.org and I will do my best to answer it right here on the blog so everyone can learn! (Don’t worry — I won’t use your name or company name!)