Von Manuel Brückmann | Strategie Tipps | 3 Reaktionen

Effektives Testing – Launch early, launch often

Die Software-Development-Philosophie „Launch Early, Launch Often“ betont, wie wichtig frühe und häufige Releases sind, um eine enge Feedback-Schleife zwischen Entwicklern und Nutzern bzw. Testern zu ermöglichen. Diese Philosophie lässt sich sehr gut auf Prozesse zur Conversion Optimierung anwenden und steht im direkten Kontrast zur funktionsgetriebenen Strategie („feature based release strategy“).

Conversion Optimierung ist eigentlich kein Hexenwerk. Die Tools bieten häufig unterstützende Funktionen, um agil Experimente durchführen zu können ohne dafür umfangreiche Änderungen am System vornehmen zu müssen. Die Erfahrung und das Fazit aus Gesprächen mit Shop- bzw. Marketing-Verantwortlichen sowie Conversion-Optimieren zeigt, dass hier häufig noch die – ich würde es mal als „Google-Website-Optimizer“- Mentalität bezeichnen – Verwendung findet und damit agiles und effektives Testing häufig nicht statt findet.

Dieser Old-School-Ablauf sieht meist wie folgt aus:

Ein Team von Experten – oder eine Personengruppe die sich zumindest für das Thema verantwortlich fühlt – definiert die Optimierungen. Diese werden an die IT-Abteilung oder -Dienstleister zur Umsetzung weitergegeben, um diese – sofern alles gut läuft – im Rahmen eines Split-URL Tests zu verproben (die neue Variante läuft parallel zu Control, der Traffic wird aufgeteilt).

Grundsätzlich kein schlechter Ansatz, da die Änderungen nach einem erfolgreichen Test direkt ausgerollt werden könnten (Wechsel zur Variation bzw. dauerhafte Ausspielung).

Leider hat dieser Ansatz zwei, eigentlich sogar drei entscheidende Nachteile:

  1. Die Umsetzung dauert länger als nötig
    Es gibt wenige Ausnahmen, bei denen eine „harte“ Umsetzung im System erforderlich wird – z.B. wenn die Änderungen zu umfangreich werden, als dass sie durch das Testingtool ausgeführt werden könnten, oder wenn die Performance ansonsten massiv verschlechtert werden würde. Auch wenn Veränderungen an Prozessen erforderlich sind, so dass das Tool an seine funktionellen Grenzen stößt, ist gegebenenfalls eine programmierte Lösung erforderlich.

    Davon abgesehen gibt es keinen Vorteil durch die direkte Umsetzung am System. Performance ist die häufigste Ausnahme. Welche Maßnahmen ergriffen werden können, um diesen Umstand zu minimieren, habe ich bereits in meinem Artikel 5 Tipps für Testing – die jeder Conversion Engineer kennen sollte erläutert. Abhängig von der Art des Testingssystems kann die Performance sogar besser sein.

  2. Keine MultiVariate-Tests (MVT)
    Es lassen sich mit dieser Vorgehensweise lediglich A/B-Testkonzepte verproben, multivariate Tests sind praktisch unmöglich.  Testplan und -konzept sind somit auf die A/B/n-Testkonstruktion limitiert, was die Möglichkeiten deutlich einschränkt.
  3. Die Kosten für einen Test steigen
    Gleich mehrere Faktoren treiben die Kosten unnötig in die Höhe. Da die Umsetzung in der Regel länger dauert, als wenn Sie für den Test im Tool durchgeführt wird, steigen auch die Kosten (auch hier gibt es Ausnahmen). Aufgrund der längeren Zeiträume zwischen Konzept und Teststart geht Potenzial verloren. Je weniger Tests im Jahr durchgeführt werden können, desto weniger Uplift und letztlich Umsatzplus kann erzielt werden.

Ein weiterer Nachteil dieser Vorgehensweise:

Nicht selten werden die Optimierungen gar nicht erst getestet, sondern kurzerhand direkt ausgerollt.

<ironie>Schließlich machen diese ja total Sinn und sind notwendig, sonst verliert man nur unnötig Zeit und Geld.</ironie>

In solchen Fällen ist der Groschen dann leider noch nicht gefallen.

Effizientes Optimieren durch agile Entwicklung = Effektives Testing

Jeff Bezoz (Gründer und CEO von Amazon) beschreibt das treffend:
If you double the number of experiments you do per year you’re going to double your inventiveness.
Das funktioniert nur in dem man auf agilere Entwicklungsmethoden zurückgreift! Dies soll nicht bedeuten, dass man am Konzept, Umsetzungsgenauigkeit oder der Qualität „Zeit spart“, sondern viel mehr die Funktionen und Möglichkeiten der Testingtools effektiver nutzt.

