Where our competitor prices come from — and why we stopped collecting them
· 5 min read
The first version of this post described how we collected competitor prices: a single query scenario, work done at night, delays between requests, respect for robots.txt. Six days after publishing it we switched the feature off. What follows is what stands in its place — and why we think it turned out for the better.
What the terms say
Booking.com forbids automated collection of content outright in its terms of use. Nocowanie.pl requires separate consent, which we did not have. These are not grey-area clauses or a nuance open to interpretation — they are sentences written to be read literally.
You can ignore them. Spaced-out requests, at night, without circumventing any protection, look innocent and technically work. For a few weeks that is exactly what we did.
Why we stopped
Because a product whose only distinguishing feature is the honesty of its numbers cannot stand on data gathered against someone’s terms. This is not a lawyer’s argument — a lawyer would talk about the size of the risk. It is an argument about consistency: it is hard to explain to a host where every złoty in a recommendation came from when the answer to the first question is „from somewhere we were not allowed to take it”.
On 31 July 2026 we removed the collection runs from the job scheduler. We did not silence them behind a toggle that could quietly be switched back on — we removed them. The price observations gathered earlier were deleted from the database.
What it cost us
A great deal, and there is no reason to hide it. We lost the market median calculated automatically for every night. We lost the property’s price position against its competitors, calculated without the host lifting a finger. Three factors in the pricing engine that rested on that data stopped working.
What remains is what we calculate from the host’s own calendar: the rhythm of the week, how fast a date sells, how far ahead bookings arrive, free nights wedged between occupied ones, regional seasonality from open European statistics, and a curated events calendar. All of it works from the first week after the calendar is connected, and none of it depends on anyone sharing their prices with us.
Where the competitor median comes from today
From what the host enters. The panel has a competitor review: you open the portal where you list the property, look at a few offers you consider your competition for a given night, and copy the prices across. We take the median of those and immediately recalculate the recommendation.
This is slower and costs a minute of work. It has two advantages the automation never had. First: the host decides who counts as competition — and they know their own neighbourhood better than any radius in kilometres. Second: the act of looking at someone else’s offer is performed by a person browsing a website, like any other visitor.
What the host gains
No number in the panel comes from someone else’s service against that service’s terms. If you ever ask us where a particular value came from, you will get an answer that needs no excuses.
Tools that show neighbour prices automatically have to get them from somewhere. It is worth asking them the same question and comparing the answers — that one question says more about a vendor than an entire feature list.
Will it come back?
Only with consent. The adapter code stayed in the repository in case one of the services agrees to share data with us on clear terms. Until such consent exists we collect nothing — and we say so plainly, rather than counting on nobody asking.