24. November 2014, 15:47, by Riv-Alain Vakili

Spass mit A/B-Tests

Motivation

Nicht selten werden bei werbegetriebenen Webseiten und Apps Updates oder Redesigns von Kernfunktionen gemacht, ohne in der Zeit nach dem Release deren Erfolg zu messen. Konkrete und begründete Erfolgserwartungen wie  z.B. +10%  Zugriffe fehlen meist ebenso.

Dies hat zur Folge, dass das Productmanagement, wenn’s drauf ankommt, nie zweifelsfrei belegen kann, dass seine Projekte ein Erfolg und die eingesetzten Ressourcen gerechtfertigt waren. Zudem werden interne wie externe Kritiker – zu Recht oder zu Unrecht – steht’s den propagierten Erfolg in Frage stellen können.
Nicht selten habe ich erlebt, dass teure Projekte nach dem Release als Erfolg gewertet wurden, obwohl die Seitenzugriffe z.B. nur saisonbedingt kurzzeitig angestiegen waren. Solche Fehlinterpretationen können fatale Folgen haben.

Obwohl man mittels Durchführung fachgerechter Usability-Tests, die Chancen auf ein erfolgreiches Produkt massiv verbessern kann, geben meist erst A/B- oder Multivarianten-Tests Aufschluss darüber, ob das neue/veränderte Produkt auch effektiv eine Verbesserung darstellt.

A/B-Tests werden meist im Zusammenhang mit Werbemittel , Landingpages und deren Konversionsrate genannt. Z.B. bei der Gestaltung einer Registrierungspage. Das Anwendungsgebiet ist aber durchaus breiter, wie das folgende Beispiel zeigt.

Beispiel: Mobile Bildstrecke

Die Bildstrecke, welche unseren Storys angehängt wird, ist unser Trafficdriver und für gut einen Drittel der Gesammtzugriffe verantwortlich. Im Rahmen einer erhofften Effizienzsteigerung haben wir diese etwas genauer analysiert. Google Analytics zeigte unter anderem, dass Mobile-User mit Safari beträchtlich mehr Zugriffe pro Besuch machen als mit Chrome.

Die Annahme:
Da auf Safari das Javascript-Sliding besser/weicher läuft, wird die Bildstrecke damit auch dementsprechend lieber benutzt. Oder wie lange würdest du in einem Bilderbuch blättern, wo jede Seite an der Nächsten klebt?

Also wurde die Bildstrecke umgebaut: Es wurden butterweiche, hardwarebeschleunigte CSS3 Transitions hinzugefügt, der Bildbeschrieb unter das Bild verschoben, die Pfeile entfernt und einen Index hinzugefügt. Idealerweise hätte man jeden Parameter einzeln getestet, um den jeweiligen Einflussfaktor ermitteln zu können.


Alte Version


Neue Version

Fertig implementiert, wurde mit Hilfe von Google Analytics ein A/B-Test aufgesetzt. Eine Sache von wenigen Augenblicken:

  • Testziel angeben ( Sitzungsdauer, Zugriffe usw. )
  • Prozentsatz des Traffics, der getestet werden soll bestimmen
  • Url’s der Varianten setzen
  • Code-Snippet in Webappliaktion einfügen

50% der User wurden dabei auf die alte und 50% auf die neue Version geleitet und das Ganze eine Woche lang laufen gelassen.

Testergebnisse

Der A/B Test zeigte deutlich mehr Zugriffe pro Besuch für die neue Version: Über eine redaktionell normale Woche hinweg im Schnitt ein Plus von über 60% Prozent. Allerdings wird dieser Wert relativ schnell übertroffen, wenn verhälnismässig viele grosse Bildstrecken den Storys angehängt werden:


Ausgehend des gemessenen Traffics der alten Bildstrecke bis Ende Oktober 2014, wäre mit den eher konservativen 60% ein Plus von deutlich über 100 Mio Zugriffen zu erwarten.

Fazit

Intern

  • Durch den A/B Test konnte einem eher kleinen Projekt eine unerwartet grosse Wirkung zugerechnet werden. Hätten wir den Test nicht gemacht, wäre dieser Erfolg ziemlich sicher untergegangen.
  • Durch die Erkenntnisse aus dem Test wurde die Projektpriorisierung angepasst und z.B. ein Update der Fotogalerie, wo ähnliche Resultate erwartet werden, in Angriff genommen.
  • Das Ergebnis wird in Zukunft auch bei der Aufbereitung der Storys berücksichtigt.

