About the Queue
- The Queuing Module regulates website visitor numbers
- A queue graph displays visitor and queue statistics in 5-minute intervals
- Maximum concurrent sessions can be set to control website traffic
- Session activity is measured through timestamp updates
- Inactive sessions become stale after a set period (default 15 minutes)
- New queue logic (from Release v204) counts all sessions for consistency
- Features include Queue notices, shuffling, and bypass options
- Queue settings can be customized in the Control Panel for optimal performance
You can find a quick preview of the Queuing module on the landing page when entering the Peppered Dashboard:
For a complete overview, select Go to Queueing Module or Go to Website > Queueing or follow the link in the queue preview.
The Queue Graph
At the top of the module, you will see a graph with several bars. Each bar represents a moment in time, spaced 5 minutes apart. A new snapshot is taken every 5 minutes.
Within each bar, you can see the number of visitors currently on the website (green) and the number of people in the queue (yellow, if the queue is active).
As of Release 204, hovering over a bar reveals the maximum concurrent sessions at that moment, also indicated by a thin line above the bar.
When the number of visitors exceeds the allowed maximum, a queue becomes active.
When will the Queue become active?
The Maximum concurrent sessions setting determines when the Queue will be activated.
This feature allows you to set the number of visitors permitted on the website simultaneously. You can choose any number, typically between 0 and 1,500, depending on the nature of the expected visits.
- For busy pre-sales, you might want to start small, giving all systems (including ticketing) a chance to gradually come up to speed. It is risky to allow many sessions at once at the exact start of the presale.
- If you expect high traffic without a pre-sale, for example, after a newsletter or other public exposure - visitors will likely trickle in more organically and just browse the website. Set a high maximum to allow all these visitors on your website. Afterwards, lower the maximum to your default value.
Take note! Although you can adjust the number yourself, be aware that lowering it may cause people already on the website to be moved back to the queue if the new limit is below the current number of visitors on the site.
How are Queue and website sessions measured?
Starting with release 204, we've updated how we measure visitors in the queue and on the website.
It's challenging to accurately determine the exact number of visitors on the website or in the queue. When a visitor shows no activity for a while, are they still present? Or have they closed their browser window?
Session timestamps
We can only measure activity, such as loading a new page while navigating or opening the queue page. However, there's no way to determine precisely if or when a visitor has left. Therefore, we must make assumptions and allow a certain amount of time to pass before concluding that a visitor is no longer active.
The way this works is by updating session timestamps:
For every new visit to the website or queue, a new session is created. The system stores the date and time of this session's creation. The session timestamp is updated whenever activity is detected. Activity may include:
- Navigating the website, browsing different pages, clicking links, adding items to a cart, and other similar actions.
- While waiting in the queue, each time the counter reaches zero, it checks if the visitor can be allowed on the website. As long as a visitor has the queue open in their browser, their session timestamp is then updated and the visitor is considered active. When the queue page is closed in the web browser, the session timestamp will no longer be updated.
Ending a session when there is no activity
The next step is determining how long a session can remain inactive before it's removed. If inactive sessions are kept for too long, they prevent other visitors in the queue from accessing the website.
On the other hand, inactivity can be easily explained. A visitor might be on an external payment page, searching for a credit card, or handling other issues. They might also be on the phone with friends, deciding how many seats to purchase in the seat map. These visitors should be given a reasonable amount of time to complete their tasks.
Based on years of data from our venues, a default inactivity period of 15 minutes has proven effective in allowing essential purchase processes to be completed. This duration can be adjusted to any number of minutes in the control panel (settings are detailed at the end of this article). When a session's timestamp remains unchanged for this specified period, the session is flagged as "stale".
In the new queue logic (introduced in release 204), stale sessions mark the end of a visitor's journey. These sessions no longer count towards the total, allowing the queue to progress. If a visitor with a stale session shows new activity, the system creates a fresh session, placing them back at the end of the queue.
Removing stale sessions is a new feature that can be switched off.
By setting "Clean up stale sessions" to "No" (default is "Yes") in the control panel, stale sessions remain in the database. Although they no longer count towards the total number of sessions, they can become active again if a visitor returns after X minutes of inactivity. This suddenly reactivates the session, counting it towards the total.
This logic can lead to an unexpected increase in website sessions, potentially pushing the most recently admitted visitor back into the queue. This behavior mirrors the original queue system before release 204. It was designed to prevent visitors from being removed from the website due to a long period of inactivity. However, the trade-off was a risk of unpredictable queue number behavior.
Another key change: We no longer ignore inactive sessions
Previously, there was a unique type of session that never showed any activity. These sessions had a creation date and time but lacked any updated timestamp. This scenario typically occurred in three situations:
- A new visitor opened the website and immediately closed it,
- A new visitor opened the website, saw the queue, and closed their browser before the queue counter could refresh and update the timestamp,
- A bot visited the website (or queue).
These special cases seems understandable, and it's tempting to conclude these sessions are useless since the visitor (or bot) has apparently left. So why not delete them to make room for other visitors?
However, if we delete all sessions without an updated timestamp, we'd be removing all new sessions—clearly not a viable solution. We need to keep them to allow visitors to become active.
So why not just ignore these sessions and not count them, making room for others? This approach seems clever and was, in fact, the queue's behavior before release 204. While not counting these sessions creates more space for active ones, it had a downside: These sessions could become active again when a visitor returned to the website in the same browser (as browsers retain session cookies). These newly active sessions would suddenly count again, affecting all subsequent sessions and potentially pushing some back into the queue. Though rare, it did occur.
Therefore, from release 204 onward, with the new default setting "Ignore inactive sessions" set to "no", these sessions always count towards the total. Most will likely remain inactive and be removed after X minutes, but some may become active. It's prudent to include them in the total count preemptively. By now counting these special sessions too, we've achieved…
These sessions don’t block any people behind them in the queue, as they work the same as other sessions and find their way to the website (and become stale), or are removed from the queue after becoming stale.
A more complete queue graph
The queue graph has now become a simpler piece of logic. In this new setup, there are only sessions with activity at least every X minutes, either from waiting in the queue or browsing the website. All other sessions are cleaned up and won't return.
You might notice an increase in website traffic in your queue since release 204. This is expected, as the graph now accounts for all sessions (see the explanation above), whether they become and stay active, or disappear after X minutes without any activity following their creation.
Access to e-tickets even if there is a queue
Some areas of the website are whitelisted to keep them accessible when a queue is active. This mainly concerns the online e-tickets, as these need to be accessible at any time before visiting an event. For this reason the entire “My account” area is accessible for everyone during a queue.
Tip If visitors open their e-tickets from their confirmation mail, they are redirected to the e-tickets inmediately, without seeing a queue.
If visitors don’t have their confirmation mail on them while visiting the venue, they might want to navigate to your website to login. They then might encounter a queue. In this case, send them to [insert your own domain here]/my/signin so they can log in and find their tickets. You can even create a QR code with that exact url and post it in your venue so visitors can use that for quick access.
Additional Actions
Notice in queue
You can place a message in the queue by scheduling a news item with the type "notice in queue." This message is immediately shown to all people waiting in the queue when the counter refreshes the page. This feature allows you to communicate actively about the current busy ticket sales situation. For instance, you can inform visitors which events are already sold out, potentially saving some people from waiting unnecessarily. The message supports images and buttons, just like any other text editor in the system.
Oh, and the notice now supports button styling too!
Shuffle Queue
This function shuffles all active sessions, assigning each a new place in a random order. It applies to all website visitors and those waiting in the queue. This is ideal if you want to give all visitors an equal chance of access. After shuffling, a number of people (equal to the set queue limit) are randomly forwarded to the website. The remaining visitors receive a new place in the queue.
It's advisable to set the queue to zero beforehand and communicate via a notice in queue that shuffling will occur at a specific time. This informs visitors that there's no advantage in waiting in line for a long time in advance, hoping to access the website sooner.
Bypass queue
The most prominent functionality here is the link to the website, with which you can bypass the queue and always be able to access the website. This is based on your dashboard login and IP address and is, therefore, inaccessible to others.
Preview queue Page
You can view the queue via the preview queue page link, even if the queue is not active.
Queue change log
Changes made to the queue are visible at the bottom of the module, so there is a clear picture of who has done what at which moment.
Queue settings (control panel)
In Control panel > Queueing, you will find a couple of settings to optimise the queue for your situation. The default settings as shown below are based on years of experience and will work for all situations, but they can be tweaked when needed.
- Queue threshold The maximum number of visitors allowed on the website. This setting can be changed in the actual Queueing module or here. It is the exact same setting. We recommend just using the Queueing module for this.
- Ignore inactive sessions (default: no) The new queue logic introduced in release 204 counts all sessions in the queue and on the website, including "inactive" ones. Inactive sessions are those without an updated timestamp, but these can become active again. By counting them towards the total number of sessions, it doesn't matter whether they're active or not, making the data more consistent (all sessions are accounted for). If you enable "ignore inactive sessions," the system disregards all sessions that haven't been updated since their creation. While this might seem advantageous and could provide a lower, potentially more accurate estimate of website activity, it has a drawback. Whenever an inactive session becomes active, it affects the total number of sessions on the website or in the queue. This can occasionally push another session back into the queue.Inactive sessions eventually become "stale" (see next setting).
- Sessions stale after (min) (default: 15 minutes) This setting manages how long a session can be inactive before it is considered “stale”. A stale session no longer counts as a session on the website or in the queue, freeing up space for others.
Stale sessions still have access to the website, unless these sessions are actively cleaned up (see next setting below). If they are not cleaned up, they can become active again, and might bump an other session back in the queue.
- Clean up stale sessions New in release 204 is the option to remove stale sessions (it’s switched on by default). If a visitors with a stale session suddenly becomes active again and tries to reach the website, this triggers the clean up protocol, and the stale session will be removed. The visitor is treated as a new visitor and starts at the back of the queue again. If a stale session never becomes active again, it will not trigger the clean up protocol, and the session lingers in the system. That’s why we have the next setting below;
- Sessions expire after (min) (default: 60 minutes) Removes sessions that have been inactive for this many minutes permanently. This has no effect on queue behaviour, and should probably be left alone.
- Display position (default: yes) This option shows the visitor the current position in the queue.
Template texts for the queue page
FE3_queueTitle The title for the queue page (see screenshot above)
FE3_queueIntro The main introduction for the queue page (see screenshot above)
FE3_queuePosition A message explaining your current position in the queue. The placeholders [!position!] and [!total!] will be continuously updated (see screenshot above)
FE3_queueLastUpate Displaying the last time your position in the queue was updated (see screenshot above)
FE3_queueMinutes Countdown to the next update in minutes and seconds (see screenshot above)
FE3_queueSeconds Countdown to the next update in seconds (see screenshot above)
FE3_queueMaintenance A default message explaining that the website is currently unavailable (only shown in the special case when max. visitors is set to zero. All other template texts mentioned above, including the counter are hidden ). This default message is overridden by adding your own notices in queue.
Related articles