Hacker News Reader

Comment by rixed | Hacker News Reader

When I worked there a few years ago, I was actually surprised to discover that all these teasers were actually factual, including the "X other guests are looking at that hotel" and "Y rooms already booked in the last X days". But the way they are phrased can definitively be misleading, which is what the article is about.

It's at the same time great and sad that no single sale genius is behind those teasers, though, as virtually anything can be tested online by anyone and only actual bookings will decide what sticks. It used to work the other way too: once a particular phrasing have been approved by the A/B experiment engine, it's very hard to get rid of it. Unless there is a new regulation of course. Regulations were also taken very seriously, but to the letter. Meaning those dark patterns will likely stay online whenever they are not regulated against.

View on HN

I ran my holiday apartment through booking.com for 18 months, until a week or so ago - 95% of my business comes via Airbnb so the additional channel just didn’t make sense.

One thing I can tell you is that the “x guests booked” absolutely isn’t true, as it would frequently say so about my apartment when I hadn’t had a booking in months.

Maybe it’s true in some cases, but there’s definitely some fudging going on.

Giving them the benefit of the doubt here - could they have been counting you blocking off dates for bookings made through other channels?

> One thing I can tell you is that the “x guests booked” absolutely isn’t true, as it would frequently say so about my apartment when I hadn’t had a booking in months.

Did it specifically say "X guests booked at this specific apartment/hotel"?

Not explicitly specifying the place would seem like an easy way to have a technically correct statement, while being extremely misleading. E.g. maybe it just meant bookings in the same city, despite showing that text beside your apartment.

It could make sense because you are at constant risk of deplatforming and having a second provider is a backup plan. Unfortunately it's really rare to be able to get bookings from two platforms in a balanced way. I'm still trying to understand why. Any ideas?

Channel imbalance is inevitable without conscious and active management to prevent it. I used to run an ecommerce platform, and saw the innards of a lot of merchants. In a nutshell, a winning channel will see snowballing resource investment, and a losing one will be starved. You can force parity, but it usually comes at the cost of overall volume.

Boils down to risk mgmt vs revenue - and all but the most conservative businesses will choose revenue.

In my case, I absolutely starved booking in favour of Airbnb, as Airbnb was much faster out of the gate. So, I have platform risk, but revenue is good.

How did you starve Booking? Didn'it just happen?

My point is that in this market it's really hard to attain channel balance.

It seems the OTAs alghoritms absolutely favour cannibalization.

I didn’t actively manage pricing, which I do on Airbnb - and had to charge a lot more on booking for the same revenue, as their commissions are fairly astronomical, if you want to feature anywhere other than the last page of search.

Wow, that's surprising. I would have bet heavily on those messages being straight out false. I have seen the "3 other guests are looking" message in hotels in quite off-track places and seasons, when booking well in advance. If that message is true, I guess I just underestimate the size of the market and/or the number of hotels that people will browse before booking.

I wonder if some of those "guests" are website scrapers or other automated systems from competitors that are looking to get pricing info.

I wonder if some of these automated systems are ran by booking.com, or someone contracted to run them? Too cynical?

I worked for a competitor, and the amount of time+money we spent blocking scrapers was insane.

The reason we spent all that time+money? It affected the metrics on which we were paid, AND consumed a huge amount of compute resources of ourselves and partners.

It's also (at least in part) why places are doing the "Sign up to see special offers" thing - because the offer isn't for display on the open site, and they don't want that value to appear on scrapers. So... logged in users only, and validate that user isn't doing scraping.

Why not offer a public api? Logging in seems like a small hurdle for a bot but enough of a hassel that customers lose interest.

We did have an API, but it wasn't public - because search traffic is expensive. Both, as mentioned, in compute resources, but also in pissing off and/or outright crashing vendors.

Logging in - requiring an email validation loop - would be simple for bots, but again, anti-bot tech stops them from doing it en-masse.

> AND consumed a huge amount of compute resources of ourselves and partners

Wow, I'm interested to know more here! How much bot/scraper traffic was there that it cost you big on compute?

I don't want to give away too much detail - Company IP, self identifying, etc.

However, lets just say that if normal peak traffic is 1X, then bot traffic can come in at 100-10000X. And in most cases it's not a smooth rise, it'll be a case of suddenly all this new traffic came in, no warning, no rise.

