Omniture is the market-leader in enterprise web analytics because it is flexible, powerful, and it has been around a long time. But because it has been around a long time, historical legacies in the software have led to patch-ups which newer solutions don’t have to deal with. One such band-aid is the Unified Sources VISTA rule.
I’d not heard about the Unified Sources VISTA rule until about a year ago. But basically, the story, as I understand it, is this: a paid-for campaign, if properly tagged, goes into the campaign tracking code variable in Omniture, with full sub-relations and most metrics available. Organic Search referrals go into the Natural Search reports in Omniture, with only “searches” as the metric, and no subrelations. Other referring traffic, like partner links, or social media, go into the referring domain or referrer reports in Omniture, with “instances” as the metric, and no subrelations. This is how Omniture has been set up almost from the get-go.
Omniture’s clients understandably raised issues with this set-up. They could not run a single report showing them all the sources of visit to their website. So Omniture developed the Unified Sources VISTA Rule. This VISTA rule is designed to take the data from these three reports (campaigns, natural search, and referring domains) and put them in one place. Because the s.campaign variable is automatically set up for full sub-relations, with all metrics available to any eVar, the s.campaign variable was designated as the container for all this information. Additionally, the keyword information (paid and natural, regardless of search engine) was also passed intentionally into a designated eVar. Omniture’s solution is a good one, and the $3000 or so it costs to implement is won back shortly as managers do not need to pore through several reports, or run Data-Warehouse requests, to get a unified picture of site-sourcing.
But the Unified Sources VISTA Rule raised troubling issues as it was implemented on large sites with intense marketing initiatives. These issues came from three places, as I’ve experienced it: reporting legacy, SAINT classifications, and success allocation. In the first case, marketing teams, having implemented Omniture a long time ago, and having developed a reporting template for weekly – or even daily – distribution, suddenly found their reports crowded with referring domains and natural search data. In some cases, the “uniques exceeded” issue cropped up, because even the s.campaign variable has a cut-off point. In other cases, reports on paid-marketing programs suddenly included non-paid data. This led to confusion and a hectic re-working of their existing reports.
In the second case, many of these marketing teams have SAINT classifications that were designed years ago, on which they base internal reporting. The sudden introduction of thousands of new data-elements in the campaign tracking code variable unforeseeably and geometrically expands their SAINT download. The manager who used to spend a few hours doing SAINT uploads now finds herself spending a whole day trying to figure out how to classify referring domains.
Finally, success allocation can suddenly become muddied with the introduction of the Unified Sources VISTA Rule into the campaign tracking code variable. Many teams get their success event data from multiple sources – Omniture, but also third-party advertising vendors, who might manage email campaigns or PPC. Very often, these third parties have implemented a tracking bug (like a spotlight tag) on the “thank you” page, and attribute the success event back to the email or PPC click. These numbers can never be expected to match Omniture’s, but usually they are close enough for comfort. However, with the Unified Sources VISTA Rule, suddenly the numbers drop. This is because the success-event is now no longer be attributed to a paid campaign, but to paid campaigns *plus* natural search or referring domains. The most common setting for campaign attribution is a life-span of 15-30 days, with allocation to “last” or “linear”. Introducing into this variable hundreds or thousands of new data-points dilutes the allocation.
The solution to these issues is to put thought into how the Unified Sources VISTA Rule should be set up. Rather than put the Unified Sources into the s.campaign variable, consider putting it into one or two other eVars. These eVars would have to get full-subrelations enabled, but this solution would allow web analytics managers to get the “unified” view, while at the same time not interrupting the reporting coming out of the campaign tracking code variable.
Recent Comments