Lease demand lock and reminder method and apparatus

Abstract

The specification provides a lease demand locking and reminding method and device. The method comprises: in the case that an access party of a lease object access event does not form a lease order, determining a user account identifier of the access party; obtaining a user feature corresponding to the user account identifier, an object feature of a lease object indicated by the lease object access event and a time node feature to predict a future lease demand probability of the access party for the lease object within a future time window; if the future lease demand probability satisfies a locking condition, creating a lease demand locking record, the lease demand locking record being used to record a demand locking relationship between the access party and the lease object; after the lease demand locking record is generated, monitoring whether the access party triggers a lease demand touch event; if the lease demand touch event is triggered, generating a lease reminder corresponding to the lease object based on the lease demand touch event and the lease demand locking record and outputting.

Description

Technical Field

[0001] This specification relates to the field of data processing technology for internet rental services, and more particularly to a method and electronic device for locking and reminding rental demand. Background Technology

[0002] In online rental service scenarios, users can access information about rental items such as cameras, game consoles, and clothing through online entry points such as advertising pages, content pages, and partner pages. Related technologies typically use statistical analysis of user browsing, redirection, and order placement behaviors within the current access session to evaluate the processing results of these behaviors.

[0003] However, users' rental decisions are generally closely related to the timing of actual usage scenarios, such as travel, events, holidays, or temporary usage plans. Therefore, the time when a user first browses rental information may not coincide with the time when they actually generate a rental demand. In such non-instantaneous decision-making scenarios, if rental access behavior is still primarily processed based on the current session results, access behaviors with different potential subsequent needs can easily be confused during data processing, affecting the accuracy of the relevant system's judgment on rental access behavior.

[0004] Therefore, how to improve the accuracy of data processing for non-real-time decision-making behaviors in internet rental scenarios is a technical problem that urgently needs to be solved in the field of data processing for internet rental services. Summary of the Invention

[0005] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a method for locking and reminding rental demand is proposed, comprising: If a rental object access event triggered by an external entry point is obtained, and it is determined that the accessing party of the rental object access event has not formed a rental order, the user account identifier of the accessing party is determined; Obtain the user characteristics corresponding to the user account identifier, the object characteristics and time node characteristics of the rental object indicated by the rental object access event, and predict the probability of the accessing party's future rental demand for the rental object within a future time window based on the user characteristics, the object characteristics and the time node characteristics; If the probability of future rental demand meets the locking condition, a rental demand locking record is created. The rental demand locking record is used to record the demand locking relationship between the visitor and the rental object. After the rental demand lock record is generated, monitor whether the accessing party triggers the rental demand reach event; If the rental demand notification event is triggered, a rental reminder corresponding to the rental object is generated and output based on the rental demand notification event and the rental demand lock record.

[0006] According to a second aspect of the embodiments of this specification, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor executes the executable instructions, it is used to implement the method described in the first aspect.

[0007] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in the first aspect.

[0008] According to a fourth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0009] As can be seen from the above embodiments, this specification, by determining the user account identifier of the visitor after an access event triggered by an external entry point fails to generate a rental order, and predicting the probability of future rental demand based on user characteristics, rental object characteristics, and time node characteristics, can differentiate the processing of different unsuccessful visits, avoiding treating all unsuccessful visits as homogeneous invalid visits; when the probability of future rental demand meets the locking conditions, a rental demand lock record is created, transforming the brief access behavior into a demand lock relationship that can be tracked by the system, avoiding the loss of potential rental demand. When a rental demand reach event is subsequently triggered, a rental reminder is generated based on this rental demand lock record, ensuring that the generation of rental reminders corresponds to the determined rental demand lock relationship and matches the user's actual rental demand time window, thereby improving the continuity and accuracy of unsuccessful rental access data in subsequent reminder generation.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the architecture of a rental demand locking and reminder system provided in an exemplary embodiment.

[0012] Figure 2 This is a schematic diagram of a server architecture provided in an exemplary embodiment.

[0013] Figure 3 This is a schematic diagram illustrating the training process of a rental demand prediction model provided in an exemplary embodiment.

[0014] Figure 4 This is a flowchart of a rental demand locking and reminder method provided in an exemplary embodiment.

[0015] Figure 5 This is a schematic diagram of an exemplary embodiment of a rights object generation process.

[0016] Figure 6 This is a schematic diagram of a pre-authorization process for credit-based deposit waivers provided in an exemplary embodiment.

[0017] Figure 7 This is a schematic diagram of a pre-authorization query process provided in an exemplary embodiment.

[0018] Figure 8 This is an exemplary embodiment of a flowchart providing a rental demand lock-in, reminder, and rental process.

[0019] Figure 9 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with relevant laws, regulations and standards, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0022] In online rental service scenarios, users can access the details pages of rental items such as cameras, game consoles, clothing, and outdoor gear through external entry points such as social media, content platforms, search platforms, and partner pages. Currently, external entry point access paths, represented by in-feed ads and search ads, are typically built around a short path of "exposure—click—instant order," and their evaluation methods focus more on whether users complete immediate actions such as clicking, redirecting, or placing orders within a short period. This type of processing logic is well-suited for ordinary instant consumption scenarios, but when directly applied to rental scenarios, it can easily deviate from the decision-making patterns of rental behavior.

[0023] Rental activities are typically associated with real-world usage scenarios such as travel, exhibitions, holidays, and temporary needs. There may be a significant gap between when a user first browses a rental item and when a rental order is actually placed. When a user enters a rental item's details page through an external portal, they may only be browsing information, comparing prices, or gaining a preliminary understanding, before they actually need to use the rental item. In this situation, if the visit is still primarily processed based on the immediate order result within the current session, it's easy to confuse potentially future rental visits with ordinary, invalid visits, making it difficult for such visits to continue participating in the subsequent rental service process if no order is placed.

[0024] In some related solutions, users who have viewed rental items can be followed up through shopping carts, favorites, or retargeting ads. However, shopping carts or favorites usually rely on users actively adding items; if users do not actively take action, the rental items are difficult to include in the follow-up process. While short-link direct rental solutions attempt to encourage on-the-spot orders by reducing the number of steps, simply compressing the access path cannot eliminate the time lag in rental decisions for users who are still comparing, planning, or waiting for actual use. Retargeting ads mostly rely on historical browsing records for repeated exposure, making it difficult to combine the future usage time of the rental item, the user's subsequent scenario, and the rental service status for continuous processing, which can easily lead to duplicate reach or mismatched reach timing.

[0025] Therefore, how to improve the accuracy of data processing for non-real-time decision-making behaviors in internet rental scenarios is a technical problem that urgently needs to be solved in the field of data processing for internet rental services.

[0026] Based on the above scenarios and processing requirements, this specification provides a method for locking and reminding rental requests, which can be applied to a rental request locking and reminder system 10. Please refer to... Figure 1 , Figure 1A schematic diagram of the logical architecture of a rental demand locking and reminder system 10 is shown. The system 10 may include a user terminal 100, an external access platform 200, a communication network 300, and a server 400.

[0027] User terminal 100 can be a mobile phone, tablet computer, wearable device, personal computer, or other terminal device capable of accessing the rental service page. External entry platform 200 can be an advertising platform, content platform, search platform, social platform, or other platform capable of providing user terminal 100 with access to rental objects. Communication network 300 connects user terminal 100, external entry platform 200, and server 400, and can include the Internet, mobile communication network, local area network, wide area network, or a combination thereof. Server 400 is used to execute the rental demand locking and reminder method in the embodiments of this specification. Server 400 can be a single server, server cluster, cloud server, distributed server, or a service system composed of multiple computing nodes.

[0028] Please see Figure 2 The server 400 can run the following modules: rental demand pre-locking module 401, rental demand prediction model 402, rights management module 403, rental demand locking record database 404, scenario-based demand activation module 405, credit-based deposit-free pre-authorization module 406, message push module 407, order processing module 408, and intelligent traffic optimization module 409. These modules can be logical function modules deployed on the same server 400, or they can be distributed across different servers or service nodes according to actual system deployment needs.

[0029] The rental demand pre-locking module 401 receives rental object access events, which are generated based on the accessor's triggering of a rental object access link pushed by the external entry platform 200. If it is determined that the accessor has not formed a rental order, the rental demand pre-locking module 401 determines the accessor's user account identifier and data such as object characteristics and time node characteristics related to the rental object access event. The rental demand prediction model 402 outputs the probability of the accessor's future rental demand for the rental object within a future time window based on user characteristics, object characteristics, and time node characteristics. The rights management module 403 generates rights objects corresponding to the rental object when the probability of future rental demand meets the locking conditions, and stores the rights objects in the user rights object set corresponding to the user account identifier.

