Rückläufigkeit in der Warteschlange. Häufige Ursachen dafür, dass Nutzer in der Warteschlange „rückwärts rücken“.

Bei CrowdHandler dreht sich alles um Fairness, und in den allermeisten Fällen betreiben Sie eine Warteschlange nach dem First-in-First-out-Prinzip. Aus diesem Grund nehmen wir Meldungen über „Warteschlangen-Regression“ (Nutzer, die berichten, dass ihre Position in der Warteschlange „rückwärts geht“) sehr ernst. Wir führen ständig Funktionstests durch, um sicherzustellen, dass sich die Warteschlangenpositionen nur in die richtige Richtung bewegen. Es gibt jedoch einige Umstände, unter denen ein Nutzer melden könnte, dass seine Nummer rückwärts geht. Dieser Artikel beschreibt die häufigsten Gründe dafür. Wir untersuchen einzelne Meldungen über Warteschlangenrückschritte, sofern sie mit einem Token gemeldet werden, aber in jedem bisher untersuchten Fall lag eine der folgenden Ursachen vor:

Token-Rotation verstehen#

Die Nutzer in der Warteschlange sind anonym. Wir erkennen die Sitzung eines Nutzers in der Warteschlange oder auf Ihrer Website, indem wir ihm bei der ersten Verbindung ein zufällig generiertes Token senden. Der Nutzer verwendet Cookies und/oder den lokalen Speicher, um das Token jedes Mal zu speichern, wenn er eine Aktualisierung seiner Position in der Warteschlange anfordert oder auf eine URL auf Ihrer Website zugreift. Dies funktioniert ähnlich wie bei jeder anderen Websitzung.

Sobald eine Warteschlange aktiv ist, wird das Token – abgesehen von Sonderfällen wie Prioritätscodes oder IP-Priorisierung – mit einer Position am Ende der Warteschlange vergeben, d. h. mit einer hohen Nummer. Wenn ein Nutzer beobachtet, dass sich seine Warteschlangenposition von einer niedrigen Nummer zu einer hohen Nummer verschiebt, bedeutet dies mit ziemlicher Sicherheit, dass ihm ein neues Token zugewiesen wurde, was wiederum bedeutet, dass er sein ursprüngliches Token verloren hat. Wenn ein Nutzer also meldet, dass seine Nummer zurückgeht, stellt sich die Frage: Wie hat der Nutzer sein ursprüngliches Token verloren? Es handelt sich mit ziemlicher Sicherheit um eine der folgenden Erklärungen:

Zeitüberschreitungen bei Sitzungen#

Sobald ein Token seinen Zweck erfüllt hat, wird es schließlich verworfen. Aber woher wissen wir, wann ein Token nicht mehr benötigt wird? Wie bei allen anderen Webanwendungen nutzen wir das Konzept eines Session-Timeouts. Das bedeutet, dass wir die Sitzung jedes Mal für eine bestimmte Zeitspanne aufrechterhalten, wenn der Nutzer eine Verbindung zu uns herstellt. Die Standardeinstellung beträgt 20 Minuten, Sie können diesen Wert jedoch in Ihren Domain-Einstellungen anpassen. Jedes Mal, wenn der Nutzer seine Position im Warteraum überprüft (was automatisch jede Minute geschieht), wird die Laufzeit der Sitzung um diesen Zeitraum verlängert. Wenn der Nutzer Ihre Website aufruft und URLs anfordert, wird die Dauer der Sitzung ebenfalls verlängert. Wenn der Nutzer jedoch nach Ablauf des Sitzungszeitlimits keine Verbindung mehr zum Warteraum oder zu Ihrer Website herstellt, wird sein Token verworfen.

In folgenden Fällen kann es zu einem Timeout einer Sitzung kommen:

