DB VISTA [Inside Omniture SiteCatalyst]

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
**For the most part, there is very little difference between VISTA and DB VISTA. Both are used to alter or augment data that you have collected via SiteCatalyst prior to it being placed into Omniture’s back-end data tables. Where DB VISTA differs from VISTA is that it adds the ability to perform a look-up to a data table as part of the VISTA rule. This allows you to FTP data to Omniture which can be accessed by the DB VISTA rule so that it can tap into this additional data when the VISTA rule processes. For example, let’s say that you are a bank and it is against your privacy policy (and Omniture’s!) to store a customer account number in SiteCatalyst. However, you have a ton of great demographic data stored in your back-end about each customer such as Age, Gender, Zip Code, Marital Status, etc… and you would really like to have this non-personally identifiable data in sProps and eVars for segmentation purposes. If only you could have Omniture temporarily use the customer account number so you could get all of the rich demographic data and then somehow throw away the account number afterwards. Well guess what? You can using DB VISTA! You can provide a secure FTP table for Omniture to do a look-up on the account number (or encrypted account number if desired), retrieve the associated demographic data, place it in sProps and eVars and then discard the account number.

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

**Real-World Example
**In this week’s real-world example, Greco Inc.’s retail division would like to incorporate product costs into its SiteCatalyst implementation. To date, Greco Inc. has been using SiteCatalyst and SearchCenter to automate their paid search activities. Currently, SearchCenter is using a Revenue based Return on Ad Spend (ROAS) as the main input to paid search keyword buys, but Greco Inc. would like to take things to the next level by basing paid search purchases on Profit instead of Revenue. However, they do not want to pass Product Cost information into SiteCatalyst through the JavaScript tag since it could be visible through “debuggers” and “packet sniffers.”

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 _<insidesitecatalyst@omniture.com_> 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