[0030] The rental demand lock record library 404 is used to store rental demand lock records. These records can be used to record the relationships between the visitor, the rental object, and the rights holder, and can further record information such as future time windows, future rental demand probability, rights status, credit pre-authorization status, number of contacts, order association status, and termination conditions. The scenario-based demand activation module 405 monitors whether the visitor triggers a rental demand contact event, and when such an event is triggered, determines the rental object to be reminded based on the event and the rental demand lock record in the rental demand lock record library 404. The message push module 407 generates and outputs rental reminders based on the processing results of the scenario-based demand activation module 405.

[0031] The credit-based pre-authorization module 406 generates a credit pre-authorization status when the visitor expresses rental intention and actively confirms authorization, and associates the credit pre-authorization status with the rental demand lock-in record. The order processing module 408 writes the order identifier back to the corresponding rental demand lock-in record when the visitor generates a rental order based on the rental reminder. The intelligent traffic optimization module 409 generates traffic adjustment parameters based on information such as the probability of future rental demand and long-term conversion evaluation results, to adjust the subsequent target audience or traffic weight.

[0032] exist Figure 1 and Figure 2 In the architecture shown, after user terminal 100 accesses the rental object through external entry platform 200, server 400 can receive the rental object access event through rental demand pre-locking module 401 and call rental demand prediction model 402 to predict the probability of future rental demand of the access party within a future time window. When the probability of future rental demand meets the locking condition, server 400 can generate a rights object through rights management module 403 and create a corresponding rental demand locking record in rental demand locking record library 404. When the access party triggers a rental demand reach event in the future, scenario-based demand activation module 405 can generate a reminder decision based on the reach event and rental demand locking record, and the message push module 407 will output a rental reminder.

[0033] Please see Figure 3This specification describes the training process of a rental demand prediction model, which can be executed by a server 400 or a model training device connected to the server 400. The model training device can obtain multiple rental object access event samples from historical access logs, order records, rental object information tables, and time node information tables. Each rental object access event sample corresponds to one historical access process and includes the user characteristics of the historical visitor, the characteristics of the historical rental object, the characteristics of the historical time node, and sample tags. User characteristics may include the historical visitor's credit status, historical rental behavior, access preferences, and geographic attributes; historical rental object characteristics may include rental category, object value, rental price, inventory attributes, and applicable scenario tags; historical time node characteristics may include access date, before or after holidays, weekdays or rest days, seasons, and activity cycles. Sample tags are used to characterize whether the historical visitor generated rental behavior associated with the historical rental object during the sample observation period, enabling the model to learn the correspondence between access events that did not result in immediate orders and subsequent rental demand.

[0034] In one possible implementation, the model training device can determine the first type of positive and negative samples based on the correlation between historical rental object access events and rental orders during the sample observation period. If a historical visitor places a rental order matching the rental category of the historical rental object during the sample observation period, it indicates a strong category consistency between the visit event and subsequent rental behavior, and the model training device can label the corresponding rental object access event sample as a first type of positive sample. If a historical visitor does not place any rental orders during the sample observation period, it indicates that the visit event does not demonstrate verifiable rental conversion results during the observation period, and the model training device can label the corresponding rental object access event sample as a first type of negative sample. Through this processing method, the model can obtain training evidence with relatively clear boundaries between direct transactions and non-transactions.

[0035] In another possible implementation, multiple rental object access event samples can also include second-type positive samples and / or second-type negative samples. If a historical visitor places a rental order during the sample observation period, but the rental category of that order is related to the rental category of the historical rental object but not exactly matched (e.g., the historical rental object was a camera, and the subsequent rental order is a game console, which is also a digital product), the model training device can label the corresponding rental object access event sample as a second-type positive sample. This type of sample reflects a category correlation between the access event and the subsequent rental behavior, but the correlation strength is weaker than in the case of a complete category match. If a historical visitor places a rental order during the sample observation period, but the rental category of that order is not related to the rental category of the historical rental object, the model training device can label the corresponding rental object access event sample as a second-type negative sample. This type of sample is used to distinguish situations where the historical visitor has other rental behaviors, but these behaviors lack relevance to the current historical rental object, avoiding directly attributing all subsequent transactions to previous access events.

[0036] During training, the label values ​​of both the first and second class of positive samples can be set to the first label value, such as 1, and the label values ​​of both the first and second class of negative samples can be set to the second label value, such as 0. To reflect the strength of the association between different samples and historical rental objects, the weight of the first class of positive samples is greater than that of the second class of positive samples, and the weight of the first class of negative samples is greater than that of the second class of negative samples. For example, the first class of positive samples can have a higher positive sample weight, and the second class of positive samples can have a lower positive sample weight; the first class of negative samples can have a higher negative sample weight, and the second class of negative samples can have a lower negative sample weight. This weight does not change the sample label value itself, but is used to adjust the degree of influence of the sample in the model parameter update process.

[0037] The model training device can input user characteristics, historical rental object characteristics, and historical time point characteristics into the rental demand prediction model to be trained, predict the probability of future rental demand, and calculate a weighted loss based on the predicted demand probability, sample label values, and sample weights. The weighted loss can be expressed as: in, Indicates the first The sample label value of each sample. This represents the predicted demand probability output by the rental demand forecasting model. Indicates the first The sample weights of each sample. This represents the classification loss for a single sample. The model training device can update the model parameters of the rental demand prediction model based on the weighted loss, so that samples with a high degree of correlation contribute more to the parameter update, while samples with a weaker correlation but still of reference value participate in the training with a lower contribution.

[0038] By employing the aforementioned sample classification and weighted training methods, the potential relevance reflected in category expansion transactions can be preserved, while reducing the interference of weakly correlated samples on the model's training direction. It can also distinguish between users who made no transactions and those who generated irrelevant rental orders, reducing the impact of label noise on the probability of future rental demand. Therefore, the model's output probability of future rental demand more closely reflects the true correlation between access events, rental objects, and subsequent rental behavior, providing a more stable probabilistic basis for creating rental demand lock-in records, triggering rental reminders, and adjusting deployment parameters.

[0039] In some embodiments, the sample observation period corresponds to a future time window. For historical rental object access event samples, the sample observation period is the time range extending backward from the occurrence time of the historical rental object access event, used to determine whether the historical visitor generated rental behavior associated with the historical rental object within this time range, and to generate sample labels accordingly. For the online prediction process, the future time window is the time range extending backward from the occurrence time of the current rental object access event, used to represent the time range within which the server predicts the visitor may generate rental demand.

[0040] In one implementation, the length of the sample observation period can be determined according to the same configuration rules as the future time window, thus ensuring that the sample observation period and the future time window length are the same for the same rental object. For example, the model training device can determine the sample observation period for access events of a historical rental object based on its category information and usage scenario information; similarly, when performing online prediction, the server 400 can determine the future time window based on the category information and usage scenario information of the current rental object. By using consistent or corresponding determination rules for the sample observation period and the future time window, the label generation criteria during model training can be kept consistent with the prediction target during online prediction, reducing the deviation between the training target and the actual prediction target.

[0041] Please see Figure 4 This specification provides an embodiment of a method for locking and reminding users of rental needs, including: In S400, when a rental object access event triggered by an external entry point is obtained, and it is determined that the accessing party of the rental object access event has not formed a rental order, the user account identifier of the accessing party is determined.

[0042] External entry points may include advertising entry points, content page entry points, search result entry points, partner page entry points, or other entry points that can guide user terminal 100 to access the rental object page. Rental object access events may include at least one of the following: access entry point identifier, rental object identifier, access time, access page information, terminal identifier, and access source information. The rental object may be a leasable good, equipment, clothing, tool, or other service object; the accessing party may be the user who triggered the rental object access event, a user account, or the access subject corresponding to user terminal 100.

[0043] Server 400 can obtain rental object access events through event data transmitted from external entry platform 200. For example, when user terminal 100 triggers a redirect to the rental object page, external entry platform 200 can send an access entry identifier, click identifier, rental object identifier, and terminal identifier to server 400. After receiving this type of data, server 400 can parse the event fields using rental demand pre-locking module 401, and use the page access, dwell, redirect, exit, or order placement status during the same access process as the basis for determining whether the visitor has formed a rental order.

