CrowdHandler est une question d'équité, et dans la grande majorité des cas, vous gérerez une file d'attente selon le principe du premier entré, premier sorti. C'est pourquoi nous prenons très au sérieux les rapports de "régression de la file d'attente" (les utilisateurs signalant que leur position dans la file d'attente "recule"). Nous effectuons constamment des tests fonctionnels pour nous assurer que les positions dans la file d'attente vont uniquement dans la bonne direction. Toutefois, dans certaines circonstances, un utilisateur peut signaler que son numéro est revenu en arrière. Cet article décrit les raisons les plus courantes. Nous examinerons les rapports individuels de régression de la file d'attente lorsqu'ils sont accompagnés d'un jeton, mais dans tous les cas que nous avons examinés jusqu'à présent, il s'agissait de l'une des causes suivantes :


Comprendre la rotation des jetons

Les utilisateurs de la file d'attente sont anonymes. Nous reconnaissons la session d'un utilisateur dans la file d'attente ou sur votre site en lui envoyant un jeton généré de manière aléatoire lors de sa première connexion. L'utilisateur utilise des cookies et/ou un stockage local pour représenter le jeton chaque fois qu'il demande une mise à jour de sa position dans la file d'attente ou qu'il accède à une URL sur votre site. Cela fonctionne comme n'importe quelle autre session web.


Une fois qu'une file d'attente est active, sauf dans des cas particuliers tels que les codes de priorité ou la priorisation IP, le jeton est délivré avec une position à l'arrière de la file d'attente, c'est-à-dire avec un numéro élevé. Si un utilisateur voit sa position dans la file d'attente passer d'un numéro bas à un numéro élevé, cela signifie très certainement qu'il a reçu un nouveau jeton, c'est-à-dire qu'il a perdu son jeton original. Par conséquent, si un utilisateur signale que son numéro est revenu en arrière, la question est de savoir comment il a perdu son jeton original. Il s'agit très certainement de l'une des explications suivantes :


Délais de session

Une fois qu'un jeton a rempli sa fonction, il est finalement mis au rebut. Mais comment savoir si un jeton n'est plus nécessaire ? Comme toutes les autres applications web, nous utilisons le concept de délai d'expiration de la session. Cela signifie que nous conservons la session pendant un certain temps à chaque fois que l'utilisateur se connecte. La valeur par défaut est de 15 minutes, mais vous pouvez la définir dans les paramètres de votre domaine. Chaque fois que l'utilisateur vérifie sa position dans la salle d'attente (ce qui est automatique, toutes les minutes), la durée de vie de la session est prolongée d'autant. Lorsque l'utilisateur se rend sur votre site web et demande à nouveau des URL, la durée de la session est prolongée. Mais si l'utilisateur cesse de se connecter à la salle d'attente ou à votre site web après le délai d'expiration de la session, son jeton sera supprimé.

Voici les moments légitimes où une session peut être interrompue :


Dans la salle d'attente
Si vous avez choisi d'autoriser l'expiration des sessions dans la salle d'attente (il s'agit d'une case à cocher sur la page du domaine), un utilisateur peut perdre son jeton s'il met son appareil en veille ou ferme l'onglet de son navigateur pendant une période supérieure à celle spécifiée pour le délai d'expiration du domaine. Si l'utilisateur rouvre son navigateur, un nouveau jeton peut lui être délivré, ce qu'il peut percevoir comme un retour en arrière de son numéro. Par défaut, la salle d'attente avertit l'utilisateur de ce comportement, et ce message est mis à jour automatiquement en fonction des paramètres de votre domaine.

Il vous appartient d'autoriser ou non l'expiration des sessions dans la salle d'attente. Si vous ne le faites pas, un utilisateur peut se reconnecter à sa session même après avoir fermé son navigateur et l'avoir rouvert, pendant une période pouvant aller jusqu'à 24 heures. Pourquoi autoriser l'expiration des sessions en salle d'attente ? Cela permet de raccourcir les files d'attente, c'est donc à vous de déterminer le comportement approprié pour votre file d'attente.

Sur votre site
Si l'utilisateur n'est pas attentif, il peut être transféré sur votre site, mais il ne peut cliquer sur aucune page pendant une durée supérieure à celle spécifiée par le délai d'attente du domaine. Lorsqu'il clique sur un lien, un nouveau jeton lui est attribué et il peut être renvoyé dans la file d'attente. Il se peut qu'il signale que sa position dans la file d'attente a reculé, parce qu'il se souvient avoir vu une position inférieure avant d'être transféré sur le site.


L'éclatement de la caisse

CrowdHandler dispose d'une fonctionnalité qui permet de détruire les tokens une fois que l'utilisateur a atteint une page d'objectif, généralement une sorte de confirmation de paiement. Cette fonctionnalité est souvent utilisée lorsque la file d'attente concerne un stock limité. Elle est conçue pour empêcher les utilisateurs de profiter de leur position dans la file d'attente pour commander plusieurs fois.

L'expérience typique de l'utilisateur est que la page de confirmation se charge avec succès, mais lorsqu'il clique sur d'autres liens déclenchant une salle d'attente, l'utilisateur reçoit un nouveau jeton et se retrouve donc à la fin de la file d'attente.
Cependant, nous avons vu des utilisateurs rapporter ce comportement voulu comme étant simplement un "retour en arrière dans la file d'attente".

Questions d'intégration

Si vous écrivez votre propre intégration personnalisée, il vous incombe de suivre le jeton des utilisateurs qui accèdent à votre site en émettant un cookie ou en utilisant le stockage de session. Il convient de faire preuve de prudence à cet égard, en particulier au premier point de transfert. Si vous définissez le cookie de manière incorrecte, ou si vous ne parvenez pas à définir le cookie sur la première page visitée par l'utilisateur, ce dernier ne repré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 se charger avant d'être renvoyé dans la salle d'attente, et il est donc probable qu'il signale ce problème comme une régression de la file d'attente. Les causes courantes de ce problème sont les suivantes

1. Diriger les utilisateurs vers des pages qui ne contiennent pas de code d'intégration CrowdHandler.
2. Problèmes généraux liés à l'installation et à l'obtention de cookies

3. Erreurs générales sur les pages d'atterrissage empêchant le code d'intégration de CrowdHandler de fonctionner.
4. Utilisateurs arrivant sur le site via des parcours inattendus et non protégés, par exemple des courriels de réinitialisation de mot de passe.


Pour en savoir plus, consultez nos conseils de dépannage pour l'intégration personnalisée.