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

 

2 comments
Adam Greco
Adam Greco

Dave, Great question! You could use a Numeric Classification to accomplish this, but there is one big drawback. Classifications are always retro-active so if the cost of a product is $5.67 today, but changes to $4.98 next month, when you re-upload the SAINT Classification file with the new cost information, all of your reports will look like the cost has always been $4.98 which will make your old reports inaccurate. By using DB VISTA the cost at the time is passed in and stored in SiteCatalyst data tables so that it won't change. Therefore, I would use DB VISTA in this scenario unless I only cared about the current time period (which is rarely the case). Let me know if this does not make sense. Thanks! Adam

Dave Eckman
Dave Eckman

Great post Adam, I was wondering, with the example above, would you be able to do something similar with Classifications? Create a product classification with cost data and then use that cost data to create your COGS calculation?