[0044] In some embodiments, when determining whether a rental order has not been formed by the visitor, the server 400 may jointly determine the page status, order status, operation status, and time status corresponding to the rental object access event. A rental object access event may correspond to a page access process triggered by an external entry point. This access process may include actions such as entering the rental object page, browsing rental object information, entering the order page, initiating a payment attempt, returning to the previous page, closing the page, or remaining on the page for an extended period.

[0045] Server 400 can receive page events reported by user terminal 100 and order status information returned by order processing module 408, and associate multiple types of events in the same access process according to access identifier, user account identifier, or rental object identifier. Page status may include whether the rental object page is closed, whether a return operation has occurred, or whether it has redirected to the order page; order status may include whether a rental order has been created, whether payment has been completed, or whether there is a payment interruption record; operation status may include page dwell time, swiping, clicking, image viewing, specification selection, and other access behaviors; time status may include the cumulative time after entering the page, the waiting time after entering the order page, and whether the preset conversion waiting time limit has expired.

[0046] In one implementation, if the server 400 detects that the visitor has exited the rental object page and no paid rental order corresponding to the access identifier or user account identifier is found, it can be determined that the visit did not generate a rental order. If the visitor has entered the order page but has not completed payment within a first preset time period, the server 400 can identify this state as an incomplete order state and determine that the visitor has not generated a rental order. If the visitor remains on the rental object page but does not perform any actions such as clicking, swiping, or selecting specifications for a duration that reaches a second preset time period, the server 400 can identify this access process as a session interruption state. If it is not possible to determine this immediately through page exit, unpaid order, or session interruption, the server 400 can also initiate a preset conversion waiting time limit after the rental object access event is triggered; if no corresponding rental order is generated after the time limit expires, it can be determined that the visitor has not generated a rental order.

[0047] If the visitor has not placed a rental order, server 400 needs to determine the visitor's user account identifier in order to associate this visit with the subsequent prediction, record creation, and alert output processes. The user account identifier can be an account identifier, user identifier, member identifier, or a de-identified account identifier used in the rental service system. Different methods can be used to determine the user account identifier depending on whether the rental object's access event triggers an account authorization process.

[0048] In some embodiments, if the access event of the rental object does not trigger the rental service application or account authorization page, the external entry platform 200 can transmit the access entry identifier and terminal identifier to the server 400 through a preset event transmission link. The server 400 can query the user account identifier that has a binding relationship or historical login relationship with the terminal identifier in the account association data based on the terminal identifier. The terminal identifier may include a device identifier, browser identifier, application instance identifier, or a terminal-side identifier after privacy protection processing. In this way, even if the accessing party does not directly log in to the rental service account on the external entry page, the access event can still be associated with the corresponding user account under the condition of satisfying the authorization and data processing rules.

[0049] In other embodiments, if a rental object access event triggers a rental service application, rental mini-program, or account authorization page, server 400 can obtain the user account identifier of the accessing party through the account authorization process. The account authorization process may include initiating an authorization request, displaying the authorization page, the accessing party confirming authorization, returning authorization credentials, and parsing the user account identifier. Server 400 can obtain the user account identifier of the accessing party in the rental service system based on the authorization credentials and associate this user account identifier with the rental object access event. Through these two paths, server 400 can obtain user account identifiers that can be used for subsequent processing under different access links, reducing data breakpoints between external access events and the rental service account.

[0050] In some embodiments, after determining that multiple access events for rental objects have not resulted in rental orders, the server 400 can generate a deduplication key based on the user account identifier, the rental object identifier, and a preset deduplication time window. The preset deduplication time window can be 24 hours, or it can be configured according to the rental object category or the access source. For multiple access events generated by the same visitor for the same rental object within the preset deduplication time window, the server 400 can merge them into a single event to be predicted, in order to avoid repeatedly triggering the future rental demand prediction process.

[0051] During the merging process, server 400 can write the first access event to the leased object into the set of events to be predicted, and retain the access identifier, entry time, and leased object identifier of the first access event. For subsequent access events to the leased object, server 400 will not generate new events to be predicted, but will update the behavior intensity parameters corresponding to the events to be predicted. The behavior intensity parameters may include at least one of the following: cumulative dwell time, browsing depth, number of browsing sessions, number of image views, and attention actions, which are used to characterize the degree of sustained attention of the visitor to the leased object.

[0052] If the initial access event to the rental object has already triggered a rental demand lock, and subsequent access events occur within the validity period of the rental demand lock record, server 400 can also update the user activity parameters in the rental demand lock record based on subsequent access events. Through this merging process, duplicate predictions and records caused by the same user repeatedly accessing the same rental object can be reduced, while retaining the intention enhancement information reflected in subsequent access behaviors, enabling subsequent rental reminder ranking to utilize more complete behavioral intensity data.

[0053] In S402, the user characteristics corresponding to the user account identifier, the object characteristics of the rental object indicated by the rental object access event, and the time node characteristics are obtained. Based on the user characteristics, object characteristics, and time node characteristics, the probability of the accessing party's future rental demand for the rental object within a future time window is predicted.

[0054] User characteristics may include at least one of the following: basic user attributes, historical rental behavior, historical access behavior, account status, rental preferences, historical order categories, and historical fulfillment status. Object characteristics may include at least one of the following: category of rental object, price, rental period, applicable scenarios, inventory status, value attributes, and historical rental popularity. Time-based characteristics may include access time, weekday information, holiday information, time interval from a specific date, seasonal information, event schedule information, or other characteristics that can characterize the time context.

[0055] Server 400 can retrieve user characteristics from the user characteristic database or account service based on the user account identifier, and retrieve object characteristics from the lease object information database based on the lease object identifier in the lease object access event. Time node characteristics can be generated by server 400 based on access time, system calendar, holiday configuration, or scenario time configuration.

[0056] A future time window represents the predicted timeframe within which a potential renter may generate rental demand. This future time window can be of fixed length or dynamically determined based on the category information and / or usage scenario information of the rental object. Different categories and / or different scenario information correspond to different future time window lengths. Category information can represent the type of rental object, such as digital products, clothing, outdoor equipment, etc.; usage scenario information can represent the possible usage conditions of the rental object, such as travel, holidays, exhibitions, tourist destinations, etc.

[0057] When determining future time windows, server 400 can read a preset time window configuration table. This table records the correspondence between different product categories, different usage scenarios, and time window lengths. For example, the average decision-making cycle for digital products (cameras, game consoles) is 7-15 days, for clothing (formal wear, Hanfu) it is 3-10 days, and for outdoor equipment (tents, skis) it is 10-30 days. The time window for consumption scenarios before holidays (such as Hanfu before the Spring Festival) is longer, at 15-30 days, while the time window for immediate scenarios (such as cameras at tourist destinations) is shorter, at 3-7 days.

[0058] By setting the aforementioned future time window, server 400 can extend the judgment of whether a rental object access event will immediately result in an order within the current access session to the prediction and management of whether rental demand may arise in the next few days. Therefore, access behavior that does not result in a rental order is no longer treated merely as an immediate, unconverted result, but can be combined with the decision-making cycle of the rental category and the time constraints of the usage scenario to form a demand judgment result with time boundaries.

[0059] The probability of future rental demand is used to characterize the likelihood that a visitor will generate rental demand for the rental object within a future time window. This probability can be output by the rental demand prediction model 402, or by a rule model, a machine learning model, or a combination of multiple models.

[0060] During the prediction process, server 400 can input user characteristics, object characteristics, and time node characteristics into rental demand prediction model 402. Rental demand prediction model 402 calculates the relationship between user characteristics, object characteristics, and time node characteristics, outputting the probability of future rental demand. This probability can be a probability value within a preset range, or a demand score that can be compared with locking conditions. Through this prediction processing, server 400 can further distinguish access behaviors that have not resulted in a rental order into access behaviors with different demand intensities, thereby providing data basis for whether to create a rental demand lock-in record subsequently.

[0061] In S404, if the probability of future rental demand meets the locking conditions, a rental demand locking record is created. The rental demand locking record is used to record the demand locking relationship between the visitor and the rental object.

[0062] The locking condition can be that the probability of future rental demand reaches a preset probability threshold, the probability of future rental demand falls into a preset demand level, or the probability of future rental demand, along with the category of the rental object, the time node, or the source of access, jointly meets preset judgment rules. Server 400 can compare the probability of future rental demand with the locking condition; if the comparison result shows that the visitor has a processable future rental demand for the rental object within a future time window, a rental demand locking record is created.

