Bei CrowdHandler ist das oft die erste Frage, die uns gestellt wird: „Unterstützt ihr ‚One In, One Out‘?“ Und die Antwort lautet: „Ja, das tun wir … aber für die meisten Nutzer empfehlen wir es nicht.“
Aus Erfahrung wissen wir, dass die einfache Festlegung der richtigen Eingangsrate eine effizientere Methode zur Verkehrssteuerung ist als das „One-In-One-Out“-Prinzip und für die überwiegende Mehrheit unserer Kunden die beste Lösung darstellt.
Leider hören viele Website-Betreiber zwar „Ja, wir unterstützen ‚One In, One Out‘“, verpassen aber den zweiten Teil unseres Ratschlags. Für sie erscheint das Konzept von „One In, One Out“ so logisch, dass sie sich kaum vorstellen können, den Datenverkehr auf andere Weise zu steuern. Also aktivieren sie die „One In, One Out“-Einstellung und schalten die Website live – nur um festzustellen, dass sich Warteschlangen bilden und Nutzer sich über die Wartezeiten beschweren.
Was spricht also gegen das Prinzip „Einer rein, einer raus“?
Das Problem ist, dass die Einfachheit der „One-In-One-Out“-Formel, wie die meisten von uns sie verstehen, nicht der Realität des Website-Traffics und der Nutzerwege entspricht. Der „One-In-One-Out“-Schwellenwert kann sowohl irrelevant als auch problematisch sein.
Irrelevant? Nehmen wir einmal an, Sie haben eine Website mit einer Kapazität von 1.000 Nutzern und lassen pro Minute 100 Nutzer zu. Da Sie wissen, dass die durchschnittliche Nutzungsdauer zehn Minuten beträgt, würden Sie bei einem Kaltstart – also bei 0 Nutzern – erwarten, dass die Kapazitätsgrenze in zehn Minuten erreicht ist. Wenn danach das Prinzip „One In, One Out“ so funktionieren würde, wie viele annehmen, wäre die Gleichung ganz einfach: 1.000/10. Man würde erwarten, dass die erste Gruppe von 100 Nutzern in der 10. Minute die Website verlässt; zu diesem Zeitpunkt lässt man die nächsten 100 Nutzer herein, und so weiter.
Wer im Algebraunterricht gut aufgepasst hat, hat vielleicht bemerkt, dass sich die Variable mit der Kapazität von 1000 inzwischen gegenseitig aufgehoben hat. Man könnte die Zuflussrate einfach auf 100 festlegen, und das hätte genau denselben Effekt.
Allerdings ist das „One-In-One-Out“-Prinzip in diesem Szenario nicht nur irrelevant, sondern sogar problematisch. Denn diese einfache „One-In-One-Out“-Gleichung lässt zudem zwei entscheidende Faktoren außer Acht: Sitzungszeitüberschreitungen und die Kapazität an den Kassen.
Problem Nr. 1: Zeitüberschreitungen bei Sitzungen
OK, die durchschnittliche Nutzerreise dauert vielleicht zehn Minuten. Aber nicht wenige Nutzer schließen den Bestellvorgang gar nicht ab – und selbst wenn sie es tun, erfahren Sie das möglicherweise nicht (es sei denn, Sie haben eine Funktion zur Erkennung abgebrochener Bestellungen eingerichtet). Anstatt also Nutzersitzungen endlos laufen zu lassen und damit möglicherweise die Kapazität dauerhaft zu beeinträchtigen, lassen wir sie nach einer bestimmten Zeit ablaufen.
Das standardmäßige Zeitlimit für Sitzungen bei CrowdHandler beträgt 15 Minuten. Das bedeutet, dass der Platz jedes Nutzers nach seiner letzten Aktivität 15 Minuten lang freigehalten wird. So können Nutzer während ihres Besuchs eine kurze Pause einlegen, eine dringende E-Mail beantworten oder auf einer anderen Website einen schnellen Preisvergleich durchführen und anschließend zur Warteschlange zurückkehren, ohne von vorne beginnen zu müssen.
Berücksichtigt man diese 15 Minuten, beträgt die tatsächliche durchschnittliche Nutzungsdauer 25 Minuten. Um auf unsere Gleichung zurückzukommen: 1000/25 bedeutet, dass die effektive Rate bei 1000 Nutzern unter Einhaltung des „One-In-One-Out“-Prinzips nur 40 Ein- und Ausgänge pro Minute beträgt. Nach unserer ursprünglichen Berechnung würden wir erwarten, dass eine Warteschlange mit 3000 Personen nach 30 Minuten leer ist, bei einer medianen Wartezeit von 15 Minuten. Berücksichtigt man jedoch das Ablauf der Sitzung, verlassen die ersten 1.000 Nutzer die Warteschlange bereits in den ersten 10 Minuten, und die verbleibenden 2.000 Nutzer werden mit einer Rate von 40 pro Minute abgefertigt, was 50 Minuten dauert. Somit dauert es tatsächlich eine Stunde, bis die gesamte Warteschlange leer ist, bei einer medianen Wartezeit von 30 Minuten. Das ist doppelt so lang.
„Ah!“, denken Sie. „Aber ich werde die ersten 1.000 Nutzer nicht mit einer Rate von 100 pro Minute hereinlassen, sondern die Rate maximieren und mich ausschließlich auf das ‚One-In-One-Out‘-Prinzip verlassen, um die ersten 1.000 Nutzer bereits in der ersten Minute hereinzulassen und so meine Kapazität zu maximieren.“ Nun, das ist aus zwei Gründen eine schlechte Idee, aber der erste ist folgender: Nach dem „One-In-One-Out“-Prinzip werden in unserem Modellszenario die verbleibenden 2.000 Nutzer in der Warteschlange 25 Minuten lang überhaupt nicht vorankommen, sobald die ersten ausgecheckten Sitzungen ablaufen. Diese Nutzer sehen eine Warteschlangenposition, die sich nicht bewegt, und eine furchtbare geschätzte Wartezeit. Genau die Art von Nutzererfahrung, die Sie vermeiden wollen. Darüber hinaus werden Sie auf lange Sicht tatsächlich weniger Checkouts haben – zusätzlich zu der hartnäckigen Warteschlange –, es sei denn, Sie berücksichtigen das Ablaufen der Sitzungen sorgfältig in Ihrem „One In, One Out“-Schwellenwert.
Problem Nr. 2: Kapazität an den Kassen
Dieses Problem entsteht aufgrund eines weiteren Missverständnisses: der Festlegung der „One-In, One-Out“-Einstellungen auf der Grundlage von Lasttestwerten.
Bei Lasttests wird der Datenverkehr in der Regel schrittweise gesteigert (genau wie bei der Festlegung einer Rate im CrowdHandler!) und oft der alltägliche Datenverkehr nachgebildet, wobei davon ausgegangen wird, dass mehr Besucher nur stöbern als tatsächlich kaufen. Bei einer stark frequentierten Produkteinführung oder einem „Drop“-Szenario ist das Verhältnis der Kaufabschlüsse jedoch deutlich höher als im normalen Datenverkehr. Sie sollten davon ausgehen, dass die meisten Nutzer, die Sie zu Beginn einer User Journey einbinden, den Kauf so früh wie möglich abschließen werden.
In vielerlei Hinsicht spielt es keine Rolle, wie viele gleichzeitige Nutzer Ihre Website Ihrer Meinung nach bewältigen kann. Entscheidend ist vielmehr, wie viele Kaufvorgänge oder Transaktionen pro Minute verarbeitet werden können. Zwar können viele Websites 1.000 gleichzeitige Nutzer bewältigen, doch nur sehr wenige sind in der Lage, 1.000 Kaufvorgänge pro Minute zu verarbeiten. Wenn Sie die „One-In, One-Out“-Einstellungen auf die Kennzahlen für gleichzeitige Nutzer stützen, wird der Anstieg der tatsächlichen Transaktionen, der während eines Drop oder einer Produkteinführung auftritt, nicht berücksichtigt. Es ist daher wahrscheinlicher, dass die Website unter der Flut von Checkouts zusammenbricht, die in Minute 10 unseres Modell-Szenarios auftritt, wenn Sie in Minute 1 bereits 1.000 Nutzer zulassen.
Eine anschauliche Analogie ist ein Ladengeschäft mit einer Kapazität von 1.000 Personen, aber nur 10 Kassen. Das Geschäft kann zwar problemlos 1.000 Kunden aufnehmen, aber pro Minute nur 10 Bestellungen effizient abwickeln. Würden 1.000 Kunden auf einmal hereingelassen, käme es lediglich zu langen Warteschlangen frustrierter Menschen, in denen es nicht vorangeht, da sich die Transaktionen stauen. Das Gleiche gilt für den Online-Handel, nur dass hier nicht nur das Risiko langer Warteschlangen besteht, sondern auch das von Serverausfällen.
So macht man es richtig
Eine Möglichkeit, die Probleme mit „One In, One Out“ zu mindern, bestünde darin, während der Einrichtung einige komplexe Berechnungen durchzuführen. Dazu könnten beispielsweise folgende Maßnahmen gehören: die Erhöhung der „One In, One Out“-Kapazität, die Verkürzung der Zeitüberschreitungswerte für Sitzungen, die Berechnung des Verhältnisses von Sitzungen zu Checkouts, die Sicherstellung, dass die Option „Sitzung beim Checkout beenden“ aktiviert ist, sowie die Ermittlung der tatsächlichen Dauer der Nutzerwege.
Tatsächlich hat es uns so sehr betrübt, mitanzusehen, wie Kunden ihre On-Sales-Verkäufe durch falsche „One-In, One-Out“-Einstellungen sabotierten, dass wir eine Prüffunktion hinzugefügt haben, die diese Berechnungen durchführt und ihnen Empfehlungen anzeigt:
Für manche Kunden – nämlich diejenigen, für die die Anzahl der gleichzeitigen Sitzungen tatsächlich eine entscheidende Anwendungskennzahl darstellt, die sicher sind, alle Ergebnisse ihrer Lasttests zu verstehen, und die ein klares Verständnis der optimalen Einstellungen für Sitzungszeitüberschreitungen und deren Auswirkungen auf den „One-In-One-Out“-Schwellenwert haben – können diese Berechnungen sinnvoll sein. Wenn Sie zu diesen Kunden gehören, ziehen wir den Hut vor Ihnen.
Für die meisten Kunden ist die Antwort jedoch viel einfacher: Vergessen Sie komplizierte Berechnungen auf der Grundlage theoretischer Grenzwerte und unzuverlässiger Lasttests und konzentrieren Sie sich stattdessen auf die Kennzahlen, die sich tatsächlich auf die Benutzererfahrung auswirken. Der Erfolg beruht darauf, Ihren nachgewiesenen Spitzendurchsatz zu kennen – und nicht auf hypothetischen Zahlen zu gleichzeitigen Nutzern.
Für die meisten Websites bedeutet dies, die Zugangsrate auf einen Wert einzustellen, der etwas über Ihrer maximal tragbaren Checkout-Rate liegt. (Ein guter Ausgangspunkt ist es, die maximale Anzahl der Bestellungen, die Sie in einem erfolgreichen einstündigen Zeitraum abgewickelt haben, durch 60 zu teilen und die Rate dann etwas höher als diesen Wert festzulegen.) Dies ermöglicht einen guten Durchfluss von Besuchern auf Ihrer Website.
Beginnen Sie vorsichtig und beobachten Sie anschließend die Leistung genau. Wenn die Warteschlange immer länger wird, die Website aber weiterhin einwandfrei funktioniert, können Sie die Rate jederzeit erhöhen; die „Autotune“-Funktion von CrowdHandler kann Ihnen dabei helfen.
Zusammenfassend lässt sich sagen: Konzentrieren Sie sich auf bewährte Leistung
Als Warteschlangenstrategie mag dies logisch klingen, doch ein vereinfachtes Verständnis des „One-In-One-Out“-Prinzips lässt die realen Faktoren bei der Umsetzung außer Acht. Dies führt häufig zu Problemen wie langen Wartezeiten, verärgerten Kunden und fehlgeschlagenen Kaufvorgängen, da die Berechnungen auf hypothetischen Annahmen beruhen: unzuverlässigen oder unrealistischen Kennzahlen.
Auch wenn wir diesen Ansatz befürworten, lautet unser Rat daher: Legen Sie keinen „One-In-One-Out“-Schwellenwert fest, ohne genau zu verstehen, was dieser bedeutet, und konzentrieren Sie sich eher auf Ihre Abschlussraten als auf Kennzahlen zu gleichzeitigen Nutzern. Indem Sie sich auf nachgewiesene Leistung und die tatsächlichen Grenzen Ihrer Website konzentrieren, verbessern Sie die Nutzererfahrung für alle.