Travel product recommendation method and computer program product

Abstract

Embodiments of the present specification provide a travel product recommendation method, and a computer program product, the method may include: in response to detecting a travel event of a target user for a destination, identifying a type of the travel event; under the condition that the travel event is a travel event, idle time of the target user in the travel process at the destination is determined; and according to the idle time, recommending a travel product for playing the destination to the target user.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of Internet technologies, and in particular, to a method for recommending travel products and a computer program product. Background Art

[0002] A travel service trading platform can provide users with travel-related services. For example, when a user is on a business trip, the user can purchase round-trip tickets to the business trip destination and book hotels through the platform. Another example is that the travel service trading platform can also recommend travel products to users, such as recommending tourist attractions to users.

[0003] In related technologies, when a travel service trading platform recommends travel products to users, it usually only focuses on the user's travel destination. For example, if the platform detects that a user has purchased a ticket to Hangzhou, it recommends some popular tourist attractions in Hangzhou to the user. However, this recommendation method assumes that the user is only for sightseeing at the travel destination and recommends all available travel products for sightseeing to the user. In fact, the travel products recommended in this way are difficult to meet the sightseeing demands of business trip users because business trip users usually have work requirements at the destination. Even if business trip users want to sightsee, they need to balance work tasks. Therefore, the travel products recommended in the above way are prone to problems of not matching the time arrangements of business trip users. Summary of the Invention

[0004] In view of this, the technical solutions provided by one or more embodiments of this specification are as follows:

[0005] According to a first aspect of one or more embodiments of this specification, a method for recommending travel products is proposed. The method is applied to a travel service trading platform, and the method includes:

[0006] In response to detecting a travel event of a target user for a destination, identifying the type of the travel event;

[0007] In the case where the travel event is a business trip event, determining the idle time of the target user during the business trip at the destination;

[0008] According to the idle time, recommending travel products for sightseeing at the destination to the target user.

[0009] According to a second aspect of one or more embodiments of this specification, a computer program product is provided, including computer programs / instructions, and when the computer programs / instructions are executed by a processor, the steps of any of the methods in this embodiment are implemented.

[0010] As can be seen from the above embodiments, when a travel event of a target user for a destination is detected, the idle time of the target user during the travel to the destination is determined, and travel products for playing at the destination are recommended to the user according to the idle time. This method not only identifies business trip users through the recognition of travel events; moreover, the idle time of business trip users during the travel is determined, so that the recommended travel products match the idle time of the users during the travel. For business trip users, the recommended travel products they obtain are products that match their own idle time and are suitable for playing during their own idle time, thus being able to better meet their playing demands during the travel idle time. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in one or more embodiments of the present disclosure or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only some embodiments recorded in one or more embodiments of the present disclosure. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0012] Figure 1 is a schematic diagram of the system architecture relied on by a travel service trading platform provided by an exemplary embodiment.

[0013] Figure 2 is a flowchart of a method for recommending travel products provided by an exemplary embodiment.

[0014] Figure 3 is a travel product of the nearby play type provided by an exemplary embodiment.

[0015] Figure 4 is a travel product of the night play type provided by an exemplary embodiment.

[0016] Figure 5 is a travel product of the on-the-way play type provided by an exemplary embodiment.

[0017] Figure 6 is a travel product of the all-day play type provided by an exemplary embodiment.

[0018] Figure 7 is a travel product of the chartered-car play type provided by an exemplary embodiment.

[0019] Figure 8 is a schematic diagram of the display interface of a chartered-car itinerary plan provided by an exemplary embodiment.

[0020] Figure 9 is a schematic diagram of scenic spot screening provided by an exemplary embodiment.

[0021] Figure 10A It is a prompt copy provided by an exemplary embodiment.

[0022] Figure 10B It is another prompt copy provided by an exemplary embodiment.

[0023] Figure 11 It is a schematic diagram of the display of a tab page provided by an exemplary embodiment.

[0024] Figure 12 It is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment.

[0025] Figure 13 It is a schematic diagram of the structure of a recommendation device for travel products provided by an exemplary embodiment. Detailed implementation

[0026] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this specification are all information and data authorized by the user or fully authorized by all parties. And the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0027] In related technologies, the recommendation methods for travel products are usually relatively simple. For example, based on the user's location, the scenic spots at the location are recommended. Another example is that based on the destination of the flight ticket purchased by the user or the destination searched by the user, the scenic spots at the destination are recommended. However, this recommendation method cannot well meet the play demands of business trip users.

[0028] Specifically, business trip users usually have work tasks at the travel destination. Even when playing, they need to take into account the execution of work tasks. And recommending travel products based on the user's travel destination is likely to be mismatched with the time arrangement of business trip users. For example: When a business trip user is on a business trip in Shanghai, due to the change in the time arrangement with the client side, the business trip user has two hours of free time in the morning, but the user still needs to continue working in the afternoon. According to the aforementioned travel product recommendation method, the travel products recommended by the platform are expected to take 4 hours to play, which does not match the user's free time, resulting in the user being unable to play according to the recommended products. And if the user queries the scenic spots suitable for a 2-hour play by himself, it is also relatively inconvenient. The user doesn't know what places suitable for a 2-hour play there are at the current destination, resulting in a poor experience for business trip users and they cannot play as they like.

[0029] Based on the above, the embodiments of this specification provide a method for recommending travel products, aiming to improve the matching degree of the travel demands of business trip users through this recommendation method, enabling business trip users to quickly find suitable travel products at the destination and adding more business for the platform.

[0030] Exemplarily, this method for recommending travel products can be executed through a travel service trading platform. A simple description of the architecture of the travel service trading platform is as follows:

[0031] Figure 1 It is a schematic diagram of the system architecture relied on by a travel service trading platform provided by an exemplary embodiment. As Figure 1 shown, this system architecture may include a server 11, a network 12, and several electronic devices, such as a PC (Personal Computer) 13, a mobile phone 14, etc.

[0032] The server 11 may be a physical server including an independent host, or the server 11 may be a virtual server hosted by a host cluster. During operation, the server 11 may run the server-side program of the travel service trading platform to implement the server side of the travel service trading platform.

[0033] The PC 13 and the mobile phone 14 are only some types of electronic devices that users can use. In fact, users can obviously also use electronic devices of the following types: tablet devices, laptop computers, personal digital assistants (PDAs), wearable devices (such as smart glasses, smart watches, etc.). One or more embodiments of this specification do not limit this. During operation, this electronic device may run the client-side program of the travel service trading platform to implement the client of the travel service trading platform. Among them, the application program of the client of the above travel service trading platform may be started and run on the electronic device. The client-side program may be a native application program installed on the electronic device, or the client-side program may be a mini program, a quick application, or other similar forms. Of course, when using web technologies such as HTML5 or similar, relevant functions can be implemented through the page displayed by the browser. Here, the browser may be an independent browser application or a browser module embedded in some applications.

[0034] For the network 12 for interaction between electronic devices such as the PC 13 and the mobile phone 14 and the server 11, communication can be specifically implemented using a wired or wireless network based on the communication methods supported by the corresponding electronic devices. The embodiments of this specification do not limit this. For example, if the PC 13 supports both wired and wireless communication, communication can be implemented using a wired or wireless network according to needs, while the mobile phone 14 usually only supports wireless communication, so wireless network can be used to implement communication.

[0035] When implementing the travel product recommendation method of the embodiments of this specification through the above-mentioned travel service trading platform, the embodiments do not limit the specific implementation manner. For example, it can be implemented through the server side of the travel service trading platform, or through the cooperation between the server side and the client side. For example, users can perform operations such as opening a page, purchasing an air ticket, and booking a hotel on the client side of the platform. The client side can transmit the obtained information to the server side, and the server side can perform operations such as identifying the type of the user's travel event and determining the free time based on the obtained multi-faceted information, and generate travel products recommended to the user based on the free time.

