Queue Regression. Common causes of users 'going backwards' in the queue.

CrowdHandler is all about fairness, and in the vast majority of cases you will be operating a queue with a first-in, first-out  set-up. For this reason we take reports of 'queue regression' (users reporting their position in the queue 'going backwards') very seriously. We do constant functional testing to ensure that queue positions are only going in the right direction. However there are some circumstances in which a user may report their number going backwards. This article describes the common reasons. We will investigate individual reports of queue regression where reported with a token, but in every case we have investigated to date it has been one the following causes:

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.

Once a queue is active, barring special cases such as Priority codes or IP prioritization, the token is issued with a position at the back of the queue - i.e. with a high number. If a user sees their queue position go from a low number, to a high number, it almost certainly means that they have been issued with a new token, meaning they have lost their original token. So if a user reports their number going backwards, the question is, how did the user lose their original token? It will almost certainly be one of the following explanations:

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 15 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 reuqets 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.

Here are legitimate times that a session may time out:

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.

It is up to you whether you allow sessions to expire in the waiting room or not. If you don't then a user can reconnect their session even after closing their browser and re-opening it, for up to 24 hours. Why would you allow waiting room sessions to expire at all? It results in shorter queues, so it's up to you to figure out the appropriate behavior for your queue. 

On your site
If the user is not being attentive, they may be passed onto your site, but they may not actually click on any pages for more than the time specified by the domain timeout. Then when they click on a link they will be assigned a new token, and may be sent back to the queue. They may report this as their queue position going backwards, because they recall seeing a lower position before being passed onto the site.

Checkout Busting

CrowdHandler has a feature which allows tokens to be destroyed once a user has reached a goal page, usually some sort of checkout confirmation. This is often used when the queue is for access to limited stock. It is designed to stop users from taking advantage of their queue position to order multiple times. 

The typical, intended, user experience is that the confirmation page loads succesfully, but when clicking on other waiting-room triggering links, the user is issued with a new token and hence placed at the back of the queue. 
However, we have seen users report this intended behavior simply as 'going backwards in the queue'.

Integration Issues

If you are writing your own custom-integration, it is your responsibility to track the token of the users who make it to your site by issuing a cookie, or using session storage. Care needs to be taken over this, especially at the first point of handover. If you set the cookie incorrectly, or if you do not successfully set the cookie on the first page the user hits then the user will not represent their token on subsequent clicks, and will hence be issued a new token. They may not even see your first page load, before being sent back to the waiting room, and will therefore likely report this as queue regression. Common causes of this issue are:

1. Directing users to pages that are not running CrowdHandler integration code.
2. General issues setting and getting cookies

3. General errors on landing pages preventing CrowdHandler integration code from running. 
4. Users arriving on site via unexpected and unprotected user journeys, e.g. password reset emails. 

 
You can find out more in our custom integration trouble-shooting tips.