Hacker News new | ask | show | jobs
by jordancolburn 3209 days ago
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.

1 comments

> 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).

Well, those sales were almost 7 minutes apart. I just looked, and the next sale was at 2017-09-11T17:59:24.000Z, so almost 15 minutes later.

> 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.

Stubhub lets you limit the shown tickets to specific zones, sections, price ranges, quantities, etc. There's no guarantee that the latest sales would be visible in your normal display. That said, if they really wanted to deceive people and make them think there was a sense of urgency when there wasn't, they could search through all the prior transactions for this event (~ 100 so far in the last 24 hours) for items that more closely matched the price and/or section and/or row to make you think that what you're looking at right then is what's selling, even if the transactions were from hours ago. Limiting themselves to what I think are likely the two most recent transactions and being completely transaparent about the section, row and prices the were sold at is fairly straightforward if you ask me (and more than you'll get on some primary markets, such as TicketMaster, where promoters will withhold large chunks of inventory to make the event look more sold out than it is, only to release them closer to the event date).

> It seems pretty clear to me that it was designed to create a sense of urgency to the user.

Sure, but what they're trading for that is real market information, which is useful for the user as well. It's a trade, not necessarily a deception or manipulation.

> 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.

So here's a question, say you're Stubhub and you want to indicate the last two sales, so users know what's selling and to hopefully influence them to buy now. You don't want to show all sales, that's proprietary information, and only a certain amount of history is even provided to those people with accounts selling for that event. How do you integrate that into the page display in a way that is noticeable, doesn't detract from other useful elements to much (such as a designated section when there aren't any recent sales, which could possibly be used for more room to show the map or listings), and can easily be added/removed as needed?

I think given those constraints, which I think are likely and not very extreme, the method they chose is a fairly natural choice, even if it doesn't make everyone happy.

> but the intent of this code seemed pretty clear to me and I was able to continually able to bring up already sold tickets.

Careful with attributing intent, or thinking you completely understand all the implications of that intent. There's a lot that goes into something like that and sitting down with someone responsible for it and understanding their position, thoughts and reasoning might change your opinion on the matter even if the intent is the exact same. Imperfect knowledge of complex systems leads to imperfect understanding actions within that system. We have different opinions on what is going on here, but that might just be because one or both of us is missing information that the other has about how the system functions as a whole. I, for one, see this almost entirely in a positive light, now that I believe I understand some of the details of how it functions. It's not fake data being presented, and it doesn't seem to be cherry picked to create incorrect assumptions in the buyer. I think it's the most recently sold items, and while the signalling isn't perfect, I would much rather have that data available than not.

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).

Fair enough, and some of those are good points that I perhaps wasn't giving enough credence to, particularly the first. The others have weight, but I think that weight canby mostly or fully mitigated by common business or implementation reasons (as noted previously).