[0036] Next, the travel product recommendation method of the embodiments of this specification will be described in detail with reference to the accompanying drawings.

[0037] Figure 2 is a flowchart of a travel product recommendation method provided by an exemplary embodiment. As Figure 2 shown, it may include the following processing steps. It should be noted that the embodiments do not limit the execution order between the following steps.

[0038] In step 200, in response to detecting a travel event of a target user for a destination, identify the type of the travel event.

[0039] In this step, the detection of the travel event of the target user for the destination may be detecting that the target user has performed a reservation operation for a travel order for the destination. Exemplarily, the reservation of the travel order may include, but is not limited to: reserving a hotel at the destination, or reserving an air ticket or a train ticket to the destination, etc.

[0040] The travel service trading platform can identify the type of the travel event. In the embodiments of this specification, the platform can determine whether the travel event is a business trip event. If it is determined to be a business trip event, it indicates that the target user is a business trip user, and travel products suitable for business trip users to play at the destination can be recommended to the target user in subsequent steps.

[0041] The following is an exemplary description of the method for determining whether a travel event is a business trip event, but it can be understood that the embodiments of this specification do not limit its determination method.

[0042] For example, when identifying the type of travel event, it can be considered from two dimensions. One dimension is the user type of the target user, determining whether the target user is a business traveler; the other dimension is the order type of the travel order triggered and generated by the target user for the travel event, determining whether the order type of the travel order is a business travel order.

[0043] The determination of a travel event being a business travel event can be made based on at least one of the above two dimensions. For example, if the target user is a business traveler, it can be determined that the travel event of the target user for the destination is a business travel event. Another example, if the travel order is a business travel order, it is determined that the travel event is a business travel event. Another example is that it can also be a combination of the above two dimensions. If both the target user is a business traveler and the travel order is a business travel order are satisfied at the same time, it is determined that the above travel event is a business travel event.

[0044] Next, how to determine whether the target user is a business traveler and how to determine that the travel order is a business travel order will be described in detail for the above two dimensions respectively:

[0045] 1) Whether the target user is a business traveler.

[0046] This dimension considers from the user type of the target user and judges whether the user type of the target user is a business traveler. The so-called business traveler can be a user with a business trip need, such as a user who often travels on business or has a high probability of traveling on business.

[0047] The following are some discriminant conditions based on when identifying business travelers. If the target user meets at least one of the following discriminant conditions, the target user can be determined to be a business traveler. Among them, the discriminant conditions for the following identification of business travelers include two categories. One category of conditions is to determine whether the user is an enterprise user based on the user's personal registration information. Usually, enterprise users have a relatively high probability of having a business trip need. Another category of conditions is based on the target user's historical travel orders. If the target user's historical travel orders are business travel orders, it indicates that the user has traveled on business before and belongs to a business traveler.

[0048] The following are more specific examples:

[0049] For example, if the personal user registration information of the target user on the travel service trading platform contains enterprise information, indicating that the target user is an enterprise employee, there is an objective need to travel on business for the work arranged by the enterprise.

[0050] Another example, if the historical travel orders of the target user on the travel service trading platform are business travel orders (the identification of business travel orders can refer to the content of the following discrimination of business travel orders), indicating that the target user has traveled on business before, then there is also a relatively high probability of traveling on business again.

[0051] In addition, the same user can be active on multiple platforms. For example, for a target user, they can register their personal user information and book travel orders on a travel service trading platform, and can also register the above information and book orders on other platforms. Based on this, on the premise of obtaining user authorization, the travel service trading platform can also combine the information of the target user on other platforms to determine the user type, so that the travel service trading platform can determine the type of the target user based on richer information, and the determination method is more flexible.

[0052] For example, the target user may have registered their personal user information on a business travel service trading platform. With the authorization of the target user, the travel service trading platform can obtain the registration information of the target user from the business travel service trading platform. Similarly, if the personal user registration information of the target user on the business travel service trading platform contains enterprise information, it indicates that this is enterprise user registration information, and the target user has an objective need for business trips.

[0053] For another example, the target user may also have booked a travel order on the business travel service trading platform, and their historical travel order is a business travel order. With the authorization of the user, the business travel service trading platform can share the order type determination result information that "the historical travel order of the target user on the business travel service trading platform is a business travel order" with the travel service trading platform, or the business travel service trading platform can also share the order information of the target user's historical travel order with the travel service trading platform, and the travel service trading platform can determine that this historical travel order is a business travel order based on this.

[0054] The described business travel service trading platform can be a platform that can provide business travel services, for example, it can include but is not limited to: business travel itinerary booking tools, such as business travel itinerary booking applications or websites, etc. On the premise of obtaining user authorization, information can be shared between these platforms and the travel service trading platform.

[0055] 2) The travel order generated by the target user for a travel event is a business travel order.

[0056] This dimension considers the travel order corresponding to the current travel event and determines whether the order type of this travel order is a business travel order. The described business travel order can be an order booked by the user during a business trip.

[0057] For the discriminant conditions based on when identifying the order type, for example, it can include: the generation platform of the travel order, the payer of the order, combining the order type of the historical travel order of the same user for the same destination, the destination of the travel order, the travel date, the type of hotel reserved by the travel order, etc. In actual implementation, the business travel order can be identified based on a certain one of these conditions, or multiple conditions can also be combined for identification.

[0058] The following are several identification methods for business travel orders:

[0059] In one example, the type of travel order can be determined based on the generation platform of the travel order. For example, the travel order is triggered and generated by the target user on the business travel service trading platform. Among them, the business travel service trading platform can be a platform that can serve enterprise users. Enterprise users can purchase travel tickets, book hotels, etc. on this platform. Since enterprise users have a high probability of business travel needs, it can be considered that the travel orders booked on this business travel service trading platform are also likely to be business travel orders. Based on this, if the travel order is generated on the business travel service trading platform, it can be identified as a business travel order.

[0060] In another example, the order type of the travel order can be determined based on the payer of the travel order. For example, the payer of the travel order is an enterprise registered on the business travel service trading platform. For instance, the business travel service trading platform can also provide enterprise payment services. That is, after a business traveler books a travel order on this platform, they can directly use the payment method with the enterprise registered on the platform as the payer. Thus, it can also be determined that this order is a business travel order based on this.

[0061] In yet another example, the order type of the travel order can also be determined by combining the order type of the historical travel orders of the same user for the same destination, as well as the destination and travel date of the travel order. For example, if the order destination of the target user's current travel order is the user's non-permanent residence. For example, it can be determined that the user's permanent residence is Beijing based on the length of stay of the user in the geographical location, and the user has booked a flight to Shanghai this time, and the destination is the non-permanent residence; the travel date of the order is a working day; and the historical travel orders of the target user for the same destination include business travel orders. For example, the user has booked a flight to Shanghai this time, and there are also flights to Shanghai in the user's historical travel orders, and the historical flights to Shanghai have been determined as business travel orders. Considering these factors above, it can be determined that the target user's current travel order to Shanghai is a business travel order, and this user may be a user who often travels to Shanghai on business.

[0062] In still another example, the order type of the travel order can also be determined by combining the destination, travel date, and the type of hotel booked for the current travel order. For example, the order destination of the target user's current travel order is the user's non-permanent residence. At the same time, the travel date of the order is a working day, and the hotel booked for the target user's travel order is a business hotel, and this hotel type usually conforms to the hotel reservation habits of business travelers. Considering these conditions, it can be determined that the target user's current travel order is a business travel order.

[0063] In addition, based on the above descriptions of how to identify business travel users and business travel orders respectively, the following is an exemplary description of the determination method of business travel events:

[0064] For example, a business travel event can be determined solely based on the identification of a business travel order. If it has been identified and determined that the travel order triggered by the target user for a travel event is a business travel order, then this travel event is determined to be a business travel event.