[0063] A rental demand lock record can be a structured data record stored in the rental demand lock record database 404. This record may include at least a lock record identifier to identify the record, and information characterizing the demand lock relationship between the accessing party and the rental object. The lock record identifier may be generated by the server 400 based on a user account identifier, a rental object identifier, access time, or a random identifier. Through the lock record identifier, subsequent contact determination, reminder generation, and status update processes can locate the same rental demand lock record.

[0064] A demand lock-in relationship can be understood as a state relationship between a visitor and a rental object where a rental demand awaits follow-up within a future time window. This relationship indicates that server 400 retains the visit behavior that did not result in an order as a data object that can be processed continuously. After creating a rental demand lock-in record, server 400 can write the record to the rental demand lock-in record database 404, enabling subsequent modules to query the record based on the visitor, rental object, or touch event.

[0065] In some embodiments, if the same user accesses the same rental object multiple times within a similar timeframe, the server 400 can query the rental demand lock record database 404 before creating a new rental demand lock record to determine if a valid record corresponding to the user and the rental object already exists. If a valid record already exists, the server 400 can update the access time, future rental demand probability, or status information in the valid record without having to create multiple records repeatedly. This approach reduces the interference of duplicate records on subsequent access decisions.

[0066] In some embodiments, please refer to Figure 5 If the probability of future rental demand meets the locking conditions, the server 400 can generate a rights object corresponding to the rental object through the rights management module 403. This rights object may include information such as rental discounts, validity period, and applicable rental object identifier, which is used to provide identifiable and redeemable rental rights to the visitor in subsequent rental reminders or rental pages.

[0067] In related technologies, when a user clicks on an ad but does not convert, a coupon can typically be issued to the user's account, waiting for the user to actively use the coupon to complete a transaction later. However, these coupons are often scattered across different merchant accounts or different page entry points, making it difficult for users to view and manage them centrally, and they are easily forgotten after the visit session ends. Furthermore, traditional coupon issuance methods mostly passively wait for users to actively view them, lacking a reminder trigger mechanism that integrates with subsequent usage scenarios; for rental scenarios, there needs to be a certain matching relationship between the validity period of the rights, the type of rental object, and the actual time of use, and general coupon mechanisms are difficult to fully adapt to rental needs, exhibiting characteristics of lag and scenario dependence.

[0068] In this embodiment, the rights management module 403 can store the generated rights objects in a set of user rights objects corresponding to the user account identifier of the visitor. This set of user rights objects can correspond to the user rights center page in the user terminal 100, so that rental rights are centrally stored at the account level, rather than being attached to a single external entry point, a single page session, or a single merchant page. Through this centralized storage method, the visitor can view the rights objects related to their rental needs through a unified entry point, and the server 400 can also retrieve the rights objects when generating rental reminders later.

[0069] After the rights and benefits object is generated and stored, server 400 can create a rental demand lock record, and record the association between the visitor, the rental object, and the rights and benefits object in this record. Through this processing method, the rental rights and benefits resulting from the rental object access event can be accumulated in the rights and benefits set under the user's account, so that subsequent rental reminders, rights and benefits display, and rental order placement can be linked based on the same rights and benefits object. This reduces the loss of rights and benefits information due to page exit, scattered merchant entry points, or closed external entry points, and improves the matching degree between rental rights and subsequent rental usage scenarios.

[0070] In S406, after the rental demand lock record is generated, it monitors whether the accessing party triggers the rental demand reach event.

[0071] A rental demand notification event can be an event that characterizes a user's entry into a rental-related scenario, time point, or behavioral environment. Rental demand notification events can be generated by user terminal 100, server 400, or other data sources related to the rental service. The specific type of rental demand notification event can be configured according to the usage scenario of the rental object; this embodiment does not limit the specific event source or event format.

[0072] After the rental demand lock record is generated, server 400 can use this record as the basis for subsequent outreach judgments. Contextualized demand activation module 405 can continuously or periodically receive event data related to the visitor and determine whether the event data meets the rental demand outreach conditions. For example, contextualized demand activation module 405 can determine whether the visitor has triggered a rental demand outreach event related to the rental object based on information such as event time, event location, event behavior type, and the corresponding event scenario.

[0073] In some embodiments, rental demand triggering events may include at least one of location events, time events, and user behavior events. Location events can be collected and reported by the user terminal 100 after obtaining authorization from the visitor, indicating that the visitor has arrived at a location area related to the rental object's usage scenario, such as a scenic spot, airport, ski resort, or exhibition venue. Time events can be generated by the server 400 based on the current time, holiday information, event schedules, or the applicable period of the rental object, indicating that the current time meets the time conditions related to the rental object's usage scenario. User behavior events can be determined by the user terminal 100 or the server 400 based on the visitor's search behavior, browsing behavior, content click behavior, etc., within the site, indicating that the visitor is generating behavioral signals related to the rental object's usage scenario.

[0074] Through the aforementioned various types of rental demand outreach events, server 400 can identify whether a visitor has entered a scenario where they might use the rental object, based on three dimensions: location, time, and behavior. This method enables the timing of rental reminder output to be linked to the actual usage scenario of the rental object, reducing invalid outreach caused by issuing reminders before the visitor has entered the relevant scenario, and improving the usability of rental demand lock records in subsequent reminder generation processes.

[0075] In S408, if a rental demand trigger event is triggered, a rental reminder corresponding to the rental object is generated and output based on the rental demand trigger event and rental demand lock record.

[0076] When the scenario-based demand activation module 405 determines that a visitor has triggered a rental demand notification event, the server 400 can read the rental demand lock record corresponding to the visitor and determine the rental object to be notified based on the record. The server 400 can match the current scenario, time, or behavioral environment represented by the rental demand notification event with the rental object recorded in the rental demand lock record to obtain the basis for reminder generation. The basis for reminder generation may include at least one of the following: rental object identifier, rental object name, rental object page entry, demand lock record identifier, and notification event information.

[0077] The message push module 407 can generate rental reminders based on the reminder generation criteria. Rental reminders can be in-app messages, system notifications, pop-ups, SMS messages, site messages, or other prompts that can be output to the user terminal 100. The content of the rental reminder can include information about the rental object and entry information for accessing the rental page. To associate rental reminders with rental demand lock records, the server 400 can include or associate a lock record identifier in the rental reminder, enabling the user terminal 100 to associate subsequent page access requests with the corresponding rental demand lock record after the user triggers the rental reminder.

[0078] After issuing a rental reminder, server 400 can record the issuance time, channel, corresponding rental object, and corresponding rental demand lock record. This record can be used to subsequently determine the reach status of the same rental demand lock record, and can also serve as a reference for subsequent processing on whether to continue issuing reminders. Through the above processing, this embodiment can convert access behavior triggered by external entry points but without forming a rental order into a rental demand lock record that can continue to be used within a future time window, and generate a rental reminder based on this record when the access party triggers a rental demand reach event, thereby enabling the rental service system to continuously process the same potential rental demand in non-real-time rental decision scenarios.

[0079] In some embodiments, where the rights and interests objects have been pre-generated and stored in the user's rights and interests object set, the server 400 can generate a rental reminder corresponding to the rental object based on the rental demand triggering event, the rental demand locking record, and the rights and interests object.

[0080] When generating a rental reminder, server 400 can read the corresponding rights object from the user's rights object set based on the rights object identifier in the rental demand lock record, and verify the status and validity period of the rights object. If the rights object is available and the rental demand trigger event matches the usage scenario of the rental object, server 400 can assemble the rental object information, rights object information, and rental entry into a rental reminder, and output it to user terminal 100 through message push module 407. Thus, the rental reminder can simultaneously carry the scenario trigger basis, historical demand lock relationship, and available rights content, making the reminder no longer just a repetitive display of previously viewed objects, but guiding the visitor to enter the subsequent rental process based on the saved rights objects.

[0081] In some embodiments, before generating a rental reminder, the server 400 may perform deduplication or frequency limiting on the rental reminders to be output. The server 400 may read the number of rental reminders received by the user within a preset time period, the historical reach corresponding to the same rental demand lock record, and the time interval between two adjacent rental reminders, and compare the above data with preset frequency limiting conditions. For example, when the number of rental reminders received by the user on the current day reaches the upper limit, or the historical reach of the same rental demand lock record reaches the upper limit, or the time interval since the last rental reminder is less than a preset interval, the server 400 may postpone, merge, or cancel the current rental reminder.

