In my last post, I explained what VISTA was and some ways in which it could be used. In this post, I will explain the subtle, but important, difference between VISTA and DB VISTA (also known as Database VISTA). If you have not read the last post, I strongly encourage you to do so prior to reading this one.
Understanding DB VISTA
As you can see, DB VISTA is really the same thing as VISTA, with the one extra step of doing a look-up to a table that you provide to Omniture. For you Excel junkies out there, you can think of it as a @DBLOOKUP function on a much larger scale! The following are some other examples of ways you can take advantage of DB VISTA functionality:
- If you have hundreds or thousands of IP address that you want to exclude (too many to manually add to a VISTA rule), you could upload a table of IP addresses to be excluded by a DB VISTA rule. This also has the advantage of allowing you to add/remove/modify IP addresses as needed by updating the table instead of having to pay Omniture to update a static VISTA rule
- If you want to assign a specific page value (which includes data from offline analysis) to a Revenue metric each time a page is accessed, you can have DB VISTA rule lookup the latest value from a table to upload to Omniture. Conversely, instead of passing in a dollar amount, you could pass in a value or “points” for each pagename to a Counter eVar to create a very rudimentary (“poor man’s”) way to enter the world of visitor engagement
- If you have customer scoring algorithms that calculate a current score for each registered customer, you could upload these scores daily and perform lookups to pass the current score to an sProp and eVar to see which pages or Success Events customers with high/low scores are accessing
- If you know your campaign meta-data ahead of time and don’ want to deal with SAINT Classifications, you could use DB VISTA to pass campaign meta-data to eVars
To accomplish this, Greco Inc. works with Omniture to securely upload product cost information to a DB VISTA table such that each Product ID has an associated Product Cost lookup value. Once this is in place, as site visitors purchase products, the DB VISTA rule enters the Product Cost into an incrementor event based upon the Product ID’s found in the Products Variable string. This produces a Cost of Goods Sold (COGS) metric that can be subtracted from Revenue to calculate Profit, which can then be used for paid search purchases as shown here:
Obviously, these are just a few examples of how DB VISTA can be used to improve/augment your SiteCatalyst implementation. Feel free to add a comment here with any ideas that you have on how you could see using this functionality…
If you want to learn more about VISTA or DB VISTA, here is a link to Engineering Services.
Have a question about anything related to Omniture 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 leave a comment here or 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!). If you are on Twitter, you can follow me at http://twitter.com/Omni_man.Learn more about Omniture Consulting Learn more about Omniture University