[0065] For another example, a business travel event can also be determined by combining the identification of business travel users and the identification of business travel orders. Specifically, if it is determined that the target user is a business travel user based on the personal user registration information of the target user and the target user's historical travel orders; and if it is determined that this order is a business travel order based on the destination, travel date, and type of reserved hotel of the travel order, then it can be determined that this travel event is a business travel event.

[0066] The travel order described in the above embodiments can be triggered and generated by the target user on the travel service trading platform, or, it can also be triggered and generated by the target user on the business travel service trading platform, and the business travel service trading platform shares the order information to the travel service trading platform. For example, if a user books a flight to Shanghai on the business travel service trading platform, the business travel service trading platform can synchronize information such as the travel date and travel destination of this flight to the travel service trading platform, and the travel service trading platform determines whether the order booked by the user on the business travel service trading platform is a business travel order based on this information.

[0067] In addition, in order to improve the determination efficiency of business travel events, it can also be done in the following way:

[0068] After each determination of a business travel event, the target user corresponding to this business travel event can be marked as a "business travel user", and this user type "business travel user" is stored. In this way, when the travel event of the same target user is detected again later, if the determination method is to determine the business travel event only based on the user type, then it can be directly determined as a business travel event according to the stored user type. If the determination method is to comprehensively determine the business travel event based on the user type and the order type, then it is not necessary to execute the determination of the user type again, and the order information of the travel order can be directly obtained, and the business travel order is determined based on the order information, so that the determination efficiency of the business travel event can be improved.

[0069] For example, assume that the travel event of user U1 is detected, and it is determined based on the stored information that this user U1 belongs to a business travel user, then its travel order can be obtained. If the destination of the order is not its usual residence, the travel date is a working day, and the hotel reserved by this user U1 is a business hotel, then it can be determined that this event is a business travel event.

[0070] In step 202, when the travel event is a business trip event, determine the idle time of the target user during the business trip at the destination.

[0071] When it is determined that the travel event of the target user is a business trip event, this step can continue to determine the idle time of the target user during the business trip at the business trip destination. Among them, the idle time may include time period information. For example, the user is idle during the time period from 8:00 to 12:00; or, the idle time may also include duration information. For example, the user is idle for 2 hours; or, the idle time may also include both time period information and duration information. For example, the user will be idle for 2 hours during the morning time period from 8:00 to 12:00.

[0072] The following are several example ways to determine the idle time. It can be understood that in actual implementation, it is not limited to this. Among them, when explaining the method of determining the idle time below, it will be divided into "how to determine the idle time on weekdays" and "how to determine the idle time on rest days", which will be explained separately.

[0073] Example method 1: Method of determining idle time on weekdays

[0074] For the method of determining idle time on weekdays, the whole day of weekdays can be set as multiple time periods. Specifically, it is to determine which of the divided multiple time periods belong to the idle time. Or more specifically, on the basis of determining that a certain time period belongs to the idle time, the playable duration in this time period can be further determined. The following will be described in detail by way of example:

[0075] For example, for a weekday during a business trip, the whole day of the weekday can be set as multiple time periods. The multiple time periods can include at least one default idle time period and at least one default busy time period. For example: the multiple time periods can include the morning time period from 8:00 to 12:00, the afternoon time period from 14:00 to 18:00, and the evening time period from 19:00 to 22:00. Usually, the evening time period can be defaulted to be idle, and the business trip user can rest in the evening. Therefore, the evening time period can be called the default idle time period; the business trip user usually needs to work in the morning and afternoon. Therefore, the morning time period and the afternoon time period can both be called the default busy time periods.

[0076] The above time period division is only an example. The embodiments of this specification do not limit the division method of each time period. These time periods can be evenly divided (the duration of each time period is the same), or unevenly divided (the duration of each time period is different), both are acceptable. For example, the time period can also be divided more finely, including time periods such as from 8:00 to 10:00 and from 10:00 to 12:00.

[0077] In this embodiment, the default idle period during weekdays in the business trip process can be determined as the idle time of the target user, that is, during the default idle period, the business trip user can usually rest. For example, as described in the above example, the evening period {19:00 - 22:00} belongs to the default idle period, and it can be defaulted that this period {19:00 - 22:00} is determined as the idle time of the target user. In addition, for the default busy period during weekdays, although it is the default busy period of the business trip user, there are times when the user may also be idle during this period. For example, if the customer suddenly has something to do and the originally scheduled meeting with the customer in the morning is postponed to the afternoon, then the morning period becomes idle. Therefore, the default busy period may also become the idle time of the target user. When determining whether the default busy period is idle time, it can be judged whether the default busy period belongs to the idle time of the target user based on a preset trigger event.

[0078] Specifically, it can be judged which period the preset trigger event occurs in, and the idle time of the target user can be determined based on the period associated with the preset trigger event. For example, for a certain default busy period, if there is a preset trigger event related to this default busy period, then this default busy period can be determined as the idle time of the target user. Or, if there is a preset trigger event related to this default busy period, this default busy period and other default busy periods associated with it can be determined as the idle time of the target user.

[0079] Among them, the preset trigger event can be various types of events, and this embodiment does not limit this. Several examples will be given below to illustrate several preset trigger events and how to determine the user's idle time based on this trigger event.

[0080] For example, the preset trigger event can be that the client of the travel service trading platform is opened by the target user. For example, the target user opens the client of the travel service trading platform, and the client can detect the time when the target user triggers the opening. Suppose it is opened at 9:30 in the morning. That is, when the user opens the client of the platform, the platform can detect that a preset trigger event has occurred. And the morning period {8:00 - 12:00} is a default busy period. Based on detecting that the target user opens the client of the travel service trading platform during this default busy period, this morning period {8:00 - 12:00} can be determined as the idle time of the target user. In this example, the default busy period where the preset trigger event is located is used as the idle time.

[0081] Alternatively, it could also be the following situation: after determining the default busy period in which the preset trigger event occurs, the default busy period and other associated default busy periods can be determined as the free time of the target user. For example, in the above example, if the preset trigger event occurs in the morning period {8:00 - 12:00}, it indicates that the user's morning period is free; however, in this case, it is speculated that the user's schedule for today may have changed and the user is temporarily free today, that is, the morning period {8:00 - 12:00} and the adjacent afternoon period {14:00 - 18:00} can be determined as the free time of the target user. In this case, the afternoon period is another default busy period associated with the morning period {8:00 - 12:00}, and these two associated default busy periods can be determined as the user's free time. In addition, it can be understood that the association method of the two default busy periods described here is only an example, that is, two adjacent periods can be used as an association relationship. In other examples, the other default busy periods can also be determined according to other association rules, not necessarily the adjacent periods in the above example, and there is no limitation on this.

[0082] For another example, the preset trigger event can be that the target user has booked a travel product related to the default busy period in the past. This can be considered based on the user's past business trip habits and travel habits. For example, the target user goes on business trips to the same customer in Shanghai at regular intervals, and the time arrangements during each business trip are similar. For example, the user often buys scenic spot tickets to play during the period from 16:00 to 19:00 on weekdays during business trips, which indicates that the user is free during the period {16:00 - 19:00} on weekdays during business trips. Based on this, for example, if it is determined according to the target user's travel history information at the business trip destination that the target user has booked a travel product for the afternoon period {14:00 - 18:00} at this destination in the past, then it can be considered that the afternoon period {14:00 - 18:00} belongs to the user's free time. That is, for a certain default busy period, if the user has booked a travel product during this default busy period in the past, then this default busy period can be determined as the user's free time. Of course, other factors can also be considered. For example, the number of times the same user has purchased travel products during a certain default busy period in the past can be further considered. If the user has only purchased a travel product once during the period {16:00 - 19:00} in the past, then it may not be considered that this default busy period is the user's free time; while if the user has purchased travel products three times during the period {16:00 - 19:00} within two months in the past, and the three travel events to the destination have all been confirmed as business trip events, then it can be considered that the user is free during the default busy period from 16:00 to 19:00 on weekdays during business trips. Similarly, the afternoon period and other associated default busy periods can also be determined as the free time of the target user.