[0082] The above processing can prevent the same user from receiving the same or similar rental reminders repeatedly in a short period of time, reduce the resource consumption of invalid outreach on user terminal 100 and message push module 407, and allow rental reminders to be output more frequently at relevant outreach times.

[0083] In some embodiments, please refer to Figure 6After creating a rental demand lock record, the credit pre-authorization module 406 can obtain the visitor's dwell time, number of images viewed, follow operations, specification selection operations, and other access behaviors during the access process corresponding to the rental object access event, in order to identify whether the visitor has rental intentions (601). If the visitor stays on the rental object page for more than a preset time, continuously views multiple images, or adds the rental object to the follow set, the credit pre-authorization module 406 can identify that the visitor has rental intentions and output a credit pre-authorization entry on the rental object page (602). For example, the credit pre-authorization entry can be presented as a one-click deposit-free lock button at the bottom of the page. After the visitor triggers the button, the user terminal 100 can display a pre-authorization explanation page, which includes the target pre-authorization amount, the pre-authorization validity period, and the amount release rules.

[0084] Before displaying the credit pre-authorization entry, the credit pre-authorization module 406 can determine a reference authorization limit based on the value of the leased object and a preset deposit-free ratio. For example, the reference authorization limit can be the product of the leased object's value and the preset deposit-free ratio. The credit pre-authorization module 406 can also obtain the visitor's credit status and determine the available credit authorization limit for that visitor according to a preset credit tier table. For example, if the credit status is below a preset threshold, the credit pre-authorization entry will not be displayed; different credit tiers correspond to different upper limits. If the available credit authorization limit meets the conditions for displaying the pre-authorization entry, the credit pre-authorization module 406 can determine the smaller of the reference authorization limit and the available credit authorization limit as the target pre-authorization limit.

[0085] The conditions for displaying the pre-authorization entry can include at least one of the following: the visitor's credit status reaches the preset credit threshold, the available credit authorization limit is greater than zero, the available credit authorization limit is not lower than the preset minimum display limit, the leased object belongs to the scope of leased objects that support credit pre-authorization, the leased object currently has rentable inventory, the risk level corresponding to the leased object does not exceed the preset risk level, and the visitor has not rejected or closed the credit pre-authorization entry within the preset cooling-off period.

[0086] In one implementation, if the visitor's credit status does not meet the preset credit threshold, or their available credit authorization limit is lower than the preset minimum display limit, the credit pre-authorization module 406 may not output the credit pre-authorization entry point to reduce invalid authorization interactions. If the reference authorization limit does not exceed the available credit authorization limit, the target pre-authorization limit can be equal to the reference authorization limit; if the reference authorization limit exceeds the available credit authorization limit, the target pre-authorization limit can be equal to the available credit authorization limit, and the difference can be borne by the rental service provider, or the visitor can be prompted to supplement the deposit during the subsequent order placement stage.

[0087] After the visitor triggers the authorization confirmation operation for the credit pre-authorization entry, the credit pre-authorization module 406 can generate an authorization confirmation record (603) and update the visitor's corresponding credit pre-authorization status from unauthorized to authorized (604). The authorization confirmation record may include information such as confirmation timestamp, device information, page screenshot summary value, target pre-authorization amount, and pre-authorization validity period, and can be written to the user authorization log table. The credit pre-authorization module 406 can also associate the credit pre-authorization status with the lease demand lock record (605), so that the lease demand lock record simultaneously records the visitor's demand lock relationship with the lease object and the credit pre-authorization status.

[0088] In one possible implementation, after outputting the credit pre-authorization entry, if it is detected that the accessing party closes the credit pre-authorization entry or initiates a rejection operation based on the credit pre-authorization entry, the credit pre-authorization module 406 can generate a rejection record and stop outputting the credit pre-authorization entry to the accessing party within a preset cooling-off period.

[0089] Through the above processing, the ability to waive deposits based on credit can be moved from the order placement stage to the leasing decision-making stage, forming a dual state of demand locking and credit eligibility locking together with the leasing demand locking record. Since the target pre-authorization limit is determined based on both the value of the leased asset and the credit status of the visitor, the display of the pre-authorization entry can be matched with the risk level of the leased asset and the creditworthiness of the visitor, reducing invalid authorization interactions that do not meet the conditions. The authorization confirmation record can also leave a trace of the visitor's proactive confirmation behavior, making the generation of the credit pre-authorization status traceable. For visitors who have already rejected or closed the pre-authorization entry, a preset cooling-off period can reduce the interference caused by repeatedly displaying the entry in a short period.

[0090] During subsequent rental reminders or order placement, server 400 can directly read the credit pre-authorization status associated with the rental demand lock record. This allows the rental page to display the deposit-free rental entry based on the authorized status, pre-fill authorization information, or reduce redundant credit assessment steps. This reduces the operational costs for users to re-understand deposit rules and re-initiate credit authorization during subsequent decision-making. Furthermore, it expands the rental demand lock record from a simple record of demand intention to a structured record encompassing both demand relationship and credit eligibility status, providing more complete data for subsequent rental reminder sorting, rental page generation, and order conversion processing.

[0091] In some embodiments, please refer to Figure 7After outputting the rental reminder (701) corresponding to the rental object, if the server 400 detects that the rental entry included in the rental reminder has been triggered, it can obtain the lock record identifier carried by the rental reminder (702). Based on the lock record identifier carried by the rental reminder, it queries the rental demand lock record database 404 to see if there is a credit pre-authorization status associated with the rental demand lock record (703). If found, it further determines whether the credit pre-authorization status is an authorized status (704). The credit pre-authorization status can be used to indicate whether the accessing party has completed the credit pre-authorization confirmation for the rental object in the previous access process.

[0092] If the credit pre-authorization status is not found, or if the credit pre-authorization status found is not an authorized status, the server can redirect the visitor to the regular credit assessment process (705) to re-obtain the credit status and make an authorization judgment during the order placement stage.

[0093] If server 400 obtains a credit pre-authorization status associated with the rental demand lock record, and this credit pre-authorization status is an authorized status, a rental page can be generated based on the rental demand lock record and the credit pre-authorization status. The rental page can display a prompt message indicating that pre-authorization has been completed (706). The credit pre-authorization status can be used to display a prompt message indicating that pre-authorization has been completed on the rental page, enabling the visitor to recognize that they have the corresponding basis for deposit waiver or credit authorization.

[0094] In one possible implementation, before generating the rental page, server 400 can also perform a lightweight check. This lightweight check may include verifying at least one of the following: the visitor's credit status, risk control rule status, the price status of the rental object, and the inventory status of the rental object. Rental conditions may include at least one of the following: the visitor's credit status still meets the requirements for deposit-free or pre-authorized use; the current risk control rules do not determine that the visitor or the rental object poses a blocking risk; the current price of the rental object does not exceed the range covered by the target pre-authorization limit; and the rental object has rentable inventory.

[0095] If the verification results indicate that the rental conditions are met, server 400 can generate a rental page and configure pre-authorization status prompts on this page. Pre-authorization status prompts may include at least one of the following: credit pre-authorization completed, deposit-free rental available, pre-authorization limit, pre-authorization validity period, expected release time, or limit release rules. Server 400 can also configure at least one of the following on the rental page based on rental demand lock records: rental object information, benefit object information, and reservation information. Rental object information may include the rental object name, model, specifications, rental price, rental period, and pick-up and return method; benefit object information may include the benefit name, discount amount, deposit-free eligibility, benefit validity period, and redemption conditions; reservation information may include the expected usage time, pick-up location, return location, contact information, or specifications previously selected by the visitor. Therefore, after entering the rental page from the rental reminder, the visitor can continue to use the previously generated demand lock data and pre-authorization data, reducing repetitive filling and judgment.

[0096] If the verification results indicate a change in the price status of the leased object, resulting in insufficient target pre-authorized amount, server 400 can configure supplementary authorization prompts or supplementary deposit prompts on the lease page to remind the visitor to make up the amount difference caused by the price change.

[0097] If the verification result indicates that the inventory status of the leased item is out of stock, the server 400 can maintain the credit pre-authorization status and configure inventory status prompts on the lease page, such as prompts that the product is temporarily out of stock, the pre-authorization qualification has been retained, and the product can continue to be used after the inventory is restored. This ensures that the credit pre-authorization status continues to be associated with the lease demand lock record during the available period.

