„Engagement“ mit Processing Rules

Im Artikel zum Thema „Engagement“ habe ich so ganz salopp vorgeschlagen „Man nehme alle Zusatzfunktionen und weise ihnen jeweils einen Wert zu.“ Das klingt erstmal gar nicht so kompliziert, man wird aber unter Garantie experimentieren müssen, bis man Werte hat, die aussagekräftig sind, d.h. gegen die man tatsächlich optimieren möchte und kann.

Wie also experimentiert man mit sowas?

Muß man da ständig den Javascript Code auf den Seiten ändern? Oder gibt es Alternativen, die vielleicht weniger invasiv sind und weniger abhängig von Releasezyklen?

Mir fallen 2 Möglichkeiten ein:

Javascript

Oft genug trackt man die für’s Engagement interessanten Aktionen sowohl in die eVar als auch mit einem event. Das bedeutet, daß man den event auf der Seite selbst setzen kann und die eVar (deren Wert wir noch nicht so genau wissen) in der s_doPlugins Methode in der s_code.js Datei.

Beispiel:

Angenommen das Posten eines Blogartikels soll erstmal provisorisch mit 5 Punkten in eVar28 gewertet werden. Außerdem wollen wir es mit event42 tracken.

Im Code auf der Seite stünde dann:

s.events="event42";

In der s_code.js würden wir abtesten, ob event42 gesetzt wurde und falls ja 5 punkte für’s Engagement rechnen:

if (s.events.indexOf("event42") != -1) {
  s.eVar28="+5"; // blog artikel gepostet - 5 punkte engagement
}

Etwas komplizierter wird die Geschichte, wenn man keine events gesetzt hat. Ich persönlich würde empfehlen, unbedingt events zu implementieren, aber es gibt ja immer Sachzwänge und so, also probieren wir es mal ohne.

Ohne events kann man mit ein wenig Aufwand immer noch den kompletten Code für’s Engagement in der s_doPlugins Methode abhandeln, und zwar indem man sich an der URL der Seite orientiert, oder an s.pageName.

Der Javascript Code würde also nicht s.events abtesten sondern stattdessen entweder s.pageName (z.B. if (s.pageName.indexOf("Blogartikel gepostet") != -1)) oder die URL (z.B. if (window.location.href.indexOf("article-submitted.php") != -1)).

Die Lösung mit s.events ist natürlich am saubersten. Der Test gegen die URL ist am wenigsten robust gegenüber Änderungen an der Site. Ich würde das vermeiden.

Processing Rules

Für diejenigen unter uns die keinerlei direkten Zugriff auf die Implementierung haben, also auch keine Möglichkeit, die s_code.js außer der Reihe anzupassen, gibt es noch eine andere Möglichkeit: Processing Rules.

Vorbedingung ist, daß man den Test besteht (siehe Knowledgebase Artikel 10655 oder hier) und den Zugriff auf Processing Rules dann via ClientCare freischalten läßt.

Processing Rules sind ähnlich wie VISTA Rules in der Lage, unter bestimmten Voraussetzungen Werte in Variablen zu schreiben. VISTA Rules sind mächtiger, sie können Variablen auslesen, Werte ändern und man kann im Prinzip beliebig komplexe Logik implementieren. Processing Rules können dagegen nur relativ einfache Tests machen. Für unsere Zwecke genügen Processing Rules.

[Screenshot]

Processing Rule für’s Engagement

Im Beispiel hier prüfe ich einen Teil der URL ab. Das gleiche Konzept funktioniert natürlich auch für s.pageName oder eine andere Variable.

Einen event kann man mit Processing Rules leider nicht abtesten.

Denkbar wäre, eine prop zu benutzen, falls z.B. alle Berichte einen bestimmten Wert in dieser prop haben. Bei Mediasites wird oft zwischen „article“ und „homepage“ unterschieden, da könnte man dann z.B. einfach testen, ob s.propXY==“article“ ist, falls man „Artikel gelesen“ in die Berechnung des „Engagement“ aufnehmen will.

Diskussion

Der Vergleich der beiden Lösungen ist nicht ganz einfach.

