Overview

The Spektrix Queue

Spektrix has queueing built in at no extra charge, providing customers with live updates on their position and - critically - moving them securely from website to purchase pathway, with no risk of losing their place in line. Once an event is on sale and the queue enabled, customers will enter a queue prior to seeing the ChooseSeats.aspx iframe. As customers at the front of the queue place their orders, more customers will be allowed to select seats.

Things to remember with the queue:

• There is only one queue per client - all events that have queueing enabled are diverted through this one queue. If there are any events that do not have queueing enabled, customers purchasing for these events are unaffected.
• Customers only queue once. When they reach the front of the queue they are able to purchase tickets for all events and instances that have queueing enabled without having to re-queue. If they confirm a transaction and visit the purchase path again, they go to the back of the queue.
• Customers with items in their basket prior to joining the queue will be asked whether they want to checkout and confirm these items, or empty their basket. If entering the queue is dependent upon these items (e.g. a priority booking period activated by a membership) then the same options still apply. Customers must have empty baskets before entering the queue.

Queueing and the Spektrix API

The queue kicks in at the chooseseats.aspx iframe. Adding tickets via the API does not have queuing and therefore it could cause suboptimal customer experience under load. If you are using the API to add tickets to the basket, or a combination of API and chooseseats.aspx iframes, and anticipate a large onsale, get in touch with Spektrix on support@spektrix.com to discuss next steps.

What does the queue look like?

The queueing page is made up of four elements, shown below:

• Custom Message for Customers in the Queue: This message is set by the Spektrix team, so the client can get in touch with Spektrix if they wish to update it. Good advice is to include a message explaining why a queue is being used, what the customer can do once they reach the front of the queue, and that they will be automatically redirected without refreshing the page.
• Progress Bar: The progress bar will show the customer’s progress as they wait in the queue. The closer to the right hand side the bar, the closer to the front of the queue the customer is.
• Position in the Queue: The customer’s position in the queue, and also the estimated waiting time, if enabled. This number will decrease as customers reach the front of the queue (we do not display the length of the queue).
• Next Update: A countdown to the next update to the queueing page. It is usually 10 secs and set by the Spektrix team who are monitoring the onsale. Once the customer reaches the front of the queue the page needs to update before Choose Seats is displayed.

The queueing page inherits the CSS styling uploaded to the Spektrix system, although web developers can change the styling should tweaks be needed. You can view the queueing iframe without switching the queue on, just go to: https://<customdomain>/<clientname>/website/QueueingPage.aspx?testing=true

Additional Customer Communication

The message displayed above the progress bar can be changed by the Spektrix team as an onsale progresses, to reflect new information the customer might need (for example, that the event is sold out, selling out or there is a problem). The system checks for any changes to the message at the end of each polling period, and displays the changes automatically. It is also possible to have a custom message to display when a customer arrives at a sold out instance via the queue. This might instruct them to select another instance, or apologise for their disappointment.

What do you need to do?

Since Spektrix handles the queuing for the iframes, it manages the complex logic of the purchase path and keeps pace with online demand effectively.

As the web developer, you are responsible for the performance of the website.

Leveraging CDNs for Optimal Performance

To ensure your website performs seamlessly during peak traffic times like ticket onsales, utilizing a Content Delivery Network (CDN) is highly recommended. CDNs cache your website's static content, so the use of a CDN on top of providing benefits under heavy load (onsale), also improves the customer experience under normal traffic patterns by reducing significantly page response times.

Since Spektrix handles most dynamic content related to customer transactions (via iframes or our client-side API), you can focus on optimizing the delivery of your static content for maximum performance.

Caching Strategies for Dynamic Elements

While CDNs excel at caching static content, certain elements on your website (outside of the Spektrix iframes/web components) might need to change dynamically during an onsale. This could include call-to-action buttons that transition through states like "On sale at x," "Priority Booking Open," "Book now," "Limited Availability," and "Sold out."

To handle these dynamic elements effectively, consider the following strategies:

• Dynamic Content within Static Pages: Fetch dynamic elements (like button states) using calls to a lightweight service on your end. This service can periodically retrieve the latest status from Spektrix server-side (e.g., every 10 minutes) and provide it to your webpage. This allows you to update specific sections of your page without requiring a full cache purge or making frequent calls to Spektrix from the browser.
• Strategic Cache Purging: Purge your CDN cache at key moments, such as the exact onsale time. This ensures users receive the most up-to-date information. However, be mindful of potential issues associated with cache purging, such as temporary inconsistencies or increased traffic to your server while caches are rebuilt. Whenever possible it’s recommended to only purge individual items (such as specific images or javascript files) to avoid triggering unnecessary requests to your website for assets that haven’t changed.
• Prevent Caching of Dynamic Content: Ensure that pages containing customer- or transaction-specific information are not cached and served to other users. This prevents accidental data leakage and ensures each user sees the correct information.
• Use a combination of CDN caching and browser caching: Make sure that for all static assets, including JavaScript, CSS, images and HTML where possible you set the correct cache-control header with a max-age value appropriate to the item to control its expiration. This allows both browsers and CDNs to keep objects in cache for as long as possible whilst reducing the risk of serving stale data. Caching in the browser also reduces the need for unnecessary requests improving the customer experience