Wenn Sie CrowdHandler installieren und einen Warteraum einrichten, möchten wir, dass Sie es gleich beim ersten Mal richtig machen.
Wir freuen uns, berichten zu können, dass viele Nutzer CrowdHandler mitten in einer Auslastungskrise direkt in der Produktionsumgebung installiert haben – und dass das Tool ihnen damit aus der Patsche geholfen hat.
Aber selbst bei bestem Willen … passieren Fehler. Deshalb hier ein kleiner Hinweis: Sieben Fallstricke, in die Kunden unserer Erfahrung nach häufig tappen – mit Tipps, wie man sie vermeiden kann, um eine reibungslosere Einrichtung zu gewährleisten.
Glaubst du, du bist vorbereitet...?
Nehmen wir einmal an, Sie führen ein neues Produkt, eine neue Dienstleistung oder eine neue Aktion ein.
Sie wissen, dass auf Ihrer Website wahrscheinlich Probleme mit der Auslastung oder der Last auftreten werden. Vielleicht rechnen Sie mit einer hohen Auslastung, weil Sie ein äußerst knappes Produkt anbieten, oder mit einem Problem durch hohe Last, weil Sie wissen, dass eine noch nie dagewesene Anzahl von Besuchern gleichzeitig auf Ihre Website zugreifen wird.
Sie wissen also, dass Sie einen Warteraum brauchen werden. Tatsächlich bauen Sie den Warteraum von Anfang an mit ein. Er wird Teil der Benutzererfahrung sein. Sie wissen genau, wie er funktionieren wird und wie die Warteschlange in die Lösung integriert wird, die Sie entwickeln. Er wird umfassend getestet werden. Es kann unmöglich schiefgehen.
...Gibt es das?
Um ganz sicherzugehen, wollen wir uns die häufigsten Probleme bei der benutzerdefinierten Integration von CrowdHandler ansehen und klären, wie man sie vermeiden kann.
1. Begrenzte Funktionsprüfung
Häufig beobachten wir, dass Kunden ihre sorgfältig ausgearbeitete, maßgeschneiderte Integration mit einer kleinen Gruppe interner Beteiligter testen: fünf oder zehn Personen, die einige Standard-Benutzerabläufe durchlaufen und überprüfen, ob die Benutzer korrekt in die Warteschlange gestellt und auf die Website weitergeleitet werden.
Allerdings vermittelt diese Art von Tests kein realistisches Bild davon, wie die Website bei einer aktiven Warteschlange funktioniert. Denn sobald diese wenigen Nutzer den Warteschlangenprozess durchlaufen haben und auf die Website zugelassen wurden, gibt es keine Warteschlange mehr. Viele Integrationsprobleme treten jedoch erst dann zutage, wenn die Warteschlange auf einer stark frequentierten Website aktiviert wird.
Beim Testen müssen Sie unbedingt überprüfen, ob die Nutzer ihren „Promoted“-Status (der in der Regel durch ein CrowdHandler-Cookie gekennzeichnet ist) auf der Zielseite beibehalten. Anstatt Ihre Testnutzer einfach aus dem Warteraum auf die Seite weiterzuleiten, sollten Sie testen, ob die CrowdHandler-Sitzung bestehen bleibt.
Sie sollten also zumindest Folgendes tun:
- Stellen Sie die Rate auf 0 ein, wodurch die Warteschlange aktiviert wird.
- Die Rate vorübergehend erhöhen, damit einige Nutzer durchkommen können
- Setzen Sie die Rate wieder auf 0 zurück (wodurch erneut eine aktive Warteschlange erstellt wird)
- Überprüfen Sie anschließend, ob die Benutzer, die auf die Website umgestellt wurden, weiterhin funktionale Benutzerabläufe durchlaufen können.
Es ist unerlässlich, die Rate wieder auf 0 zurückzusetzen, nachdem einige Benutzer durchgelassen wurden, denn wenn zu diesem Zeitpunkt die CrowdHandler-Sitzung eines Benutzers unterbrochen wird, wird dieser zurück in die Warteschlange geleitet. Wenn Sie die Rate jedoch hoch halten, werden diese Benutzer nicht in die Warteschlange geleitet, und Sie werden nicht bemerken, dass Ihre Integration ein Problem aufweist.
2. Die Produktionsumgebung entspricht nicht der Entwicklungsumgebung
Klar, jeder würde gerne behaupten, dass seine Staging- und Entwicklungsumgebungen die Produktionsumgebung originalgetreu widerspiegeln … aber unserer Erfahrung nach ist das selten der Fall.
Eines der häufigsten Probleme, das wir beobachten, ist, dass ein Kunde Tage oder sogar Wochen damit verbringt, in seiner Entwicklungs- oder Staging-Umgebung zu testen, dann aber eine Stunde vor der Schaltung dieselbe Konfiguration auf die Produktionsumgebung anwendet und erwartet, dass alles genauso funktioniert wie zuvor. Wenn er merkt, dass dies nicht der Fall ist, ist es bereits zu spät.
Das liegt daran, dass genau die Unterschiede zwischen der Live- und der Entwicklungsumgebung häufig zu Problemen im Warteraum führen. Viele der Sicherheitsmaßnahmen, die auf der Produktionsumgebung eingerichtet sein müssen – zum Beispiel die Einbindung der Website in ein CDN, der Betrieb einer Firewall oder Bot-Schutz – sind in der Staging-Umgebung in der Regel nicht erforderlich, sodass sich das Netzwerk-Routing oder die Konfiguration teilweise unterscheiden können.
Achten Sie also unbedingt auf Unterschiede bei:
- Netzwerk-Routing (insbesondere bei CDN- und DNS-Implementierungen)
- Bot-Schutz oder Firewall-Infrastruktur oder Konfigurationen, die nicht dem Live-Betrieb entsprechen
Um sicherzustellen, dass Sie in einer späten Phase nicht auf größere Probleme stoßen, empfehlen wir, die Live-Schaltung in der Produktionsumgebung mindestens 24 Stunden vor dem geplanten Zeitpunkt durchzuführen. Sobald Sie die Funktionstests in einer Entwicklungs- oder Staging-Umgebung abgeschlossen haben, beschränken Sie diese auf einen Bereich der Produktionsumgebung, der für Sie kein Problem darstellt – beispielsweise ein bestimmtes geschütztes URL-Muster, das echte Nutzer wahrscheinlich nicht beeinträchtigt – und führen Sie einige Tests in kleinem Umfang in der Live-Umgebung durch. Sie könnten sogar mitten in der Nacht einen kleinen Test in der Produktionsumgebung durchführen.
Aber... warte damit nicht bis zur letzten Minute.
3. IP-Sperrung
Bei benutzerdefinierten Integrationen wird die IP-Adresse des Nutzers an die CrowdHandler-API gesendet, damit wir überprüfen können, ob sie nicht auf einer Sperrliste steht. Es kommt jedoch nicht selten vor, dass Websites so eingerichtet sind, dass sie uns versehentlich die IP-Adresse eines Proxy-Servers anstelle der IP-Adresse des Nutzers übermitteln … was fälschlicherweise die IP-Sperre von CrowdHandler auslöst.
Das ist in der Regel nur dann ein Problem, wenn Sie Ihre Integration selbst einrichten (wenn Sie eine unserer Integrationen nutzen, haben wir uns bereits um alles gekümmert), aber es kann leicht zu Fehlern kommen, seien Sie also vorsichtig.
Weiterlesen: Fehlerbehebung bei benutzerdefinierten API-Integrationen
4. Die Rate zu hoch ansetzen
Die meisten Menschen glauben, dass ihre Website weitaus mehr Traffic bewältigen kann, als dies tatsächlich der Fall ist. Aus diesem Grund legen Kunden unserer Erfahrung nach die Eingangsrate oft viel zu hoch fest.
Wenn dies Ihr erster Live-Start ist, wissen Sie nicht, mit wie viel Traffic Sie rechnen müssen, und – ehrlich gesagt – wissen Sie auch noch nicht, wie viel Traffic Sie bewältigen können. Lassen Sie sich nicht davon täuschen, dass Ihre Website Tausende von Anfragen pro Sekunde verarbeiten kann; dies lässt sich nicht auf die Anzahl der tatsächlichen Menschen übertragen, die Sie aus Ihrer Warteschlange hereinlassen können.
Websites, die problemlos mehr als 60 Nutzer pro Minute (d. h. eine neue Sitzung pro Sekunde) bewältigen können, sind ziemlich selten. Daher sollten Sie wahrscheinlich mit 30 oder weniger beginnen, es sei denn, Sie kennen das Auslastungsprofil Ihrer Website genau.
Kurz gesagt: Es ist besser, mit einer niedrigen Rate anzufangen. Wenn man dann positiv überrascht ist, lässt sich die Rate leicht erhöhen. Eine nicht mehr funktionierende Anwendung wiederherzustellen, kann schwieriger sein.
Siehe auch: Warum funktionieren Lasttests nicht?
5. Ausgeschlossene URLs
Wenn Sie die DNS-Integration, die CDN-Integration oder Ihre eigene serverseitige Integration mit einem Front-Controller verwenden, wird jede einzelne URL überprüft, um die Nutzer in die Warteschlange zu leiten.
Bestimmte URLs werden jedoch wahrscheinlich von Anwendungen von Drittanbietern aufgerufen, die nicht an eine Warteschlange gesendet werden sollten – daher müssen diese URLs ausgeschlossen werden.
Ein offensichtliches Beispiel hierfür ist ein Zahlungsgateway. Ein Nutzer schließt eine Transaktion beispielsweise über PayPal oder Stripe ab, und das Zahlungsgateway sendet eine Bestellbestätigung zurück, indem es eine URL auf Ihrem Server aufruft. Wenn Sie diese URL nicht ausgeschlossen haben, greift die CrowdHandler-Integration (die, wie Sie sich erinnern, jede einzelne URL überprüft) ein und meldet, dass das Zahlungsgateway in eine Warteschlange gestellt werden muss. Die Bestellung wird niemals abgeschlossen, und der Nutzer kann den Bestellvorgang nicht abschließen.
Dies ist ein weiterer Grund, bereits rechtzeitig umfassende Funktionstests durchzuführen. Setzen Sie Ihre Rate auf 0, um sicherzustellen, dass die Warteschlange aktiv ist, und testen Sie vollständige Nutzerabläufe, einschließlich der Anwendungen von Drittanbietern, die möglicherweise auf Ihre geschützte Domain angewiesen sind.
Weiterlesen: Fehlerbehebung bei benutzerdefinierten API-Integrationen
6. Die Vorlage zu stark vereinfachen
Einer der Hauptgründe, warum Nutzer CrowdHandler gerne verwenden, sind die benutzerdefinierten Vorlagen, und wir haben gesehen, dass Nutzer mit der Freiheit, die diese Vorlagen bieten, wirklich kreative und spannende Dinge auf die Beine stellen.
Die Standardvorlage – auch „Startvorlage“ genannt – enthält verschiedene Meldungen und Zustände für mehrere Szenarien, von denen einige offensichtlicher sind als andere. Dazu gehören beispielsweise, dass der Raum noch nicht geöffnet ist, dass der Raum voll besetzt ist, dass der Nutzer aufgrund verdächtigen Verhaltens gesperrt wurde und dass dem Nutzer noch keine Position in der Warteschlange zugewiesen wurde.
Wenn Nutzer die Vorlage jedoch anpassen, berücksichtigen sie häufig nur den „Happy Path“ und ignorieren – oder, schlimmer noch, entfernen vollständig – einige der weniger offensichtlichen Fehlermeldungen und Zustände. Wenn ein Nutzer dann auf eine dieser Situationen stößt, wird ihm eine weitgehend unhilfreiche Benutzeroberfläche angezeigt.
Es ist wichtig zu verstehen, dass Nutzer Feedback sehen müssen, auch wenn dieses Feedback ihnen etwas mitteilt, das Sie nicht als positiv empfinden – wie beispielsweise ihre aktuelle Position, den Fortschrittsbalken oder die geschätzte Wartezeit. Unserer Erfahrung nach ist es kontraproduktiv, diese Elemente auszublenden. Ohne sie verhalten sich Nutzer unvorhersehbar oder reagieren negativ auf den Mangel an Informationen. Sie könnten Umsätze verlieren oder sogar Ihrem Ruf schaden.
7. Festlegen extremer Sitzungszeitüberschreitungen
Jede Webanwendung nutzt das Konzept des Sitzungszeitlimits, und CrowdHandler bildet da keine Ausnahme.
Die Standardeinstellung von CrowdHandler beträgt 15 Minuten, was eine relativ übliche Sitzungsdauer für eine Webanwendung ist. Das bedeutet lediglich, dass CrowdHandler, sobald ein Benutzer auf etwas geklickt hat, für die nächsten 15 Minuten davon ausgeht, dass er noch auf der Seite ist.
Der Nutzer hält seine Sitzung aufrecht, indem er auf Seiten klickt, doch dank eines Zeitlimits von 15 Minuten kann er sich 15 Minuten Zeit nehmen, um sich eine Tasse Kaffee zu holen, und zurückkommen, ohne wieder in die Warteschlange zu geraten. Wenn er erneut klickt, wird die Sitzung wiederbelebt, sodass er noch reichlich Zeit zum Stöbern hat.
Man sollte bedenken, dass die Anzahl der Sitzungen nur ein sehr vereinfachter Anhaltspunkt für die Auslastung Ihrer App ist. Wenn Nutzer gerade unterwegs sind, um sich einen Kaffee zu kochen, belasten sie Ihre Anwendung nicht.
Wir stellen jedoch fest, dass einige Kunden die Sitzungsdauer entweder viel zu kurz oder viel zu lang einstellen.
So oder so ist es kontraproduktiv. Ist der Wert zu niedrig, schickst du die Nutzer möglicherweise mitten während ihres Besuchs zurück in die Warteschlange. Ist er zu hoch, könntest du es mit einer sehr langen Warteschlange zu tun haben, da die Sitzungen der Nutzer noch lange aktiv bleiben, nachdem sie die Seite verlassen haben.
Weiterlesen: Einer rein, einer raus
Sind Sie bereit, es gleich beim ersten Mal richtig zu machen?
Rechnen Sie mit hohem Andrang oder großer Nachfrage und möchten Sie einen Warteraum einrichten?