VISTA rules

If you have been in an Adobe Analytics implementation, it is highly probable that, at one point or another, you have heard the expression “VISTA rules”. However, many of you might still wonder what those little beasts are. First of all, let’s start with the name. Unless you dig in Google or in the help section, you will never have guessed that VISTA stands for “Visitor Identification, Segmentation & Transformation Architecture”. Do not get too impressed with this name, it was just an imaginative way of getting a fancy name.

What is exactly a VISTA rule? It is a little piece of code, which is executed before processing the data and can be used to modify the hit (image request) that has been received by the data collection servers. These is a list of things that you can do in VISTA rule:

  • Modify the value of any variable in the hit: eVars, props, hier, products, events… depending on the value of another variable.
  • Copy or move a hit to a secondary report suite.
  • Force the end of a visit.
  • Do a lookup in a database table and do any of the previous actions, according to the values in the database.

Although the previous list might not be impressive, there are a few interesting uses cases that benefit from a VISTA rule:

  • Move all internal traffic to a secondary report suite. By supplying the publicly facing IP addresses of your offices, a VISTA rule can keep your main report suite free of internal traffic, but still be able to analyse what your employees use your website for. One particular case that I found very inspiring was a customer with a call centre; the operators did not have a separate application to generate the orders, instead, they used the main website. In this case, the behaviour of the operators will be very different from regular visitors, but my customer wanted to analyse the requests coming from the call centre in detail. So, having internal traffic in a separate report suite allowed that flexibility.
  • Cost of goods sold. Using the products string, Adobe Analytics calculates the revenue. If you also want to get a report with your profits or margins, in theory, you could add them in JavaScript, but you would be exposing sensitive information that your competitors might use against you. The best solution is to add this margin (or cost) server-side, so that it appears in Adobe Analytics, but nobody else can see.
  • Decrypt data. If you have some sensitive data, which you do not want to travel through the open Internet in clear text, but you want to see in Adobe Analytics, you can encrypt it in your servers and have a VISTA rule decrypt it. It must be noted that, in this case, you would need a DB VISTA, with key/value pairs, where the key is the encrypted data and the value is the clear text data. VISTA rules cannot execute complex algorithms like AES or 3DES.
  • I have seen one case where my customer could not modify the JavaScript so it was easier for them to have a VISTA rule do some modifications to the hit, modifications that you would normally do in JavaScript.
  • Set eVars/props/hier variables depending on the URL. Again, with a DB table and a set or VISTA rules, you can avoid passing all the values through the HTML and set them server-side. This is particularly useful if you have a website that is continuously changing and it is difficult/impossible to add meta-data to your CMS.
  • Detect fraudulent hits. It is quite common to see some unexpected image requests, with useless information. This is particularly important on the order confirmation page, were you want to capture real data. A VISTA rule can be created to detect when the total revenue exceeds certain value and prevent it from making it to the reports.
  • Another interesting example I have is a retailer that sells both their own brand and other brands. Legally, the analytics of the own brand cannot access the information of other brands. In this case, two VISTA rules were created: one to copy the traffic to a secondary report suite and another to delete the information that the analysts was not allowed to see, in the secondary report suite.

If you search in Google, you will find old Web pages with more use cases. Although the previous list is not comprehensive, I have omitted a few use cases that were important in the past but are not relevant any more. Adobe has been adding new features into Adobe Analytics (bots rules, processing rules, segment manager, calculated metrics) that make it unnecessary to create VISTA rules for some use cases. In general, before requesting a VISTA rule, you should try to figure out if you can achieve the same goal with the out-of-the-box features.

Finally, there are some limitations to what a VISTA rule can do:

  • It can only process a hit. VISTA rules know nothing about visits and visitors.
  • It cannot modify hits from the past; only live hits.
  • It does not have access to the virtual cookie; i.e. it cannot get the persistent value of an eVar.
  • It cannot execute complex algorithms; a VISTA rule should execute in milliseconds.
  • The database table has limits in its size.

I hope that, by now, you have a clear understanding of what a VISTA rule is and what it can do. If you still have questions about this feature, use the comments section and I will be happy to help you!

3 thoughts on “VISTA rules

Leave a Comment