Im Wartezimmer Wenn Sie festgelegt haben, dass Sitzungen im Wartezimmer ablaufen dürfen (dies ist eine Option auf der Domain-Seite), kann ein Benutzer sein Token verlieren, wenn er sein Gerät in den Ruhezustand versetzt oder den Browser-Tab länger als die für die Domain festgelegte Zeit schliesst. Wenn der Benutzer seinen Browser erneut öffnet, wird ihm möglicherweise ein neues Token zugewiesen, was er als Rückgang seiner Nummer wahrnehmen könnte. Standardmäßig warnt der Warteraum den Nutzer vor diesem Verhalten, und diese Meldung wird automatisch entsprechend Ihren Domäneneinstellungen aktualisiert.

Es liegt ganz bei Ihnen, ob Sie zulassen, dass Sitzungen im Wartezimmer ablaufen oder nicht. Wenn Sie dies nicht tun, kann ein Benutzer seine Sitzung auch nach dem Schließen und erneuten Öffnen des Browsers bis zu 24 Stunden lang wiederherstellen. Warum sollten Sie überhaupt zulassen, dass Sitzungen im Wartezimmer ablaufen? Dies führt zu kürzeren Warteschlangen, daher liegt es an Ihnen, das für Ihre Warteschlange geeignete Verhalten zu ermitteln.

Auf Ihrer Website Wenn der Nutzer nicht aufmerksam ist, wird er zwar auf Ihre Website weitergeleitet, klickt aber möglicherweise länger als die durch das Domain-Timeout festgelegte Zeit nicht auf eine Seite. Sobald er dann auf einen Link klickt, erhält er ein neues Token und wird möglicherweise zurück in die Warteschlange geschickt. Er könnte dies so wahrnehmen, als würde sich seine Position in der Warteschlange verschlechtern, da er sich daran erinnert, vor der Weiterleitung auf die Website eine niedrigere Position gehabt zu haben.

Kassenbetrug#

CrowdHandler verfügt über eine Funktion, mit der Tokens gelöscht werden können, sobald ein Nutzer eine Zielseite erreicht hat – in der Regel handelt es sich dabei um eine Bestätigungsseite für den Bestellvorgang. Diese Funktion wird häufig eingesetzt, wenn die Warteschlange den Zugriff auf begrenzte Lagerbestände regelt. Sie soll verhindern, dass Nutzer ihre Position in der Warteschlange ausnutzen, um mehrere Bestellungen aufzugeben.

Die typische, beabsichtigte Benutzererfahrung ist, dass die Bestätigungsseite erfolgreich geladen wird; wenn der Benutzer jedoch auf andere Links klickt, die den Wartezimmer-Modus auslösen, erhält er ein neues Token und wird somit an das Ende der Warteschlange gestellt.

Wir haben jedoch festgestellt, dass Nutzer dieses beabsichtigte Verhalten einfach als „Rückwärtsbewegung in der Warteschlange“ beschreiben.

Integrationsprobleme#

Wenn Sie eine eigene benutzerdefinierte Integration erstellen, liegt es in Ihrer Verantwortung, das Token der Nutzer, die auf Ihre Website gelangen, durch das Setzen eines Cookies oder mithilfe des Session-Speichers zu verfolgen. Dabei ist besondere Sorgfalt geboten, insbesondere beim ersten Übergabepunkt. Wenn Sie das Cookie falsch setzen oder es nicht erfolgreich auf der ersten Seite setzen, die der Nutzer aufruft, wird der Nutzer sein Token bei nachfolgenden Klicks nicht vorweisen können und erhält daher ein neues Token. Möglicherweise sieht er nicht einmal, wie Ihre erste Seite geladen wird, bevor er zurück in den Warteraum geleitet wird, und wird dies daher wahrscheinlich als Warteschlangen-Regression melden. Häufige Ursachen für dieses Problem sind:

1. Weiterleitung von Benutzern auf Seiten, auf denen kein CrowdHandler-Integrationscode ausgeführt wird.
2. Allgemeine Fragen zum Setzen und Abrufen von Cookies
3. Allgemeine Fehler auf Landingpages, die die Ausführung des CrowdHandler-Integrationscodes verhindern.
4. Benutzer, die über unerwartete und ungeschützte Benutzerpfade auf die Website gelangen, z. B. über E-Mails zur Passwortzurücksetzung.

Weitere Informationen finden Sie in unseren Tipps zur Fehlerbehebung bei benutzerdefinierten Integrationen.