Clientseitiges Testen vs. Serverseitiges Testen: Beide gewinnen.
Veröffentlicht: 2020-05-28Bei der Durchführung von Experimenten können Optimierer zwischen clientseitigem und serverseitigem Testen wählen.
Sie können zwar fast jeden clientseitigen Test auf der Serverseite und einige leichte Backend-Experimente über clientseitige Tests (unter Verwendung von Split-URL- oder Redirect-Experimenten) ausführen, dies ist jedoch nicht so machbar oder robust wie Sie. d wie … weil für jede Hypothese nur eine der beiden am besten funktioniert .
Und die Wahl des richtigen muss sorgfältig abgewogen werden. Bei dieser Wahl sind viele Aspekte abzuwägen. Betrachten Sie die Auswirkungen des Setups auf Geschwindigkeit und SEO, den Aufwand und die Zeitanforderungen für den Lebenszyklus des Experiments, das Ziel des Experiments und mehr.
Lassen Sie uns diese Faktoren durchgehen und sehen, wie sich clientseitige Tests von serverseitigen Tests unterscheiden und welche Vor- und Nachteile sie haben.
Clientseitiges Testen vs. Serverseitiges Testen
Was ist der Unterschied zwischen clientseitigem Testen und serverseitigem Testen?
Beim clientseitigen Testen stellt Ihr Server diese bereit, sobald ein Benutzer eine Seite anfordert. ABER in diesem Fall implementiert Ihr Experimentiertool etwas Javascript im Browser Ihres Benutzers, um den vom Server gelieferten Inhalt zu ändern, sodass der Endbenutzer basierend auf Ihren Ausrichtungsregeln die entsprechende Variation erhält. (Der Browser ist der „Client“.)
Beim serverseitigen Testen hingegen bestimmt Ihr Server, sobald ein Benutzer eine Seite anfordert, die zu liefernde Version und liefert genau diese. Ihr Experimentiertool funktioniert auf dem Server und nicht im Browser Ihres Benutzers.
Da clientseitige Tests nur mit JS-Ausführung auf Browserebene stattfinden, können Sie damit nur Dinge auf Oberflächenebene wie Layouts, Farben und Nachrichten testen. Einige Optimierer bezeichnen solche Tests als „kosmetische“ Tests.
Dies würde jedoch clientseitige Tests außer Acht lassen.
Clientseitiges Testen mag einfach erscheinen, ist aber wirkungsvoll.
Es ist leicht, clientseitige A/B-Tests als „einfache Tests“ abzutun, die jeder durchführen kann. Einverstanden: Es ist einfach zu implementieren. Und manchmal kann es so klein sein wie das Testen einer anderen CTA-Button-Farbe oder -Kopie.
Aber ob es sich nun um dies oder etwas so Großes wie das Testen eines Redesigns oder einer überarbeiteten Seite handelt, clientseitige Tests wirken sich auf das Endergebnis eines Unternehmens aus .
Was ist clientseitiges Testen?
Kurz gesagt: Clientseitiges Testen bedeutet, dass die Optimierung auf Browserebene stattfindet. Basierend auf den von Ihnen eingerichteten Targeting-Regeln ändert der Browser des Besuchers den Inhalt, um die beabsichtigte Version bereitzustellen.
In dieser Fallstudie verwendete ein SaaS-Unternehmen Convert Experiences als kundenseitiges A/B-Testtool, um das Wachstum der Leads auf seiner Homepage um 61 % zu steigern:
Hier ist ein weiteres A/B-Testexperiment mit Convert Experiences als clientseitiges Testtool für dasselbe SaaS-Unternehmen auf seiner Preisseite, das zu einem Anstieg der Leads um 57 % führte:
Die meisten Erfolgsgeschichten zur Conversion-Optimierung, die Sie online sehen, sind clientseitige Tests, die ein Erlebnis auf Oberflächenebene erfolgreich optimiert und große Erfolge erzielt haben.
Aber mit serverseitigem Testen können Sie tatsächlich mehr testen.
Wenn Sie tiefer als das Frontend testen müssen, müssen Sie sich für serverseitige Tests entscheiden.
Was ist serverseitiges Testen?
Serverseitiges Testen ist eine Art Experiment, bei dem der Webserver die Version des zu liefernden Inhalts bestimmt. Beim serverseitigen Testen wird die gesamte Optimierung direkt auf den Servern und nicht in den Browsern der Besucher implementiert.
Lassen Sie uns dies anhand einiger Szenarien ins rechte Licht rücken.
Wenn Sie ein E-Commerce-Unternehmen wären, könnten Sie ein clientseitiges A/B-Testexperiment verwenden, um herauszufinden, ob eine neu gestaltete Suchleiste Ihre Suchanfragen im Geschäft steigern (und zu mehr Verkäufen führen) könnte.
Aber wenn Sie einen neuen Suchalgorithmus testen wollten, der relevantere Suchergebnisse liefern könnte (und der langfristig zu mehr Verkäufen führen würde), müssten Sie ein serverseitiges A/B-Testexperiment durchführen .
Wenn Sie stattdessen ein B2B-SaaS-Unternehmen wären, könnten Sie ein clientseitiges Experiment durchführen, um festzustellen, ob ein bestimmtes UVP auf Ihrer Homepage besser funktioniert. Oder ob eine Kopie in Langform eine in Kurzform schlagen könnte.
Wenn Sie jedoch ein schnelleres Backend testen und sehen möchten, ob es die Bindung oder das Engagement verbessern könnte, müssen Sie ein serverseitiges Experiment durchführen. Wenn Sie eine neue Onboarding-Sequenz testen möchten, müssen Sie sich erneut für ein serverseitiges Experiment entscheiden. Denn neben der Unterstützung Ihres neuen Onboarding-Workflows können Sie mit serverseitigen Tests auch ein Multi-Channel-Experiment orchestrieren, das sich über E-Mails, SMS und andere erstreckt und auf verschiedenen Geräten stattfindet.
Wenn Sie ein B2C-SaaS-Unternehmen wären, könnten Sie ebenfalls ein clientseitiges Experiment durchführen, um zu erfahren, ob ein bestimmter Preisplan besser funktionieren könnte als die anderen.
Wenn Sie jedoch eine bessere Empfehlungs-Engine testen möchten, müssen Sie sich für serverseitige Tests entscheiden.
Wie Sie aus den verschiedenen Anwendungsfällen des serverseitigen Testens entnehmen können, ist es eher darauf ausgerichtet, bessere Produkte zu entwickeln, als sofortige Conversions zu erzielen. Im Gegensatz zu clientseitigen Experimenten, die sich auf sofortige Verkäufe oder Konversionen konzentrieren, konzentrieren sich serverseitige Experimente auf die Optimierung des Produkts oder der Lösung, sodass der lebenslange Kundenwert steigt.
Man könnte sagen, wenn Client-seitiges Testen für Marketer ist, dann ist serverseitiges Testen in erster Linie für Produkt- und Entwicklungsteams. Und A/B-Testtools wie Convert Experiences bieten sowohl clientseitige als auch serverseitige Tests, um sowohl Marketing- als auch Engineering-Teams gerecht zu werden.
Probieren Sie es 15 Tage lang kostenlos aus!
Da das Testen solch tiefgreifender Änderungen auf Produktebene viel mehr erfordert als eine einfache browserbasierte JS-Manipulation, kann dies nicht innerhalb des Browsers geschehen und muss auf Serverebene angegangen werden.
Während serverseitiges Testen seine einzigartigen Anwendungsfälle hat, verwenden einige Unternehmen es sogar zum Ausführen kosmetischer Tests – Tests, die sogar auf der Clientseite vollkommen störungsfrei laufen würden.
Sie tun dies oft, um „Flimmern“ oder das Phänomen „Flash of Original Content“ zu vermeiden. Flimmern tritt auf, wenn das Experimentiertool den vom Server bereitgestellten Originalinhalt ändert, nachdem die Endbenutzer ihn bereits gesehen haben. Stellen Sie sich vor, Ihre Benutzer sehen eine bestimmte Überschrift und sehen dann, wie sie blitzschnell zu einer anderen wechselt. (Ja, Flimmern kann die Erfahrung eines Benutzers ernsthaft beeinträchtigen!)
Zu anderen Zeiten tun sie dies für eine verbesserte Geschwindigkeit. Während das Testen eine Website nicht verlangsamt oder ernsthafte Leistungsprobleme verursacht, fügt es dem wahrgenommenen Ladeerlebnis einer Website ein oder zwei Sekunden hinzu. Serverseitig kann dies schneller erfolgen.
Gelegentlich führt ein Unternehmen aufgrund von Datenschutz- oder Sicherheitsbedenken ein serverseitiges Experiment anstelle eines clientseitigen Experiments durch. Da das Zielgruppen-Targeting auf dem Server erfolgt und sich der Experimentiercode beim serverseitigen Testen auf dem Server befindet, erhalten Unternehmen eine bessere Kontrolle über die Datenschutz- und Sicherheitsaspekte.
Die Implementierung eines serverseitigen Experiments ist jedoch nicht immer machbar, insbesondere wenn ein clientseitiges Experiment genauso gut funktionieren würde.
Implementieren serverseitiger Experimente
Beim clientseitigen Testen benötigen Sie nur begrenzte Design- und Entwicklungsressourcen, um Ihre Experimente zu erstellen und auszuführen. Sie brauchen diese nicht einmal, wenn Sie nur Textänderungen vornehmen oder die Farbe einer Schaltfläche ändern. Alles, was Sie tun müssen, ist:
1. Melden Sie sich bei einem Tool wie Convert an.
2. Verwenden Sie den WYSIWYG-Editor und erstellen Sie die Variationen.
3. Richten Sie das Experiment ein (stellen Sie die Zielgruppen-Targeting-Bedingungen, die Testdauer, die Stichprobengröße und -aufteilung, das Konfidenzniveau usw. ein)
Holen Sie sich den JS-Code und fügen Sie ihn Ihrer Website hinzu.
Und fertig.
Sie würden dann Entwicklungshilfe suchen, um die Gewinnerversion einzuführen, wenn die Kontrolle zufällig verloren geht.
Serverseitiges Testen ist jedoch nicht so einfach.
Hier müssen Sie:
1. Erstellen Sie Ihr Experiment in Convert Experiences
2. Entwickeln und implementieren Sie alle Variationen Ihres Experiments auf Ihrem Server.
3. Ordnen Sie Ihre auf dem Server bereitgestellten Erfahrungen in Convert Experiences mithilfe von benutzerdefiniertem Code zu (unter Verwendung der ID Ihres Experiments, der IDs der Variationen, die in Ihrem Experimentiertool festgelegt sind, und mehr).
Bei solchen serverseitigen Experimenten muss Ihr Code dem Server mitteilen, welche Variante einem aktuellen Benutzer angezeigt werden soll. Sie könnten Cookies verwenden, um dies zu erleichtern. Um beispielsweise einen serverseitigen A/B-Test mit Convert zu implementieren, müssen Sie ein Cookie mit den folgenden Daten einrichten:
Der Server liest dann Ihr Cookie und
eine Version (und alle nachfolgenden Sessions) entsprechend servieren.
Da Ihr Server bestimmt, welche Version an einen Benutzer gesendet wird, erfolgt das Targeting auf dem Server (und nicht innerhalb des Browsers wie bei clientseitigen Tests). Ihre Testpräzision hängt davon ab, wie gut Sie Ihre Targeting-Bedingungen auf Ihrem Server codieren können. Mit clientseitigem Testen können Sie Ihr Publikum jedoch mit all Ihren Erfahrungen gezielt ansprechen.
Außerdem können serverseitige Tests in einem Multi-Server-Setup komplexer werden und auch, wenn ein CDN integriert werden muss.
4. Führen Sie das Experiment durch.
5. Rollen Sie die Gewinnerversion aus und die Verlierer zurück.
Möglicherweise müssen Sie auch Ihre Server bereinigen und den endgültigen Rollout/Rollback veröffentlichen.
Wie Sie sehen können, ist der Lebenszyklus eines serverseitigen Experiments im Gegensatz zu einem clientseitigen Experiment lang und komplex. Aus diesem Grund bedarf es einiger Überlegung, serverseitige Tests durchzuführen.
Im Allgemeinen würden Sie kein serverseitiges Experiment durchführen, wenn es ein clientseitiges tun würde …
Selbst die Ausführung eines einzigen serverseitigen Experiments ist eine Herausforderung, da die Entwicklung und Einführung ein ressourcenintensiverer und zeitaufwändigerer Prozess ist.
Wenn Sie außerdem serverseitige Tests verwenden, um Änderungen zu testen, die clientseitig leicht validiert werden können, wird es schwierig sein, eine gute Testgeschwindigkeit und ein robustes Experimentierprogramm zu erreichen.
Wenn Sie sich für solche Experimente für serverseitige Experimente entscheiden, wenn Sie einige großartige clientseitige A/B-Testtools haben, mit denen Sie sie flimmerfrei ausführen können, ohne Ihre SEO oder Geschwindigkeit zu beeinträchtigen, verspricht dies nicht die beste Nutzung Ihrer Tests Bandbreite.
Serverseitige Experimente sollten nur dann bevorzugt werden, wenn sie starke Argumente für die gegebene Hypothese liefern. Und sie tun dies einige Male, weil viele Experimente, die sich auf die Kennzahlen eines Unternehmens auswirken, nur auf der Serverseite stattfinden können.
Sagen Sie uns also … haben Sie serverseitige Tests durchgeführt? Wenn ja, was war der schwierigste Teil des Prozesses? Oh, und wenn Sie einen serverseitigen A/B-Test durchführen möchten, sehen Sie sich Convert an (es ist 15 Tage lang kostenlos!)