<tag>-basierte Tools bieten neben einem visuellen Editor die Möglichkeit, HTML – also z. B. JavaScript-Code oder CSS – direkt in die Testvariante einzufügen. Dafür muss nichts am System verändert werden. Die inhaltlichen Änderungen werden z. B. direkt oder durch JavaScript im Tool erzeugt.

Effektives Testing - Beispiel für eine Toolbasierte Testumsetzung
Beispiel für eine toolbasierte Testumsetzung (90% CSS, 10% JavaScript) – links Control, rechts Variation mit Fokus auf Qualität – keine Backendanpassung, Ladeverzögerung 60 – 130ms

Diese Vorgehensweise ist in der Regel deutlich schneller und „beweglicher“. Läuft ein Test nicht wie gewünscht, muss evtl. nachgebessert oder gar neu aufgesetzt werden. Die erneute Umsetzung außerhalb des Tools ist meist mühselig und langwierig. Hier spielen dann die Deploymentprozesse und Deploymentzyklen häufig eine Rolle. Durch den Einsatz der Manipulationen im Testingtool sind diese Prozesse und Zyklen nicht notwendig.

Erst wenn der Test zufriedenstellend abgeschlossen wurde sollten die Änderungen dauerhaft umgesetzt werden. Oft können hierbei beispielsweise das durch JavaScript generierte HTML oder CSS für die dauerhafte Implementierung verwendetet werden – zumindest teilweise.

Ein weiterer, nicht zu unterschätzender Vorteil: je nach Test müssen nicht mehr zwingend die IT-Abteilung oder Dienstleister bemüht werden. Je nach Tool und Art der Implementierung kann diese gänzlich ohne technischen Background durchgeführt werden. Dies spart nochmals Zeit und Geld. Bei leistungsfähigeren Conversion Testingtools sind diese in der Regel systembedingt entsprechend umfangreich integriert, so dass Experimente gänzlich ohne Programmierung auskommen (z. B. regelbasiert).

Allerdings ist die Bandbreite an Möglichkeiten mit dem visuellen „Edit in Place“- oder WYSIWYG-Editoren (What You See Is What You Get) auf inhaltliche und minimale gestalterische Anpassungen beschränkt. Geht es um tiefer greifende Testkonzepte, wird zumindest ein Frontend-Entwickler (bei Web Arts „Conversion Engineer“) benötigt.

Ein weiterer Faktor, der für die testingtool-basierte Umsetzung spricht, ist: Je umfangreicher die Testkonstruktionen werden (beispielsweise wenn behavioural Targeting oder responsive Design Testing dazu kommen) kann der Aufwand außerhalb des Tools enorm hoch werden.

Fazit

Conversion Testing scheint im eCommerce zwar endlich angekommen zu sein, aber leider wird dieses häufig noch viel zu zögerlich oder umständlich eingesetzt.

Verantwortlich dafür sind langsame interne Prozesse und die Angst vor hohen Kosten – Stolpersteine, die einen agilen Testingprozess behindern. Aber so muss es nicht sein. Es gibt ausreichend Tools und Möglichkeiten, um den Prozess zu beschleunigen, schnell und einfach Tests an den Nutzer zu bringen und in einem überschaubaren Zeitraum Testergebnisse und Erfolge zu erzielen.

 

Ähnliche Artikel:

 

Weiterführende Links:

Manuel Brückmann

Manuel Brückmann ist als Mitglied der Geschäftsleitung bei konversionsKRAFT für den Bereich Technologie verantwortlich. Er beschäftigt sich neben der Beratung im Bereich Testing mit eCommerce-Entwicklung und -Optimierung.
Frage zum Artikel? Frag den Autor

3 Reaktionen auf „Effektives Testing – Launch early, launch often

  1. Vielen Dank für den Artikel, es stimmt: Bevor man gar nichts macht, sind die visuellen Editoren eine gute Lösung. Meine Erfahrung, z. B. bei Landing Pages, ist jedoch, dass die gestalterischen Änderungen oft zu tiefgehend sind. Dazu kommt, dass der Code bei vielen Shop-Systemen relativ komplex ist und auch das „einfache“ WYSIWYG-Editieren nicht selten zur Sysiphosaufgabe mutieren kann 😉

    • von Manuel Brückmann

      Hallo Christoph,
      absolute richtig, der WYSIWYG-Editor eignet sich nur für statische Seiten und eher oberflächliche Anpassungen. Tiefer greifende Änderungen funktionieren dann besser über JavaScript und CSS.
      Dadurch lassen sich Variationen in der Regel aber dennoch deutlich schneller realisieren als die „native“ Umsetzung im Quellcode der Originalseiten (selbst wenn die Deploymentprozesse oder -zyklen kurz sind).

      Schreibe einen Kommentar

      Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.