After the previous rules, another key element is : "Over what period of time should the user run the queries?" This parameter is directly linked to their booking pattern by arrival dates and their advance booking.

Anticipate further as possible the market watch to get alerted as early as possible.

If most of the reservations are taken within the 1 or 2-week before the departure date, it may be sufficient to get a rate shop for the upcoming 3 or 4 weeks ahead as more than 50% of the reservation will be booked during this time. For a reservation trend starting 2 or 3 months ahead, it is required to set the query much more in advance. And this is even more important when a key departure date is concerned.

For mainland Europe, the first day of school vacation or a long Public Day Off weekend must be checked with caution. With Rateshaker and QL2 as the data provider, it is possible to configure the query not only on a rolling day of departure but also on some fixed departure dates (ie Easter weekend, May week-ends, Summer vacations starting date, etc).

In these particular periods, your business analyst must know precisely the booking behavior of every channel and market segment: Tour Operators and Brokers usually book in advance while a direct customer may wait longer to confirm their stay.

Fortunately, with Rateshaker, it is possible to mix a set of rolling dates with fixed departure dates. The user can control the market prices for the upcoming 12 or 16 weeks ahead as well as having a look already at the Summer vacations and upcoming Winter hot departure date. For example in South Africa, the Christmas vacation starting date is key; therefore it has to be shopped all year around. It is also possible to reduce the number of rolling weeks and increase the number of fixed dates to remain with the same number of queries. When the first fixed date is covered by the rolling interval of dates, your business analyst will set the new fixed date to be shopped and thus will remain with the same number of queries. But using this way of configuring the rate survey required a bit of advanced expertise to configure regularly the two different sets of dates.

Previously (check rule #3), we already had 450 queries set. Now we need to add the number of rolling or fixed departure dates to the shop. If you want to retrieve rates over 16 weeks ahead (12 rollings and 4 fixed), the new computation is 450 x 16 = 7200 shops for weekly delivery. If the user wants to get data twice a week, the total number of shops is simply multiplied by two.

‍