How many non-trivially complex sites do you know that can suddenly take 100-10000X their normal peak in under a minute? Those that do - are their managers happy about spending on idle infrastructure?

How fast do you think even services like AWS can scale? (hint: it's not fast enough).

Normal traffic is, in aggregate, quite predictable in load. Outside of very unusual situations, you don't get hundreds of thousands of people suddenly hitting your site.

Plus, because that traffic is nice and predictable, you can have decent caching rules, reducing the cost of the traffic again.

Along comes Mr Botnet and they want to scrape everything: every hotel in every city, every checkin/out tuple for stays of 1-7 days for the next 12 months, and a bunch of room configurations.

Kiss your caching goodbye, because now not only is your cache hit ratio for their searches going to be effectively zero, but now it's being filled with other shit that nobody else wants.

And this is just our infrastructure. There's the third party OTAs that we hit, and they have the same issue, often with smaller and less experienced teams running on crappier infrastructure. So, you get angry calls from them that their shared hosting provider is cutting them off and you're ruining their business. Because of course, this shared hosting is not only hosting their room availability search API, but their hotel check-in and sales applications - so nobody in 30 hotels can check-in/out.

Thanks for the detail. It's just mind-boggling to me that you could have a peak of (for example) 1K requests per second, then a bot rises that to 10M requests per second.

If nothing else, it seems incredible that bot authors would be so willfully harmful - they must know that kind of behaviour is going to prompt a reaction

I don't think even google crawls the whole www with 10M rps.

This wouldn’t be a problem if these companies offered an API to access their data. But of course, that wouldn’t be good for a business which ultimately depends on information asymmetry and walled garden lock-in. Personally I’m not a big fan of these business models (see LinkedIn for another example), but I at least understand where they’re coming from. I also understand it’s sometimes out of your hands, i.e. the hotel partners don’t want you to make the data easily available. Similar incentive structures exist in flight booking and geoblocked Netflix content.

FWIW, I’ve been on the other side of this (not in the travel industry), and written scrapers. I never scraped the HTML, though. My strategy was to MITM the mobile app and use the same API. I also made sure to throttle the traffic, if not to be respectful, at least to blend in without setting off alarms...

> This wouldn’t be a problem if these companies offered an API to access their data.

Sorry, but you're talking about something you have no idea of.

The impact on that platform of someone using the API vs crawling the site is approximately the same.

Whether someone scraped us via the API or via the HTML made no difference in terms of impact on the platform.

> Sorry, but you're talking about something you have no idea of.

This kind of personal attack seems unnecessary, and by the way, I probably know a lot more than you assume about this particular topic.

Regardless, if you had an API, you could charge for it. It wouldn't cover 100% of the scrapers, but it would cover some.

My intent was not to attack you, but to respond to your assumptions about the business model, and your comparisons to geoblocking and LinkedIn's anti-crawling stuff.

There were APIs. I won't go into the business relationships that existed over their use.

There were still scrapers, regardless.

We also had problems with scrapers using our data. We contacted lawyers, got advice to plant extra messages to get evidence. They then took care of it and the problems have slowly gone away. Cache now works much better. Not fun when you spend a lot of time and money to accumulate data and someone thinks they should have it for free.

If you put the data on the internet, and it’s accessible at a public address, it’s free. If you don’t want people (or robots) to access it, don’t make it public.

You might be interested in the case of LinkedIn vs HiQ [0], which is setting precedent for protecting scraping of public data.

Based on the fact that you “inserted special messages,” it sounds like the people scraping your site may have been republishing the data. That is a separate issue that in some cases can violate copyright. But in that case, it’s not the scraping of the data that is the problem, so much as it is republishing the data outside the bounds of fair use.

I am of the strong belief that if you make your data publicly available to users, you should expect bots to scrape it too. If your infrastructure is setup in a way that makes traffic from those bots expensive, that’s your problem. The solution is not to sue people or send them letters. You can mitigate it with infrastructure changes like aggressive caching, or you can charge for access for everyone, not just bots. IMO, it’s especially wrong if you allow google to scrape your data, but try to stop every other bot from doing the same.

[0] https://www.eff.org/deeplinks/2019/09/victory-ruling-hiq-v-l...

> You can mitigate it with infrastructure changes like aggressive caching

Rate data has a very limited validity period. Customers get super super pissed (and assume you're scamming them) if when they click through they find out that the hotel/flight/whatever that on the previous page you had said was $200, is now either $250 or sold out. Customers, and the local authorities also tend to get lawyers involved if it happens (in their eyes) too frequently without a good explanation.

It's expensive to get that rate data, because unless you have your own inventory, you have to go out to third party APIs to request that rate for the search parameter tuple which has a specific checkin/checkout dates. When you're searching larger cities - where you might have thousands of hotels - that can be an insanely large number of API calls to return rates.

Most places (including my former employer) don't have a problem issue with scrapers, so long as they didn't abuse the platform to the point that it was causing a ton of extra load. When you have someone who spins up huge numbers of connections at once, that's when we have to do something about it.

> you can charge for access for everyone

That's implicit in the purchase process.

It's like if there's a little cafe that provides free water and tables to sit at on their balcony. That works out for them because it attracts customers. Not everyone might buy something, but most do.

Then someone who runs a dog walking business decides to make that a stop on their walk with 20 dogs. Their dogs eat all the treats, run around the balcony, while the walker sits at the table and drinks the water. Meanwhile, customers are annoyed that there's now 20 barking dogs running around and so they leave.

The business is well within their rights to tell the dog walker to leave and not return without also blocking others who aren't abusing the system.

"My strategy was to MITM the mobile app and use the same API."

Did the app use cert pinning

What percentage of apps actually use cert pinning

A fair amount of apps use cert pinning, not sure on the percentages. It’s easy to circumvent if you have a jailbroken device. I haven’t done this in a few years but there used to be something called SSLKillSwitch for jailbroken iOS which would hook the HTTP request method to remove the cert pinning.

> Sign up to see special offers

Another reason why they do that is because their partners require they don't advertise special pricing to the world at large, they're contractually forbidden from doing so.

As you might intuitively conclude, Booking and its competitors invest quite heavily into detecting real vs. bot traffic. Often, sites will block bot traffic or degrade the content. Booking is very torn on that because they don't want an arms race. When I worked on the experiment tooling, we very much preferred to have more, but tagged bot traffic than less and undiscovered. That's because for the experiment analysis, the undiscovered bot traffic was poison.

True the are lots of booking scrapers like trivago

There's actually many things that I hated about travel sites, and then I worked at a "travel tech" company and it changed by perception of the industry as a whole. Part of the issue is the suppliers themselves. Bcom, Expedia, Kayak etc are all at the mercy of what individual hoteliers and airlines report. I've seen data issues where hotels will report little/no inventory, and we investigated the issue and it was on their end (user error, oops). Or, a huge party booked up the hotel, but users were angry because just 24 hours before, we showed N open rooms, and now we have almost nothing.

Issues like this happen all the time, and the debate always centered around messaging. We would love to tell users why something is unbookable, but trying to figure out the details with suppliers ended up being near impossible.

That being said, OTAs do have their own set of issues to answer for, including misleading messaging, scummy sales tactics, etc.

I’ve recently joined travel/hospitality tech company adjacent to but not exactly the same as the core booking segment. What you said about investigating a lack of vacancy coming from the Hotelier/user error I would suspect has to do with poor PMS integration. You probably know some of the same vendor names that I do.

For those unfamiliar, think of a Hotel’s PMS system like an ERP platform but for hotel operations and associating guest services with guest billing info. Buy the high-speed WiFi instead of using the slow free WiFi? That goes to the PMS and tells the hotel to bill you for it (if they don’t farm that out to a third-party who bills and remits on their behalf).

Anyhow.

I’ve come to learn, without naming any of my clients publicly that technology integration in hospitality (I specifically refer to household name hotel brands, not necessarily brands associated with ordering reservations like Expedia and Booking.com) ranges from exceptional but difficult to horrifying but trivial, and a common source of my personal frustrations as a product manager for our specific services (which require integration to these PMS platforms) is incomplete or inaccurate data produced by the property or hotel brand THEMSELVES

I feel your frustration.

Totally! I agree with everything you've said, their relatively lack of tech sophistication a huge PIA and it causes us daily headaches.

In addition, I've noticed that their hardware and software is often terrible, non-performant or buggy. So when we try to interface with them, we need to do hacks like severe rate limiting and long term caching of inventory (sometimes 24+ hours), simply because if we wanted to run at the TPS we run at, they would tip over. This leads to stale inventory on our end, and customer anger. We would love to do everything live (with short term caching), but the suppliers just can't take the load. Just about the only direct call made is the booking one, everything else is stale by some amount.

Monitoring/logging is often non-existent, so when you say "hey we're seeing latency" they have no idea how to diagnose or fix. Often, they don't have metrics in place and are unaware that there is latency to begin with.

> incomplete or inaccurate data produced by the property or hotel brand THEMSELVES

I believe it's largely because the RPC soap calls that many of these integrations use are stateful, so making the same call over and over again can lead to different results. Much of their tech stack is stuck in the 90s/early 2000s, and it shows.

I can confirm it was also true for a competitor.

It doesn't say anything about when they are looking for. It's a lie by omission.

I believe the alerts false, statistically speaking, these alerts don't make sense. Every room you click is in an end-of-world situation where you have to book now otherwise "who knows" and 5 days later the same amount of rooms is available and the same exact scenario is presented for all rooms/hotels.

ps. What I usually do, is look at booking.com for hotels at cheaper prices and then head to the hotel's website. They usually have more categories of available rooms and at a cheaper price.

I guess this heavily depends on markets. I'm often frustrated by the hotel's reply: book on booking.com

Wasn’t there an article, recently, maybe for another website, that these were generated client side with Math.random()?

I seem to recall this too, as well as others claiming to have worked at booking.com saying these things were knowingly false.

Edit: it's quite possible that I'm mixing up memories of a company other than booking.com

Would love to see an example of a booking employee (current or former) claiming they're false. I looked into a number of them first hand and they weren't (last I did that would've been 2016/2017 and certainly didn't audit the entire code base).

Sorry for the self reply, some context. The reason I looked at a number of these urgency messaging implementations is that we'd gotten a bunch of allegations from legislators that they were wrong. I was in a senior enough position that I would've been able to push back on anything dodgy/outright lying I would've found. I didn't find any that were incorrect.

That was CheapOair, a brand of Fareportal. Different company.

I remember reading that article at some point in the past. Pretty ridiculous, having a customer lie to themselves. I can’t remember what site that was, either.

It was either Math.random or it was a request that always got back the same number. It was posted on here; I remember it clearly.

I've interviewed for Booking.com and even the girl on the phone couldn't make their process appealing (tons of Perl; no plans to migrate to anything not perl, very few tests, very little code review, developers can push straight to production .. seems like a hell shop).

There are currently plans to do new stuff in Java. A rewrite of the old code base is impossible.

Most of your code will be deployed as an experiment, so you are more likely to throw away that code instead of refactoring it.

Developers can push to production, and are expected to be responsible for the results of that push. It works quite well.

That's not what three former Booking.com folks I know have said. There's a striking unanimity to their descriptions: risk-heavy day-to-day work ("experiments" not being nearly as firewalled as you might hope), a consistent level of incuriosity amongst line developers and their leadership (which, not gonna lie, "new stuff will be in Java in TYOOL 2020" does a lot to buttress), and rotgut technical-debt Perl that will never be rehabilitated (ditto). Also an HR department that plays real hardball if you're not an EU citizen.

(I used to work in the travel space, at TripAdvisor, but that was about eight years ago; no other affiliations.)

Well, everyone is of course entitled to her own experience, but for what it's worth I think Booking has been one of the most interesting place I've seen, not in small part because of how data driven they are, as opposed to myth driven like most IT business/people.

One of their mantra was indeed "we are not an IT company", which I came to understand as "we don't want to hear about how things ought to be done. We do not bow to best practices. We rely on measurements not culture".

After a few years in a big corporation where you couldn't change more than 3 lines of code without 2 code reviews and approval from 2 managers, without ever considering the customers or the final product, moving there was such a relief!

Usage of a runtime typed, interpreted language for so many loc in production was of course concerning (esp. Perl which syntax and semantic are sometime surprising), but the attitude considering of caring more about measuring and controlling every possible effect than following the best practices of the day is invaluable.

This is definitively a place I would recommend to any engineer willing to learn.

I think it was this series of tweets:

https://twitter.com/OphirHarpaz/status/1184486445039411201

There was an article that ran a few months back here about how most of those teaser numbered were backed by a rand() function

Reply on news.ycombinator.com