[0083] For another example, the preset trigger event may be that the travel return time of the target user falls within any of the default busy periods. For example, assume that the return flight ticket purchased by the target user is at 15:00 in the afternoon, that is, the travel return time is 15:00, and this time falls within the default busy period - the afternoon period {14:00 - 18:00}, then this afternoon period can be determined as the free time of the target user. Alternatively, this afternoon period and the adjacent morning period can also be determined as the free time of the user.

[0084] As described above, for the working days during the business trip, the default free period can be determined as the free time of the target user; and if a preset trigger event occurs during the default busy period, the default busy period associated with the preset trigger event can be determined as the free time, or the default busy period and other default busy periods associated with it can be determined as the free time of the target user. In addition, the preset trigger event may also be the moment when the platform actively pushes travel products to the user. For example, the user does not actively open the platform's client, but the platform actively pushes suitable travel products to the user at around 19:00 in the evening. Then, the moment when the platform actively pushes can be used as the moment of the trigger event. If this moment is within the evening period {18:00 - 22:00}, then this evening period can be determined as the free time of the user.

[0085] Furthermore, for the free time determined in the embodiments of this specification, before recommending suitable travel products to the target user based on this free time, more detailed time determination can be performed based on this free time. For example, in the above example, a certain period can be determined as the free time of the user, such as the morning period {8:00 - 12:00} is the free time of the target user. Based on this determined period, the available play duration of the target user can also be obtained. For example, the morning period {8:00 - 12:00} is 4 hours of available play duration. In addition, in other examples, the available play duration corresponding to this free time can be determined more specifically. For example, the free time is the morning period {8:00 - 12:00}, but the user may open the platform client at 10:00 in the morning, that is, the user is only free at 10:00 in the morning. Then the actual available play duration is the period {10:00 - 12:00}, that is, 2 hours. Therefore, by refining the determination of the available play duration corresponding to the free time and then recommending matching travel products to the target user based on this available play duration, it can make the recommended travel products match the user's free time more precisely, meet the user's play requirements, and improve the user experience.

[0086] Specifically, the following are several ways to determine the playable duration. Among them, the determination of the playable duration can specifically be to determine the start time and end time of the playable duration, and the duration of the time interval between the start time and the end time is the playable duration. Alternatively, it can also be to determine the playable duration according to the historical playing habits of the target user. The following will give specific examples:

[0087] 1) Use the moment when the client of the travel service trading platform is opened by the target user as the start time, or use the moment when the target user returns from a business trip as the end time to calculate the playable duration corresponding to the target user's free time.

[0088] For example, use the moment when the client is opened by the target user as the start time and calculate the playable duration of the target user based on this start time. Then, after determining the start time, the end time can be determined first, and then based on the start time and the end time, the time interval between the two can be determined to obtain the playable duration. For example: If the target user opens the client of the travel service trading platform at 10 am, then 10 am is called the start time. Then, based on this start time, the end time can be further determined to obtain the playable time interval corresponding to the free time, and the duration of this time interval is the playable duration.

[0089] Exemplarily, for the determination of the above end time, any of the following methods can be used. Among them, the determination of the end time can be to add a certain preset duration to the start time to obtain the end time; or it can also be to use some preset activity times as the end time:

[0090] For example, the moment after adding a preset static duration to the start time, where the preset static duration is a fixed value. Taking the above 10 am as the start time as an example, this start time can be added with a preset static duration, and the moment obtained after the addition is used as the end time. Assuming the preset static duration is 1 hour, then the end time is 11 am.

[0091] For another example, the moment after adding a preset dynamic duration to the start time can be used as the end time. The preset dynamic duration is a dynamically changing duration. As for what factors the dynamically changing duration is related to, this embodiment does not make any restrictions. For example, the value of the preset dynamic duration is related to the time period in which the start time is located. For example, assuming that the preset dynamic duration associated with the morning time period is 2 hours and the preset dynamic duration associated with the afternoon time period is 4 hours, then if the start time is 10 am, the end time is 12 pm obtained by adding 2 hours to 10 am; and if the start time is 3 pm, then the end time is 7 pm obtained by adding 4 hours to 3 pm.

[0092] For another example, the end time of a platform preset activity after the start time on the same day can be used as the end time. The end time of the platform preset activity can be determined according to the usual life and work times. For example, the end time of the platform preset activity can include, but is not limited to: the start time of a meal, the start time of work, the closing time of a business at the travel destination, etc. For example, assuming the start time is 10 am and the end time can be set as 1 pm when work starts in the afternoon, the time interval corresponding to the idle time is {10 am - 1 pm}. In addition, the end time of the platform preset activity can be further refined according to the work arrangements of specific users. For example, users can be allowed to input their work arrangements at the business trip location through a man-machine interaction method. For example, some work may start having meals at 4 pm or start work at 3 pm, which is different from most people having meals at 12 pm and getting off work at 1 pm. This more refined way of determining the end time of the preset activity helps to more accurately determine the idle time of users.

[0093] The above examples illustrate several ways to determine the end time of the time interval corresponding to the idle time. Among them, in some examples, if the same day is the return day of the business trip, it is also possible to determine whether the end time determined by the above method meets the end time selection condition. This condition can include: not being later than the business trip return time, and the time interval between it and the business trip return time is not less than a preset value. For example, if the time after adding the preset dynamic duration to the start time has exceeded the business trip return time, it does not meet the end time selection condition. Or, if the time interval between the added time and the business trip return time is less than the preset value of 1 hour, it also does not meet the end time selection condition. If the end time meets the end time selection condition, this end time can be adopted.

[0094] If the end time does not meet the end time selection condition, the end time that meets the end time selection condition can be deduced based on the business trip return time. For example, if the time after adding the preset dynamic duration to the start time has exceeded the business trip return time "3 pm", and assuming that the time interval between the end time set in the end time selection condition and the business trip return time is not less than the preset value of 1 hour, the end time that meets the condition can be deduced based on the business trip return time as 2 pm, and this 2 pm is used as the end time.

[0095] As described above, based on the start time and the determined end time, the time interval corresponding to the idle time is obtained, and through this time interval, the specific time period and duration of the target user's idle time can be obtained. For example, if the time interval is {10:00 - 13:00}, the available play duration is 3 hours. In addition, the above start time takes the example of the user opening the client of the travel service trading platform. It can also be the time when the user opens the client of other platforms and is shared to the travel service trading platform; or, the start time can also be the time when the travel service trading platform or other platforms actively recommend travel products to the target user.

[0096] For example, taking the business trip return time of the target user as the end time to calculate the available play duration of the target user. In this case, the start time can be determined according to the end time, and then based on this start time and the end time, the time interval between the two is determined, so as to obtain the available play duration. If the return day is a working day, the end time of the time interval corresponding to the idle time can be determined. Among them, the end time can be the business trip return time.

[0097] Exemplarily, when reverse calculating the start time based on the end time, any of the following methods can be adopted. For example, the start time can also be obtained by reverse calculating a certain duration from the end time; or, the start time can also be determined based on the preset start time of the platform preset activity.

[0098] For example: The business trip return time of the target user, "15:00 PM", is in the afternoon period, and this afternoon period can be considered as the user's idle time. When calculating the specific available play duration, the start time can be calculated based on this end time. For example, the start time is the time determined by reverse calculating the second duration from the end time. Assuming the end time is 15:00 and the second duration is 4 hours, the start time is 11:00 AM.

