Jump to content
  • entries
    47
  • comments
    43
  • views
    10859

How accurate are advertised ride queue times?: A statistical analysis using data from Alton Towers and the UK Merlin parks

Matt N

Entry posted by Matt N in Data Analysis

865 views

 Share

Disclaimer: This is a long, geeky post. If you don't like statistics or maths talk, turn back now! If you'd like a more concise summary, a TL;DR can be found at the bottom.

Hi guys. When you go to a park, you will often see advertised queue times all over the place to help you determine how long the ride queues are. But sometimes, you might find that these do not necessarily tell the truth. At times, you might get in a queue with a reasonable advertised time and wait far longer than expected, and at other times, you might get in a queue with a long advertised time and wait far less than expected. With this in mind, you might be wondering; how accurate actually are these advertised queue times? Can they be relied upon? Or are they largely hokum?

 

Well, dear reader, that is the question I'm aiming to answer today. Through the power of statistics, I am going to work out; how accurate are advertised queue times? 

 

Let's firstly start with the methodology of my statistical analysis...

Methodology

You might be wondering "Matt, how on Earth are you going to get hold of advertised and actual queue time data to conduct this analysis?". Well, the answer to that is that I had an idea... for years, I've been writing trip reports from various theme parks, and within these, I often make reference to the advertised queue time and how it compared to the actual queue time. And I was thinking that I could use my anecdotes from some of these trip reports as samples for the analysis. Yes, there's finally a day where my comparisons of advertised and actual queue times come in handy!

 

My method entailed reading my various trip reports from the UK Merlin parks from over the years and looking for anecdotes referring to the advertised queue time in comparison to the actual queue time of a ride. I chose the UK Merlin parks because these are where I have by far the most data from, and they are also likely to share similar technology, processes and the like for determining advertised queue times, which removes any uncertainty from working with companies with differing processes.

 

I should note that I did not count every time I went on a ride. I only counted rides where there was one of:

  • An explicit comparison between advertised queue time and actual queue time given.
  • A comparison between advertised queue time and actual queue time that heavily hinted towards the actual queue time given. For instance, words like "walk-on" or "I waltzed straight onto the train" would infer a 0 minute actual queue time, and words like "the queue time board stayed true to its word" would infer no discrepancy between the advertised and actual queue times.

There were rides I did not count, as I felt that they would not be representative of the actual main queue. These are:

  • Any time where I talk about using a Single Rider Queue or otherwise benefitting considerably from single rider status (such as being called to walk past a long queue to fill an empty seat).
  • Any time where I talk about using Fastrack or similar.
  • Any time where I talk about waiting longer for a specific experience, such as the front row.

Through these rules, I was able to gather:

  • 15 days and 75 rides of data from Alton Towers, dating back as far as 23rd June 2019
  • 9 days and 48 rides of data from Thorpe Park, dating back as far as 6th May 2018.
  • 3 days and 9 rides of data from Legoland Windsor, dating back as far as 31st August 2017.
  • 1 day and 3 rides of data from Chessington, from 17th September 2023.

I should also give a few caveats. These are:

  • This is my data and mine only. There are multiple reasons why that means that it may not be a fully representative sample. For example, Chessington and Legoland are under-represented, whereas Alton Towers and Thorpe Park are over-represented.
  • The actual level of understatement may be higher than what this analysis suggests, as this only factors in queues I have personally waited in. If a queue looks vastly understated at first glance, there's a good chance I won't join it.
  • Where I provided a range of time for the actual queue length, I went with the upper bound. For example, if I described a queue as taking 20-25 minutes, I logged the actual queue time as 25 minutes.
  • I should strongly emphasise that this is not a massively exact science. The measurement of actual queue time was me looking at my watch throughout the queue, and for a variety of reasons, the movement of a queue can be affected in ways that the advertised time can't account for.

With this out of the way, let's move onto the actual meat of the analysis...

 

For each part of the analysis, I'll look at an individual park, as well as all 4 Merlin parks amalgamated together. For the individual park, I picked Alton Towers, as this is the park for which I have the most data.

 

Let's start with a simple correlation analysis to determine the strength of the relationship between advertised queue time and actual queue time...

Correlation

