Properties with 0.0 rate

[rmascarenhas]

Description

When publishing a property, we need to set the initial nightly/weekly/monthly for it. However, for some properties such values are set to 0.0, causing Roomorama to reject the property.

Possible solutions

We need to double check our mapper to make sure it's correctly mapping the data. It could be an issue on our mapper, or on their data, but we need more investigation.

Occurrences

#304683, #303098

[leandrocg]

Maybe this happens because the property was not available (marked as "on-request") at this time.
If so, we could make estimate those values by quoting price for few weeks from now.
Unless the suspicious data property is published, the impact is low.
@sharipov-ru Any comment?

[sharipov-ru]

Before starting discussion on this topic, let me first remind the overall strategy for setting prices for SAW properties / units.

Firstly, metadata worker performs SAW Search API calls, and the response includes price column for every property. This price column is the same as SAW show for their users on the search results page. On their site this price is called as lowest nightly rate, so this price is just the first estimation without any connection to specific unit in property.

However, sometimes price is returned as 0.0 for some properties.

Some numbers:

Staging:

• Number of properties (all, including on request properties): 368
• Number of properties with 0.0 price: 287
• Number of properties which have price set: 81

It's important to mention that 329 properties from 368 are on request, so sometimes they return prices by Search API endpoint even when property is on request, which is positive news for us since we would be able to import more properties to our system with existing estimations.

Production environment is a bit different in numbers:

• Number of properties (all, including on request properties): 334
• Number of properties with 0.0 price: 11
• Number of properties which have price set: 323

So positive news here is the fact that almost all properties have this price value set and only 11 properties from 334 haven't. We just haven't these numbers before because we ignored those properties which are on request.

Next. Let's talk about rates for property units because price column from the above is just first estimation.

To fetch rates for units we currently perform bulk rates search API call with 20 ids on every request. This endpoint return prices only for units which currently are not on the request and very often this endpoint doesn't return rates for units in property because most of the property units are on request.

Currently, when we fail to fetch specific rates for property units, the very first price from property is used for every unit in this property. which means that for most properties we would have one price for all units inside property and the exact price will be fetched only while quoting price.

So that, continuing what @rmascarenhas suggested in the first post:

We need to double check our mapper to make sure it's correctly mapping the data. It could be an issue on our mapper, or on their data, but we need more investigation.

I can admit that 11 properties from 334 on production have no any price estimation and it's not currently issue on the mapper side.

And answering @leandrocg's question:

we could make estimate those values by quoting price for few weeks from now

Unfortunately, I failed to find any dates when those properties available and return prices. This ids are: [2957, 2540, 2825, 2823, 2824, 2941, 2960, 2974, 2976, 2970, 2763]

I suggest to ignore these ids (maybe hardcode it all) and move on without those properties for the beginning.

[keang]

Rollbar issue:
https://rollbar.com/Roomorama/Concierge/items/286/