Régression dans la file d'attente. Causes courantes du « recul » des utilisateurs dans la file d'attente.
CrowdHandler est axé sur l'équité, et dans la grande majorité des cas, vous gérerez une file d'attente selon le principe « premier entré, premier sorti ». C'est pourquoi nous prenons très au sérieux les signalements de « régression de la file d'attente » (utilisateurs signalant que leur position dans la file « recule »). Nous effectuons en permanence des tests fonctionnels pour nous assurer que les positions dans la file d’attente évoluent uniquement dans le bon sens. Il existe toutefois certaines circonstances dans lesquelles un utilisateur peut signaler que son numéro recule. Cet article décrit les causes les plus courantes. Nous examinons chaque signalement de régression de la file d’attente accompagné d’un jeton, mais dans tous les cas que nous avons étudiés à ce jour, la cause était l’une des suivantes :
Understanding token rotation
Users in the queue are anonymous. We recognize a user's session in the queue, or on your site, by sending them a randomly generated token when they first connect. The user uses cookies and/or local storage to represent the token each time they request an update on their queue position, or access a URL on your site. This works much as any other web session.
Une fois qu'une file d'attente est active, sauf cas particuliers tels que les codes de priorité ou la priorisation par adresse IP, le jeton est attribué en fin de file d'attente, c'est-à-dire avec un numéro élevé. Si un utilisateur constate que sa position dans la file d'attente passe d'un numéro bas à un numéro élevé, cela signifie presque à coup sûr qu'un nouveau jeton lui a été attribué, ce qui implique qu'il a perdu son jeton d'origine. Ainsi, si un utilisateur signale que son numéro recule, la question est de savoir comment il a perdu son jeton d'origine. L'une des explications suivantes s'applique presque à coup sûr :
Session Timeouts
Once a token has served its useful purpose, it is ultimately discarded. But how do we know when a token is no longer required? Like all other web applications, we use the concept of a session timeout. That means that we hold the session for a length of time each time the user connects with us. The default is 20 minutes, but you can set this in your domain settings. Each time the user checks their position in the waiting room (which is automatic, every minute) the life of the session is extended for that period of time. When the user gets onto your website and requests URLs, the length of the session is extended. But if the user stops connecting with the waiting room, or your website, after the session timeout, their token will be discarded.
Voici les cas légitimes dans lesquels une session peut expirer :
In the waiting room If you have opted to allow sessions to expire in the waiting room (this is a checkbox setting on the domain page) then a user may lose their token if they allow their device to go to sleep, or close their browser tab for more than the period of time specified for the domain timeout. If the user re-opens their browser they may be issued a new token, and they may perceive this as their number going backwards. By default, the waiting room warns the user about this behavior, and this messaging is updated automatically based upon your domain settings.
C'est à vous de décider si vous souhaitez ou non que les sessions expirent dans la salle d'attente. Si vous ne le faites pas, un utilisateur pourra se reconnecter à sa session même après avoir fermé puis rouvert son navigateur, et ce pendant 24 heures maximum. Pourquoi autoriseriez-vous les sessions de la salle d'attente à expirer ? Cela permet de réduire les files d'attente ; c'est donc à vous de déterminer le comportement le plus adapté à votre file d'attente.
Sur votre site Si l'utilisateur n'est pas attentif, il peut être redirigé vers votre site, mais il se peut qu'il ne clique sur aucune page pendant une durée supérieure au délai d'expiration du domaine. Lorsqu'il cliquera ensuite sur un lien, un nouveau jeton lui sera attribué et il pourra être renvoyé dans la file d'attente. Il peut avoir l'impression que sa position dans la file d'attente recule, car il se souvient avoir vu une position inférieure avant d'être redirigé vers le site.
Checkout Busting
CrowdHandler dispose d'une fonctionnalité permettant de supprimer les jetons dès qu'un utilisateur a accédé à une page de finalisation, généralement une page de confirmation de commande. Cette fonctionnalité est souvent utilisée lorsque la file d'attente concerne l'accès à un stock limité. Elle est conçue pour empêcher les utilisateurs de profiter de leur position dans la file d'attente pour passer plusieurs commandes.
L'expérience utilisateur normale et prévue est la suivante : la page de confirmation se charge correctement, mais lorsque l'utilisateur clique sur d'autres liens déclenchant l'accès à la salle d'attente, un nouveau jeton lui est attribué et il se retrouve donc en fin de file d'attente.
Cependant, nous avons constaté que certains utilisateurs décrivaient ce comportement, pourtant voulu, simplement comme « un retour en arrière dans la file d'attente ».
Integration Issues
Si vous développez votre propre intégration personnalisée, il vous incombe de suivre le jeton des utilisateurs qui accèdent à votre site, soit en créant un cookie, soit en utilisant le stockage de session. Il convient d’y prêter une attention particulière, notamment lors du premier transfert. Si vous configurez le cookie de manière incorrecte, ou si vous ne parvenez pas à le définir correctement sur la première page consultée par l'utilisateur, celui-ci ne présentera pas son jeton lors des clics suivants et se verra donc attribuer un nouveau jeton. Il se peut même qu'il ne voie pas votre première page s'afficher avant d'être renvoyé vers la salle d'attente, et qu'il signale donc probablement ce problème comme une régression de la file d'attente. Les causes courantes de ce problème sont les suivantes :
- Rediriger les utilisateurs vers des pages qui n'exécutent pas le code d'intégration de CrowdHandler.
- Problèmes généraux liés à la configuration et à la récupération des cookies
- Erreurs générales sur les pages de destination empêchant l'exécution du code d'intégration de CrowdHandler.
- Les utilisateurs accédant au site via des parcours inattendus et non sécurisés, par exemple des e-mails de réinitialisation de mot de passe.
Pour en savoir plus, consultez nos conseils de dépannage pour les intégrations personnalisées.