[0098] If the verification results indicate a decline in the visitor's credit status, or a change in the risk control rules, server 400 can reassess the credit based on the updated risk control rules. Valid pre-authorization conditions may include at least one of the following: the visitor's credit status is not below a preset credit threshold, the credit rating has not declined by more than a preset range, the visitor has not triggered the updated risk interception rules, the rental object still falls within the scope of objects allowed for pre-authorized rentals, and the target pre-authorization amount is still within the available limit. If the reassessment results indicate that the valid pre-authorization conditions are not met, server 400 can update the credit pre-authorization status to a released status and configure a status change notification on the rental page. The status change notification may include at least one of the following: pre-authorization released, credit assessment required, re-authorization required, or switching to a regular deposit rental method.

[0099] Through the above processing, lightweight verification can identify potential issues that could lead to order failures, such as changes in credit status, risk control rules, prices, and inventory, before the formal submission of a rental order. These issues are then transformed into manageable outcomes such as page prompts, supplementary authorizations, inventory alerts, or status releases. This shifts anomalies that might otherwise surface during payment, review, or order submission to the rental page generation stage, reducing interruptions caused by insufficient credit, unavailable inventory, or expired pre-authorization after the user enters the order process. Furthermore, this approach reuses previously generated pre-authorization results and rental demand lock records while retaining dynamic verification capabilities, creating a continuous data link between rental reminders, credit pre-authorization, and the rental page, reducing repetitive operation costs for the user in subsequent rental processes.

[0100] In some embodiments, the same user account identifier can be associated with multiple rental demand lock records. Different rental demand lock records may correspond to different rental objects, different benefit objects, different prediction time windows, or different number of outreaches. When the server 400 receives a rental demand outreach event, the scenario-based demand activation module 405 can determine the candidate lock record related to the visitor from the rental demand lock record library 404 to avoid the disorderly output of multiple rental reminders under the same outreach scenario.

[0101] In one implementation, the scenario-based demand activation module 405 can filter rental demand lock records that meet valid conditions from at least one rental demand lock record corresponding to the visitor, and select these records as candidate lock records. Valid conditions may include at least one of the following: the record status is locked or in progress; the corresponding benefit object has not expired; the number of outreach attempts has not reached a preset limit; and the interval between the record creation time and the current time does not exceed a preset valid observation period. For example, if the benefit object corresponding to a rental demand lock record has expired, or the number of outreach attempts for that record has reached a preset limit, the scenario-based demand activation module 405 may no longer consider that record as a candidate lock record, thereby reducing the number of invalid records participating in subsequent reminder generation.

[0102] In another implementation, the scenario-based demand activation module 405 can determine the target scenario based on rental demand trigger events and identify candidate rental objects matching the target scenario according to the preset mapping relationship between scenarios and rental objects. The target scenario can be determined based on location events, time events, or user behavior events, such as the visitor arriving at a scenic spot, entering a period before a holiday, or generating a travel guide search behavior. The mapping relationship between scenarios and rental objects can be generated based on the applicable scenario tags for rental objects configured by the rental service provider, as well as the correlation statistics between order scenarios and rental objects in historical rental orders.

[0103] For example, association confidence levels between scenic scenes and rental objects such as cameras, tents, and clothing can be obtained through association rule mining algorithms. This mapping relationship can also be updated according to a preset period based on recent rental transaction data, for example, by using a sliding window weighting method to merge historical confidence levels with recent confidence levels. For newly added rental objects, an initial association confidence level can be set for them based on the configured scene tags, and a mapping relationship between the scene and the rental object can be added.

[0104] After identifying candidate rental objects, the scenario-based demand activation module 405 can filter rental demand lock records related to the candidate rental objects from at least one rental demand lock record corresponding to the visitor. This relevance can include identical rental object identifiers, identical rental categories, or belonging to the same related category. Through this processing method, even if the rental object previously viewed by the visitor is not entirely consistent with the current scenario, the server 400 can still retrieve scenario-related records from existing rental demand lock records based on the mapping relationship between scenarios and rental objects.

[0105] After obtaining the candidate lock records, the scenario-based demand activation module 405 can sort the candidate lock records based on the degree of matching between the rental demand outreach event and the corresponding rental object of each candidate lock record. The degree of matching can be determined by combining at least one of the following: the association confidence between the scenario and the rental object, the probability of future rental demand, the remaining valid duration of the benefit object, the user activity of the visitor, the inventory status of the rental object, and historical outreach results. For example, weights can be configured for each factor, and an activation priority score can be calculated for the candidate lock records; candidate lock records with higher activation priority scores can be given priority for generating rental reminders.

[0106] During the sorting process, if the originally viewed rental item is out of stock, the scenario-based demand activation module 405 can select a similar rental item with a higher scenario matching degree as an alternative rental item and configure alternative description information in the rental reminder. If the rental item preferred by the visitor is inconsistent with the rental item with a high target scenario matching degree, the scenario-based demand activation module 405 can determine the rental item to be promoted based on the activation priority score and retain the benefits reminder of the other rental item. If the difference in activation priority scores of multiple rental items is less than a preset difference, the rental item originally viewed by the visitor can be selected first to utilize the visitor's existing knowledge of the rental item.

[0107] Before determining the target lock record based on the sorting results, the scenario-based demand activation module 405 can also perform deduplication and frequency limiting on the candidate lock records. For example, if the same visitor has already received a rental reminder for the same rental object within 24 hours, the rental reminder for that rental object will not be output repeatedly; when there are multiple candidate rental objects in the same category, the record with the higher activation priority score can be retained; the number of rental reminders received by the same visitor in a single day can be set to an upper limit; the number of times the same rental demand lock record is reached can be set to an upper limit; the time interval between two adjacent rental reminders can be configured to be no less than a preset interval. If there are multiple high-scoring candidate lock records under the same reach event, the server 400 can merge the multiple records into one rental reminder and configure the rental reminder to redirect to the user's rights object collection page or the candidate rental object list page.

[0108] Through the above processing, server 400 can select the record that is highly relevant to the current scenario and is still available to generate a rental reminder when multiple rental demand lock records are associated with the same user account identifier. This method can reduce the interference of invalid records, duplicate records, or low-relevance records on reminder generation, ensuring that the content of the rental reminder is consistent with the current scenario of the visitor, historical demand lock relationships, and available rights objects, and reducing the processing pressure on user terminal 100 and message push module 407 caused by the simultaneous output of multiple rental reminders. In some embodiments, after the rental reminder is output, server 400 can determine whether the visitor has formed a rental order based on the rental reminder by using the association data between message push module 407, order processing module 408, and rental demand lock record database 404. The rental reminder may carry a reminder identifier, lock record identifier, rights object identifier, or rental entry identifier. After the visitor triggers the rental entry and forms a rental order, order processing module 408 can return the order information of the rental order to server 400. The order information may include order identifier, user account identifier, rental object identifier, rental category, order time, rights redemption information, pre-authorized usage information, etc.

[0109] Server 400 can generate sample tags based on order information and combine these sample tags with the original rental object access event and rental demand lock-in records to construct new training samples. Sample tags can be used to indicate whether the rental object access event generated a rental behavior associated with the rental object within a future time window. For example, if the rental object or rental category corresponding to the rental order matches the original rental object access event, a positive sample tag can be generated; if no related rental order is formed within the corresponding time range, a negative sample tag can be generated; if the formed rental order only has a category association with the original rental object access event, a positive sample with a lower sample weight can be generated. Server 400 can input the new training samples into the model training process to update the rental demand prediction model. Through this process, the actual order results after rental reminders can be fed back into the model training data, enabling the rental demand prediction model to continuously learn the correlation between access behavior, lock-in records, reminder reach, and rental orders, reducing prediction bias caused by the model's long-term reliance on historical static samples.

[0110] In some embodiments, after outputting a rental reminder, if a rental order is generated based on the rental reminder, the server 400 can also write back the order identifier of the rental order to the corresponding rental demand lock record. During the write-back, the server 400 can determine the corresponding rental demand lock record based on the lock record identifier carried by the rental reminder, and write information such as the order identifier, order time, rights redemption status, and pre-authorized usage status into the rental demand lock record. After writing, the rental demand lock record can be updated from a locked state or a reaching-in-progress state to a completed state, and the termination condition can be updated to an associated rental order.

