Wir hoben Microsoft Clarity als Produkt hervor, das von erfahrenen Produktmanagern mit Blick auf praxisnahe Anwendungsfälle entwickelt wurde, die die Herausforderungen von Unternehmen wie Switas verstehen. Funktionen wie die Erkennung von Wutklicks und die JavaScript-Fehlerverfolgung erwiesen sich als unschätzbar wertvoll, um Frustrationen der Nutzer und technische Probleme zu identifizieren und so gezielte Verbesserungen zu ermöglichen, die sich direkt auf die Nutzererfahrung und die Konversionsraten auswirkten.
Serverseitiges Testen
Serverseitiges Testen ist ein Experiment, bei dem sowohl die Variantenzuweisung als auch das Rendering der Varianten auf dem Server erfolgen, bevor die Antwort den Browser erreicht. Der Besucher erhält den vollständig formatierten Code der ihm zugewiesenen Version, ohne dass clientseitige Skripte die Seite nach dem Empfang überschreiben. Dies steht im Gegensatz zum clientseitigen Testen, bei dem die Originalseite zuerst geladen und anschließend von einem Testskript im Browser modifiziert wird.
Die technischen Vorteile sind erheblich. Es gibt kein Flimmern, da der Besucher das Original erst sieht, nachdem die Variante angezeigt wurde. Da keine Abhängigkeit von der erfolgreichen Ausführung von JavaScript besteht, beeinträchtigen Werbeblocker, datenschutzfreundliche Einstellungen zur Skriptblockierung und langsame Geräte die Ergebnisse nicht. Es wird kein zusätzliches renderblockierendes Skript verwendet, sodass die Seitenladezeit nicht beeinträchtigt wird und die Ergebnisse somit nicht verfälscht werden. Vor allem aber ist die Variante nicht auf die im DOM manipulierbaren Elemente beschränkt: Serverseitige Tests können Preise, Lagerlogik, Suchmaschinenranking, Empfehlungsmodelle, API-Antworten, Geschäftsregeln und alle anderen Berechnungen der Anwendung ändern.
Die Kosten sind eher organisatorischer als technischer Natur. Serverseitige Tests erfordern Entwicklungskapazitäten für die Erstellung jeder einzelnen Variante. Dadurch landen die Experimente im Entwicklungs-Backlog und konkurrieren mit anderen Aufgaben. Die Zeitspanne von der Idee bis zum Live-Test wird in Sprints statt in Stunden gemessen. Marketing- und Optimierungsteams verlieren die Autonomie, die sie mit visuellen Editoren haben, und die Anzahl der Experimente, die ein Programm pro Quartal durchführen kann, ist durch den Durchsatz der Entwicklungsabteilung und nicht durch den Datenverkehr begrenzt. Organisationen, die auf serverseitiges Testen umsteigen, ohne ihren Planungsrhythmus anzupassen, erleben in der Regel einen deutlichen Rückgang der Experimentiergeschwindigkeit, bevor die Qualitätsgewinne sichtbar werden.
In der Praxis nutzen ausgereifte Programme beides. Clientseitiges Testen ist weiterhin geeignet für Änderungen an Texten, Layout, visueller Hierarchie und Präsentation, die sich sicher im Browser umsetzen lassen und die Marketingteams schnell iterieren müssen. Serverseitiges Testen ist für alles reserviert, was Geschäftslogik betrifft, alles, bei dem Flimmern das Ergebnis beeinträchtigen würde, alles auf stark frequentierten Pfaden, wo die Leistungseinbußen durch ein Testskript inakzeptabel sind, und alles, was konsistent auf Web, mobilen Apps und E-Mails funktionieren muss. Die Zuordnung eines Tests zu einer Kategorie ist Teil des Versuchsdesigns und keine plattformweite Richtlinie.
Serverseitiges Testen verändert auch die Anforderungen an die Analyseschicht. Da die Zuordnung serverseitig erfolgt, muss die Variantenkennung zuverlässig an die Analyse- und Data-Warehouse-Schichten übergeben werden, um Analysen zu ermöglichen. Sie muss zudem konsistent jedem nachgelagerten Ereignis zugeordnet werden, auch solchen, die erst Tage später per E-Mail oder in einer mobilen App erfolgen. Die korrekte Einrichtung dieser Instrumentierung ist in der Regel der schwierigste Teil der Migration. Fehlerhafte Implementierungen führen zu Experimenten, deren Zuordnung zwar technisch korrekt ist, deren Ergebnisse aber nicht rekonstruiert werden können.
Dieser Ansatz erweitert die Experimentiermöglichkeiten über die Website hinaus auf Bereiche, die clientseitig nicht erreichbar sind. Mobile Anwendungen lassen sich nach der Veröffentlichung ohne Einreichung im App Store nicht mehr ändern, daher müssen alle Experimente innerhalb dieser Anwendungen serverseitig konfiguriert werden. E-Mail-Inhalte, Transaktionsnachrichten, Preislogik, Suchmaschinenranking und Empfehlungsmodelle werden ebenfalls serverseitig festgelegt. Sobald die Zuordnung zentral erfolgt, kann dasselbe Experiment Web, App und Messaging mit einheitlicher Kategorisierung umfassen. So kann ein Unternehmen Änderungen an der gesamten Kundenerfahrung testen, anstatt nur die Darstellung in einem einzelnen Kanal. Für Organisationen, deren Kunden regelmäßig zwischen verschiedenen Kanälen wechseln, ist diese Konsistenz jedoch keine Verbesserung: Ein Experiment, das eine Person einer Variante auf der Website und einer anderen in der App zuordnet, liefert keine aussagekräftigen Ergebnisse.
Da die Umstellung sowohl die technische Architektur als auch die Funktionsweise der Optimierungsfunktion betrifft, wird sie üblicherweise als gemeinsame Aufgabe angegangen. Die Infrastruktur befindet sich bei ,, die Messschicht mit Datenanalyseund die Versuchsplanung und Priorisierung mit dem CRO-Dienstleistung Funktion. Für Unternehmen, die Handel in großem Umfang betreiben, ermöglicht diese Kombination, die Teile der Nutzererfahrung zu testen, die tatsächlich Umsatz generieren, und nicht nur die Teile, die zufällig im Browser bearbeitbar sind.
Switas, wie gesehen auf