Generell

  • Oft sind es gerade die Produkte, die gut laufen, sprich, viele Zugriffe haben, wo es noch viel zu holen gibt.
  • Lange genug Testen: Abhängig von Produkt und veränderten Parameter, muss der Test-Zeitraum passend gewählt sein um Fehlschlüsse in der Analyse  zu vermeiden.
  • Für den gewonnenen vielfachen Nutzen ist der kleine Mehraufwand vernachlässigbar.
  • Es herscht Transparenz bezüglich des Projekterfolgs. “Wir glauben, dass es ein Erfolg war” wird zu “Wir wissen, dass es ein Erfolg war”
  • A/B Tests machen Spass: Das wiederholende Herumschrauben an Parametern und das anschließendene Testing haben einen nicht zu unterschätzenden Suchtfaktor.

Erweiterungen

Natürlich ließen sich im Falle der Bildstrecke noch mehr Varianten mit veränderten Parametern testen.
So könnte man ein Variante mit und eine ohne Werbebanner laufen lassen, um den Maximalwert Zugriffe/Besuch zu ermitteln. Diesem würde man sich dann mittels Optimierung der Parameter der Werbeauslieferung ( Frequenz, Typ des Werbemittels ) versuchen anzunährern um eine optimale Ad-Auslieferung zu erzielen.

20. May 2008, 11:11, by Leo Büttiker

tilllate.com is now all Zend Framework.

Trevi FountainWe made it! Last Friday we have replaced the last two legacy components with their Zend Framework based counterpart: The gallery an the user registration. The whole site tilllate.com is now running on Trevi, our extension of Zend Framework. With a reach of 2.5 million unique clients a month, tilllate.com is one of the world’s biggest installation of Zend Framework.

Ciprian, Ivan, Jia-Yong, Kevin, Leo, Riv, Roger, Sanja, Thilo, Vanja, Vladimir and project manager Maarten have done a wonderful job reverse engineering the old, smelly spaghetti code and refactoring everything in a clean and solid MVC architecture: 115’480 Lines of code (Thanks StatSVN).
(more…)

Filed under: PHP,tilllate.com,Web Development
14. December 2007, 18:35, by Silvan Mühlemann

Meet our Belgrade Superstars

As you might know, tilllate has a development team in Belgrade: Sanja, Ivan, Vanja and Vladimir. Skype and video conferences are nice. But it’s nicer to be able to meet in person: So to get them accustomed to the tilllate groove every serbian developer spends a few weeks in our office in Switzerland.

Meet Vladimir and Ivan:

Vladimir and Ivan (small)

Looks like working on fresh and clean TREVI code is quite enjoyable. (Trevi is our new Zend Framework based framework). In the red circle, Trevi project manager Maarten is stretching after committing the newest Sphinx config files.

Filed under: tilllate.com
2. June 2007, 16:15, by Silvan Mühlemann

tilllate IT-Team in Fotos

Schon mehr als ein halbes Jahr betreiben wir diesen Blog, doch noch nie habe ich das tilllate IT-Team vorgestellt. Holen wir dies mit ein paar Fotos nach:

IT Team Gangsta Style
Das IT-Team verschläft keine Trends: In diesem Bild posieren wir im "Gangsta-Style", welcher an Urban-Parties unter den Kids sehr beliebt ist. Maarten und Stefan fehlen auf dem Bild. Maarten ist an der Uni und saugt sich in der BWL-Vorlesung Powerpoint-Folien rein. Infrastuktur-Chef Stefan stattet den Servern einen Besuch ab.

(more…)

Filed under: tilllate.com
16. May 2007, 17:43, by Silvan Mühlemann

Neue Büros für die tilllate-IT

Bisher war das gesamte tilllate-Headquarter eine grosse Halle der alten Spinnerei in Adliswil. Mit dem gewaltigen Personalzuwachs in den letzten Monaten wurde es langsam eng. Und laut.

Die IT und Produktentwicklung ist nun in das rote 80er-Jahre-Gebäude nebenan gezogen. Parkettboden. Fensterflächen zum Albis hin. Und ruhig.

Spontane Rufe aus dem Sales-Egge quer durch die Halle ("Roger, meine Mails gehen nicht raus") gibt es nicht mehr. Dafür entfällt den abteilungsübergreifende Treff bei der Kaffeemaschine.

Neues Office
Leo, kaum 2 Wochen da und schon ein Puff… *tststs*

Filed under: tilllate.com
25. March 2007, 22:10, by Silvan Mühlemann

Sicherheitslücken entdeckt. Und behoben.

