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.

18. September 2010, 09:43, by Silvan Mühlemann

ORM tool or handwritten SQL?

We recently had a discussion about whether to use an ORM tool or code the SQL manually. These are discussions like “Apple vs. Nokia” or “Spaces vs. Tabs“. Very emotional.

You should know that tilllate is using a self-made “ORM” tool: Our ORM framework maps table columns to object properties. But it is agnostic of relationships between tables. And when you want to write a complex query, you end up programming long lines of native SQL. Unreadable.

(more…)

Filed under: Management,Web Development
8. September 2010, 09:42, by Silvan Mühlemann

Make them feel welcome

Recently a friend of mine had his first day of work with a new employer. The company was famous to be very employer-friendly. Surprisingly, my friend experienced the opposite: When he came, his boss was not around. No one told him what he had to do. An initial training was not announced. And when he wanted to go to lunch, he found himself alone in the office. He just felt lost at his new workplace. Bad start.
(more…)

Filed under: Management
17. March 2009, 23:33, by Silvan Mühlemann

Scrum: How we do Sprint Retrospectives

Four weeks have passed since the last sprint planning meeting. Sprint number two has come to an end. It’s time for the sprint retrospective.

The motivation for the sprint retrospective is:

  • Visualize the accomplishment – important for the team morale
  • Review any impediments and discuss measures on how to avoid them in the next sprint

Here’s how we are structuring the sprint retrospecives:

The set up

The team and the product owner are allocating one hour in the meeting room. We’re looking at the wall with the task board showing the user stories, the burn down chart and the impediment backlog. This is a big paper with a post it for every impediment encountered during the sprint. We collected the impediments during the bi-weekly scrum meetings (aka daily scrum).

Visualize the achievements

First, I go through all done user stories and say a few words about every story. Time for praising the team. Developers often think “we haven’t achieved anything”. So it’s important to visualize the finished user stories.

(more…)

16. February 2009, 23:14, by Silvan Mühlemann

Implementing scrum at tilllate.com

The first sprint is done! Yes we finally started doing Scrum at tilllate.com*. Well, it’s not exactly how Schwaber and Sutherland would expect it. But our way fits our team. And the acceptance in both the IT team and the rest of the organization is high. It improves motivation and therewith the performance of the team. And that’s what matters.

Sprint planning meeting

Sprint planning meeting

(more…)

7. January 2008, 08:39, by Leo Büttiker

Trevi is online!

Trevi FountainTrevi is not only a fountain in Italy, it’s our new application framework as well. We migrated our first pages to this new platform and brought them online three weeks ago. But let me explain the story of Trevi.

Another Framework?

There’re already thousands of web frameworks out there so I would sink into the ground if we really wrote another one. But serving pages for 2 million unique clients, it would also not have been a solution to just go to a shop and take the beautiful looking, nice boxed xyz framework from a big company. So my co-worker (and Trevi project lead) Maarten started a year ago to evaluate a framework that fits our needs best.
(more…)

Filed under: Management,PHP
30. December 2007, 23:49, by Silvan Mühlemann

Holiday season: The best time to… work

Christmas TreeFor me, the time around Christmas and New Year is the best time of the year. Of course, there’s the peaceful family reunions around the christmas tree. The cozy evenings at home on the couch. Or days where you can shamelessly sleep in. In my case I am expecting my son Orell who should be born anytime.

But stop: This is a business related blog. And so I am not talking about my private life. When I say “the best time of the year” I am thinking about work. There’s no better time of year for not taking vacations. Here’s why:
(more…)

Filed under: Management
4. December 2007, 20:33, by Silvan Mühlemann

What motivates your programmer?

We’d like to deliver great products on tilllate.com. For great products you need motivated developers. So recently, Leo, Stefan, Maarten, Mario and me did a brainstorming about “what motivates programmers”. Here are the results:

1. Offer him the best type of work

Avoid giving finished specs to your developer. Let him do the specifications himself. Let him do the technology selection. Let him define the architecture. Give him challenging tasks to do on technologies he has never used before. Keep routine and maintenance work from him (nevertheless, someone has to do those tasks).

(more…)

Filed under: Management
19. October 2007, 10:04, by Silvan Mühlemann

Five ways to impress at the job interview

Job interview

As CTO I often have to do job interviews. Recently, I spent two days interviewing candidates for our tilllate development center Belgrade (Yes, I am one of these brave CTOs having a distributed team :-)). So here’s five tips to impress your employer of your dreams:

Keep a low profile!

Andy writes in his CV that he’s "extemely experienced in OOP". And when I ask him why he thinks he’s so experienced OOP he tells me: "My biggest class has 25’000 lines.". Ooops. God class. Classical Antipattern. Not only he showed that he has no idea of good OOP coding style. But also he cannot judge his own skills. Once at your company he’ll be the guy grabbing every cool project but then not finishining due to missing skills. Zap. Disqualified.

(more…)

Filed under: Management
11. October 2007, 08:07, by Silvan Mühlemann

Visit of the Silverlight evangelists

Preacher

There are two ways convince a company to switch to a new programming language. The old fashioned way is to send out salesperson. They get in touch with the CEO show them a few Power-Point slides, throw some buzzwords at them and voilà, Mr. Manager will introduce that new technology.

Well, he will try to introduce that new technology. In most of the cases it won’t work. Because usually the CEO looks at other things when deciding for a programming language than the development team. The dev-team won’t accept the new technology. This will slow down development and thus reduce productivity.

(more…)

Filed under: Management
Next Page »

© 2014 tilllate Schweiz AG - Powered by WordPress