Parameter updating method and device, equipment and storage medium
By acquiring historical behavior information of user accounts and using multi-dimensional strategies to assess activity, the problem of rigid parameter update logic in existing technologies has been solved, resulting in more accurate parameter updates and improved system efficiency.
Patent Information
- Application Number
- CN202511614088.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-06
- Publication Date
- 2026-02-27
AI Technical Summary
Existing technologies suffer from rigid and inflexible logic in updating user account parameters, leading to distorted user activity assessments and impacting system operational efficiency.
By obtaining historical behavior information of account IDs, extracting predefined auxiliary update data, and determining the target update strategy based on multiple parameter update strategies, user activity can be evaluated from multiple dimensions.
This improved the accuracy of parameter updates and system operational efficiency, and enhanced user stickiness and engagement.
Smart Images
Figure CN121579490A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of behavioral analysis technology, and in particular to a parameter update method, apparatus, device, and storage medium. Background Technology
[0002] In various computer business systems (such as user loyalty programs, game achievement systems, and marketing platforms), dynamically updating specific parameters of user accounts (such as points, levels, and experience points) is a fundamental and crucial technology. This parameter update operation aims to respond to user behavior, incentivize continued engagement, and enhance business stickiness by adjusting the user account status.
[0003] However, existing technologies for implementing parameter update functions generally suffer from systemic defects. The core problem lies in the rigidity and inflexibility of the update logic. In the current parameter update process, the logic relies solely on a preset, single update logic to reflect user activity, leading to distorted user activity assessments, which in turn affect subsequent decisions and the overall operational efficiency of the system. Summary of the Invention
[0004] This application provides a parameter update method, apparatus, device, and storage medium. The method extracts predefined auxiliary update data based on the historical behavior information corresponding to the obtained account ID (Identifier), and determines a target parameter update strategy from multiple preset parameter update strategies based on the auxiliary update data and performs parameter updates. This enables the evaluation of user activity from multiple dimensions, improving the accuracy of parameter updates and the operational efficiency of the system.
[0005] In a first aspect, embodiments of this application propose a parameter update method, including:
[0006] In response to the parameter update command, the system obtains the account ID to be updated and sends a request message carrying the account ID to the database management system. The request message is used to request the historical behavior information corresponding to the account ID.
[0007] Receive a reply message sent by the database management system, the reply message including historical behavior information corresponding to the account ID;
[0008] Extract predefined auxiliary update data from the historical behavior information, and determine the target parameter update strategy from multiple preset parameter update strategies based on the auxiliary update data;
[0009] The parameters corresponding to the account ID are updated according to the update steps in the target parameter update strategy.
[0010] In some possible embodiments, determining the target parameter update strategy from a set of preset parameter update strategies based on the auxiliary update data includes:
[0011] Based on the auxiliary update data, the target update condition that the auxiliary update data satisfies is determined from a plurality of preset update conditions;
[0012] Based on the predefined correspondence between update conditions and parameter update strategies, a target parameter update strategy corresponding to the target update condition is determined from a plurality of preset parameter update strategies;
[0013] The predefined auxiliary update data includes historical login counts, historical login status, and historical login days.
[0014] In some possible embodiments, determining the target update condition satisfied by the auxiliary update data from a plurality of preset update conditions based on the auxiliary update data includes:
[0015] If the number of historical logins is less than the preset number of logins, then the auxiliary update data is determined to meet the preset first update condition;
[0016] If the number of historical logins is greater than or equal to the preset number of logins, and the historical login status is a non-continuous login status, then the auxiliary update data is determined to meet the preset second update condition.
[0017] If the number of historical logins is greater than or equal to the preset number of logins, the historical login status is a continuous login status, and the number of historical login days is less than the preset number of login days, then it is determined that the auxiliary update data meets the preset third update condition.
[0018] If the number of historical logins is greater than or equal to the preset number of logins, the historical login status is a continuous login status, and the number of historical login days is greater than or equal to the preset number of login days, then the auxiliary update data is determined to meet the preset fourth update condition.
[0019] In some possible embodiments, the first parameter update strategy corresponding to the first update condition is:
[0020] Generate a virtual tag that includes the account ID and the real-time login count of the corresponding account ID, wherein the real-time login count is synchronized with the corresponding historical login count in the database management system;
[0021] When the number of real-time logins detected in the virtual tag is greater than or equal to the preset number of logins, the parameter corresponding to the account ID is updated using the preset first update parameter value.
[0022] In some possible embodiments, the predefined auxiliary update data also includes historical signature information, and the second parameter update strategy corresponding to the second update condition is:
[0023] The number of days of login and the number of missed signatures corresponding to the account ID are determined based on the historical login days and the historical missed signature information corresponding to the account ID.
[0024] Based on the number of days of login to make up for missed signatures, a second update parameter value is determined, and the parameter corresponding to the account ID is updated using the second update parameter value.
[0025] In some possible embodiments, the third parameter update strategy corresponding to the third update condition is:
[0026] Based on the number of historical login days corresponding to the account ID, a third update parameter value is determined, and the parameter corresponding to the account ID is updated using the third update parameter value.
[0027] In some possible embodiments, the fourth parameter update strategy corresponding to the fourth update condition is:
[0028] The parameters corresponding to the account ID are updated using the preset fourth update parameter value.
[0029] Secondly, embodiments of this application also propose a parameter updating device, comprising:
[0030] The information request module is used to respond to parameter update instructions, obtain the account ID to be updated, and send a request message carrying the account ID to the database management system. The request message is used to request the historical behavior information corresponding to the account ID.
[0031] The information receiving module is used to receive the reply message sent by the database management system, the reply message including the historical behavior information corresponding to the account ID;
[0032] The strategy determination module is used to extract predefined auxiliary update data from the historical behavior information, and determine the target parameter update strategy from a set of preset parameter update strategies based on the auxiliary update data.
[0033] The parameter update module is used to update the parameters corresponding to the account ID according to the steps in the target parameter update strategy.
[0034] Thirdly, embodiments of this application also provide an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a parameter update method as described in any of the first aspects above.
[0035] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for performing a parameter update method as described in any of the first aspects above.
[0036] The parameter update method, apparatus, device, and storage medium described above in this application embodiment extract predefined auxiliary update data based on the historical behavior information corresponding to the obtained account ID, and determine the target parameter update strategy from multiple preset parameter update strategies based on the auxiliary update data and perform parameter update, thereby realizing the evaluation of user activity from multiple dimensions, improving the accuracy of parameter updates and the operational efficiency of the system.
[0037] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description
[0038] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0039] Figure 1 This is a schematic diagram of a parameter update method in an embodiment of this application;
[0040] Figure 2 This is a flowchart illustrating a strategy for determining target parameter updates in an embodiment of this application.
[0041] Figure 3 This is a flowchart illustrating a process for determining the target update conditions that are met, as described in an embodiment of this application.
[0042] Figure 4 This is a schematic diagram illustrating an exemplary parameter update process in an embodiment of this application;
[0043] Figure 5 This is a schematic diagram of a parameter update device in an embodiment of this application;
[0044] Figure 6 This is a schematic diagram of an electronic device structure in an embodiment of this application. Detailed Implementation
[0045] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods.
[0046] In various computer business systems (such as user loyalty programs, game achievement systems, and marketing platforms), dynamically updating specific parameters of user accounts (such as points, levels, and experience points) is a fundamental and crucial technology. This parameter update operation aims to respond to user behavior, incentivize continued engagement, and enhance business stickiness by adjusting the user account status.
[0047] However, existing technologies for implementing parameter update functions generally suffer from systemic defects. The core problem lies in the rigidity and inflexibility of the update logic. In the current parameter update process, the logic relies solely on a preset, single update logic to reflect user activity, leading to distorted user activity assessments, which in turn affect subsequent decisions and the overall operational efficiency of the system.
[0048] In view of the problem that the existing parameter update process is relatively simple and leads to evaluation distortion, this application proposes a parameter update method, apparatus, device and storage medium that can evaluate user activity from multiple dimensions, improve the accuracy of parameter updates and the operational efficiency of the system.
[0049] First, this application proposes a parameter update method, such as... Figure 1 As shown, it includes:
[0050] Step S101: Respond to the parameter update instruction, obtain the account ID to be updated, and send a request message carrying the account ID to the database management system. The request message is used to request the historical behavior information corresponding to the account ID.
[0051] The parameter update command can be automatically triggered according to actual needs, such as at a fixed time every day or at a fixed time on the first day of every month. The parameter update command can also be triggered manually. In this embodiment, different parameter update times can be set according to different parameter update fields, without specific limitations.
[0052] Step S102: Receive a reply message sent by the database management system, the reply message including historical behavior information corresponding to the account ID;
[0053] In this embodiment, for each account ID, the corresponding historical behavior information is stored in the corresponding database management system of the user system. For different parameter update domains, the historical behavior information will present different types, including but not limited to login behavior information, transaction behavior information, participation behavior information or browsing behavior information, etc., which are not specifically limited in this embodiment.
[0054] Step S103: Extract predefined auxiliary update data from the historical behavior information, and determine the target parameter update strategy from a set of preset parameter update strategies based on the auxiliary update data;
[0055] Based on the aforementioned different types of historical behavior information and multiple preset parameter update strategies, corresponding auxiliary update data is set, and based on the set auxiliary update data, a target parameter update strategy is determined from the multiple preset parameter update strategies. The multiple parameter update strategies can be preset based on different types of historical behavior information and parameter update domains. In this application embodiment, only one possible implementation method is given, and no specific limitation is made.
[0056] Step S104: Update the parameters corresponding to the account ID according to the update steps in the target parameter update strategy.
[0057] The parameter update strategy includes corresponding parameter update steps, which are used to indicate how to update the parameters using the corresponding update steps. In this embodiment, only one possible implementation is given, and no specific limitation is made.
[0058] The aforementioned parameter update method is typically applied to a backend management terminal. Based on the historical behavior information corresponding to the obtained account ID, predefined auxiliary update data is extracted. Then, based on the auxiliary update data, a target parameter update strategy is determined from multiple preset parameter update strategies, and the parameters are updated. This enables the evaluation of user activity from multiple dimensions, improves the accuracy of parameter updates, and enhances the operational efficiency of the system.
[0059] In some possible embodiments, the above parameters are points or accumulated points, which can be applied to various fields, such as finance, retail, e-commerce, public services, etc. Specifically, in the financial field, corresponding auxiliary update data and parameter update strategies are set according to the user's transaction behavior information to update the points based on the transaction behavior information; in the e-commerce field, corresponding auxiliary update data and parameter update strategies are set according to the user's browsing behavior information to update the points based on the browsing behavior information. The above provides one possible implementation method, and no specific limitation is made in this application embodiment.
[0060] In this embodiment, in response to the parameter update instruction, the backend management terminal needs to send a corresponding request message to the corresponding database management system to request the historical behavior information corresponding to the account ID to be updated, and then receive a reply message from the database management system to obtain the historical behavior information corresponding to the account ID. Specifically, in response to the request message, the database management system determines the storage location of the corresponding historical behavior information based on the carried account ID, reads the historical behavior information based on the storage location, and then sends a reply message to the backend management terminal so that the backend management terminal can perform parameter updates.
[0061] Optionally, the backend management terminal can also directly call the database management system, determine the storage location of the historical behavior information of the account ID to be updated in the database management system, and then directly read the corresponding historical behavior information based on the storage location.
[0062] In some possible embodiments, the historical behavior information is stored in the database management system in the form of a data folder. When the backend management terminal obtains the data folder carrying the historical behavior information, it obtains the corresponding historical behavior information by reading the data and extracts the historical behavior information based on predefined auxiliary update data.
[0063] The auxiliary update data described in this embodiment is set based on different types of historical behavior information and preset multiple parameter update strategies. For example, if the historical behavior information is login behavior information, and the corresponding multiple parameter update strategies involve historical login counts, historical login status, historical login days, etc., then the corresponding predefined auxiliary update data is set to the corresponding historical login counts, historical login status, and historical login days. This embodiment only provides one possible implementation method and does not specifically limit the type of auxiliary update data.
[0064] The backend management terminal determines the target parameter update strategy from a set of preset parameter update strategies based on the extracted auxiliary update data. Specifically, for example... Figure 2 As shown, it includes the following steps:
[0065] Step S201: Based on the auxiliary update data, determine the target update condition that the auxiliary update data satisfies from a plurality of preset update conditions;
[0066] Step S202: Based on the predefined correspondence between update conditions and parameter update strategies, determine the target parameter update strategy corresponding to the target update condition from a set of preset parameter update strategies.
[0067] For the aforementioned preset multiple parameter update strategies, corresponding update conditions are defined. Based on the auxiliary update data, when it is determined that the corresponding update conditions are met, the target parameter update strategy is determined. In this embodiment of the application, the update conditions include a first update condition corresponding to the first parameter update strategy, a second update condition corresponding to the second parameter update strategy, a third update condition corresponding to the third parameter update strategy, and a fourth update condition corresponding to the fourth parameter update strategy.
[0068] This application provides only one possible implementation method. The number of parameter update strategies and corresponding update conditions is not specifically limited in this application. Different numbers can be set according to the actual parameter update field and situation.
[0069] Taking the aforementioned historical behavior information as login behavior information as an example, based on the auxiliary update data, the target update condition that the auxiliary update data satisfies is determined from a plurality of preset update conditions, such as... Figure 3 As shown, it includes the following steps:
[0070] Step S301: Extract auxiliary update data from the login behavior information;
[0071] Step S302: Determine whether the historical login count is greater than or equal to the preset login count;
[0072] Step S303a: If yes, then determine whether the historical login status is a continuous login status;
[0073] Step S303b: If not, then determine that the auxiliary update data meets the preset first update condition;
[0074] Step S304a: If yes, then determine whether the number of historical login days is less than the preset number of login days;
[0075] Step S304b: If not, then determine that the auxiliary update data meets the preset second update condition;
[0076] Step S305a: If yes, then determine that the auxiliary update data meets the preset third update condition;
[0077] Step S305b: If not, then determine that the auxiliary update data meets the preset fourth update condition.
[0078] In some possible embodiments, the determination of whether the historical login status is a continuous login status can also use the historical login time corresponding to the account ID as auxiliary update data. By performing a continuity analysis on the historical login time, if the login time is continuous, the historical login status of the account ID is determined to be a continuous login status; otherwise, it is determined to be a non-continuous login status.
[0079] Based on the above steps, the auxiliary update data corresponding to any account ID includes the following four cases:
[0080] Case 1: If the historical login count is less than the preset login count, then the auxiliary update data is determined to meet the preset first update condition, wherein the first parameter update strategy corresponding to the first update condition is:
[0081] Generate a virtual tag that includes the account ID and the real-time login count of the corresponding account ID, wherein the real-time login count is synchronized with the corresponding historical login count in the database management system;
[0082] When the number of real-time logins detected in the virtual tag is greater than or equal to the preset number of logins, the parameter corresponding to the account ID is updated using the preset first update parameter value.
[0083] In some possible embodiments, the preset login count is zero. When the historical login count is less than the preset login count, i.e., the account ID has never logged in, the first parameter update strategy is determined to be the target parameter update strategy. The backend management terminal updates the parameters corresponding to the account ID according to the update steps in the target parameter update strategy. Specifically, based on the account ID and the corresponding real-time login count, a corresponding virtual tag is generated, and the virtual tag is detected. The specific method for generating the virtual tag can refer to the steps in the prior art, and will not be repeated here.
[0084] The real-time login count carried in the aforementioned virtual tag can be obtained from the database management system, including but not limited to sending requests to the database management system in real time to continuously update the real-time login count. No specific limitation is made here. When the real-time login count is detected to be greater than or equal to the preset login count, it is determined that the account ID has met the conditions for parameter update, and the parameters corresponding to the account ID are updated using the preset first update parameter value.
[0085] Case 2: If the number of historical logins is greater than or equal to the preset number of logins, and the historical login status is a non-continuous login status, then the auxiliary update data is determined to meet the preset second update condition.
[0086] In this embodiment of the application, the predefined auxiliary update data further includes historical signature information, wherein the second parameter update strategy corresponding to the second update condition is:
[0087] The number of days of login and the number of missed signatures corresponding to the account ID are determined based on the historical login days and the historical missed signature information corresponding to the account ID.
[0088] Based on the number of days of login to make up for missed signatures, a second update parameter value is determined, and the parameter corresponding to the account ID is updated using the second update parameter value.
[0089] At this point, the second parameter update strategy is determined to be the target parameter update strategy.
[0090] In some possible embodiments, before updating the parameters corresponding to the account ID according to the update steps in the target parameter update strategy, the backend management terminal will also send a supplementary signature processing rule to the database management system to request the current corresponding second parameter update strategy, and calculate the number of supplementary signature login days used to determine the update parameter value based on the obtained supplementary signature processing rule, historical login days and historical supplementary signature information.
[0091] Once the number of days for retroactive login is determined, the second update parameter value is calculated based on the aforementioned retroactive login processing rules. For example, if the number of days for retroactive login is m and the second update parameter value is n, then n = m × M, where M is a fixed value. In this embodiment, the aforementioned retroactive login processing rules are not specifically limited, and different retroactive login processing rules can be set according to actual circumstances.
[0092] Case 3: If the historical login count is greater than or equal to the preset login count, the historical login status is a continuous login status, and the historical login days are less than the preset login days, then the auxiliary update data is determined to meet the preset third update condition. The third parameter update strategy corresponding to the third update condition is:
[0093] Based on the number of historical login days corresponding to the account ID, a third update parameter value is determined, and the parameter corresponding to the account ID is updated using the third update parameter value.
[0094] At this point, the third parameter update strategy is determined to be the target parameter update strategy.
[0095] In some possible embodiments, before updating the parameters corresponding to the account ID according to the update steps in the target parameter update strategy, the backend management terminal will also send a parameter calculation rule to the database management system to request the current corresponding third parameter update strategy. Based on the obtained parameter calculation rule and the number of historical login days, it will calculate the third update parameter value used to determine the update parameter value. For example, if the number of historical login days is p and the third update parameter value is q, then q = p × P, where P is a fixed value. In this embodiment, the above parameter calculation rule is not specifically limited, and different parameter calculation rules can be set according to the actual situation.
[0096] Case 4: If the historical login count is greater than or equal to a preset login count, the historical login status is a continuous login status, and the historical login days are greater than or equal to a preset login days, then the auxiliary update data is determined to meet a preset fourth update condition. The fourth parameter update strategy corresponding to the fourth update condition is:
[0097] The parameters corresponding to the account ID are updated using the preset fourth update parameter value.
[0098] In this embodiment of the application, when the number of historical login days is greater than or equal to the preset number of login days, the parameter corresponding to the account ID is updated using the preset fourth update parameter value.
[0099] The following example demonstrates how to update the parameters of an account with account ID 1234 using the aforementioned parameter update method. The historical behavior information mentioned refers to login behavior information, such as... Figure 4 As shown, it includes at least one of the following steps:
[0100] Step S401: Respond to the parameter update instruction, obtain the account ID to be updated as 1234, send a request message carrying the account ID 1234 to the database management system, and receive the reply message from the database management system to obtain the login behavior information corresponding to the account ID 1234;
[0101] Step S402: Extract the historical login count, historical login status, and historical login days from the login behavior information;
[0102] Step S403: Determine whether the number of historical logins is greater than or equal to the preset number of logins; if the number of historical logins is greater than or equal to the preset number of logins, determine whether the historical login status is a continuous login status.
[0103] Step S404: Determine that the historical login status is a continuous login status, and determine whether the number of historical login days is less than the preset number of login days;
[0104] Step S405: Determine that the number of historical login days is less than the preset number of login days, determine that the preset third update condition is met, and send the parameter calculation rules for requesting the current corresponding third parameter update strategy to the database management system.
[0105] Step S406: Based on the obtained parameter calculation rules and historical login days, calculate the third update parameter value used to determine the update parameter value, and use the third update parameter value to update the parameter corresponding to the account ID.
[0106] The parameter update method described above in this application embodiment enables the evaluation of user activity from multiple dimensions, improving the accuracy of parameter updates and enhancing system operational efficiency. Furthermore, when the parameter is points or accumulated points, the method can be widely applied in various fields such as finance, e-commerce, and retail. By analyzing users' historical behavior information and setting corresponding auxiliary update data and parameter update strategies, personalized parameter update strategies can be implemented, enhancing user stickiness and increasing user engagement.
[0107] Based on the same inventive concept, embodiments of this application also propose a parameter updating device, such as... Figure 5 As shown, it includes:
[0108] The information request module 501 is used to respond to parameter update instructions, obtain the account ID to be updated, and send a request message carrying the account ID to the database management system. The request message is used to request historical behavior information corresponding to the account ID.
[0109] Information receiving module 502 is used to receive a reply message sent by the database management system, the reply message including historical behavior information corresponding to the account ID;
[0110] The strategy determination module 503 is used to extract predefined auxiliary update data from the historical behavior information, and determine the target parameter update strategy from a set of preset parameter update strategies based on the auxiliary update data.
[0111] The parameter update module 504 is used to update the parameters corresponding to the account ID according to the steps in the target parameter update strategy.
[0112] In some possible embodiments, the strategy determination module is specifically used for:
[0113] Based on the auxiliary update data, the target update condition that the auxiliary update data satisfies is determined from a plurality of preset update conditions;
[0114] Based on the predefined correspondence between update conditions and parameter update strategies, a target parameter update strategy corresponding to the target update condition is determined from a plurality of preset parameter update strategies;
[0115] The predefined auxiliary update data includes historical login counts, historical login status, and historical login days.
[0116] In some possible embodiments, the strategy determination module is specifically used for:
[0117] If the number of historical logins is less than the preset number of logins, then the auxiliary update data is determined to meet the preset first update condition;
[0118] If the number of historical logins is greater than or equal to the preset number of logins, and the historical login status is a non-continuous login status, then the auxiliary update data is determined to meet the preset second update condition.
[0119] If the number of historical logins is greater than or equal to the preset number of logins, the historical login status is a continuous login status, and the number of historical login days is less than the preset number of login days, then it is determined that the auxiliary update data meets the preset third update condition.
[0120] If the number of historical logins is greater than or equal to the preset number of logins, the historical login status is a continuous login status, and the number of historical login days is greater than or equal to the preset number of login days, then the auxiliary update data is determined to meet the preset fourth update condition.
[0121] In some possible embodiments, the first parameter update strategy corresponding to the first update condition is:
[0122] Generate a virtual tag that includes the account ID and the real-time login count of the corresponding account ID, wherein the real-time login count is synchronized with the corresponding historical login count in the database management system;
[0123] When the number of real-time logins detected in the virtual tag is greater than or equal to the preset number of logins, the parameter corresponding to the account ID is updated using the preset first update parameter value.
[0124] In some possible embodiments, the predefined auxiliary update data also includes historical signature information, and the second parameter update strategy corresponding to the second update condition is:
[0125] The number of days of login and the number of missed signatures corresponding to the account ID are determined based on the historical login days and the historical missed signature information corresponding to the account ID.
[0126] Based on the number of days of login to make up for missed signatures, a second update parameter value is determined, and the parameter corresponding to the account ID is updated using the second update parameter value.
[0127] In some possible embodiments, the third parameter update strategy corresponding to the third update condition is:
[0128] Based on the number of historical login days corresponding to the account ID, a third update parameter value is determined, and the parameter corresponding to the account ID is updated using the third update parameter value.
[0129] In some possible embodiments, the fourth parameter update strategy corresponding to the fourth update condition is:
[0130] The parameters corresponding to the account ID are updated using the preset fourth update parameter value.
[0131] The parameter update device described above in this application embodiment extracts predefined auxiliary update data based on the historical behavior information corresponding to the obtained account ID, and determines the target parameter update strategy from multiple preset parameter update strategies based on the auxiliary update data and performs parameter update, thereby realizing the evaluation of user activity from multiple dimensions, improving the accuracy of parameter updates and the operational efficiency of the system.
[0132] Based on the same inventive concept, embodiments of this application also propose an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a parameter update method as described in any of the above embodiments.
[0133] The following reference Figure 6 This application describes an electronic device 600 according to one embodiment of the present application. Figure 6 The device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0134] like Figure 6 As shown, an electronic device 600 is presented in the form of a general-purpose electronic device. The components of an electronic device 600 may include, but are not limited to: at least one processor 601, at least one memory 602, and a bus 603 connecting different system components (including memory 602 and processor 601).
[0135] Bus 603 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus structures.
[0136] The memory 602 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 6021 and / or cache memory 6022, and may further include read-only memory (ROM) 6023.
[0137] The memory 602 may also include a program / utility 6026 having a set (at least one) of program modules 6024, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.
[0138] An electronic device 600 can also communicate with one or more external devices 604 (e.g., keyboard, pointing device, etc.), and with one or more devices that enable a user to interact with the electronic device 600, and / or with any device that enables the electronic device 600 to communicate with one or more other electronic devices (e.g., router, modem, etc.). This communication can be performed via an input / output (I / O) interface 605. Furthermore, an electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via a network adapter 605. As shown, the network adapter 606 communicates with other modules used in the electronic device 600 via a bus 603. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the electronic device 600, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0139] This application also proposes a computer-readable storage medium storing computer-executable instructions for performing a parameter update method as described in any of the above embodiments.
[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0143] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0144] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A parameter updating method, characterized by, Comprise: In response to the parameter update instruction, obtain the account identifier ID to be updated, and send a request message carrying the account ID to the database management system, the request message is used to request the historical behavior information corresponding to the account ID; Receive the reply message sent by the database management system, the reply message includes the historical behavior information corresponding to the account ID; Extract the pre-defined auxiliary update data in the historical behavior information, and determine the target parameter update strategy from the pre-set multiple parameter update strategies based on the auxiliary update data; According to the update step in the target parameter update strategy, the parameters corresponding to the account ID are updated.
2. The method of claim 1, wherein, The target parameter update strategy is determined from the pre-set multiple parameter update strategies based on the auxiliary update data, comprising: Based on the auxiliary update data, determine the target update condition satisfied by the auxiliary update data from the pre-set multiple update conditions; Based on the correspondence between the pre-defined update condition and the parameter update strategy, determine the target parameter update strategy corresponding to the target update condition from the pre-set multiple parameter update strategies; Wherein, the pre-defined auxiliary update data includes historical login times, historical login state, historical login days.
3. The method of claim 2, wherein, The target update condition satisfied by the auxiliary update data is determined from the pre-set multiple update conditions based on the auxiliary update data, comprising: If the historical login times are less than the pre-set login times, it is determined that the auxiliary update data satisfies the pre-set first update condition; If the historical login times are greater than or equal to the pre-set login times, and the historical login state is not a continuous login state, it is determined that the auxiliary update data satisfies the pre-set second update condition; If the historical login times are greater than or equal to the pre-set login times, the historical login state is a continuous login state, and the historical login days are less than the pre-set login days, it is determined that the auxiliary update data satisfies the pre-set third update condition; If the historical login times are greater than or equal to the pre-set login times, the historical login state is a continuous login state, and the historical login days are greater than or equal to the pre-set login days, it is determined that the auxiliary update data satisfies the pre-set fourth update condition.
4. The method of claim 3, wherein, The first parameter update strategy corresponding to the first update condition is: Generate a virtual tag including the account ID and the real-time login times corresponding to the account ID, wherein the real-time login times are synchronized with the corresponding historical login times in the database management system; When the real-time login times in the virtual tag are greater than or equal to the pre-set login times, the corresponding parameters of the account ID are updated with the pre-set first update parameter value.
5. The method of claim 3, wherein, The pre-defined auxiliary update data also includes historical make-up information, and the second parameter update strategy corresponding to the second update condition is: According to the historical login days and the historical make-up information corresponding to the account ID, determine the make-up login days corresponding to the account ID; Based on the make-up login days, determine the second update parameter value, and update the parameters corresponding to the account ID with the second update parameter value.
6. The method of claim 3, wherein, The third update condition corresponds to the third parameter update strategy: Determine a third update parameter value based on the historical login days corresponding to the account ID, and update the parameter corresponding to the account ID using the third update parameter value.
7. The method of claim 3, wherein, The fourth parameter update strategy corresponding to the fourth update condition is: Update the parameter corresponding to the account ID using a preset fourth update parameter value.
8. A parameter updating apparatus characterized by comprising: Comprise: An information request module configured to, in response to a parameter update instruction, acquire an account ID to be updated, and send a request message carrying the account ID to a database management system, the request message being used to request historical behavior information corresponding to the account ID; An information receiving module configured to receive a reply message sent by the database management system, the reply message comprising the historical behavior information corresponding to the account ID; A strategy determination module configured to extract predefined auxiliary update data in the historical behavior information, and determine a target parameter update strategy from a plurality of preset parameter update strategies based on the auxiliary update data; A parameter update module configured to update the parameter corresponding to the account ID according to the steps in the target parameter update strategy.
9. An electronic device, comprising: The computer readable storage medium stores computer executable instructions, and the computer executable instructions are used to execute the parameter update method in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer executable instructions, and the computer executable instructions are used to execute the parameter update method in any one of claims 1-7.