For those not aware, the correlation between two variables determines whether or not they are inter-related. The magnitude of a correlation lies between 0 and 1, with 0 indicating no correlation and 1 indicating a perfect strong correlation, and a correlation can also be positive or negative. A positive correlation means that as the value of one variable rises, the value of the other rises in unison, while a negative correlation means that as the value of one variable rises, the value of the other falls.

 

Now that I've explained a bit about correlation, let's have a look at what the data says about the correlation between advertised queue time and actual queue time! I'll consider two different correlation coefficients, Pearson and Spearman. Pearson's correlation coefficient assumes a linear relationship between two variables, whereas Spearman's correlation coefficient does not.

 

If we look at Alton Towers on an individual level, the scatter graph of advertised queue time and actual queue time looks something like this:

Alton-Towers-Queue-Times.png

And the correlation figures are as follows:

Correlation Type Correlation Coefficient (2dp) Correlation Classification
Pearson 0.67 Moderate Positive Correlation
Spearman 0.74 Moderate Positive Correlation

 

Whereas if we look at the UK Merlin parks overall, the scatter graph of advertised queue times versus actual queue times is as follows:

UK-Merlin-Park-Queue-Times.png

And the correlation figures are as follows:

Correlation Type Correlation Coefficient (2dp) Correlation Classification
Pearson 0.65 Moderate Positive Correlation
Spearman 0.70 Moderate Positive Correlation

 

So if we look at correlation, I think we can conclude that there is a relationship between advertised queue time and actual queue time. Based on correlation alone, we can infer that on a general level, there is a moderate-to-strong correlation between advertised and actual queue time, so if the advertised queue time increases, you can generally expect actual queue time to increase along with it. However, the correlation is far from a perfect positive correlation, so this will not be the case in every scenario. In fact, the fact that the positive correlation does not even quite breach the threshold of "strong" (which I was told was 0.75) would suggest that this is not always the case by a long shot, and the relationship is far from perfectly proportional.

 

So in general, the correlation analysis would suggest that the advertised queue times are trustworthy to a broad extent to get a gauge of the broader picture, but perhaps with a notable margin of error for exact figures.

 

Let's now look at the average discrepancy...

Discrepancy (Vector)

Let's now look at the average discrepancy as a vector quantity. Vector quantities have both magnitude and direction, so this form of discrepancy will consider whether the queue is overstated or understated as well as its actual magnitude. Where the queue is overstated, the discrepancy is negative, whereas the discrepancy is positive where the queue is understated.

 

If we firstly look at Alton Towers on an individual level, here are the boxplots showing the ranges of raw and proportional discrepancies respectively. It's important to consider proportional discrepancy because if an advertised queue time is longer, there's bound to be a larger discrepancy in general:

Alton-Towers-Raw-Discrepancy.png

Alton-Towers-Proportional-Discrepancy.pn

And the raw and proportional discrepancy stats, as well as average queue time, are as follows. Both mean and median values are provided, as each metric has flaws in isolation and I felt that showing both offered maximum transparency:

  Average Advertised Queue Time (minutes, 1dp) Average Raw Discrepancy (minutes, 1dp) Average Proportional Discrepancy (1dp) Adjusted Average Proportional Discrepancy (1dp)
Mean (Calculated Average) 28.3 2.2 8.8% 7.8%
Median (Middle Value) 25 0 0% 0%

 

I should clarify that Average Proportional Discrepancy is the average of the proportional discrepancies listed alongside each anecdote, which excludes those where the advertised queue time was 0 minutes and the actual queue time was a different number (you cannot divide a non-zero number by 0, so a percentage proportion cannot be provided). Adjusted Average Proportional Discrepancy is a simpler calculation of Average Raw Discrepancy as a share of Average Advertised Queue Time on an overall basis, which (sort of) takes these into account.

 

If we now look at the UK Merlin parks overall, here are the boxplots showing the ranges of raw and proportional discrepancy respectively:

UK-Merlin-Park-Raw-Discrepancy.png

UK-Merlin-Park-Proportional-Discrepancy.

 

And the raw and proportional discrepancy stats, as well as average advertised queue time, are as follows:

  Average Advertised Queue Time (minutes, 1dp) Average Raw Discrepancy (minutes, 1dp) Average Proportional Discrepancy (1dp) Adjusted Average Proportional Discrepancy (1dp)
Mean (Calculated Average) 26.1 1.3 13.7% 5.1%
Median (Middle Value) 25 0 0% 0%

 

So looking at this, Alton Towers and UK Merlin queue times are understated by up to 1-2 minutes on average.

 

If we look at the median, that would imply that there's no discrepancy between advertised and actual queue time at all on average, and even the higher mean values infer that there are average discrepancies of less than 10% in some cases. At face value, these stats would give reason to believe that Merlin's advertised queue times are very accurate overall, with an average error of only 1-2 minutes and less than 10%.

 

However, you should note my use of the term "at face value"... because that's not the full picture. You might remember that earlier, I said about how the discrepancy being shown here is a vector quantity, meaning that it has both magnitude and direction. That means that understated queues have a positive discrepancy value and overstated queues have a negative discrepancy value, so the two balance each other out. So while you'd think that the low average discrepancies shown here mean that the queue times are very accurate... the use of vector discrepancies here mean that all this really shows is that understating and overstating balance each other out quite nicely, meaning that you can't really rely on Merlin parks to understate or overstate their queues. They both understate and overstate to broadly equal extents.

 

To get the true picture of how accurate these queue times really are, we need to convert the discrepancy values into a scalar quantity and look at the absolute values of discrepancy...

Absolute Discrepancy

To get the true gist of how accurate these queue times really are, let's now look at the absolute discrepancy values. Absolute means that only the magnitude of discrepancy is considered, and that the discrepancy values are scalar quantities rather than vector quantities.

 

If we firstly look at Alton Towers on an individual level, the boxplots showing the range of raw and proportional absolute discrepancy values are as follows:

Alton-Towers-Raw-Absolute-Discrepancy.pn

Alton-Towers-Proportional-Absolute-Discr

And the raw and proportional absolute discrepancy stats, as well as average queue time, are as follows:

  Average Advertised Queue Time (minutes, 1dp) Average Raw Absolute Discrepancy (minutes, 1dp) Average Proportional Absolute Discrepancy (1dp) Adjusted Average Proportional Absolute Discrepancy (1dp)
Mean (Calculated Average) 28.3 14.1 39.3% 49.6%
Median (Middle Value) 25 10 27.5% 40%

 

If we look at the UK Merlin parks overall, the boxplots showing the ranges of raw and proportional absolute discrepancy are as follows:

UK-Merlin-Park-Raw-Absolute-Discrepancy.

UK-Merlin-Park-Proportional-Absolute-Dis

And the raw and proportional absolute discrepancy stats, as well as average queue time, are as follows:

  Average Advertised Queue Time (minutes, 1dp) Average Raw Absolute Discrepancy (minutes, 1dp) Average Proportional Absolute Discrepancy (1dp) Adjusted Average Proportional Absolute Discrepancy (1dp)
Mean 26.1 13.5 58.7% 51.6%
Median 25 5 33.3% 20%

 

So looking at these stats, UK Merlin queue times are wrong by 5-15 minutes on average, and broadly, the average proportional absolute discrepancy ranges between 20% and almost 60%.

 

This would imply that the advertised queue times are not phenomenally accurate, and may not be 100% correct in terms of the exact figure on average. However, it would suggest that they are still quite good at a more general level to get a general gauge of how long a queue might be. If a queue is advertised at 100 minutes, it's unlikely to be walk-on, and vice versa. These figures suggest that the advertised queue times can generally be used as a broad gauge of the length of the queue, but should not be taken as gospel and the exact figures should be taken with some degree of caution.

 

Let's now look at some final conclusions...

Conclusion

So in conclusion, how accurate are these advertised queue times? Well, I think these results show that they're overall reasonable as a gauge of the broad ballpark the queue time is likely to fall into, but have somewhat weaker accuracy at determining exact queue times.

 

In terms of the correlation analysis, the advertised queue time and the actual queue time have a reasonable correlation, but not a perfect one. The two are moderately positively correlated, with a correlation coefficient of around 0.6-0.7, which would suggest that the two variables are broadly related and do increase in unison with one another in general, but this is far from a perfectly proportional increase and is not a perfect rule by any means.

 

On average, the vector discrepancy between advertised queue time and actual queue time was to be understated by 1-2 minutes, and the percentage margin of error was often to be understated by less than 10%. This suggests that understating and overstating overall happen to roughly equal degrees, and you can't really rely on Merlin to reliably do either.

 

On average, the absolute discrepancy between advertised queue time and actual queue time was 5-15 minutes, and the percentage margin of error for the advertised queue time was between 20% and 60%. This would suggest that the advertised queue times are rarely 100% accurate and should be treated with a degree of caution and a margin of error, but that they're generally decent as a way of gauging broadly how long a queue will be. If a queue is advertised at 30 minutes, for example, you can assume that it will probably be between about 15 minutes and about 45 minutes. That is quite a wide margin, admittedly, but the advertised queue times are unlikely to be amazingly wrong, on the whole. A 30 minute advertised queue, as an example, would indicate a roughly "middle of the road" queue time with a reasonable degree of reliability; the queue is unlikely to be obscenely short, but it's unlikely to be obscenely long as well.

 

So in conclusion, I think this analysis suggests that the advertised queue times are decent for getting an idea of broadly how long a queue is likely to be, but are worse at pinpointing the actual exact queue time, and the estimates should be considered with a good margin of error and not taken as exact estimates.

 

If you'd like to look at my data, here are the full spreadsheets for Alton Towers and UK Merlin queue times respectively:

https://docs.google.com/spreadsheets/d/1c2b05czi2xwwDxKRVBMJ9qyB3_-_b0RyMdc-N8n8JJI/edit?usp=sharing

https://docs.google.com/spreadsheets/d/1jpqqpu2pErHY41vHTpDP_NEZqnjuMwgtVVp99JexjvI/edit?usp=sharing

 

So that brings us to the end of this statistical analysis! I hope you enjoyed reading it as much as I enjoyed concocting it, and I hope you found it interesting! I'd be really interested to hear your thoughts; I'm receptive to any feedback, good or bad!

TL;DR: I performed a statistical analysis to try and determine how accurate advertised queue times are, using datasets of advertised vs actual queue times in Alton Towers and the UK Merlin parks taken from my past trip reports. A correlation analysis showed that there was a moderate positive correlation of magnitude 0.6-0.7 between advertised and actual queue time, indicating that they do generally increase in unison, but that this is far from a perfect trend and this is not necessarily a proportional increase. An analysis of average vector discrepancies showed that Merlin parks do not reliably understate or overstate queue times, with both understating and overstating happening to broadly equal degrees. An analysis of average absolute discrepancies showed that the queue times can provide a broad idea of roughly how long a queue may be, but are unlikely to be too accurate at determining the exact queue time.

 Share

4 Comments

Recommended Comments

Inferno

Matt this is absolutely glorious.

 

It’s a weirdly interesting topic that actually has a massive impact on a visit.

 

I’d love to know how queue times are actually measured - or is it literally just a glance and an estimate?

I remember some fanfare years ago about Saw the Ride having some sort of Bluetooth thing that tracks where people’s phones are, but that has always sounded like a lot of bs to me 🤷‍♂️ 

Link to comment
Matt N
8 minutes ago, Inferno said:

Matt this is absolutely glorious.

 

It’s a weirdly interesting topic that actually has a massive impact on a visit.

 

I’d love to know how queue times are actually measured - or is it literally just a glance and an estimate?

I remember some fanfare years ago about Saw the Ride having some sort of Bluetooth thing that tracks where people’s phones are, but that has always sounded like a lot of bs to me 🤷‍♂️ 

I’d be really interested to know how it works too!

 

In all likelihood, it’s probably some degree of glancing and estimating from the staff. In some cases, I’m not even sure they do that; in one instance logged in my spreadsheet, Vampire at Chessington was advertised at 5 minutes, yet it was nearly out the entrance and I waited 60…

 

I had an idea in my head of a near foolproof way of reliably estimating queue times. Imagine some sort of system that logs the amount of people entering and leaving the queue that’s paired with the ride computer system that logs the ride throughput, uniting queue entry/exit management and ride throughput management in perfect unison to make a wonderful, near foolproof queue time estimation system! Goodness knows how you’d implement it technically, but in the world of IoT and the like, it must surely be possible, at the very least…

 