[0099] Another example is that the start time can also be the start time of the platform preset activity earlier than the end time. The start time of the platform preset activity can include but is not limited to: the end time of dining, the end time of work, the start time of business in the travel destination, etc. For example, assuming the end time is 15:00 and the end time of dining is 12:00, then take 12:00 as the start time. Similarly, the start time of the platform preset activity can be determined according to the usual life and work times, or can be more refined according to the work arrangements of specific users. For example, the user can be allowed to input their time arrangements at the business trip location through a human-computer interaction method. For example, some work may end at 13:00 for dining. This more refined method of determining the start time of the preset activity helps to more accurately determine the user's idle time.

[0100] As described above, after determining the start time based on the end time, the time interval corresponding to the idle time is obtained, and the duration of this time interval is the playable duration. For example, in the above example, it is determined that the user is idle in the time interval {12:00 - 15:00}, so the playable duration is 3 hours.

[0101] It can be understood that the business trip return time itself can be used as the end time, or the time determined by backward deduction of the first duration from the business trip return time can also be used as the end time. For example, if the first duration is 1 hour and the business trip return time is 15:00, then 14:00 can be used as the end time.

[0102] 2) Determine the playable duration corresponding to the idle time of the target user according to the historical playing habits of the target user.

[0103] In this example, the playable duration corresponding to the idle time of the target user can be determined according to the historical playing habits of the target user. For example: The previous business trip habits and playing habits of the same user can be considered. For example, the target user goes on business trips to the same customer in Shanghai at regular intervals, and the time arrangements during each business trip are similar. For example, this user often buys scenic spot tickets to play during the period from 15:00 to 18:00 on weekday afternoons during business trips. Then it indicates that the user is idle during the period {15:00 - 18:00} on weekdays during business trips. Accordingly, if the target user opens the client of the travel service trading platform at 15:00 in the afternoon, instead of determining the entire afternoon period as the idle time of the user, it can be specifically refined to determine that the playable duration corresponding to the idle time of the user is 3 hours, or it can be said that the time interval corresponding to the playable duration is {15:00 - 18:00}. More refined determination of idle time helps to be more accurate in subsequent travel product recommendations.

[0104] Example Method 2: Method for Determining Idle Time on Rest Days

[0105] The foregoing example describes the method for determining the idle time of the target user on weekdays during business trips. Here, an example will be given to illustrate how to determine the idle time on rest days during business trips. For example, the whole day of the rest day during business trips can be determined as the idle time of the target user. Among them, if the target user returns on a rest day, then the "whole day" can be understood as the time before the business trip return time on the return day. Another example, if the business trip return day of the target user is a weekday next week, then the whole day of this weekend will be determined as the idle time of the target user. Among them, the "week" here can be understood as starting from Monday to Sunday as a week, with Monday as the start of each week and Sunday as the end of each week.

[0106] For another example, if the return day of a business trip falls on a rest day, the time period during which the business trip return time falls within that rest day and / or other time periods associated therewith can also be determined as the free time of the target user. For instance, if the business trip return time is 17:00 in the afternoon, it is generally considered that the business trip user is likely to be free for some time before the return, to ensure that the user has enough time to avoid delaying the return. Therefore, based on the business trip return time, the time period in which the return time falls or its associated time period can be determined as the user's free time. For example, in the aforementioned example, if the business trip return time is 17:00 in the afternoon, which is within the afternoon time period, the afternoon time period during which the return time falls can be used as the free time of the user. Of course, specifically, the time before the business trip return time within that afternoon time period can be used as the free time. Or the afternoon time period and its associated time periods can also be used as the free time. For example, the time period {12:00 - 14:00} adjacent to the afternoon time period {14:00 - 18:00} can also be used as the free time.

[0107] As described above, for rest days during a business trip, corresponding free time can be determined, and the available play duration corresponding to this free time can also be determined. For example, if the whole day is considered as free time, the available play duration can be considered as 12 hours (taking into account removing the sleeping time at night); in the aforementioned example, if the time periods {14:00 - 16:00} in the afternoon and the adjacent time period {12:00 - 14:00} are considered as free time, then the total available play duration is 4 hours. Making subsequent travel product recommendations based on the available play duration will help to make the recommended products match the user's free time better.

[0108] In step 204, according to the free time, recommend travel products for playing at the destination to the target user.

[0109] In this step, travel product recommendations can be made based on the free time determined in step 202.

[0110] As mentioned in the previous example, when determining the free time of the target user, travel products can be recommended to the user based on this free time. In addition, to improve the matching degree of the recommended products with the user's free time, the available play duration corresponding to this free time can also be determined. For example, the user can play for 3 hours; this available play duration can also correspond to a time interval. For example, the specific available play time interval is {15:00 - 18:00}. In this step, travel products that match the available play duration can be recommended to the target user based on the available play duration, so that the recommended travel products can match the target user better.

[0111] The following examples are based on the method of recommending travel products based on free time, but are not limited thereto. Among them, if there are multiple types of travel products to be recommended, a certain recommendation rule can be established for each type of travel product in advance, and recommendations can be made according to this recommendation rule. Exemplarily, this recommendation rule can be to establish a mapping relationship between each type of travel product and free time. More specifically, it can be to establish a mapping relationship between each type of travel product and the available play duration; or, it can also be to establish a mapping relationship between each type of travel product and time periods. In this way, after determining the free time of the target user in the previous step, the type of product to be recommended can be quickly determined according to the mapping relationship.

[0112] For example, in order to meet the various play demands of users, a relatively rich variety of travel product types can be provided. For instance, multiple types of travel products can be predefined, and each type of travel product can establish a mapping relationship with free time. Exemplarily, the multiple types of travel products can include: play nearby, play at night, play on the way, play all day, etc. When establishing the mapping relationship between each type of travel product and free time, there can also be various flexible methods:

[0113] For example, the product type can be associated with the available play duration. For example, the "play nearby" type is associated with "within 2 hours", that is, the scenic spots recommended for the play nearby type usually have a play duration within 2 hours. Another example is that the "play on the way" type is associated with "3 - 4 hours", that is, the total play duration of the recommended scenic spots for playing on the way is usually between 3 and 4 hours. Again, the "play at night" type is associated with the time period "{18:00 to 22:00}", that is, the scenic spots recommended for playing at night usually operate at night from {18:00 to 22:00}. Similarly, the all-day play type is associated with the all-day duration.

[0114] After determining the free time of the target user in step 202, based on the mapping relationship between free time and product type in the above examples, the type of product to be recommended can be determined, and then based on the travel product generation logic corresponding to this product type, the travel products to be recommended can be generated. The travel product generation logic will be described later.

[0115] For another example, it can also be to associate the product type with a certain time period. For example: as mentioned in the previous example, the whole day of a working day can include at least one default idle period and at least one default busy period. The product type can be associated with these time periods. When the preset trigger event occurs in a certain time period, the product type corresponding to that time period is determined as the product type to be recommended. For example, if the target user opens the client of the platform at 19:00 in the evening and the preset trigger event occurs in the evening period, then "play at night" associated with the evening period can be used as the product type recommended to the user. Another example is that if the target user opens the client at 14:00 in the afternoon, then "play on the way" associated with the afternoon period where the preset trigger event is located can be used as the product type recommended to the user.

[0116] The above mapping method is only an example. Other association methods can be adopted as long as the determined idle time is associated with the predefined product type. Of course, it can be understood that the above-mentioned multiple product types are also examples. In actual implementation, there can be only one type and only one recommendation logic for travel products. This logic can be to screen travel products that match the idle time based on the determined idle time and recommend the products to the target user.

