SiteCatalyst 15 – contextData Variablen & Processing Rules

Zeitgleich mit SiteCatalyst 15 wurden zwei neues Feature freigeschaltet, die weniger mit dem Processing der Daten zu tun haben, also dem eigentlichen Schwerpunkt der Unterschiede zwischen SiteCatalyst 14 und 15, sondern mit der Datensammlung: contextData Variablen und Processing Rules.

Die beiden sind eng verknüpft: Processing Rules werden überwiegend mit contextData Variablen benutzt, und contextData Variablen sind ohne Processing Rules sogar sinnlos.

contextData Variablen

Eine typische Komplikation bei jeder Implementierung ist die Übersetzung von Semantik einer Variablen zu ihrem Namen. Consulting händigt am Ende einer Implementierung ein Dokument aus: Das „Solution Design Reference“ Spreadsheet oder „SDR“ enthält einer Liste aller Variablen und definiert, wofür sie genutzt werden.

Theoretisch sollte ein Entwickler jede Seite korrekt implementieren können, wenn er nur das SDR hat. Das ist in der Praxis nicht immer so, und vor allem läßt umgekehrt der Code auf einer Seite keine direkten Rückschlüsse zu auf den Zweck einer Variablen.

Die contextData Variablen sollen das ein Stück vereinfachen. Anstatt die Werte in eVars und props zu schreiben, weist man sie semantisch korrekt benannt zu. Also nicht:

s.prop1 = "Damenmoden";
s.prop2 = "Hosen & Röcke";

Sondern stattdessen:

s.contextData['Abteilung'] = "Damenmoden";
s.contextData['Bereich'] = "Hosen & Röcke";

Natürlich „weiß“ SiteCatalyst nicht, was eine ‚Abteilung‘ ist. Die Zuweisung konfiguriert man daher einmalig. Die eigentlichen Werte landen letztendlich wieder in s.prop1 und s.prop2 und zwar mithilfe der Processing Rules.

Ziel der contextData Variablen ist wie gesagt, Entwicklern das Leben einfacher zu machen und einen direkten Bezug zwischen Semantik und Inhalt herzustellen.

Processing Rules

Mit Processing Rules kann man Werte in Variablen schreiben (props, eVars und events), basierend auf anderen Informationen im gleichen Request.

Das hört sich erstmal recht einfach an, kann aber weitreichende Auswirkungen haben, je nach Umgebung.

Wer schon mit VISTA Rules gearbeitet hat, wird die zugrundeliegenden Konzepte wiedererkennen: Processing Rules können die Daten des aktuellen Tracking Calls lesen und teilweise modifizieren.

Die Grafik soll zeigen, wo genau im Prozeß die Processing Rules ausgeführt werden: vor den VISTA Rulesund dem Prozeß für Marketing Channels.

Was kann mit Processing Rules machen?

• Einfache Regeln
• Werte aus URL oder Query String auslesen
• Werte aus SiteCatalyst Variablen lesen (inklusive contextData!)
• Werte zusammenfassen
• SiteCatalyst Variablen einen Wert zuweisen

Was kann man mit Processing Rules nicht machen?

• Hits in eine andere Report Suite umleiten
• IP-basierte Ausschlußregeln
• Werte auftrennen (z.B. „logged in|Homepage“ in „logged in“ und „Homepage“ zerlegen)

Die Anwendungsbeispiele aus dem Originalposting gefallen mir ganz gut, daher:

Beispiel 1 – URL Parameter

Ähnlich wie mit dem getQueryParam Plugin kann man Kampagnencodes für’s Tracken der Kampagnen auch direkt mit einer Processing Rule aus der URL lesen und der Variablen s.campaign zuordnen. Das geht so:

Vorteil einer Processing Rule: man kann die ohne Deployment schnell einstellen, bricht also aus dem Releasezyklus aus. Weiterer Vorteil: Die s_code.js Datei kann kleiner ausfallen. Das ist besonders bei Sites die für Mobile optimiert sind durchaus etwas wert.

Beispiel 2 – Event setzen

Angenommen wir haben im letzten Monat endlich das Release gehabt mit dem interne Suche getrackt wird. Heute merken wir, daß zwar die Suchbegriffe in die entsprechende eVar getrackt werden, der event wird aber nicht gesetzt. Ein Fehler! Der nächste Release ist in 6 Wochen. Autsch.

Mit Processing Rules kann man den event in der Zwischenzeit setzen, und zwar basiert auf entweder der eVar oder dem Namen der Suchergebnisseite.

Wie bekomme ich Processing Rules?

Die Kollegen bei ClientCare können den Zugriff auf Processing Rules für zertifizierte Benutzer freischalten.

Warum braucht man eine Zertifizierung? Adam Egbert sagt das so: „Essentially, by giving you access to these features, we are also giving you the power to royally mess up your implementation!“ Schön gesagt.

Wie man sich zertifiziert, beschreibt Artikel 10655 in der Knowledge Base. Die Zertifizierung kostet nichts.

Die beste Vorbereitung auf den Test ist die Dokumentation, Trainings gibt es meines Wissens zur Zeit nicht.