Getting The Most Out Of Omniture Vista Rules

We’ve been doing a LOT of implementation work in the past year – both fresh out of the box and re-implementations to fix or improve an existing setup. What probably isn’t too surprising is that the bulk of that work – both ways – is for Omniture’s SiteCatalyst. Now it’s no secret that Omniture implementations can be kind of complicated – largely because you have so many options. One of the most useful but surprisingly under-utilized of those options are Vista Rules.

Vista Rules process records as they are received, modifying, adding or moving the information contained within a record. They are setup by Omniture and since Vista Rules are custom-built, they can do quite a wide range of different tasks including copying data from one type of variable to another, copying whole records between report suites, filtering records, applying lookups and even performing calculations. However, there are some things Vista Rules can’t do – and to understand what these are the key is to understand how Vista Rules operate.

I mentioned that Vista Rules are applied to each record you send Omniture as it’s received. That means they operate on each record independently – before the records are sessionized. So you can’t have a Vista Rule do something like stamp every record in a session when the visitor ends up making a purchase or add the total visit time to a record. Vista Rules also can’t look-up previous visitor behavior or re-key previous records visitor ids once a visitor logs-in.

Vista Rules need to be custom implemented – which means they don’t come included in your implementation and you’ll have to pay for them. If you are using a stock Vista rule (something Omniture has written before or something that is quite simple), you should expect to pay a few thousand dollars to perhaps five thousand dollars. If it’s something more complex, then the price is going to be more. But you pay only once for a Vista rule – there’s no ongoing charge – and you can use a Vista rule against all your report suites for a single charge. In some types of cases, that makes them remarkably attractive.

I think the best way to give you a sense of what Vista rules can accomplish and why you might want to use them, is to give some examples of Vista rules we often recommend:

Unified Sources Vista Rule
This may be the single most popular Vista Rule around. What it does is really pretty simple – it creates a campaign source code for every visit to your site, regardless of where it comes from. If a visit is sourced from a campaign, the campaign code is saved just like you would expect. If a visit comes from natural search, then the Vista Rule detects that the referring site is a search engine and copies the search-engine name plus “organic” to the campaign code. If the visit comes from a non search site, it copies the referring domain to the campaign code. I’ve simplified it a bit, but the gist is that every single visit arrives as some kind of campaign. The Unified Source Vista Rule means that your campaign report will effectively track every single visit. That’s nice. But the real beauty of the Unified Source Vista Rule is that the campaign variable (tracking code) is fully sub-related in SiteCatalyst. That means you can see every referral – and not just campaigns – cross-tabulated with every eCommerce variable. It’s this capability that makes the Unified Source Vista Rule so popular. And depending on how expensive it is in your contract, implementing the Unified Source Vista Rule can be more economical than fully sub-relating the other sourcing variables you might be interested in.

Time Stamp Rule
It’s true that every record that gets passed to Omniture is timestamped. But in most data analysis situations, that timestamp really isn’t available to you. That’s why we frequently add a timestamp to a variable when we pass an important event to Omniture. Having the timestamp lets us select segments based on when a visitor did an important action. In addition, most clients like to track special information like the week-day and day-part for PPC visits to support day and time-parting analysis. You can do all this in the javascript  tag, of course, and we frequently do it that way. But generating that stuff in javascript can make the tag a fair amount weightier and the image tag a little longer (a concern in mobile). You can eliminate both these concerns by simply time-stamping every record using a Vista Rule. For many organizations, the cost of a simple Vista Rule is a small price to pay for the reduction in tag weight.

Report Suite Copy
You can do multi-suite tagging (sending a single image to more than report suite) right in the javascript. But there are some limitations to what you can do in the javascript. When you set up multi-suite tagging, you send an identical image request to each report suite. That’s not always what you want. In addition, if you are moving code through Dev, QA, and Production machines, multi-suite tagging in javascript introduces another element that has to be changed. A Vista Rule can copy all or some of the records and all or some of the data from one Report Suite to another. With a standardized naming convention, it can automatically detect the right environment (Test to Production) to send the copies. It can do multiple copies. And it can filter records and screen or change variables when it does the copy. Doing a Vista Rule copy doesn’t eliminate the secondary server call expense of course (otherwise no one would ever make the second call!) but it can make your report suite setup and configuration significantly more powerful and more convenient. This, by the way, is part of the survey integration solution I recommended for saving all of the survey data in a report suite.

Database Lookup
You can use a database lookup to append or translate information you send to Omniture. Why wouldn’t you use a SAINT table for this? You might, of course, but SAINT isn’t always as convenient as a Vista DB Lookup. With a DB Lookup table, you can do very large lookups in real-time with no lag. You can set variables directly, get uniques counts and pathing on them, and you can filter records in real-time. When a database lookup is the right solution, it can be vastly more convenient than any alternative. 

Mobile Robot Detection / IP Exclusion / IP Copy
Tagging solutions rely heavily on the fact that robots typically won’t load javascript. If you are using image tagging on mobile that built in protection goes out the window. You can use a DB Vista Rule (really this is just a variation of a Database Lookup) to implement mobile robot detection and filter out requests you don’t want. You can combine this with a report suite copy if you want to actually measure robotic traffic. You can use essentially the same technique to unify your IP exclusions across all report suites. And you can also use this to copy your internal data if you want to keep track of your own site usage. There are times when this is quite handy – especially when employees use public sites for operational purposes.

Visitor Geo-Copy
Like most web analytics packages, SiteCatalyst provides some basic reporting broken out by geo-demographics. If you’ve enabled it, you can get reports in SiteCatalyst that will break out visits by Country, State and DMA. Also like most web analytics packages, these reports don’t always give you the detail and break-downs you’re looking for. When we really care about geo-demographics (if, for instance, we want to track Mass Media performance using the web), we usually recommend the IP Lookup value be copied into a prop/eVar. This significantly increases the amount of reporting you can get on geo-demographic basis. Though we’ve never done it, you co
uld even add this level of detail to the Unified Sources Vista Rule (you’ll pay more for using a non-standard version of the rule). That would give you full sub-relations on geo-demographics by acquisition source.

Mobile Device Info Copy
This is another case – like geo IP Lookup – where a vista copy of mobile information to a prop can significantly improve your reporting access. If you are getting serious about tracking mobile, this is definitely another Vista Rule worth considering.

Vista Rules can solve quite a few implementation issues.

If you need to apply similar processing to multiple report suites, if you need to lookup values against a large table, if you need better reporting access to an Omniture variable, or if you need filter, copy or move values around in or across report suites, then a Vista Rule is often the only alternative.

If you have even modestly complex rules you want to implement in javascript, Vista Rules are often a good alternative. There’s a real virtue in keeping your tag weight as small as possible. Sometimes, a Vista Rule can also take the place of tag changes which your IT department doesn’t have time for or which would cost you more than the Vista Rule.

And just a note, if you are going to implement one or more Vista Rules, make sure you surface them with Omniture as early in the development cycle as possible. They can take many weeks to get implemented – so if you start too late they may not be available when you need them.

So if you are planning an implementation or trying to improve an existing setup, make sure you give a thought to the stable of common Vista Rules that are available and to what you might be able to accomplish on a custom basis. They can be an easy and elegant solution to a great many implementation challenges.


Gary Angel
About Gary Angel
Gary Angel is the author of the "SEMAngel blog - Web Analytics and Search Engine Marketing practices and perspectives from a 10-year experienced guru.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>