jordancolburn

LinkedIn: All the creepiness of a social network, with the addition of all the pushiness of a recruiter.

I appreciate the thorough response. It did make me stop and think about my assumptions. You present some convincing points,but I still come to the same conclusion because:

1. The sales stop showing after the first load and the values are saved in application storage. Why would they hide them if they are so valuable to the user. My guess is that users would be annoyed to constantly see these values and the users would catch on that they are only "recent" and not "realtime" sales

2. Why are the recent sales randomized in their location on the list. If it is such valuable info, why are they not placed at the top every time. Again, b/c users would ignore them and quickly learn they are not real-time sales.

3. If it so valuable to users, why not present it in a special location such as its own list. Why would useful pricing data be randomly put into the top of the list. Again, users don't really care so much about what recently sold as much unless it affects what is available now.

4. As SH, you have the option to show people recent sales, or how many tickets that are left. But to only show two recent sales and do it in a way that blends with other tickets is a deliberate choice to manipulate the user in a way that does not coincide with their expectation that those tickets shown to them on load where available when the page was loaded.

Basically, this "feature" was a combination of many design decisions and all of them lean toward cues to the user that these items are "real time" sales that just happened since we loaded the page, and away from helping the user realize the true nature of these sales. And of course it is done in a way that benefits stub hub and not the consumer, which is upsetting from a place that presents itself as a "marketplace", since users expect transparency from them (the price you list is the price, what I am told is available is available).

They are showing tickets that recently sold. Just regardless of whether or not they fit in your searches and whether or not they knew they were already sold at the time you loaded the page.

They are going out of their way to insert previously sold tickets at the top of searches to make things look busy. I never timed how long it could be from sale to "simulated sale" but there were a few that stuck around for probably 10 min (guesstimate, but it was long enough to grab my coworkers and discuss and look at the code and refresh a number of times).

I did think that might be the case. However, after deleting the IDs multiple times, the same sold tickets kept popping up, even minutes later (didn't time it exactly, but it was a while).

So, why don't the sold tickets follow the sorting rules, they are inserted at the top. And why is it limited just to 2 of these unsorted previously sold items at the top and not just mark them in their place on the list if they have since sold. It seems pretty clear to me that it was designed to create a sense of urgency to the user. Another user on reddit also reported that they saw items that did not match their filters at all but were somehow inserted on their list.

I am 100% open to the fact that poking around for 20 min or so might not lead me to a complete understanding of their system, but the intent of this code seemed pretty clear to me and I was able to continually able to bring up already sold tickets.

Company responded and said they removed the "feature". They confirmed to me that it was part of an AB test (which I had seen in the code), but did not confirm or deny my suspicion that the AB was used to apply it only to events where it was less likely to be discovered.

I was half-jokingly going to ask for tickets to the game, lol. But after they requested I post an update and clarify their response to removing the feature, it just felt wrong. I mean, I'm glad they removed it, but that's a pretty big thing to act like it should all just be OK and it's a "feature" users didn't like. And I think their urgency in removing it only shows how bad it really was, not how concerned they are for users.

https://twitter.com/StubHub/status/907384565085257729

Maybe, they had some other junk about AB test flags and I didn't dig far enough to see how that was set or if it was random from the server. My wild guess is that they turn it on for popular events close to the time of the event, so there is less chance of users noticing.

I was pretty surprised, but maybe they were hoping for security by obscurity as it was buried a little in the sources. I don't think devs as a whole have really grasped a lot of the trade-offs/repercussions of moving so much logic to the client side.

Good point. Races (5k, marathon, etc) do that also to encourage people to sign up early. I think it's dumb, but at least the festival tier thing is honest.

It's the dishonesty that kills me. The reason I think I was bugged enough to look into it is that I fell for the trick. I knew it's going to be a sold out game, so I assumed it was real traffic/user actions and almost let that influence my purchasing decisions.

I actually didn't catch that typo they made the first time as I was so shocked at how easy it was to force it to keep reloading already sold tickets.

Yeah, but to stick with the analogy, isn't this more like putting out empty boxes of TVs that have already been sold and having employees dressed as customers frantically buying them in front of regular customers.

Thanks for reading btw, and thanks to whoever posted it here.