[0111] Server 400 can generate long-term conversion evaluation results based on the number of rental demand lock records generated and the number of rental demand lock records with written order identifiers. For example, the long-term conversion evaluation result is the ratio of the number of rental demand lock records with written order identifiers to the number of rental demand lock records generated. The long-term conversion evaluation result can indicate how many of the created rental demand lock records formed rental orders within a preset statistical period. This evaluation result can be statistically analyzed according to dimensions such as rental category, external entry source, future time window, benefit object type, touch event type, or user segmentation. Through this processing, the system no longer uses whether an order is placed immediately within the current access session as the conversion judgment criterion, but can evaluate the contribution of rental demand lock records to the formation of subsequent orders over a longer period of time.

[0112] Long-term conversion evaluation results can be used to update at least one of the sample labels, sample weights, locking conditions, and delivery strategy parameters in the future rental demand forecasting process. For example, for rental categories or scenario combinations with a high proportion of long-term order write-backs, the training weight of the corresponding samples can be increased, or the probability threshold for creating rental demand lock-up records can be appropriately reduced; for external entry sources or reach event types with a low proportion of long-term order write-backs, the weight of the corresponding samples can be reduced, or the probability threshold in the locking conditions can be increased. Through this closed-loop processing, rental demand lock-up records are not only used for reminder generation, but also serve as a data carrier for conversion evaluation and parameter adjustment, enabling future demand forecasting, locking strategies, and reach strategies to be corrected based on actual order results.

[0113] In one possible implementation, server 400 can generate delivery adjustment parameters corresponding to the visitor based on the probability of future rental demand. The probability of future rental demand can be output by a rental demand prediction model, representing the likelihood that the visitor will generate rental demand for the rental object within a future time window. The delivery adjustment parameters can be used to adjust the weight of the visitor's target audience set in subsequent ad delivery or content reach, such as increasing the weight, maintaining the original weight, decreasing the weight, or excluding it from the target audience set.

[0114] If the probability of future rental demand meets the rental intention determination criteria, server 400 can configure the delivery adjustment parameters to increase the delivery weight of the target audience set to which the visitor belongs. The rental intention determination criteria may include at least one of the following: the probability of future rental demand reaches a preset probability threshold, the rental demand lock record corresponding to the visitor is valid, the target asset is still available, or the visitor has recently exhibited behavioral signals related to the rental asset. If the probability of future rental demand does not meet the rental intention determination criteria, server 400 can configure the delivery adjustment parameters to decrease the delivery weight of the target audience set to which the visitor belongs, or exclude the visitor from the target audience set.

[0115] Through the aforementioned delivery adjustment method, server 400 can use the probability of future rental demand for subsequent traffic allocation, giving higher priority to visitors with a higher probability of future rental demand, while reducing duplicate delivery to visitors with a lower probability of demand. This method extends rental demand prediction results from single reminder generation to external entry point delivery parameter adjustment, allowing the delivery side to utilize feedback data formed by rental demand locking and long-term conversion evaluation to reduce duplicate delivery to low-intent visitors and increase the probability of high-intent visitors receiving relevant service entry points in subsequent rental scenarios.

[0116] In some embodiments, based on any or a combination of the above embodiments, a rental demand lock-in record can be configured to carry associated data between the access party, the rental object, the rights object, the credit pre-authorization status, the outreach process, and the order conversion result. The rental demand lock-in record may include a lock-in record identifier, a user account identifier, and a rental object identifier, and further includes at least one of the following: an access identifier for the rental object access event, a record creation time, a future time window, a future rental demand probability, a rights object identifier, a rights status, a rights validity period, a credit pre-authorization status, a target pre-authorization amount, a pre-authorization validity period, the number of outreaches, the most recent outreach time, an order identifier, termination conditions, and a record status.

[0117] Among them, the lock record identifier can be used to uniquely identify a rental demand lock record; the user account identifier can be used to identify the visitor; the rental object identifier can be used to identify the accessed or locked rental object; the access identifier can be used to associate the rental object access event triggered by the external entry point; the record creation time and future time window can be used to determine the time boundary of the rental demand lock record; the future rental demand probability can be used to represent the prediction result of the visitor's rental demand for the rental object within the future time window; the rights object identifier, rights status, and rights validity period can be used to associate and manage the corresponding rights object; the credit pre-authorization status, target pre-authorization amount, and pre-authorization validity period can be used to record the visitor's credit pre-authorization status for the rental object; the number of touches and the most recent touch time can be used for reminder frequency limiting and sorting; and the order identifier can be used for write-back and conversion evaluation after a rental order is formed.

[0118] The status of rights includes at least one of the following: pending, in effect, used, expired, and revoked. The status of credit pre-authorization includes at least one of the following: unauthorized, authorized, used, and released.

[0119] Termination conditions include at least one of the following: the lease demand lock record is associated with a lease order, the rights object corresponding to the lease demand lock record has expired, the number of times the lease demand lock record is reached has reached a preset number, the credit pre-authorization status corresponding to the lease demand lock record has been released, or a cancellation instruction is received from the accessing party.

[0120] The recorded state includes at least one of the following: locked, reaching and advancing, and completed.

[0121] Through the above field configuration, the rental demand lock record can organize data such as external access, future demand forecast, benefit objects, credit pre-authorization, reminder delivery and order write-back in the same record structure. This allows the server 400 to process data based on a unified data object when performing at least one of the following functions: filtering, sorting, frequency limiting, reminder generation, page generation and conversion evaluation. This reduces correlation errors caused by data dispersion across multiple systems.

[0122] In one exemplary embodiment, please refer to Figure 8 In step 801, user terminal 100 triggers a rental object access event through external entry platform 200. In step 802, server 400 determines whether the accessing party has formed a rental order; if a rental order is formed, the immediate conversion result is recorded in step 803; if no rental order is formed, the user account identifier is determined and predictive features are obtained in step 804. Predictive features may include user features, rental object features, and time node features.

[0123] In step 805, server 400 predicts the probability of future rental demand based on predictive features. In step 806, server 400 determines whether the probability of future rental demand meets the locking conditions; if not, it marks the user as a low rental intention visitor in step 807 and generates delivery adjustment parameters in step 808; if it meets the conditions, it generates a rights object in step 809 and stores it in the user rights object set, and creates a rental demand locking record in step 810.

[0124] In step 811, server 400 determines whether the conditions for displaying the credit pre-authorization entry are met. If so, it outputs the credit pre-authorization entry in step 812 and checks whether the accessing party confirms authorization in step 813. If authorization is confirmed, an authorization confirmation record is generated in step 814 and updated to the authorized status; if authorization is not confirmed, a rejection record is generated in step 815 and the system enters a cooling-off period. Subsequently, in step 816, server 400 waits for a rental request event.

[0125] In step 817, server 400 determines whether a rental request notification event has been triggered. If triggered, step 818 identifies the target lock record and outputs a rental reminder. In step 819, server 400 determines whether the rental entry point has been triggered. If not triggered, step 820 records the unclicked result and proceeds to the next notification cycle. If triggered, step 821 queries the credit pre-authorization status. In step 822, server 400 determines whether the credit pre-authorization status is already authorized. If so, step 823 generates a rental page based on the lock record and pre-authorization status. If not, step 824 proceeds to the regular credit assessment process and generates a rental page.

[0126] In step 825, server 400 determines whether the visitor has formed a rental order; if no rental order has been formed, the activation failure result is recorded in step 826; if a rental order has been formed, the rental order is generated in step 827, and data feedback and optimization are performed in step 828. Data feedback and optimization may include at least one of the following: order information write-back, prediction model update, generation of long-term conversion evaluation results, and adjustment of delivery strategy parameters.

[0127] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0128] Figure 9 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 9 As shown, device 900 mainly consists of a communication interface 902, a user interface 904, a processor 906, and a data storage 908. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 910. Communication interface 902 enables device 900 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, communication interface 902 may include an antenna and related processing devices for wireless communication with a radio access network or access point. Furthermore, communication interface 902 can be a wired interface such as Ethernet, Token Ring, or USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or wide area wireless interface (e.g., WiMAX or LTE). Of course, communication interface 902 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. Communication interface 902 may also include multiple physical communication interfaces, such as Wi-Fi interfaces, Bluetooth interfaces, and wide area wireless interfaces.

[0129] User interface 904 includes receiving user input and providing output to the user. Therefore, user interface 904 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 904 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 904 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 900 may support remote access from other devices via communication interface 902 or another physical interface (not shown). User interface 904 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 904 may also be configured as a display device for rendering or displaying text fragments.

[0130] Processor 906 may contain one or more general-purpose processors and / or special-purpose processors.

