VISTA

Von | 24. April 2012

Dieser Artikel soll einen viel benutzten aber selten wirklich verstandenen Teil der SiteCatalyst Architektur vorstellen: VISTA Rules.

Die interne Folklore sagt, VISTA sei ein Akronym und stehe für „Visitor Identification, Segmentation & Transformation Architecture“. Das hört sich erstmal kompliziert an, schreit also nach einer Erklärung.

Weil VISTA in der Tat recht flexibel ist, sieht man sich VISTA Rules am besten unter zwei verschiedenen Gesichtspunkten an:

  1. Was passiert, wenn eine VISTA Rule bei der Datensammlung im Spiel ist?
  2. Was kann man mit so einer VISTA Rule tun und was nicht?

Was ist VISTA?

VISTA ist ein Mechanismus, mit dem man Daten in SiteCatalyst ändern kann, und zwar nachdem sie gesammelt aber bevor sie gespeichert wurden.

Mit anderen Worten: Nachdem ein Browser einen Trackingcall abgeschickt hat und dieser auf den SiteCatalyst Servern in Empfang genommen wurde, kann man die Daten im Call per VISTA Rule noch ändern, bevor sie dann bearbeitet und in die entsprechenden Reports abgelegt werden.

Die VISTA Rule hat Zugriff auf alle im Trackingcall gesendeten Daten sowie einige der HTTP und IP Header (z.B. die IP Adresse des Besuchers). Die meisten aber nicht alle dieser Datenfelder kann die VISTA Rule verändern. Darüberhinaus kann sie Daten in eine andere Reportsuite kopieren oder als „nicht anzeigen!“ markieren.

Eine VISTA Rule hat keinen Zugriff auf historische Daten. Jeder Trackingcall ist wie Neuland für die VISTA Rule. Sie hat auch keinen Zugriff auf bereits gespeicherte Werte wie z.B. eVars oder s.campaign.

Wie genau muß man sich so eine VISTA Rule vorstellen?

Eine VISTA Rule ist ein kurzes Programm. VISTA Rules werden von den Kollegen bei „Engineering Services“ programmiert und implementiert. Die Palette geht dabei von Standard VISTA Rules bis hin zu hochgradig komplexen und angepaßten Spezialregeln.

Wer ein Login hat, kann sich die Standardlösungen und das Portfolio ansehen.

VISTA Rules kosten Geld, und zwar sowohl das Anlegen als auch zukünftige Änderungen.

Wenn eine VISTA Rule implementiert ist, wird fortan jeder Trackingcall durch VISTA geschickt. Die VISTA Rule bearbeitet den Call und ändert je nach Zweck einzelne Felder.

Was kann man mit VISTA Rules machen und was nicht?

  • Die IP Exclusion VISTA Rule sieht sich für jeden Trackingcall die IP Adresse des Browsers an und schickt Calls von internen Adressen in eine separate Reportsuite.
  • Mit einer VISTA Rule kann man Daten aus einer SiteCatalyst Variable in eine andere kopieren, z.B. Tracking Codes von s.campaign in eine eVar mit anderer Allokation (damit man first und last touch auswerten kann).
  • VISTA kann z.B. Daten aus Geosegmentation oder Technology Reports in props und/oder eVars kopieren.
  • Einen Success Event oder eine Variable setzen, wenn ein URL Parameter oder die URL passen.
  • Daten entschlüsseln, die zuvor mit JavaScript im Browser verschlüsselt und damit nicht im Klartext über’s Netz gesendet wurden.
  • Visits in Kanäle einteilen („Unified Sources“).
  • Traffic von Bots und Spidern in eine getrennte Reportsuite leiten.

Es gibt zwei verschiedene Typen von VISTA Rules, die „normalen“ VISTA Rules, bei denen die Logik komplett in Code gegossen wird, und die DB VISTA Rules, die mit einer Lookuptabelle arbeiten, welche man anpassen kann. Letztere beschreiben wir in einem künftigen Posting genauer.

Wann benutzt man VISTA Rules?

Es gibt eine ganze Reihe von Szenarios, in denen VISTA Rules sinnvoll sind.

Erstens die schon erwähnten Fälle, in denen man Daten aus einem der eingebauten Reports wie z.B. Geosegmentation zum Segmentieren aller möglichen Reports benötigt. VISTA kann die Daten aus den Reports in eine prop und/oder eVar kopieren und sie damit überall in SiteCatalyst verfügbar machen.

Zweitens wenn man aufgrund bestimmter Informationen den Traffic in verschiedene Reportsuites tracken will. Hierunter fallen Dinge wie die Erkennung und Sonderbehandlung von Bots oder internen IP Adressen, aber man kann auch Daten in mehrere Reportsuites tracken so wie beim Multi-Suite Tagging, oder man kann Sampling implementieren.

Drittens kann eine VISTA Rule Daten beliebig bearbeiten. Die schon erwähnte Entschlüsselung von vorher in JavaScript verschlüsselten Daten ist ein gutes Beispiel für diese Anwendung. Manche Websites verschlüsseln die Kundennummer, bevor sie im Trackingcall gesendet wird.

Viertens kann man mit VISTA Daten aggregieren. Beispiel: Eine Website trackt die Visitnummer in eine eVar. Mit VISTA kann ich diese Nummer einer Gruppe (z.B. „Wiederkehrer“) zuordnen und die Gruppe in eine weitere eVar schreiben. Gegenüber SAINT hat das den Vorteil, daß man später weniger Aufwand hat.

Fünftens kann man Dinge implementieren, die man zur Zeit auf der Website nicht machen kann, sei es weil der Releasezyklus zu lange dauert, oder weil das CMS es schlicht nicht kann.

VISTA ist so flexibel, daß sich diese Liste beliebig erweitern ließe. Daher unsere Frage: Benutzen Sie VISTA? Wofür?

2 Gedanken zu „VISTA

  1. Pingback: “Engagement” mit Processing Rules « Webanalyse auf Deutsch

  2. Pingback: IP Adressen Nicht Tracken | Webanalyse auf Deutsch

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.