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 sub­tle, but impor­tant, dif­fer­ence between VISTA and DB VISTA (also known as Data­base VISTA).  If you have not read the last post, I strongly encour­age you to do so prior to read­ing this one.

Under­stand­ing DB VISTA
For the most part, there is very lit­tle dif­fer­ence between VISTA and DB VISTA.  Both are used to alter or aug­ment data that you have col­lected via Site­Cat­a­lyst prior to it being placed into Omniture’s back-end data tables.  Where DB VISTA dif­fers from VISTA is that it adds the abil­ity to per­form a look-up to a data table as part of the VISTA rule.  This allows you to FTP data to Omni­ture which can be accessed by the DB VISTA rule so that it can tap into this addi­tional data when the VISTA rule processes.  For exam­ple, let’s say that you are a bank and it is against your pri­vacy pol­icy (and Omniture’s!) to store a cus­tomer account num­ber in Site­Cat­a­lyst.  How­ever, you have a ton of great demo­graphic data stored in your back-end about each cus­tomer such as Age, Gen­der, Zip Code, Mar­i­tal Sta­tus, etc… and you would really like to have this non-personally iden­ti­fi­able data in sProps and eVars for seg­men­ta­tion pur­poses.  If only you could have Omni­ture tem­porar­ily use the cus­tomer account num­ber so you could get all of the rich demo­graphic data and then some­how throw away the account num­ber after­wards.  Well guess what?  You can using DB VISTA!  You can pro­vide a secure FTP table for Omni­ture to do a look-up on the account num­ber (or encrypted account num­ber if desired), retrieve the asso­ci­ated demo­graphic data, place it in sProps and eVars and then dis­card 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 pro­vide to Omni­ture.  For you Excel junkies out there, you can think of it as a @DBLOOKUP func­tion on a much larger scale!  The fol­low­ing are some other exam­ples of ways you can take advan­tage of DB VISTA functionality:

• If you have hun­dreds or thou­sands of IP address that you want to exclude (too many to man­u­ally 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 advan­tage of allow­ing you to add/remove/modify IP addresses as needed by updat­ing the table instead of hav­ing to pay Omni­ture to update a sta­tic VISTA rule
• If you want to assign a spe­cific page value (which includes data from offline analy­sis) to a Rev­enue met­ric each time a page is accessed, you can have  DB VISTA rule lookup the lat­est value from a table to upload to Omni­ture.  Con­versely, instead of pass­ing in a dol­lar amount, you could pass in a value or “points” for each page­name to a Counter eVar to cre­ate a very rudi­men­tary (“poor man’s”) way to enter the world of vis­i­tor engagement
• If you have cus­tomer scor­ing algo­rithms that cal­cu­late a cur­rent score for each reg­is­tered cus­tomer, you could upload these scores daily and per­form lookups to pass the cur­rent score to an sProp and eVar to see which pages or Suc­cess Events cus­tomers with high/low scores are accessing
• If you know your cam­paign meta-data ahead of time and don’ want to deal with SAINT Clas­si­fi­ca­tions, you could use DB VISTA to pass cam­paign meta-data to eVars

Real-World Exam­ple
In this week’s real-world exam­ple, Greco Inc.‘s retail divi­sion would like to incor­po­rate prod­uct costs into its Site­Cat­a­lyst imple­men­ta­tion.  To date, Greco Inc. has been using Site­Cat­a­lyst and Search­Cen­ter to auto­mate their paid search activ­i­ties.  Cur­rently, Search­Cen­ter is using a Rev­enue based Return on Ad Spend (ROAS) as the main input to paid search key­word buys, but Greco Inc. would like to take things to the next level by bas­ing paid search pur­chases on Profit instead of Rev­enue.  How­ever, they do not want to pass Prod­uct Cost infor­ma­tion into Site­Cat­a­lyst through the JavaScript tag since it could be vis­i­ble through “debug­gers” and “packet sniffers.”

To accom­plish this, Greco Inc. works with Omni­ture to securely upload prod­uct cost infor­ma­tion to a DB VISTA table such that each Prod­uct ID has an asso­ci­ated Prod­uct Cost lookup value.  Once this is in place, as site vis­i­tors pur­chase prod­ucts, the DB VISTA rule enters the Prod­uct Cost into an incre­men­tor event based upon the Prod­uct ID’s found in the Prod­ucts Vari­able string.  This pro­duces a Cost of Goods Sold (COGS) metric that can be sub­tracted from Rev­enue to cal­cu­late Profit, which can then be used for paid search pur­chases as shown here:

Obvi­ously, these are just a few exam­ples of how DB VISTA can be used to improve/augment your Site­Cat­a­lyst imple­men­ta­tion.  Feel free to add a com­ment 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 Engi­neer­ing Ser­vices.

Have a ques­tion about any­thing related to Omni­ture Site­Cat­a­lyst?  Is there some­thing on your web­site that you would like to report on, but don’t know how?  Do you have any tips or best prac­tices you want to share?  If so, please leave a com­ment 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 every­one can learn! (Don’t worry — I won’t use your name or com­pany name!).  If you are on Twit­ter, you can fol­low me at http://​twit​ter​.com/​O​m​n​i​_​man.

Learn more about Omni­ture Consulting

Learn more about Omni­ture University