Großer Vorteil beider Lösungen ist, daß sie weniger Aufwand machen als Änderungen an den individuellen Seiten.

Wer es kann/darf und die s_code.js getrennt vom CMS und außerhalb der Releasezyklen verwaltet, für den ist die Javascript Lösung interessant.

Wer gar keinen Zugriff auf die Implementierung hat, sollte sich Processing Rules zu Gemüte führen.

Beide Lösungen haben einen Nachteil: Sie finden außerhalb des „normalen Taggings“ statt, man muß sich also zusätzliche Prozesse ausdenken für Deployment, Test, QA und Regression Tests.

Welche Lösung ist also besser? Das kann ich nicht sagen. Die Antwort hängt zu sehr von den Umständen ab.

Was sind die jeweiligen Vor- und Nachteile der zwei Lösungen?

Lernaufwand

Wer auch immer die Lösung umsetzt muß entweder gut mit Javascript umgehen können oder mit Processing Rules. Das kann bedeuten, daß die Person eins von beiden lernen muß.

Wenn man eins schon kann – super, Problem gelöst.

Wenn nicht, dann hängt es vom Hintergrund der Person ab. Entwickler? Javascript. „Normalo“? Processing Rules. Letztere sind für Nicht-Entwickler um Größenordnungen einfacher zu lernen.

Prozesse

Beide Lösungen liegen wie erwähnt außerhalb des normalen Taggings und man muß sich daher um Deployment, Tests und das Drumherum kümmern.

Für Processing Rules ist das erstmal einfacher, weil nur an einer Stelle eingegriffen wird. Dafür ist diese Stelle aber komplett außerhalb der technischen Umgebung in der getrackt wird.

Javascript hingegen kommt in die s_code.js, die man unter Umständen periodisch dem ganz normalen Releaseprozeß unterziehen kann. Damit hat man dann z.B. (hoffentlich!) Regressionstests abgedeckt und kann sich sicher sein, daß man nicht die Website zerstört.

Kopplung / Dokumentation

Beide Lösungen ändern eine Variable basierend auf Informationen, die woanders gesammelt werden. Wenn die woanders gesammelten Informationen sich ändern, versagen beide Methoden.

Ich sehe hier einen leichten Vorteil für Javascript, weil der Code innerhalb der s_code.js noch am ehesten auffällt, wenn jemand anders irgendwo etwas am Tracking ändert.

Processing Rules jedoch sieht man wirklich nur, wenn man das will.

Wer gut dokumentiert, kann das Problem eventuell eingrenzen, Sicherheit bietet das aber auch nicht. Und wer weiß schon, wie aktuell die Dokumentation an einem beliebigen Zeitpunkt in der Zukunft sein wird?

Ein weiterer Vorteil für die Javascript Lösung ist, daß man gezielt einen event abtesten kann. Das geht mit Processing Rules nicht! Wer für die Processing Rules eine prop abstellen kann, fährt ähnlich gut, aber die Lösung mit dem event ist natürlich sauberer und robuster.

Entfernen

Wenn man die Experimentierphase verläßt und die Punkte sich nicht mehr ändern, sollte man sie sinnvollerweise an der Quelle tracken, also da wo auch der jeweilige event gesetzt wird.

Zeitgleich müssen Javascript / Processing Rule entfernt werden.

Vorteil für Javascript, denn da kann man durch den Releasezyklus einfach sicherstellen, daß beide Änderungen gemeinsam live geschaltet werden.

Für die Änderung an den Processing Rules müßte im Prinzip jemand im SiteCatalyst UI die Regel deaktivieren, und zwar genau wenn die geänderte Site oder sogar Seite live geht, sonst fehlen Daten oder Engagement wird doppelt gezählt.

Fazit

Beide Lösungen können im Fall der Fälle aus der Patsche helfen. Beide haben Vor- und Nachteile, der unangenehmste dürfte die Entkopplung sein.

Man muß sich also gut überlegen, ob man das tun will.

Es ist aber definitiv gut zu wissen, daß man es tun kann!

Über

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , , , ,
Veröffentlicht in Fortgeschrittenes, Tips & Tricks

Sagen Sie Ihre Meinung!

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Autoren
%d Bloggern gefällt das: