BMOrg’s latest post on ticketing does nothing to quell doubts about the motivations behind Ticket Hell. Taking us on an emotional roller coaster from hell, and generating and focusing a massive amount of psychic energy around a totem, are clearly uppermost in the minds of the rulers of Burning Man:
it takes time to process all those transactions. Maddening time. Anxiety-inducing time. Time people spent on an emotional rollercoaster from hell, as they waited helplessly to see whether or not the winds of fate would blow a golden ticket into their hands. And during this time, probably more intensive psychic energy was heaped onto one single thing than anything else in Burning Man’s 29-year history: The Little Green Man.
The Little Green Man (yes, we’re capitalizing it, shut up) was the little dude standing, strolling or running along the progress indicator bar, marking one’s advancement through the ticket queue. As ticket-seekers urged him on with a fervor worthy of a filly at the Derby, he ascended to the level of a little green mythical being of possibility that would make the average totem, rune, relic or fetish (wait for it…) green with envy.
So wait a minute – one of the world’s largest occult rituals, with a city of 70,000 people anchored around the symbol of The Man, sitting awestruck as the effigy burns – and even that doesn’t generate as much “intensive psychic energy heaped onto one single thing” as this ticketing process?
Most people wouldn’t consider the idea of making someone “green with envy” over a magical symbol like a totem, rune, or relic, as a thing to brag about. We are investing all our psychic energy into the alien-looking avatar of BMOrg’s creation, and being taken on an emotional roller coaster ride from Hell that puts us in a helpless position. This has been deliberately engineered, and now BMOrg are crowing about how well it all worked.
At one point there were Pac Man ghosts chasing the man:
The ghosts are yet another occult symbol. They emphasize the cycle of Death and Rebirth being celebrated in this annual sacrificial ritual.
Image: Emilie Ogez/Flickr (Creative Commons)
[Update 2/23/14/ 11:53am] – Reader JV informs us that the Pac Man screenshot above was Photoshopped, and posted on Burning Man’s official web site in the discussion forums as a joke.
In another post de-briefing us on the situation, BMOrg said:
Did the servers crash?
No, they never did and the ticket buying process was never stopped — the queue was intentionally paused (briefly) to allow the servers to catch up to the demand — and nobody lost their place in line as a result.
This conflicts with reports from at least 5 different Burners who got a message that Ticketfly went down. Here’s a screenshot from one of them:
If Ticketfly had crashed, and the system had to be brought up again, that would have explained why some who were in the queue at 12:00:07 or less didn’t get tickets, while others who entered around 12:10:00 did. The queue was re-started on a new server, and all the people in the original queue were left hanging. If the system worked as planned, then how did people who logged in later skip the queue? Ticket season here is no small feature, if you ever needed to rack your brain about choosing server for small business, then you know how quickly things get complicated and risky if your traffic exceeds your expectations.
Whether the system crashed or not, it is becoming extremely clear that this did NOT operate on a FIFO (First In, First Out) basis. People who logged in at seconds past noon didn’t get tickets, while people who logged in 15 minutes or more after did.
Why did some Burners get offered a $20 donation to make, and some a $40? Something is obviously segmenting Burners into groups, before they get to buy. Is this segmentation based on Burner profiles? If not, then how do they decide who gets shown a $20 donation and who gets the $40? Random? Or once the tickets are sold, the donation cost rises?
It should be: every Burner is equal, first come-first serve, process the transactions simultaneously. This is a computer system, after all. It’s not like we are all actually standing in a line at a ticket booth, waiting for someone to type in our details and get back to us. I can see no technical reason why 21,500 transactions couldn’t be processed in less than 10 minutes.
What about the massive waste of time from when they sold the last ticket, to when they let Burners know there was no point waiting in the queue any more?
Why were people held in line for so long only to find out tickets had sold out?
The system lets people into the purchasing stage, and then people purchase their tickets. Until they’ve all successfully purchased their tickets, it’s not sold out. If for some reason somebody doesn’t complete their transaction (bad credit card, they bail out, etc.), then their spot is given to the next person in line. So we don’t remove people from the line until all the tickets have been successfully purchased, because technically you still have a chance to get one.
While this statement may be accurate on the face of it, it’s not the whole truth. If you are #50,000 in the line when the last ticket is sold, there is no chance for you to get a ticket, technically or otherwise. The statement does not adequately explain how 60,000 58,500 people were kept waiting in line for 15+ minutes after the last ticket had been sold. It takes no-one 15 minutes to complete the transaction with Ticketfly, not everyone.
Putting the pieces together, it seems like what happened was the queue didn’t shut down because there was still soe inventory available. The inventory was the Donations, which were unlimited.
Were people given any advantage if they made a donation?
No, not at all. It was first-come, first-served for everybody.
Another statement that is clearly not true, according to hundreds of Burner reports online. Some people were logging in to buy multiple tickets for their friends, because they could get straight through while their friends were still waiting. If it was “first-come, first-served for everybody”, this would have been impossible.
we do actively weed out known resellers as part of the registration process (that’s one of the reasons we have you register for the sale).
An admission here that Burner profiles are screened, and “undesirables” on their list are “weeded out”. Do they ever receive a message, being told “your Burner profile has not been accepted because we know you’re a reseller”? Or are they just sitting there in the queue, waiting like everyone else, but with no chance to get through because their code won’t be accepted?
as long as people are willing to buy tickets at exorbitant prices (we wish they wouldn’t, but some apparently do), there will be a market for predatory resellers. It’s antithetical to our community’s ethos, but it’s also the reality of supply and demand (and technically legal).
“We wish they wouldn’t”…and yet they hiked the price of VIP tickets to $800 this year. I guess $800 is no longer considered “exorbitant”, so long as you give the money to BMOrg instead of a fellow Burner.
The lack of vehicle passes is looking to be a huge problem, they have leaped to $325 now on Stubhub. Some Burners are prepared to go to extreme lengths to get the little slip of paper:
We have no information that this is Susan, or that this camp is offering vehicle pass trades. It’s Burning Man, these things do happen…
Some Burners are reporting that Verizon customers got through much faster:
Verizon Customer Service: I was a Verizon Customer Service Representative for 9 years until I moved into management. Verizon has a camp at BM, but I can’t tell you the name. We’ve been working closely with BMorg to bring cell service and other benefits to the playa. I can’t tell you officially that Verizon customers get preferential treatment in the sale of BM tickets, but if I were you, I would change service providers next year to increase your chances.
There has been a great deal of discussion online about this ticket situation. Here are a few selected highlights from Voices of Burning Man:
IE How can there be a thousand scalped tickets? Do 100 people work for stub hub who have the back door secret? Who, besides the 1%, can afford to pay $1000 for a ticket, many many tickets? Something just seems out of line here. I feel your pain.
Hmmm, okay, I guess that was my surprise of the day. I wasn’t going to play the game this year, but decided ‘oh what the hell’. So at 12 minutes after, I got in thinking I had zero chance since I know everyone else starts within seconds after the hour. Guess what? Tickets baby!
We didn’t break any rules as the codes they used were from other friends and they purchased all of our tickets as they were getting through so quickly.
I was lucky (so much so that I had to check my confirmation email multiple times to make sure that it was actually real) enough to get ticket within minutes and was never put in the dreaded queue. At about 11:59 (2:59 my time) I clicked the link in the email and was told I was to early. I kept closing the page and re-clicking the link until the page changed. My memory gets little fuzzy here – to much adrenaline – but I don’t even remember seeing a green button. The page first said something about the site being down. So I refreshed. Then it said all tickets were already in carts! BUT HOW COULD THAT BE!?! Only a minute had gone by. I just kept refreshing the page until the ticket buying option came up – bingo, got one in about four minutes.
This is the same thing I did last year. Refreshing constantly. Didn’t get put in queue either. Got my ticket in two minutes.
Unfortunately out of our planned camp of six, only myself and my friend got tickets. The others will join the thousands of others in the hunt for one.
To all of those looking – best of luck and stay positive.
Also, all international tickets are sent out via post which is way better as there’s no need to spend hours queueing for Will Call!!
I’ve no idea why BMorg don’t implement a similar system, why keep trying to reinvent the wheel??
This further implies that the end of all the successful 21,500 sales probably occurred around 64.5 minutes after noon, i.e. the AVERAGE rate of processing of successful transactions was about 1,000 every three minutes, or FIVE PER SECOND.
This further implies that TRANSACTIONS WERE PROCESSED IN PARALLEL. i.e. there were MULTIPLE SERVERS (or AT LEAST multiple threads within a single server) processing the eventually successful transactions at any given time. We can estimate that the fastest an average individual could possibly complete the final purchase with confirmations of credit card, mailing address, etc would be 10 seconds, and a more likely upper average transaction time for an individual final purchase completion would be about 60 seconds. Since the eventual average processing rate was 5 purchases per second, this means that there must have been somewhere between 50 and 300 processes (threads within servers) handling eventually successful transactions ON AVERAGE throughout the sale.
But given the EXTREME variations in expected wait times that I saw during my 57-minute wait to get to the final purchase page, IT CANNOT POSSIBLY BE TRUE that there was no variation in server resources (e.g. due to server or thread crashes/hangs) during the first hour of the sale process, EVEN WHEN YOU ACCOUNT FOR THE “PAUSE” of the line (unless you assume that the algorithm to calculate the remaining wait time was complete bullshit 🙂
Because IF the allocation of server resources had remained constant (apart from the pause), and the average time taken by an individual to buy ticket(s) when they got to the final page remained constant, AND the remaining wait time algorithm WASN’T complete BS, then we should have seen expected remaining times decreasing monotonically throughout each successful purchasor’s sale process.
Because IF the position in the queue was determined by the server arrival times of the clicks on each user’s green button (in my case at about two SECONDS past noon), then effectively every eventually successful person’s position in the queue was determined WITHIN THE FIRST FEW SECONDS AFTER NOON of the sale, since on the basis of my experience clicking two seconds after noon (I synced my computer’s clock with the nist.gov atomic clock and had a display of that running during my purchase) and being probably one of the last people to get a ticket, there must have been over 20,000 green button clicks received at the servers within the first few seconds….
The thing that gets me (and probably most other people) emotionally wound up, is when we see (as I did), for over half an hour, that each minute my expected wait time is going down by a minute (so we believe all is going along nicely and we just have to wait) and then suddenly it goes up (as it did in my case) from 9 minutes to OVER AN HOUR, when we are MORE THAN HALF AN HOUR into the wait process. Changes like that CANNOT POSSIBLY be due to changes in the AVERAGE time taken by an individual user behavior in completing their purchase once they are on the final page, which probability theory tells us is EXTREMELY unlikely to change by a factor of two over many thousands of presumably similar buyers. It MUST be due to changes in the allocation of resources on the sever side (e.g. crashes).
So if the sale had proceeded per the theoretical “stable” model, by 30 minutes into it there should have been approximately 10,000 eventually successful purchases left to process. But my remaining wait time after waiting more than 30 minutes was shown to be 9 minutes (which would imply an estimated average sale completion of more than 1,000 per minute i.e. three times the final “official” average). But then it went up to “over an hour”, a change by more than a factor of six, which cannot be reasonably accounted for by changes in average user purchase time behavior.
On a technical note, there is really no need for the process to be as incomprehensible as it currently is. Since there is a pre-reg, it is trivial to load-balance ahead of time. In principle, if we expect 80,000 attempts to purchase, we can pre-allocate users to 80 servers, each of which only needs to process 1,000 requests (or equivalent architectures with multiple threads per server). The ONLY technical challenge is in fairly synchronizing across server queues, but if the clocks of the servers are synchronized, and arrival times of each user “green button click” are noted at each server down to the millisecond, then there is NO REASON WHATSOEVER not to make it totally transparent to everyone within the first few minutes of the sale EXACTLY what position they are at in the queue, EXACTLY what the average purchase processing time has been so far, and to show a REALISTIC view of how likely it is for their purchase to be successful given the current average number of tickets sold per customer, plus a REALISTIC and relatively predictably changing estimate of how long it will take to either get to the purchase page or find out that they have not been successful….
I’m a “glass half full” kind of guy, so I celebrate the fact that I was able to buy one ticket, but I still do think it was weird that I wasn’t able to buy two, and I strongly believe that the whole process could be dramatically improved…
People- My comments have nothing to do radical inclusion. This ticket thing year after year has nothing to do with radical inclusion. This is business making business decisions which for the life of me I don’t agree with.
Chip- Please help the rest of the org understand this, to give back to the loyal customers just like you did so perfectly at JDV.
Disappointed? Yes. But more just tired of this ticket game year after year.