If you have never used any of Omniture’s tools or are new to SiteCatalyst platform then the range of flexibility and configurability can be daunting. Props, eVars, merchandising, allocation, expiration are all terms bandied about by those who have been using SiteCatalyst for years, but what does it all mean? When do I use these variables and how?
In this post, I’d like to provide you as a developer on the Omniture platform with a few “fundamentals” about some of our variables. Today’s post will start with the prop. From there we can move to talk about eVars and events and maybe some solutions we can use these variables to build. I hope these posts will accelerate your ability to develop innovative and meaningful solutions and integrations.
The prop is a fairly standard metric that provides page level traffic data. Common props are s.pageName (yes it’s a prop with a pretty name) and s.channel. If s.pageName is the friendly name of the specific page, s.channel is its highest level of aggregation. I normally tell clients to think of s.channel as the main navigation on the site. Other common uses for props are capturing a search term for in internal search, the number of search results, or search refinements. The data that props collect other than the value that it’s set equal to are Page Views, Visits, and Visitors.
A powerful aspect of props is that they can be broken down by other props. In Omniture speak this is called a correlation. You have to enable a correlation before you can break a prop down by another prop and this can be done within the admin console or using the admin API. Remember, however, since props are traffic metrics and not persistent any props that you want to correlate must exist together on the same page and be sent on the same image request.
Let’s take a look at how this applies. Say for instance, you want to track a custom link, such as a link to sign up for a newsletter. To do this, you may be inclined to put into a prop the value “Newsletter” on the newsletter signup confirmation page. After setting up a correlation between page name and the newsletter prop and go into the reporting, select the newsletter traffic metric and break it down by page name. You would think you would get a list of pages on which the newsletter link was clicked, but you won’t. Why?
Remember that traffic metrics are not persistent, so for any two props to have relationship they need to be on the same image request. The page on which the user saw the link is not the page where the value “Newsletter” was set to a prop. That was on a previous page. In order to correlate the page name with the newsletter prop you must persist in a cookie or some other form the previous page name to the newsletter confirmation page.
Other real life scenarios of how this might be useful are on exit links. The Site Catalyst JavaScript file automatically tracks exit links through s.setInternalFilters. By adding an onclick to the document object the code automatically sends and image request when a link is clicked that contains a domain not included in the s.setInternalFilters variable. Since this image request will not be a page view and not register a page name you will not be able to correlate the exit links report by the page name. But if you set up a prop that always contains the page name and make sure that prop is included in the s.linkTrackVars variable, you will easily be able to break down exit links by page name and vice versa.
Perhaps the coolest feature of props is that you can enable pathing for them. Using pathing on the page name, you can see what pages led to say a featured article or even what were the last three pages of the site visit. Taking pathing to the next level you could also turn on pathing for your search terms to understand how people are using you internal search to find the product or content you want them to find.
Traditionally, we think of props as telling us things about the traffic of the page or the pages, whereas eVars and events tend to be arbiters of conversion metrics like revenue and orders. SiteCatalyst has always made a fairly strong distinction between traffic and conversion, but props can be used to answer some conversion questions by enabling what we refer to as participation.
Now let’s say you want to know how are the new landing pages you just launched doing (participating) to drive conversion. Let’s say we set up a prop to reflect these page types. The values would be something like – “Landing Page”,” Product Page”, “Article Page”, “Checkout Page”, etc. Now let’s you want to know how are the new landing pages you just launch doing to drive conversion. By turning on participation for this prop you can quick see that the landing pages are participating in $X of revenue. Set up a quick comparison with the same time period last month or last year and you can answer your business question.
The intent of these posts is really just to get those of you unfamiliar with the variable types available to the SiteCatalyst comfortable with them. I’m intending to dive into some code examples and commerce variables in future posts. Let me know if there is something in particular you would like review in future posts.