[0131] Data storage 908 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 906. Data storage 908 may include removable and non-removable components.

[0132] Processor 906 is capable of executing program instructions 918 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 908 to perform the various functions described herein. Data storage 908 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 900, enable device 900 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 906 executing program instructions 918 may result in processor 906 using data 912.

[0133] For example, program instructions 918 may include an operating system 922 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 900 and one or more application programs 920 (e.g., a browser, social media application, or game application). Similarly, data 912 may include operating system data 916 and application data 914. Operating system data 916 is primarily accessible to the operating system 922, while application data 914 is primarily accessible to one or more application programs 920. Application data 914 may reside in a file system visible or hidden from the user of device 900.

[0134] Application 920 can communicate with operating system 922 through one or more application programming interfaces (APIs). These APIs help application 920 read and / or write application data 914, transmit or receive information via communication interface 902, receive or display information on user interface 904, etc.

[0135] In some terminology, application 920 may be simply referred to as "app". Furthermore, application 920 can be downloaded to device 900 through one or more online app stores or app markets. However, applications can also be installed on device 900 in other ways, such as through a web browser or a physical interface on device 900 (e.g., a USB port).

[0136] In some embodiments, the rental demand locking and reminder device can be applied to, for example... Figure 9 The device shown implements the technical solution described in this specification. For details regarding the rental demand locking and reminder device, please refer to the relevant description of the above solution; it will not be repeated here.

[0137] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0138] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0139] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0140] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0141] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0142] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0143] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0144] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0145] This specification uses specific terms to describe embodiments thereof. Terms such as "some embodiments," "an embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least some embodiments of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "some embodiments," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0146] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A method for locking in and reminding about rental demand, comprising: If a rental object access event triggered by an external entry point is obtained, and it is determined that the accessing party of the rental object access event has not formed a rental order, the user account identifier of the accessing party is determined; Obtain the user characteristics corresponding to the user account identifier, the object characteristics and time node characteristics of the rental object indicated by the rental object access event, and predict the probability of the accessing party's future rental demand for the rental object within a future time window based on the user characteristics, the object characteristics and the time node characteristics; If the probability of future rental demand meets the locking condition, a rental demand locking record is created. The rental demand locking record is used to record the demand locking relationship between the visitor and the rental object. After the rental demand lock record is generated, monitor whether the accessing party triggers the rental demand reach event; If the rental demand notification event is triggered, a rental reminder corresponding to the rental object is generated and output based on the rental demand notification event and the rental demand lock record.

2. The method according to claim 1, wherein predicting the probability of the visitor's future rental demand for the rental object within a future time window based on the user characteristics, the object characteristics, and the time node characteristics includes: The user characteristics, the rental object characteristics, and the time node characteristics are input into the pre-trained rental demand prediction model, and the rental demand prediction model outputs the probability of future rental demand. The rental demand prediction model is trained based on multiple rental object access event samples. The rental object access event samples include user characteristics of historical visitors, characteristics of historical rental objects, characteristics of historical time nodes, and sample labels. The sample labels are used to characterize whether the historical visitors have generated rental behavior associated with historical rental objects during the sample observation period.

3. The method according to claim 2, wherein the sample label is determined by at least one of the following methods: If the historical visitor forms a rental order that matches the rental category of the historical rental object during the sample observation period, the corresponding rental object access event sample is marked as a first type of positive sample; If the rental category of the rental order formed by the historical visitor during the sample observation period is related to the rental category of the historical rental object but not completely matched, the corresponding rental object access event sample is marked as a second type of positive sample. If the historical visitor does not generate any rental order during the sample observation period, the corresponding rental object access event sample will be marked as a first-type negative sample; If the historical visitor forms a rental order during the sample observation period, and the rental category of the rental order is unrelated to the rental category of the historical rental object, the corresponding rental object access event sample is marked as a second type of negative sample; in, The sample label values ​​of the first type of positive samples and the second type of positive samples are both first label values, and the weight of the first type of positive samples is greater than the weight of the second type of positive samples; the sample label values ​​of the first type of negative samples and the second type of negative samples are both second label values, and the weight of the first type of negative samples is greater than the weight of the second type of negative samples; During the training process of the rental demand prediction model, the weights are used to weight the loss terms corresponding to different categories of samples in order to adjust the contribution of different categories of samples to the update of model parameters.

4. The method according to claim 1, wherein the future time window is determined based on the category information and / or usage scenario information of the rental object; wherein, Different product category information and / or different usage scenario information correspond to different future time windows of varying lengths; And / or, The rental demand notification event includes at least one of location events, time events, and user behavior events; The location event is used to indicate that the visitor has arrived at a location area related to the usage scenario of the rental object; The time event is used to characterize the current time meeting the time conditions related to the usage scenario of the leased object; The user behavior events are used to characterize the search or browsing behavior generated by the visitor that is related to the usage scenario of the rental object.

5. The method according to claim 1, wherein before creating the rental demand lock record, the method further comprises: Generate the rights object corresponding to the leased object; The rights and interests objects are stored in a set of user rights and interests objects corresponding to the user account identifier of the accessing party; The rental demand lock record is used to record the association between the visitor, the rental object, and the rights object; The process of generating a rental reminder corresponding to the rental object based on the rental demand notification event and the rental demand lock record includes: Based on the rental demand notification event, the rental demand lock record, and the rights holder, a rental reminder corresponding to the rental object is generated.

6. The method according to claim 1, wherein generating a rental reminder corresponding to the rental object based on the rental demand reach event and the rental demand lock record includes: Based on the rental demand event, candidate lock records are determined using at least one of the following methods: From at least one rental demand lock record corresponding to the accessing party, select rental demand lock records that meet the valid conditions as candidate lock records; or... Based on the rental demand reach event, a target scenario is determined. According to the preset mapping relationship between the scenario and the rental object, a candidate rental object matching the target scenario is determined. From at least one rental demand lock record corresponding to the visitor, rental demand lock records related to the candidate rental object are selected as candidate lock records. The candidate locking records are sorted based on the degree of matching between the rental demand outreach event and the rental object corresponding to each candidate locking record; The target locked record is determined based on the sorting results, and the rental reminder is generated based on the target locked record.

7. The method according to claim 1, further comprising: After creating a rental demand lock record, during the access process corresponding to the rental object access event, if the access behavior of the accessing party indicates that the accessing party has a rental intention, a credit pre-authorization entry is output. Based on the authorization confirmation operation triggered by the access party for the credit pre-authorization entry, an authorization confirmation record is generated, the credit pre-authorization status corresponding to the access party is updated from unauthorized to authorized, and the credit pre-authorization status is associated with the rental demand lock record; After outputting a rental reminder corresponding to the rental object, if it is detected that the rental entry included in the rental reminder is triggered, the credit pre-authorization status associated with the rental demand lock record is obtained; If the credit pre-authorization status is "authorized", a rental page is generated based on the rental demand lock record and the credit pre-authorization status.

8. The method according to claim 7, wherein generating the rental page based on the rental demand lock record and the credit pre-authorization status includes: Verify at least one of the following: the credit status of the visitor, the risk control rule status, the price status of the leased object, and the inventory status of the leased object, and obtain the verification result; If the verification result indicates that the rental conditions are met, a rental page is generated based on the rental demand lock record and the credit pre-authorization status, and a pre-authorization status prompt message is configured on the rental page, and / or, at least one of the following is configured based on the rental demand lock record: rental object information, rights object information, and reservation information; If the verification result indicates that the price status of the rental object has changed and the target pre-authorized amount is insufficient, supplementary authorization prompt information or supplementary deposit prompt information shall be configured on the rental page; If the verification result indicates that the inventory status of the leased object is out of stock, the credit pre-authorization status is maintained, and inventory status prompt information is configured on the lease page; If the verification result indicates that the credit status of the accessing party has declined or the risk control rule status has changed, resulting in the failure to meet the pre-authorization validity conditions, the credit pre-authorization status will be updated to the released status, and a status change prompt message will be configured on the rental page.

9. The method according to claim 1, further comprising, after outputting the rental reminder: When a rental order is generated based on the rental reminder, the order identifier of the rental order is written back to the corresponding rental demand lock record, and a long-term conversion evaluation result is generated based on the number of rental demand lock records generated and the number of rental demand lock records with written back order identifiers; The long-term conversion evaluation results are used to update at least one of the sample labels, sample weights, locking conditions, and delivery strategy parameters in the future rental demand forecasting process.

10. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-9 by executing the executable instructions.

Images