Updated: 18 November 2024 for Release v204
About the Queue
- The Queue 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
A preview of the Queueing module is visible 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, there is a graph with several bars. Each bar represents a moment in time, spaced 5 minutes apart. A new snapshot is taken every 5 minutes.
In 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 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! Be aware that lowering the number 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?
With Release 204, we have updated how Visitors are measured in the queue and on the website.
It is 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 is no way to determine precisely if or when a visitor has left. 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.
For some parts of the booking journey 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".
The new Queue logic (introduced in Release 204) will make sure a stale session means 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.
In the Control Panel > Queueing, set Clean up stale sessions to No (default is Yes), 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.
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 is 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?
If we delete all sessions without an updated timestamp, we would remove all new sessions. We need to keep them to allow visitors to become active.
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 suddenly 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 someone back into the queue. Though rare, it did occur.
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 [Sessions stale after (min)] minutes, but some may become active. It is prudent to include them in the total count preemptively. By now counting these special sessions too, we have achieved:
- Inactive sessions do not block any people behind them in the queue, as they work the same as all other sessions and either find their way to the website or are removed from the queue after becoming stale.
- Prevent current active visitors from being suddenly pushed back into the queue when a previously inactive session becomes active
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 even 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.
Good to know! If Visitors open their e-tickets from a confirmation mail, they are redirected to the e-tickets immediately, without seeing a queue.
If Visitors do not have their confirmation mail on them while visiting the venue, they might want to navigate to your website to login. If the queue is active they will be added to it. In this scenario, direct them to [insert your own domain here]/my/signin where they can log in and access their tickets. You could even create a QR code with that exact URL and post it in your venue so visitors can use that for quick access.
Additional Queue Actions
Notice in queue
You add a message to the queue by scheduling a News item with the type notice in queue. This message is immediately shown to all visitors waiting in the queue when the counter refreshes the page. This allows you to communicate actively about the current 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.
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 is 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 to waiting in line for a long time in advance, hoping to access the website sooner.
Bypass Queue
This allows you to bypass the queue and to always have access to 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)
Go to System > Control Panel > Queueing to update Queue settings to optimise the queue for your situation. The default settings shown below are based on years of experience and will work for all situations, they can be tweaked when needed.
- Queue threshold: The maximum number of visitors allowed on the website. This setting can be changed in the Queueing module or here. It is the exact same setting. We recommend using the Queueing module for this.
- Ignore inactive sessions [Default = No]: The queue logic counts all sessions in the queue and on the website, including "inactive" ones. Inactive sessions are those without an updated timestamp, these can become active again. If you change this to Yes, the system disregards all sessions that have not 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 could push another session back into the queue. Inactive sessions eventually become stale (see next setting).
- Sessions stale after (min) [Default = 15]: 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 Clean up stale sessions setting). 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 [Default = Yes]: If 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 new 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]: Removes sessions that have been inactive for this many minutes permanently. This has no effect on queue behaviour, recommend leaving this as the default setting.
- Display position [Default = Yes]: This option shows the visitor the current position in the queue.
Queue Template Texts
Below is a list of the available template text. All Queue Template Text begin with FE3_queue
- 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