It’s unlikely to ever come to fruition, but I can dream!

Link to comment
JoshC.
12 hours ago, Inferno said:

I’d love to know how queue times are actually measured - or is it literally just a glance and an estimate?

 

I can give insight here.

 

A few years ago (well, more than a few years now...8 years ago...I'm old), I had a job at Thorpe which was focusing primarily on 'looking after queue times', if you will. I had to update queue times that would appear on the boards, along with some other things.

 

At the time when I joined, it was simply a glance and estimate. It was a two-way operation: the ride operator was required to contact the 'queue person' (ie: me) via phone once an hour (at a minimum), saying what they thought the queue time was. The queue person would also walk around the park, visually looking at all queues and updating the queue times.

 

How is it physically done?

All updates were done via a secure webpage. The queue person walked around with an iPad and could update directly all queue times from said webpage. Other people (park managers, etc) had access and ability to as well (will get onto this later).

 

How would ride operators know what the queue time is?

This was done by looking at the length of the queue, which for many rides, they could only see through via the ride's security cameras. The security cameras ride operators have access to focus primarily on ride areas (making sure no one is entering them), meaning coverage was mixed. Ride operators would sometimes not see much of the queue.

Note: Queue lines are still covered by CCTV cameras, but ride operators won't have access to them all necessarily. The ride operator job is to run the ride safely.

 

And that's a key point, the ride operator is there to run the ride safely, look after the ride hosts, etc. Updating queue times can go quite low on the list of priorities.

 

Also, ride operators generally didn't have much knowledge of queue times. It would all be based on own experiences, either from when they might have visited the park and queued themselves, other operators, what guests say, etc. Generally they would get good ballpark figures, but when you hit busy periods, that experiential data is less helpful.

 

How would the Queue Person know what the queue time is?

Same idea. They would walk around, see the queue time, and update it. The advantage they had is they could see the whole queue, and have knowledge of what else is going on around the park. Eg: Colossus operator might not be aware that Saw closed down recently, meaning more people might flock there if they're nearby and want to ride a coaster. Queue Person would know this, and could keep a closer eye as a result.

 

So it was all guesswork?

Going onto my experience of working in this position as the queue man.

 

I noted straight away there was very minimal written down information about how the physical length of a queue translates to a queue time. Of course, everyone was aware that this is a very muddled science: it depends on operations, number of trains, number of Fastrack / RAP users, delays, etc etc. Many of those things ride operators will not be aware of explicitly. Some of those things are out of a singular person's control.

 

However, there is a way of turning it into a science. "Queueing theory" is a very rich area of maths, for example, which gives us many lessons we can learn. There's a lot of social science studies into how people will fill up a given space with strangers. There is access to lots of data about the rides; their uptime, their throughput/utilisation, so on and so on. You can combine all of those factors together to give a better estimate for queue times, one which relies on data, rather than just guesswork.

 

Taking the Guessing out of the Guesswork

I'll chuck in a bit of the numbers and theory here. Feel free to skip over.

 

When thrown into a barriered queue, you'll find people spread out in similar ways. Except in extreme scenarios (very wide or very narrow queue lines), about 11 people will fill up 3m of space. This is to do with how groups of people will huddle together, groups will leave a space, etc. That data comes from a published research paper back in 2014/15 I believe and focused on UK audiences. Would be interesting to see if that's changed post-Covid, or is different in other countries.

 

Anyways. If we know that, we can work out how many people a physical queue line holds. For example, if the Colossus queue line was 300m long, it would hold roughly 1100 people. And you can split that up; if the queue line from the airgates to the tunnel of Colossus' queue was 90m long, the number of people between the queue line and boarding is 330. (NB: Lengths made up).

 

Now, we know what Colossus' theoretical throughput is. Internally, there is also a target throughput. But even better, parks track their throughputs for each ride. So you can see what they're actually achieving. If, over the course of last week, Colossus got a throughput of 550pph, and it had a full, 300m long queue line, you could see that it should be a 2 hour queue.

 

Obviously that ignores Fastrack and RAP users. But again, you know the number of RAP and Fastrack users each day. You can take those into account, in some way. You don't know when they're going to use, but you can take it into account. 

For example, if there were 700 Colossus Fastrack tickets sold for an 8 hour park day, and 500 RAP users expected, you can account for that. If Colossus was getting a throughput of 550ph, over 8 hours it would get 4400 riders. But 1200/4400 of those riders came from Fastrack or RAP. So that means only 73% of riders are coming through the main queue, or rather the throughput of the main queue is 73% of 550, which is 400pph. Now if that 300m long queue of Colossus is filled with 1100 people, and you know 400pph are going through that queue, you can advertise the queue at 2h45min, rather than 4 hours.

(Again, all numbers are fake here)

 

On top of that, you can also take into account the chance of a shutdown. If Colossus has an uptime of 95%, then that means its closed 5% of the time. Of course, this is unlikely to spread evenly across the day, and usually occurs in a chunk, but if you add on that extra, you create a buffer which allows for a 'chance of shutdown', or just anything going wrong (slower operations, etc).

 

I'll take this chance here to say: ride staff do not artificially inflate queue times to sell Fastrack tickets. I've no doubt it happens whereby a queue is advertised much longer than it is, and people have ended up buying Fastrack. But the queue time is not inflated to drive Fastrack sales.

In saying that, I think it's better to advertise a queue time which might be 5-10 minutes longer since it will: 1) Create a buffer in case of issues and 2) Create happy guests - "Oh, the queue was advertised as 50 minutes, but we actually queued 40...result!"

 

So, the way that I planned to calculate (note the word calculate, not estimate/guess) queue times would be:

 

(N*(1+D))/(T*(1-(F/R))), where:

N is number of people in queue

D is percentage downtime 

T is throughput

F is number of Fastrack and RAP users expected

R is total ridership expected for the day

 

Those 4 last variables would be based off numbers from how the ride has run over a period of several days / weeks prior, giving it a good outlook at how it should operate in practice. It wouldn't be perfect, but it does the job. And of course, number of people in a queue is again estimated, but can be done reasonably well.

 

Of course, this isn't something that can be done in your head or anything, but can all be programmed to be done automatically, so long as you say the number of people in the queue roughly.

 

When I trialled this system, it worked well, with overall accuracy of queue times improved, and less complaints about inaccurate queue times, which also saw a reduction in complaints about queue times altogether for a short period of time. (Those two might not be linked, but I'm gonna claim it's because of me). I'm a Celebrity was one which hugely benefitted, in part down to the huge buy in from the Entertainments Team running it.

 

The issue here is, simply put, getting buy in from others. I required a bit more help setting up the automation and implementing it on a broader scale. Some people are opposed to change, some people are opposed to change where they don't understand every detail, some are just happy with the way things are. Some of Matt's analysis here is exactly the sort of thing which would be excellent for the operations teams at Merlin theme parks to see, so they can have more detailed data to help them determine how they're performing and the reflection on advertised queue times. But from my past experience within the parks, you would find yourself encountering people who:

-Don't understand the analysis behind this, so immediately disregard it,

-Would love the bottom line, but wouldn't use the data to help improve it,

-Disregard everything and say everything is fine,

-Agree with everything, but don't have the time/resources to action upon anything that would help.

Obviously, with shifts in Merlin, this may be different now. But it's such a difficult thing to achieve. There are (naturally) some excellent data-driven minds who work in Merlin, who would love this stuff too, but they are used in other roles, usually outside of day-to-day operation / outside of attractions entirely. So Merlin know the importance of these things, it just hasn't trickled down to operational success.

 

My time within the queue person job ended back in 2017, and this isn't the place to discuss that. But ultimately, the system devolved into operators phoning a central figure in an office to update queue times, with managers also chipping it. Likely with zero consistency. I don't know how things are this season admittedly, and I've been impressed with the accuracy being better than it has in the past. So maybe they've got something a bit better now.

 

FAQ

Do all parks do this guesswork?

Within Merlin, I believe so yes. I think Towers have staff at rides update queue times, and Chessington was similar.

 

Why did Thorpe need a central figure to update queue times? Couldn't it just be done by each ride through the website?

The issue with the website and multiple users would be the constant need to refresh. If, say, there were 2 people on the website, and Person A updates Colossus' queue time from 10 minutes to 50 minutes, the site according to Person B would still have Colossus' queue time listed as 10 minutes, even though it was displaying on boards as 50. Then, if Person B updated Swarm's queue time from 30min to 20min, without refreshing the website, they would also update Colossus' queue time back to 10 minutes. So yeah, clunky system. I don't know if they've updated this.

 

*This park* advertises queue times super accurately, how do they do it?

I don't know. I would love to know how parks like Efteling, Europa, etc do it.

 

Why can't parks just count the number of people going into a queue and going on a ride, using barriers, infrared, whatever?

These work nicely in theory, but are open to abuse (people spinning barriers) and prone to error.

 

13 hours ago, Inferno said:

I remember some fanfare years ago about Saw the Ride having some sort of Bluetooth thing that tracks where people’s phones are, but that has always sounded like a lot of bs to me 🤷‍♂️ 

 

The Alton Towers app had some Bluetooth tracking tech a while back, where it could see where guests were spending more of their time, etc. I don't know if they still do that, but I believe attractions.io (the company that does the Merlin apps and more) have loads of cool backend features.

 

With Saw though, they had a very cool (rather complicated) piece of software they trialled. The name escapes me, but I'm sure I'll find it sooner or later. Basically though, it would track people in all queue lines, to see how long people were spending in the queues, and use it to give accurate queue times. It would update regularly, and give to the minute readings (eg, 47 minutes). This software was just installed to work with existing CCTV cameras.

 

And, it worked well. Very well. Queue times were accurate. The system wasn't prone to error or breaking. It just worked, so you could leave it. 

 

In saying that, there were operational issues:

-If you ever needed to over-ride it, you had to reset all the cameras to get the system back

-It would never display a queue time lower than 10 minutes

-It didn't work when the queue became external (ie out of the main queue)

-People were weirded out by the exact numbers

 

The middle two are the bigger issues here, but again, not huge in the grand scheme of things.

 

There were bigger, more damning issues:

-It was expensive. I don't know how much, but given every other queue time system is free pretty much, spending money on one is an issue. Spending lots of money is a bigger issue.

-It required static CCTV cameras on the entire queue line. Whilst the entirety of Thorpe Park is covered by CCTV, many of these have the ability to change angle, which can help in a security situation. If you needed static CCTV cameras for the queue lines, it meant having to buy, set up, operate and maintain more new ones. And for some queue lines, this would require an awful lot (Colossus would be nightmare, with its sprawling queue line, going through tunnels, foliage, etc).

 

Ultimately, whilst it gave accurate queue times, the initial outlay cost, and ongoing maintenance costs, weren't justifiable. 

 

 

Do accurate queue time really matter?

Just to round off on this very long, tangential post (sorry Matt!). How important are accurate queue times? At the low level, yes, it's handy to know if a queue is 5 minutes or 10-15 minutes. At an extreme level, it's good to know if a queue is 1 hour or 2 hours.

 

But beyond that? Does it matter if a queue is 30 minutes or 35 minutes? 110 minutes or 130 minutes? I think sometimes there's an overpush on queue time accuracy: if a queue is advertised at 110mins and I queue 130mins, I've still queued about 2 hours for a ride, with added annoyance that I've queued an extra 20 minutes than I was told.

 

It might be better if there's ranges that are advertised (0-10, 10-20, etc, 90-120, 120-150, etc). It buckles you up for the length of the queue, tempers expectations, but gives leeway for a park too.

 

You can have the most accurate queue times in the world, but if they're long and / or slow, that's all people will care or remember about.

Link to comment
Inferno
On 7/25/2024 at 1:32 PM, JoshC. said:

I can give insight here.

Thank you Josh!  I’m loving all the details behind the scenes!
A proper nerdy enthusiast binge this thread.

 

I kind of agree with that last comment there - I don’t think it matters at all if the queue times are slightly off. At the end of the day, the queue time board really only serves to help you decide “ok let’s do it” or “woah nope not this time” - it’s a nice to know, but an estimate really is enough.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
×
  • Create New...