In this section you can look for Business Intelligence module applications.
¶ Detecting a drop of bookings
¶ 1. Drop bookings with an agency
To detect a booking decrease in an agency, we should build Company name - Bookings cube as follows:
As we can see, the bookings of agency02 increase, those of agency05 decrease and those of agency03 remain stable.
To analyse agency05, we implement the following view of the booking cube, fixing agency05 and breaking down the agency in the different suppliers with the following screenshot:
Among the other measures that allow to analyse the loss, we may find the %MarkUp, that will help us see if, by increasing the prices, we have made our product less attractive, causing the booking decrease. However, we should particularly focus on the statistics cube, which enables us to see if a booking decrease is due to technical issues, occurrence of errors, etc.
¶ 2. Drop bookings with a supplier
To detect a booking decrease in a supplier, we should build Company name - Bookings cube as follows:
As we can see, the bookings of supplier 1 increase, whereas those of supplier 4 decrease.
Below, we will break down per supplier the agency that suffered the losses, to know if it is a general problem or something specific to a given agency.
In this case we can see that the bookings lose come from account 3.
¶ Detecting traffic changes in an agency
The traffic received by an agency may be analysed from Company name - Client Statistics History cube. To detect if there has been a change in the traffic that an agency sends, we should perceive an evolution of the traffic sent by each agency in the past few days.
In this case, if we compare the day 03/10 with previous days, we can see how:
- Agency 1, 3 and 4 have approximately the same traffic as the previous days;
- Agency 2 sends only 50% of the traffic compared to the previous days;
- Agency 5 is a new connection in the system, as it did not send traffic before;
- Agency 6 did not send any traffic on the 03/10. However, if we look at the same day of the previous week (26/09), it did not send any traffic either. That is why it seems to be its usual tendency.
In this case, for agency 2, which is the one that has reduced its traffic the most, we recommend showing the times, to know what the traffic decrease is due to.
In this specific case, we can see how the agency stops sending traffic at 12h. If it is not due to a scheduled disconnection, Agency 2 should be contacted to know if any problem has occurred.
On the other hand, this cube allows you to monitor the types of requests that each agency sends (Availability, Cancellation Policy or Bookings, among others).
¶ Data transfer monitor
The analysis of the data usage is performed from Company name - Client Statistics History cube, using the metrics found in the Size folder. Size GB Response is the most common, although other metrics can also be used.
If we wish to monitor the data used by each agency, we can also show the Agency field.
Moreover, you can see in which areas an agency has consumed more traffic durnt a specific period of time.
The GB of an agency are directly related to the product that is being returned to them. That is why, a change in the GB used by an agency is directly related to the following features:
- Traffic of the agency: if the agency requests more (the traffic increases), we probably return them more product.
- Configured time-out: the higher the time-out, the more product will be returned to them.
- Agency template: the bigger the template, the more hotels the agency will request, and, in most cases, the more product will be returned.
- Way to request for an agency: each agency requests different types of information to make a booking. For example, they may request only the cheapest room, all the board types, hotel photos… These different ways to request have a direct impact on the GB of a client.
¶ Common errors
¶ 1. Configuration errors
Whenever there is an error related to the configuration of the parameters of an agency, this may be seen in Company name - Client Statistics History cube. To detect them, the Request type and Error dimensions should be reduced, as, in this way, it will be possible to determine at which step of the request the anomaly occurred.
The Common errors are:
-
Invalid IP: this error occurs when an agency is sending traffic through an IP which is not properly configured in the system. To solve it, we should identify which IP is returning the error (under the IP field).
To solve the error, we recommend contacting the agency or integrator associated to that IP, to check that it actually belongs to them and, if possible, to request a log of the response we return them through this IP.
Afterwards, you should contact the PM or XML team (xml@ejuniper.com), to set the appropriate configuration for the IP that returns the error.
-
Invalid nationality: in this case, this error is returned because one or several agencies are requesting a nationality that is not allowed to them. To see more details of the error, we recommend dragging the agency, to know which one requests an unallowed nationality.
For example: if we have the agency Juniper in an agency group that we do not allow to book from Spain, when the agency Juniper requests from Spain, this error will be returned.
-
Invalid currency code: just like in the previous case, an agency requests us a currency with which we do not allow them to book.
-
Invalid customer: an agency to which we deny the access is sending us traffic.
For example: if the agency Juniper is disabled but continues to send traffic, the traffic received will be registered with the Invalid customer error.
¶ 2. Price changes errors in Cancellation policy or in Booking
Let us put that a specific agency complains that we are returning a lot of errors in cancellation policies. In many cases, this problem is related to a price changes error.
This is usually due to the fact that the supplier has changed the rate, but its technological system has not updated it in the availability requests (Availability). This problem must be addressed, as it generally causes upset to the agencies that receive this price changes, and may hinder the business relationships.
To identify these errors, we can go to the price change cube, and see which suppliers and hotels are causing the conflict.
To do so, we will drag the Changes and Requests measurements to the value box, placing the Date field in rows, and the Module and Product Code fields in the column box, while filtering in the Customer = [Desired agency] field. Additionally, we can filter by Interface, if we wish to break down the errors by XML or Web interface, channel, etc.
In this case, we can see that, among all the connected suppliers, only one is returning price changes. We should check from the booking cube if this supplier is generating bookings with this agency. From that moment, different cases may occur:
- If the conflictive supplier is not generating bookings, and the business relationship with the affected agency can be at risk for that reason, the most drastic cure might be to disconnect the supplier.
- In many cases, the supplier that is causing the problem generates bookings at the same time, and the solution is not as easy, as it would not be advisable to disconnect such supplier.
In such circumstances, it would be less invasive to block the hotels affected at the moment. Indeed, it would not make sense to block hotels that returned price changes errors over the last few days, but no longer do.
¶ Hotel requested information
The analysis of hotel requested is performed from Company name - Statistics Hotel and Company name- Satistics Hotel Client.
You can select different views depending on the aim of the analysis.
¶ 1. Requests to a supplier
If you want to see the total hotel requested from a specific supplier (in this example to your own product) you can use the following view:
¶ 2. Requests by an agency
This information can also be analyzed by agency, so you can see which are the hotels requested by a specific agency from which suppliers.
¶ 3. Correct or wrong responses
If you want to see the number of correct and error response by a supplier on a specific day, the following view can be used:
¶ 4. Requests by travel date
It may also be useful to analyse supplier availability by dates. For example, if we see a hotel with a high perfentage of KO requests, you can see if it is only during specific dates or in widespread. In case of being on certain dates, it is probably due to contract issues and, through this report, you can alert which hotels are being requested without fares.
