He joined Qunar in 2016 as a Java developer. Excessive exposure to front-end technology. At present, I am mainly engaged in back-end development work, and part-time work related to data algorithm engineering.
For a commercial product, profit is not the only purpose, to solve the demands of users, to provide better services is also one of the core purposes. In this article, we will talk about what we have done to provide better service to our customers in one year at the international hotel.
1. Business background
The end of 2018 to the beginning of 2019 is a relatively important time node for the business of international hotels. International hotels are dismantled from the hotel business to establish a separate business division. Before 2019, the domestic and international business of the hotel is a unified whole, and the system structure and developers behind it are basically unified. However, there are actually many differences between the two businesses.
Take international business as an example: first of all, international hotel not only refers to the international business, but also includes Hong Kong, Macao, Taiwan and other domestic and overseas business, that is, the actual distinction is based on the user’s travel scenario (such as whether you can use the ID card as the hotel booking and check-in voucher); Secondly, in the hotel commodity sales scene, the international coverage is wider (countries, cities) more hotels, and will access more agents (including domestic and overseas agents) to provide users with better prices; However, due to the overall environment, the market of domestic tourism is larger than that of international tourism at the present stage, which means that the international business has greater space for development, and also means that the domestic business is leading both in terms of business and technology.
As a result of these differences, in the context of limited resources, the overall international service, both pre-sale and post-sale, was not very good at that time because the business and technical system was more domestically oriented. From the end of 2018 to the beginning of 2019, international hotel’s colleagues have separated international from domestic, but still use the existing domestic structure and system. I came to the International Hotel Department from the airline ticket Department, and had the honor to participate in the follow-up improvement process of pre-sales and after-sales service.
2. Pre-sales service
2.1 Definition of Indicators
(1) How to understand pre-sale service?
We can all understand after-sales service, so how to define pre-sales service? In our definition, pre-sales service refers to whether the whole process is smooth from the user entering our client to search for the hotel to the payment of the hotel order. The opposite of smoothness is interception of the user in the process.
(2) How to measure it
From the start of the search to the place of order, there are several main links: hotel list (L), hotel details (D), reservation (B), filling in the form (O page), payment (P). What the user wants most is that what you see is what you get: the price you see in the initial search is the price you end up buying, and the user is notified as soon as possible of any inventory changes during the purchase process that make it impossible to buy. There are two concepts: house price and housing condition. House price, that is, the amount of hotel room sales; Room state, that is, the hotel room inventory state.
So, from the user’s point of view, we define the concept of smoothness: the overall process smoothness = L-D smoothness × D-B smoothness × B-O smoothness × O-P smoothness.
Among them, there are the concepts of house state smoothness and house price smoothness in L-D, D-B and B-O links, that is, the smoothness of a single link = (in a single link) house state smoothness × house price smoothness. For example, in the process of booking, the room condition is not smooth, which means that the corresponding room type product of the previous browse quotation can not complete the booking behavior when checking and discovering that there is no inventory, and prompt the user similar to “the room type is sold out, choose again”; The price is not smooth, which means that there is inventory of the room corresponding to the previous browsing quotation. However, the agent has adjusted the price, and the current price is higher than the browsing price, prompting users to “the price rises, the price changes”.
The smooth structure of O-P link is relatively simple, which refers to the smooth completion of payment in the process of transaction.
With a grip, businesses and systems can be modified to meet expectations. Our expectation is to improve the overall process smoothness of the international hotel to 87%. The initial situation is as follows:
2.2 Improved smoothness of L-D link
(1) What&Why & How
Among the links mentioned above, I was mainly responsible for the index improvement and system transformation of l-D link. [L-D initial index]. This means that only more than 30% of users in this stage of the price change or room type problems, but in fact, the change of house state and house price is not so frequent, most of the problems are caused by the unreasonable system mechanism. As mentioned above, our overall process smoothness index is 87%. After estimation, the L-D link needs to reach the interval of 95-98, which means that we need to find out and solve the problems one by one, and achieve the smoothness of L-D to the extreme.
Let’s make two assumptions to analyze the current problems:
Hypothesis 1: the whole process is real-time search to obtain the hotel room rate and room status, so that all links are the latest room rate and room status, only the real quote and inventory changes will have interception, so the smoothness will basically reach the maximum value in the real situation. Say the conclusion first and then say the reason: unfortunately, can’t.
Qunar, as an OTA platform, mainly provides commodities for sales agents, which means that Qunar does not have its own inventory. In order to obtain the hotel’s price and room status, Qunar must call the hotel’s quotation interface for acquisition. In the case of the L page, there are dozens of hotels under the client page, and dozens of D page searches for the back-end interface. Look at the agent interface, a hotel may have a number of agents are sold, so to call a number of agents interface in order to get as much as possible better hotel quote. However, the QPS provided by different agent interfaces are different, from the single digit to the hundred digit; The response time for a single request ranges from 1s to 10s. The QPS volume provided by the vast majority of agents is far less than the volume required for real-time search on PAGE L, and users cannot wait for all quotations on page L in 10s after search.
Hypothesis 2: Since real-time invocation is not possible, how about using caching entirely? For example, in L-D all use cache to show the same quote, then it must be able to ensure that L-D link smoothness 100%. Again, the conclusion is no. Our goal is the smoothness of the overall process. The use of cache in l-D single link will inevitably lead to a large number of quotes and changes in room state or price in D-B link.
The focus of the previous business was to make the d-B link as smooth as possible for users. In the D page, the agent quotation interface would be queried in real time to obtain the room status and housing price in the interface. In this way, when users entered the B link in a short time, the smoothness of D-B would be improved because the quotation of D was the latest. In contrast, because the traffic is allocated to page D, in order to avoid page L triggering fetching and resulting in exceeding the QPS limit of the agent, the strategy for page L is to use the quote in the cache. However, as page D is a real-time quote, l-D is not smooth. This is the main reason why the smoothness of L-D link is not ideal at the beginning.
In fact, there are two limiting cases in hypothesis 1 and hypothesis 2, which are all real-time quotes and all caching. From hypothesis 1, we can get a conclusion: real-time quotation fetching scheduling is not in line with the actual situation; From hypothesis two and historical experience, we get an experience: to adjust the fetching scheduling strategy can solve a certain problem, can not blindly pursue a certain link, multi-link unified reasonable cache and update mechanism operation can achieve a better overall effect.
(2) Quotation capture scheduling mechanism transformation
① International hotel quotation structure
The mechanism for caching and updating was mentioned earlier, which we refer to as the fetching scheduling mechanism for quotes. In the hotel business, an agent (supplier) on the supply side is called the supplier, and after the storage (packaging) on the quotation side, it is called the wrapper. Most of the relationships between the supplier and the wrapper are one-to-one, and a few are one-to-many, because the one-to-many analysis is not involved below. So the wrapper will be the main analysis object. The entire quotation structure can be simplified as follows:
As can be seen from the figure, the quotation cache pool is used to cache the quotation, and the pre-sales links such as quotation logic and presentation layer do not distinguish whether the L or D links are all using this cache. The structure stored in the cache is the hotel dimension. Different wrapper quotes will be stored under a hotel. When the number of a hotel is requested by an agent, the wrapper quotes of the corresponding hotel will be updated in the cache.
Abstract the quotation structure, it is clear to see the causal relationship. The pre-sale quotation is regarded as output, the quotation logic as function, and the quotation cache as input. Then we can draw a conclusion that in order to improve the l-D smoothness index, the fundamental need to analyze the reasons for the inconsistency of the L-D link in the quoted cache. The quote cache is updated by the number of fetching returns, so the fetching scheduling mechanism needs to be adjusted and reformed after the analysis.
(2) Quote cache and capture scheduling problem analysis
First, we analyze bad cases of inconsistent L-D cache as shown in the following two cases:
In the case of the figure above, this is the number of new wrapper (w3) returns after page L is presented to the user
In the case of the figure above, after page L was shown to the user, the wrapper (w2) updated the price
Why the difference? Let’s take a look at the original fetching scheduling mechanism, as shown in the figure below: When a user accesses PAGE L or D, the cache quotation will be displayed preferentially, and all wrapper fetching messages under the hotel will be sent to the dispatching system. The scheduling system will determine whether the fetching is necessary. If not, it will ignore the message. If it is necessary, it will tell the downstream system in real time to fetch the quotation on the agent interface. So how do you tell here? It is mainly by maintaining a copy of the last fetching time and the time needing cache for judgment. When the time difference between this fetching time and the last fetching time is less than the time needing cache, then the judgment does not need fetching this time. When the crawl is complete, the user-side display may be updated as appropriate.
How do I get this cache time? In the original mechanism, some key wrappers were configured by the production and research institutes, and L and D were distinguished from each other. The cache time of most important wrapper-L fetching requests varies from 10s to 10min, while the cache time of D is from 0s to 1min. The remaining wrappers will adopt the cache time provided by the agent, and the agent will notify the operation to modify it so as not to exceed the maximum QPS limit provided by the agent. The L and D links are not differentiated, and the cache time varies from 10min to 2h.
From the above analysis, we can see that:
- Page D basically relies on real-time quotes;
- L page seems to rely on the cache quote, but a natural form of international business is the request volume is not large but the coverage of countries, cities, hotels, the request is more discrete, in this case, the cache is difficult to do a good coverage, so L page also depends on real-time quote to a certain extent.
As mentioned above, real-time is unreliable due to the agent interface. Therefore, our policy tone is locked in the reasonable allocation and utilization of agent interface resources, the establishment of offline cache based quotation strategy. At the same time, in order to avoid the inefficiency and unreasonable problems caused by manual configuration, we hope to do as much as possible in the construction process of adaptive deployment to replace manual configuration. The solution is as shown in the following figure, the biggest impact on the index is relatively hot quotation, and the most important is to do a good job of offline fetching, to do the automatic update of the hot quote, to ensure the freshness of the quote.
Check out the following article, “Improving Customer Service capabilities in International Hotels (part 2),” for details on exactly what we are doing to improve smoothness.