Mehr als nur ein Editor

Wenn man seine Developer zu einem Optimizely Meeting einlädt, kann es durchaus sein, dass man vor allen Dingen erstmal eines zu hören bekommt: Nichts. Oder anders ausgedrückt: Das Interesse hält sich in Grenzen. Verständlicher Weise löst ein WYSIWYG Editor, der aus Drag & Drop Front-End Veränderungen im Browser schlussendlich clientseitige JavaScript Injektionen macht, bei Entwicklern nicht wirklich euphorische La Ola-Wellen aus.

Vorab: In unserer Firma haben wir mittlerweile ein recht breites Spektrum an Einsatzbereichen für Optimizely. Neben den klassischen Anwendungsbereichen (clientseitige Wordingtests, Redirecttests (mit komplett neuen Seiten), Native Testing auf Android & IOSs, einfache MVP “Feldtests” etc.) haben wir mittlerweile verschiedene Ansätze gefunden, Optimizely in unsere sonstige Testingumgebung zu integrieren. Aber: Optimizely wird als Tool erst dann richtig interessant, wenn man sich mit dem kompletten Featureset auseinandersetzt – angefangen z.B. bei den API function calls

Wir werfen die Münze, Optimizely wartet auf die Zahlen

Ein Beispiel: Wir sind bei unseren serverseitigen Tests im Rahmen eines Stackwechsels von PHP auf REACT auf unerwartete Probleme im Tracking gestoßen. Während unserer Fehlersuche kamen wir auf die Idee, Optimizely´s Stats Engine in das Setup zu integrieren und somit die Möglichkeit zu erhalten, auf eine schnelle Art und Weise den Daten aus dem Standardtracking mit Google Analytics ein alternatives, ebenfalls clientseitig betriebenes Tracking gegenüber zu stellen.

Hierfür haben wir im Rahmen eines Tests in unsere serverseitig ausgespielte Kontroll- bzw. Alternativvarianten jeweils ein Bucketing Snippet geschrieben, welches die Trackingdaten an Optimizely schickt – der Test wurde auf diese Weise nicht wie sonst durch Optimizely selbst (Coin Flipping, Audience etc), sondern über unsere serverseitige Lösung aktiviert. In Optimizely muss für ein solches Szenario zwar wie gehabt ein Experiment angelegt werden – dieses verbleibt jedoch im Grunde im Standby Modus und wartet auf extern zugeteilte User. 

Nieder mit der clientside-Iteration!

Das hat natürlich eine beruhigende Wirkung auf die Erzfeinde clientseitiger Tests: Da der Code weiterhin von uns ausgeliefert wird, kann es hier zu keinem Flickering kommen (was ich mittlerweile übrigens generell für eine Urban Legend halte – aber das ist ein anderes Thema).

Bei den Codeschnipseln, die die Daten aus den Buckets an Optimizely schicken, handelt es sich jeweils gerade mal um 4-Zeiler:

Auf diese Weise kann man einen User einer Variante in Optimizely zuweisen – völlig unabhängig von Optimizely´s Standardzuteilung. Der ‘bucketVisitor’ call muss hierzu natürlich vor dem Optimizely Snippet geladen werden. Ein Bucketing über die API ignoriert übrigens auch jegliche Audiencedefinition in Optimizely – der Call kann wie ein VIP Ticket betrachtet werden (“Du kommst immer rein”). Die Experiment-ID sowie die beiden jeweiligen Versions-IDs findet man im Optimizely Experiment unter Options –> Diagnostic Report (Experiments Summary & Variations Summary).

Möchte man außerdem verhindern, dass ein Pageview Event gefeuert wird, sobald der Call rausgeht, kann man sich wie folgt behelfen:

Optimizely vielfältig einsetzen

Mit dieser Herangehensweise hat man nun ein (mögliches) Setup, um das Tracking bzw. das Analyseframework von Optimizely zu nutzen, auch wenn der Test selbst auf andere Weise realisiert wird. Inwiefern das hilfreich ist oder einen Mehrwert bietet, hängt natürlich maßgeblich von der Fragestellung, der Intention oder auch dem Setup ab, das man für seine Tests nutzt. In Zukunft werden wir auf jeden Fall noch ein paar weitere derartige “Spielereien” vorstellen, bei Interesse also einfach wieder vorbeischauen!

Viel Spaß beim ausprobieren!

Jan
Jan
Autor
Psychologe, Web Analyst, Science Junkie, Star Wars Missionar und Gründer des Blogs

Hinterlasse einen Kommentar

Please enter your comment!
Please enter your name here