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
13. October 2009, 16:33, by Steven Varco

Remote system cloning

Wieder mal ein Tipp aus der Linux-Admin Trickkiste. ;-)

In diesem Fall ging es darum ein System komplett auf ein anderes zu klonen. Sind die beiden Systeme baugleich, ist das mit dd und ssh relativ einfach einfach möglich.

Dazu müssen zuerst beide Systeme mit einer Linux-BootCD (z.B. sysrescuecd) gebootet- und das Netzwerk konfiguriert werden.

Dann gibt man auf dem Quell-System einfach:

quelle~ # dd if=/dev/sda | ssh root@zielsystem "dd of=/dev/sda"

ein und wartet bis der Vorgang abgeschlossen ist. Wer sich noch einen Status des Kopiervorganges anzeigen lassen möchte:

ziel~ # kill -USR1 $(pgrep '^dd$')

-Die Ausgabe erfolgt dabei auf der Konsole vom Quellsystem.

Nach dem Kopiervorgang sollte man das System mounten und die Netzwerk-, sowie Hostname noch anpassen; sonst gibt es danach einen IP-Adresskonflikt im Netzwerk.

Achtung: Dass das ganze klappt sollten beide Systeme (zumindest die Disks) relativ baugleich sein – Und natürlich gehen die Daten auf dem Zielsystem unwiderruflich verloren. ;-)

Erweiterungen

Komprimieren: Es wäre nun noch Möglich die Daten durch gzip zu pipen um Bandbreite zu sparen.

Erweiterter Status: Mit pv kann man sich erweiterte Statusinformationen über den Kopiervorgang zusammenbasteln.


Filed under: Arbeit,IT Infrastructure
22. May 2009, 14:09, by Leo Büttiker

From the for loop to the generator in JavaScript

I recently spent some time writing JavaScript code and do reviews of JavaScript features. JavaScript has some nice language features that make it easy to write short and readable code. (On the other hand it is also quite easy to write horrible code with it.) In this article I try to show you how you can refactor your code to something more readable.

We may start with this non-fictional example:

/**
* Returns array of uids of selected items
*/
getSelected:function() {
	var returnArray = new Array();
	var modelFriendListItems = this.modelFriendListItems.getSelected();

	for (var index = 0 ; index < modelFriendListItems.length ; ++index) {
		if(!modelFriendListItems[index].isFacebookUser)
			returnArray.push(modelFriendListItems[index].id);
	}

	return returnArray;
},

It’s just one function out of a class that does quite something typical. This function goes over a list of items (iterate) and builds an array out of some of this items (filter). A friend of mine does some ruby coding and in ruby this would look something like this:

this.modelFriendListItems.getSelected().select{|item| !item.isFacebookUser}.collect {|item| item[:id]}

This is quite short and still yet readable. In JavaScript you can go as well in the direction of more functional programming. So let us refactor the JavaScript example above over some iterations. The following examples use prototype.js because this framework extends the JavaScript array with some fancy functions.
(more…)

Filed under: PHP,Programming
18. May 2009, 19:39, by Silvan Mühlemann

20 Notizen zum Silicon Valley

Because I did not plan to post this article in this blog, it is in German. This should be an exception. Sorry for the English readers.

Die letzte Woche habe ich im Silicon Valley verbracht. Mit einer Gruppe von 12 Leuten haben wir verschiedene Firmen und Organisationen besucht. Hier zähle ich ein paar wild zusammengewürfelte persönliche Eindrücke auf:

  1. Die zwei heissesten Themen in US-Firmen sind Cloud Computing und Green IT.
  2. Trotz Green IT ist die durchschnittliche Temperatur im Sitzungszimmer nie höher als 18°. Warme Kleidung ist empfohlen.
  3. Je niedriger die Temperatur im Sitzungszimmer, desto grösser das Unternehmen.
  4. Die NASA arbeitet mit Original-Anlagen aus den 50er-Jahren. Gut amortisiert!
    Von Silicon Valley Tour 2009
  5. Google ist jene Firma, welche am häufigsten unsere Fragen mit “I cannot comment on that” beantwortet hat.
  6. (more…)

Filed under: Web Development
23. April 2009, 10:34, by Riv-Alain Vakili

Website performance optimization: Don’t forget the client-side!

Regarding the topic “optimizing page-loading-times” too many people still set the focus only on the server-side, ignoring the fact that most of the loading time is spent getting all the components of the page(CSS, JavaScript, images, ads).


Also, pages (like tilllate.com) more often make heavy use of JavaScript with the goal of providing a better user experience. The problem is, that most developers work on modern hardware and develop on their favourite web browser – which is usually a recent one. They forget that a big amount of visitors still surf with their first computer bought 7 years ago at Interdiscount and is mostly surfing on the developers least favourite browser (like IE 6). As a result, those visitors often do not get the optimal user-experience and the website loses traffic (=money).



The conclusion out of this is:



  • We have to optimize our page following yahoo’s findings.

  • We have to optimize our JavaScript-execution.

Where to start?


Most of our traffic is generated through the photo album. We analyzed and improved following use-case in terms of loading-speed and responsiveness:


homepage


User comes to homepage…


thumbnails


…goes to the a photoalbum…


photo


…clicks through the photos


Tweaks


We then did the following things:



  • Reduced HTTP requests needed to load the JavaScript files: from 45 to 1-2 requests by merging the multiple files into a single one.

  • reduced file sizes of CSS- and JavaScript files by using yui-compressor

  • reduced amount of external scripts (like Google Analytics) or load them after everything else to reduce the dependency on third party hosts

Also with the photo album being a JavaScript app we went through the code and implemented the following improvements:



  • reduced DOM-operations

  • reduced amount of written code by refactoring

  • found and removed some common memory leak-patterns

  • removed fancy fading-effects as they were useless and took a lot of CPU time

The results


For example on IE7 (50% of our users are using it) we had following improvements:



  • time loading and set up the photoalbum decreased from 4.8 to 2.9 seconds

  • time switching between thumbnailpages decreased from 1.3 to 0.3 seconds

  • the general loading/parsing-time of JavaScript decreased from 1,2 to 0.6 respectively 0.5 to 0.3 seconds (Firefox).

Once we released the tweaks, the pageviews per visit increased by 20%.

Filed under: Web Development
31. March 2009, 21:41, by Silvan Mühlemann

Job opening: Web developer (PHP / AJAX)

Are you enthusiastic about web technologies? Do you have strong PHP, Javascript and SQL skills? Would you like to work with a team of smart and passionate people? Are you open to advanced development methodologies like Scrum or Test Driven Development? Would you like help further develop one of the biggest Swiss website?

Then you should apply for a job at tilllate.com: Our team is looking for dedicated web developers. You’ll find more information in our job ad:

Filed under: Arbeit,PHP,Web Development
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…)

1. March 2009, 13:43, by Silvan Mühlemann

MVC for Javascript Controls

I recently had to take over an unfinished project. It was an AJAX control to select multiple friends as you can find it on Facebook.

friendselector_facebook

“It’s 99% complete”, I was told. Yeah, right. I counted 2 story points (without looking at the code). Soon I knew I was too optimistic: Classes calling other classes without logic. Randomly named variables. Data, creation of DOM elements, AJAX calls spread all over the place:

Architecture before refactoring (dramatized)

Architecture before refactoring (dramatized)

That’s not going to be easy. To make things worse: I am a Javascript beginner. What I did up to now was procedural Javascript code.

(more…)

Filed under: Web Development
Next Page »

© 2014 tilllate Schweiz AG - Powered by WordPress