Lock on Network PlugAargh. Peinlich. XSS-Vulnerability auf tilllate.com! Da bilden wir uns laufend in Sachen Sicherheit aus (z.B. mit Ilia Alshanetsky‘s Buch, Shiflett’s Artikel im phpArchitect), haben interne Security-Richtlinien (den “Escaping Circle”), und Code-Reviews zur Qualitätssicherung. Und dann passiert uns sowas: Eine Sicherheitslücke wird entdeckt und öffentlich am Blogcamp bekannt gemacht.

Zum Glück wurde die Lücke innert wenigen Stunden geschlossen. Die vom Entdecker Benbit gesammelten Zungangskeys wurden ungültig gemacht. So konnte kein Schaden entstehen.
(more…)

Filed under: tilllate.com,Web Development
11. March 2007, 20:23, by Silvan Mühlemann

Diät für die Foto-Tabelle

Orange on Diet“Silvan, das Hinzufügen von Fotos ist schweinelangsam am Weekend! Die Fotografen sind am jammern. Ich bekomme andauernd Anrufe. Mach was!”. So beklagten sich die Regionalmanager in den letzten Wochen.

Unsere Überwachungstool bestätigen die Situation: Wie aus dem Maschinengewehr wird mein Handy von Nagios mit SMS beschossen. Die graue Kurve, welche im Ganglia die Server-Load beschreibt, ist weit über der roten Linie. Moreti, unser Tool, um die Antwortzeit zu messen meldet mehrere Sekunden, um eine tilllate-Seite zu liefern.

Server-Load-Graph
(more…)

28. February 2007, 15:38, by S R

Server-Relocation – Teil 2 (Interxion)

InterxionErst vor kurzem sind wir mit unseren Servern von einem halben in ein komplett für uns gemietetes Rack umgezogen (Server-Relocation Teil 1). Das ist nur knapp 2 Monate her und doch mussten wir schon wieder unser ganze Equipment an einen anderen Ort transportieren.

Kurz zur Vorgeschichte. Wir hatten uns damals für das IXEurope (beherbergt auch das Telehouse) in Zürich entschieden, da es einen ungeheur guten Ruf und dementsprechende Bekanntheit erreicht hat. Auch dass alle grossen Carrier ihre Peerings in diesen Gebäuden verwalten hat dafür gesprochen und wir hatten ja im halben Rack durchaus gute Erfahrungen mit dem IX gemacht.
Voller Freue haben wir dann anfangs Jahr unser neues 1/1 Rack bezogen. Von da an haben die Probleme begonnen:

(more…)

28. January 2007, 21:09, by Silvan Mühlemann

Replikation mit MySQL: Tricky!

DelfinPro Sekunde werden auf tilllate.com 5000 Abfragen von den Datenbank-Servern beantwortet. Wie können wir diese Last auf 30 Datenbank-Server verteilen? Mit Replikation. Aber auch nach fünf Jahren Erfahrung habe ich dieses Feature noch nicht ganz im Griff.

Auf Datenbank-Ebene besitzt tilllate.com vier Servergruppen mit unterschiedlichen Funktionen (= “horizontale Skalierung”): Werbung, Statistik, Chat und schliesslich der Rest der Website tilllate.com. Werbung, Statistik und Chat kommen mit einem einzelnen Datenbank-Server aus.

Der “Rest” macht 90% der Abfragen aus. Der Rest sind 27 MySQL Datenbank-Server. Auf diesen 27 Server befindet sich eine identische Kopie der Haupt-Datenbank. Damit dies so bleibt, muss jede Änderung der Datenbank (z.B. eine UPDATE-Query) wird über einen definierten Weg auf alle 27 Maschinen repliziert. Wir benutzen hier die Replikations-Features von MySQL.

Einfache Master-Slave-Replikation
(more…)

19. January 2007, 14:03, by Silvan Mühlemann

Interview with the tilllate-AJAX-Chat developer.

Portrait CiprianAfter 4 years having a slow reload-frame-based chat (also called “codename Neandertal”) tilllate has launched a new, state-of-the-art chat. In addition of average-joe chat functionality you can also open your own private rooms and invite your friends there. I spoke with Ciprian, our developer of this product.

Screenshot chat

How successful is the new tool?
The tilllate members seem to chat a lot in the new chat. Almost 100 000 messages the 1st day, and 125 000 the second day. I think it’s quite a lot. But there were also bug reports. Really weird ones: “There’s something wrong with tilllate. They don’t have the old slow and ugly chat anymore. This must be an error! With such a cool chat I am going to spend even more time on tilllate. That’s bad for my career.”
A new thing for me was to hear somebody complaining the web it’s too fast (“Es isch fast zu schnell!!“).
(more…)

Filed under: tilllate.com,Web Development
Next Page »

© 2017 tilllate Schweiz AG - Powered by WordPress