[0117] Next, in combination with the accompanying drawings, the generation logics of several types of travel products are exemplified. The following travel products are exemplified by scenic spots, but it can be understood that the travel products can also be other types of products other than scenic spots. Among them, the following exemplified travel products can include "play by oneself" and "play by chartering a car". Among the "play by oneself" type, there can be further included "play by oneself - play nearby", "play by oneself - play at night", "play by oneself - play on the way", and "play by oneself - play all day". The following will describe these types of products in detail respectively:

[0118] 1) Play by oneself - play nearby

[0119] Products of this type can be used to solve the user's demand for not wanting to go far to play. In this case, usually the user's idle time is short, such as the available play duration within 2 hours.

[0120] Specifically, taking the travel product to be recommended as a scenic spot as an example, some scenic spots can be screened from the preset scenic spot library according to the product selection parameters. Among them, the product selection parameters can include the above-mentioned available play duration, such as 2 hours, that is, screen scenic spots with an expected play duration within 2 hours. For example, if a scenic spot takes 4 hours to play through, then this scenic spot cannot be selected.

[0121] In addition to the playable duration described above, attractions can also be filtered based on other factors. For example, attractions that do not require reservations can be prioritized, so that users do not need to make reservations and can go directly, which is very convenient. For example, the current geographical location of the user can also be combined to select attractions within a certain range around this location, so that users do not need to travel far when playing. For example, it can be within a range of 5 kilometers around. And when presenting to the user, the distance between the attraction and the user's current location can be displayed, so that the user can more quickly understand the distance of the attraction. For example, the historical behavior information of the user at the business trip destination can also be combined. For example, if the user has been to this destination many times, and it is known from the historical behavior information that the user has visited many attractions in this destination, then some attractions with relatively low popularity but high praise ratings can be filtered for this recommendation. Another example is that recommendations can also be made based on attributes such as the user's age and gender. Exemplarily, if the user is young, some amusement parks, historical sites, etc. can be recommended. If the user is older, museums can be recommended. Similarly, different attractions can be recommended to users of different genders.

[0122] Please refer to Figure 3 as shown Figure 3 which shows some travel products recommended under the nearby play type, and they can be sorted by the distance between the attraction and the user, and the distance between the attraction and the user's current location is also shown. For example, the recommended product 31 is within 1 kilometer nearby, and product 32 is within 1.5 kilometers nearby.

[0123] 2) Self-guided play - Nighttime play

[0124] Products of this type can be used to address the travel needs of users during their free time at night. Considering that the user is on a business trip and it is not suitable to play too late at night, the playable duration corresponding to nighttime play can be in the interval of {18:00 - 22:00}.

[0125] Specifically, some night show tickets and nighttime entertainment items (such as boat rides) at the business trip location can be recommended to the user. When filtering attractions, it can be done in a similar way as in the nearby play mentioned above, which will not be elaborated here. Only in the product selection parameters used for filtering, the playable duration can be 4 hours or 3 hours, etc., which is longer than the playable duration of nearby play.

[0126] When presenting after the filtering is completed, there can also be various ways of presentation order. For example, it can be sorted by the distance from the user's current location, or it can also be sorted by the popularity of the attraction. Please refer to Figure 4 the illustration of Figure 4Schematically shows some travel products recommended for the night play type. For example, these products can include "Cruise tour of the scenery on both sides of the Pearl River in Guangzhou", "Night tickets for Chimelong Water Park", etc., all of which are products that users can play at night. When displaying, the scenic spot 41 closest to the user can be ranked first, and then the scenic spot 42 with higher popularity can be displayed. It can be understood that other sorting methods can also be adopted without limitation.

[0127] 3) Self-guided tour - Visiting along the way

[0128] The products of this type can be used to solve the user's demand for visiting multiple places along the way. For example, users may think that a single place may not be worth it, but it will be more worthwhile when there are two or more places.

[0129] Specifically, the travel products for visiting along the way usually include at least two scenic spots, that is, at least two scenic spots are recommended as an overall product. The total estimated playing time of these scenic spots can be about 3 to 4 hours. Since it is visiting along the way, the distance between the scenic spots is usually not too far. When screening the scenic spots, in addition to considering the factor of playing time, the distance between the scenic spots can also be considered so that the distance between adjacent scenic spots is within the preset distance threshold.

[0130] Please refer to Figure 5 For an example in the figure, one of the travel products 51 for visiting along the way recommended in the figure. This product can include two scenic spots, "Electronic guided tour of Chen Clan Academy" and "Personalized guided tour of Shamian Island in Liwan". And when displaying, in order to make it easier for users to understand, the adjacent scenic spots belonging to the same travel product for visiting along the way can be connected by symbols. For example, Figure 5 Between the scenic spot 511 and the scenic spot 512 in Figure 5 can be connected by a plus sign 52, so that users can understand that these two scenic spots are recommended as scenic spots for visiting along the way. Of course, it can be understood that Figure 5 As can also be seen, the distance between the scenic spots for sequential visiting can also be shown to users, so that users can more clearly know how far these scenic spots are from each other, which is convenient for users to arrange their own itinerary. For example, the distance between the scenic spot 511 and the scenic spot 512 is 2.2 kilometers.

[0131] For different travel products for visiting along the way, the sorting order when displaying is not limited in this embodiment either. Exemplarily, it can be sorted according to "the distance between the scenic spots". For example, in Figure 5Among them, the scenic spots in the first recommended product for on-the-way play 51 are 2.2 kilometers apart, and the scenic spots in the second recommended product are 3.1 kilometers apart. In other examples, it is also possible to sort by the popularity of the scenic spots, or combine different factors for sorting. For example, in Figure 5 Among them, the first sorting priority can be "the distance between scenic spots". Suppose there are two recommended products with the same "distance between scenic spots", then these two products can be further sorted by the popularity of the scenic spots, and the one with higher popularity can be displayed in the front. For on-the-way play products, the comparison of popularity can be the comparison between the scenic spots with the highest popularity in the products.

[0132] For another example, the distance between the product and the user's current location can also be used as a sorting consideration factor. The distance between the product and the user's current location can be the numerical value of the distance between the scenic spot closest to the user in the product and the user. For factors such as "the distance between scenic spots", "the popularity of scenic spots", and "the distance between scenic spots and the user" in the above examples, different priorities can be set for each factor when displaying the sorting to determine which factor to prioritize to determine the sorting order. This embodiment does not limit this.

[0133] 4) Self-guided tour - full-day tour

[0134] This type of product can be used to meet the user's demand for a full-day trip. For example, if the user has a rest day during a business trip and can rest all day, a full-day tour can be carried out. The generation logic of this product is similar to the foregoing, and various factors such as the play duration, whether to make a reservation, and the user's geographical location can be considered for screening scenic spots, which will not be elaborated here. For example, full-day tickets with a play time of more than 6 hours in the current city, or one-day tour products and entertainment products can be screened. Figure 6 Some recommended products for full-day tours are exemplified. For example, they can include multiple scenic spots such as product 61 and product 2. These products are all suitable for full-day tours, and information such as the popularity of the products and the distance from the user can be displayed during the display so that users can have more understanding.

[0135] For the various types of self-guided tour products exemplified above, the user can click on one of the recommended scenic spots to view the detailed introduction of the scenic spot or perform operations such as purchasing tickets for the scenic spot.

[0136] The above-mentioned various types of self-guided travel products can meet the travel needs of users during the breaks of business trips. In addition, target users on business trips also have another need, that is, they want to charter a car for sightseeing on the day of their return journey. For example, it is too troublesome and inconvenient to go out sightseeing with luggage after checking out of the hotel. Moreover, without a plan, they are afraid of getting lost and worried about missing the flight. In the travel products provided in the embodiments of this specification, in addition to the above-mentioned self-guided products, charter-car sightseeing products can also be provided. This charter-car sightseeing product can send the target user to the airport on time, and the user's luggage will go with the car. Moreover, the itinerary of the chartered car is also quite diverse, and multiple charter-car sightseeing plans can be provided for users to choose from.

[0137] For example, for the day of return, assume that the business trip return time of the user is 18:00 in the afternoon. At 9:00 in the morning on the same day, the user opens the client of the travel service trading platform. At this time, the user's free time can be determined first. Based on the previous example, the moment when the client is opened by the user can be used as the starting moment to calculate the available play duration; or the business trip return time of the user can be used as the ending moment to calculate the available play duration.

[0138] Among them, the number of calculated available play durations can be multiple. Exemplarily, from the moment "9:00 in the morning" when the client is opened by the user to the business trip return time "18:00 in the afternoon", the time interval is 9 hours. According to the determination method of the available play duration in the previous example, multiple available play durations such as "4 hours", "6 hours", "8 hours" can be determined. For example, taking the moment "9:00 in the morning" when the client is opened by the user as the starting moment, adding a preset static duration to obtain an ending moment. If the preset static duration is 4 hours, the ending moment 13:00 can be obtained; if the preset static duration is 6 hours, the ending moment 15:00 can be obtained. Other available play durations can also be obtained, which are not listed in this embodiment.

[0139] In the scenario of charter-car sightseeing, by calculating and determining multiple available play durations, charter-car sightseeing travel products corresponding to the multiple available play durations can be provided accordingly, so that the types of charter-car sightseeing travel products are relatively rich and users can choose flexibly.

[0140] Please refer to Figure 7 For the example in, the charter-car sightseeing product can provide multiple charter-car options such as "4-hour charter car", "6-hour charter car", "8-hour charter car" for users to choose from. If the user clicks on the "Select Itinerary" option 71, the Figure 8 shown interface can be further displayed. As Figure 8 shown, the specific itinerary arrangement of the charter-car sightseeing provided by the merchant "Guangzhou XX Tourism Franchise Store" that provides charter-car sightseeing can be displayed in this interface.

[0141] Among them, if the target user selects Figure 7For a chartered vehicle with a certain duration, for example, if the user selects "6-hour chartered vehicle", only the itinerary options for the 6-hour chartered vehicle can be provided to the user, and multiple itinerary options for the 6-hour chartered vehicle can also be provided for the user to choose a suitable option from. If the target user does not select Figure 7 a certain duration, then the itinerary options for the 4-hour, 6-hour, and 8-hour chartered vehicles can all be provided to the user through Figure 8 the interface shown in

[0142] For the generation logic of a certain chartered vehicle itinerary corresponding to a certain playable duration, it can be as follows: The travel service trading platform can obtain the starting and ending positions and the starting and ending times in the user attribute information; among them, the starting and ending positions are the starting position and the ending position of the chartered vehicle travel itinerary, and the starting and ending times are the starting time and the ending time of the chartered vehicle travel itinerary. Among them, the acquisition method of the above user attribute information can be: On the day of the return journey, the starting position can be the user's current location or the location of the hotel reserved by the user. The platform can automatically obtain the user's order information until the hotel is obtained, or the platform can also automatically obtain the user's current location through the positioning module. There can be multiple determination methods for the specific location to be used. For example, through the human-computer interaction page, the user can be allowed to select whether to use the positioned location or the hotel location. Similarly, there can be multiple determination methods for the above starting and ending times. For example, the user can choose to set the starting time and the ending time, or can also set it so that the platform automatically determines the ending time according to the order time of the business trip return order. For example, if the business trip return time is 16:00, the platform can default 15:00 as the ending moment and send the user to the airport at this ending moment to avoid delaying the user's return journey.

[0143] In addition, the above starting and ending positions and the starting and ending times can be either precise times, such as 10:00 am; or, they can also be a time period, such as the morning, that is, the time in the morning can be used as the starting time of the chartered vehicle travel itinerary.

[0144] After the travel service trading platform obtains the above information, it can send this user attribute information to the itinerary generation device. The itinerary generation device can be a device of the travel service trading platform or a device of other platforms. For example, please refer to Figure 8In the example, the time and location information of this chartered tour have been sent to the itinerary generation device, where the location can be "Guangzhou Garden Hotel" as the departure location, "Guangzhou Baiyun Airport-T2 Terminal" as the end point, and the starting time is around 16:00 in the afternoon. The itinerary generation device can generate a chartered tour product between the starting and ending locations based on the above-mentioned user attribute information received. For example, based on the above-mentioned starting and ending locations and starting and ending times, a chartered travel itinerary for the chartered tour product is generated. For example, the chartered travel itinerary can be generated by a pre-trained itinerary generation model, or it can be generated by other methods. For example Figure 8 The chartered bus flash tour plan generated by the itinerary generating device is shown in FIG. 4 , which describes the itinerary arrangement of the chartered bus in detail.

[0145] In addition, in addition to sending the above-mentioned starting and ending positions and starting and ending times to the itinerary generating device, the travel service trading platform can also impose some restrictions on the products selected by the itinerary generating device. For example, still taking the product as a scenic spot as an example, the travel service trading platform can preset a scenic spot library, and select some scenic spots from the scenic spot library and send them to the itinerary generating device. When the device generates a chartered travel itinerary, it further selects scenic spots from these scenic spots selected by the platform to arrange the chartered travel itinerary. Among them, the scenic spots in the scenic spot library can be selected according to preset conditions. For example, for example, the scenic spots selected in the scenic spot library can include the following conditions: "Based on the city center, radiating within a range of 20 kilometers", "Scenic spots that do not require reservations", "Scenic spots with high popularity". Of course, it can also be selected according to other conditions without restrictions.

[0146] Specifically, when the platform screens the attractions in the attraction library, it can be based on the starting and ending locations of the chartered travel itinerary. For example, assuming that the starting location is the hotel where the user is staying and the ending location is the airport where the user is returning. Based on the hotel location and the airport location, a screening area range can be determined, and then based on the location information of each attraction in the attraction library, the attraction whose location is within the said area range is selected as the attraction pushed to the itinerary generation device.

[0147] For example, you can combine Figure 9 For example, the area of ​​the city where the user is currently located can be divided into four area ranges: A, B, C, and D. Assuming that the starting point of the chartered car is starting point 91 and the end point is end point 92, it can be seen that the starting and ending points are both within area B. The platform can prioritize the attractions within area B and push them to the itinerary generation device, such as attractions 93 and 94. As for attraction 95, since it is located in area D, in the opposite direction of the user going to end point 92, the platform usually does not push it to the itinerary generation device to avoid delaying the user's return trip.

[0148] The generation methods of various types of travel products are illustrated as above by way of example. Next, the display method of travel products on the page will be described:

[0149] First, for the travel products recommended to target users, there is no restriction on their display positions. For example, they can be displayed at the upper part of the platform's home page, and users can quickly see them as long as they open the travel service trading platform. Second, in order to stimulate users' demand for tourism, a prompt copy can also be displayed on the travel product recommendation page. Figure 10A and Figure 10B Two examples of copy are illustrated. For example, "There are only 9 hours left to play before leaving Guangzhou" can be displayed to prompt users to travel as soon as possible. The remaining time "9 hours" can be obtained by the platform by backtracking from the business trip return time corresponding to the user's return order. Another example is that copy information such as "Play on the way during a business trip and leave the last day for yourself" can also be used to prompt users to travel.

[0150] When displaying travel products, as described above, the platform can provide various types of products such as playing nearby, playing at night, playing by chartering a vehicle, etc. Then, on the travel product recommendation page, the respective tab pages corresponding to each type of travel product can be displayed. Please refer to Figure 11 As shown, the tab pages on the travel product recommendation page can include: a first tab page 1101 corresponding to the travel products of the playing-by-chartering-vehicle type, and a second tab page 1102 corresponding to the travel products of the playing-by-oneself type. And / or, under the tab page of the travel products of the playing-by-oneself type, at least one of the following can also be included: the tab page corresponding to the travel products of the playing-nearby type, the tab page corresponding to the travel products of the playing-at-night type, the tab page corresponding to the travel products of the playing-on-the-way type, and the tab page corresponding to the travel products of the playing-all-day type.

[0151] As described above, the types of products to be recommended that match can be obtained according to the free time. For example, if it is determined according to the free time that the "playing-nearby" type is to be recommended to the user, then the products of this playing-nearby type can be called the target type of travel products, and the selected travel products, that is, various scenic spots for playing nearby, can be displayed in the tab page corresponding to this type of product.

[0152] In addition, when the travel service trading platform according to the embodiments of this specification recommends products in any of the embodiments of this specification, it may recommend products to users based on the information of the travel service trading platform itself. For example, after a user of the travel service trading platform books a flight ticket or a hotel, the platform recommends travel products to this user; alternatively, the travel service trading platform may cooperate with other platforms to implement this product recommendation method. For example, for users of other platforms, if a user books a flight ticket or a train ticket on another platform, in this case, the other platform may share the information required for product recommendation with the travel service trading platform. After the travel service trading platform obtains the travel products to be recommended based on the information, it then sends the travel products to the other platform and displays them to users through the other platform.

[0153] The following briefly describes an exemplary application scenario for recommending travel products:

[0154] For example, user Xiao Wang is going to Shanghai on a business trip and he books a flight ticket to Shanghai on the travel service trading platform. After the travel service trading platform determines that Xiao Wang is a business travel user and determines that this order is a business travel order based on information such as the travel date and destination of this flight ticket order, it confirms that the type of this travel event of user Xiao Wang is a business travel event, that is, going to Shanghai on a business trip. Then, during Xiao Wang's business trip in Shanghai, assuming at 10 o'clock in the morning on a working day, Xiao Wang actively opens the client of the travel service trading platform. The platform calculates therefrom that Xiao Wang is idle in the morning. The specific idle period may be {10:00 - 12:00}, and the available play time is 2 hours. Then the platform can determine to recommend travel products of the "Nearby Play" type to Xiao Wang. Based on the available play time, Xiao Wang's current location and other information, the platform screens the attractions that can be recommended and displays the screened attractions under the "Nearby Play" tab on the travel product recommendation page. User Xiao Wang can directly see these attractions. If there is an attraction he likes, Xiao Wang can click to purchase tickets and perform other operations.

[0155] Figure 12 It is a schematic structural diagram of an electronic device provided by an exemplary embodiment. Please refer to Figure 12, at the hardware level, the device includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile memory 1210. Of course, it may also include other hardware required for other functions. One or more embodiments of this specification can be implemented in a software manner. For example, the processor 1202 reads the corresponding computer program from the non-volatile memory 1210 into the memory 1208 and then runs it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementation manners, such as logical devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logical unit, and can also be hardware or a logical device.

[0156] Please refer to Figure 13 , the travel product recommendation device can be applied to a device as shown in Figure 12 to implement the technical solutions of the embodiments of this specification. The device may include: a type recognition module 1301, a time determination module 1302, and a product recommendation module 1303.

[0157] The type recognition module 1301 is configured to recognize the type of the travel event in response to detecting a travel event of a target user for a destination.

[0158] The time determination module 1302 is configured to determine the idle time of the target user during the business trip at the destination when the travel event is a business trip event.

[0159] The product recommendation module 1303 is configured to recommend travel products for visiting the destination to the target user according to the idle time.

[0160] Based on the same concept as the above method, this specification also provides a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0161] Based on the same concept as the above method, this specification also provides a computer program product, including computer programs / instructions, and when the computer programs / instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0162] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, commodity or device comprising a series of elements not only includes those elements but also other elements not expressly listed, or elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, commodity or device comprising said element.

[0163] The specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0164] The above are only the preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of one or more embodiments of this specification shall be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A travel product recommendation method, characterized in that: The method is applied to a travel service transaction platform, and the method comprises: In response to detecting a travel event of the target user to a destination, identifying a type of the travel event; In the case where the travel event is a business trip event, determining the free time of the target user during the business trip to the destination; According to the free time, travel products for visiting the destination are recommended to the target user.

2. The method according to claim 1, characterized in that The identifying the type of the travel event includes: If the target user is a business travel user, and / or the travel order generated by the target user in response to the travel event trigger is a business travel order, then the travel event is determined to be a business travel event; The travel order is triggered and generated by the target user on the travel service transaction platform, or the travel order is triggered and generated by the target user on the business travel service transaction platform, and the information of the travel order is shared by the business travel service transaction platform to the travel service transaction platform.

3. The method according to claim 2, characterized in that If the target user meets at least one of the following user type determination conditions, the target user is determined to be a business travel user: The target user's personal user registration information on the travel service transaction platform includes corporate information; receiving, on the travel service transaction platform, corporate user registration information about the target user provided by the travel service transaction platform; The historical travel orders of the target user on the travel service transaction platform are business travel orders; The historical travel orders of the target user on the travel service transaction platform are travel orders; and / or, If the travel order meets at least one of the following order type determination conditions, the travel order is determined to be a business trip order: The travel order is triggered and generated by the target user on the travel service transaction platform; The payer of the travel order is the enterprise registered on the travel service transaction platform; The target user's historical travel orders for the same destination include business trip orders; The destination of the travel order is a non-resident location of the target user; The travel date of the travel order is a working day; The hotel booked for the travel order is a business hotel.

4. The method according to claim 1, characterized in that: The determining of the free time of the target user during the business trip to the destination includes: In the case that the whole day of a working day is divided into at least one default free time period and at least one default busy time period, the default free time period of the working day during the travel process is determined as the free time of the target user.

5. The method according to claim 4, characterized in that The determining of the free time of the target user during the business trip to the destination includes: If there is a preset trigger event related to any default busy period, the any default busy period is determined as the idle time of the target user, or the any default busy period and other default busy periods associated therewith are determined as the idle time of the target user.

6. The method according to claim 5, characterized in that The preset trigger event includes any of the following: The client of the travel service transaction platform is opened by the target user; The target user has historically booked travel products related to any of the default busy periods; The target user's business trip return time is within any of the default busy periods.

7. The method according to claim 6, characterized in that The method further includes: using the time when the client of the travel service transaction platform is opened by the target user as the starting time, or using the time when the target user returns from a business trip as the ending time, to calculate the playable duration corresponding to the free time of the target user; or determining the playable duration corresponding to the free time of the target user based on the historical play habits of the target user; The recommending to the target user a travel product suitable for visiting the destination during the free time includes: recommending to the target user a travel product that matches the available travel time.

8. The method according to claim 1, characterized in that The determining of the free time of the target user during the business trip to the destination includes: Determine the entire rest day during the travel process as the target user's free time; or, If the return date of the business trip is a working day next week, the whole day of this weekend will be determined as the free time of the target user; if the return date of the business trip is a rest day, the time period of the return time on the rest day and / or other time periods associated with it will be determined as the free time of the target user.

9. The method according to claim 1, characterized in that: The recommending to the target user a travel product suitable for visiting the destination during the free time includes: In the travel product recommendation page, the tab page corresponding to the target type of travel product is displayed, and the travel product recommendation page contains tab pages corresponding to each type of travel product; wherein the tab pages include: a first tab page corresponding to a travel product of a chartered tour type, a second tab page corresponding to a travel product of a play-by-yourself type; and / or, the tab page corresponding to a travel product of a play-by-yourself type includes at least one of the following: a tab page corresponding to a travel product of a play-nearby type, a tab page corresponding to a travel product of a play-at-night type, a tab page corresponding to a travel product of a play-on-the-way type, and a tab page corresponding to a travel product of a play-by-all-day type; The filtered travel products are displayed in the tab page corresponding to the target type of travel products.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images