Application method and system of plug-in AB experiment

Abstract

The invention relates to an application method and system of a plug-in AB experiment. The method comprises the following steps: initializing an experiment plug-in of an AB experiment management system, wherein the experiment plug-in comprises experiment plan configuration and experiment rule group; each experiment rule group comprises a rule condition, a user tag dictionary and an experiment identifier; the request end triggers a corresponding scene node to initiate an AB experiment request based on the current scene; after receiving the experiment request, the requested end judges whether an executable experiment plan exists in a current scene node or not, and if yes, an experiment rule group corresponding to the current experiment plan is read; constructing a user portrait based on the experiment rule group corresponding to the current experiment plan; and judging whether the user portrait hits rule conditions in the experimental rule groups, distributing a special risk control model to the hit experimental rule groups, and distributing a universal risk control model to the missed experimental rule groups.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of AB experiment application, and mainly relates to an application method and system of plug-in AB experiment. BACKGROUND

[0002] In the field of Internet finance, AB experiment, as an important means to verify the effectiveness of strategies, is widely used in risk control model optimization, marketing strategy testing, product function iteration and other scenarios, and provides data support for business decision-making by comparing the actual effects of different schemes.

[0003] In the prior art, the implementation of traditional AB experiment relies on cumbersome manual collaboration and hard-coded implementation; specifically, the process usually needs to go through multiple links, and each link needs to be manually pushed; At the same time, the existing technology has significant pain points in the experiment management and configuration level: in the management level, the experiment life cycle lacks a standardized management mechanism, the online time and end node of the experiment depend on manual judgment, and the experiment may run overtime due to human oversight, causing waste of traffic or affecting user experience; and the data after the experiment ends does not form a unified storage and labeling system, making it difficult to quickly retrieve the configuration details and results of historical experiments during subsequent review, affecting experience accumulation; in the configuration level, the technical threshold is high and relies too much on development resources, so product or operation personnel cannot directly participate in experiment configuration, even simple optimization such as adjusting page text and risk control parameters requires developers to modify the code and redeploy, resulting in low efficiency of experiment iteration; in addition, the configuration flexibility is poor, when the experiment involves multiple variable combinations, a large number of versions need to be manually configured, which is prone to problems such as missing configuration and misconfiguration, and if the traffic allocation, rule conditions, etc. need to be adjusted during running, the code needs to be redeployed, which cannot take effect in real time, making it difficult to adapt to the high-frequency and rapid strategy iteration needs in specific scenarios.

[0004] Therefore, there is an urgent need for an application method that can realize plug-in AB experiment and improve configuration flexibility and execution efficiency. SUMMARY

[0005] In order to solve the problems existing in the prior art, the present application provides an application method and system of plug-in AB experiment.

[0006] The technical scheme of the present application is as follows: On the one hand, the present application provides an application method of plug-in AB experiment, which comprises: initializing the experiment plug-in of the AB experiment management system, including experiment plan configuration and experiment rule group grouping; each experiment rule group includes rule conditions, user label dictionary and experiment identification; The request end initiates an AB experiment request based on the corresponding scene node triggered by the current scene; After receiving the experiment request, the requested end determines whether there is an executable experiment plan in the current scene node, and if so, reads the experiment rule group corresponding to the current experiment plan; The user portrait is input into a rule calculation engine to determine whether the user portrait hits the rule conditions in the experiment rule group. A special risk control model is distributed to the hit experiment rule group, and a general risk control model is distributed to the missed experiment rule group.

[0007] Preferably, the experiment plan configuration specifically configures the AB experiment management system with a preset number of experiment plans. The experiment rule group grouping specifically divides each experiment plan into at least one experiment rule group according to a preset rule condition, and each experiment rule group includes a unique experiment identifier.

[0008] Preferably, the user portrait is constructed based on the configuration of the current experiment plan, and the specific steps are as follows: Obtain the user historical data and the experiment rule group corresponding to the current experiment plan, extract the user features in the user label dictionary in the experiment rule group, and obtain the user label. Based on the preset label generation logic in the user label dictionary, the user historical data is calculated to generate the specific value of each user label. Integrate the user label and the specific value of the corresponding user label to obtain the user portrait.

[0009] Preferably, the determination of whether the user portrait hits the rule conditions in the experiment rule group includes the following specific steps: The rule calculation engine parses each experiment rule group to obtain the parsed rule conditions. Match the user portrait with the parsed rule conditions. If at least one rule is hit, stop rule calculation, obtain the experiment identifier of the hit experiment rule group, and bind the corresponding experiment plan identifier in the hit experiment rule group to the user portrait.

[0010] Preferably, the determination of whether the user portrait hits the rule conditions in the experiment rule group includes the following specific steps: Select the experiment rule group currently in an enabled state and filter the experiment rule group matching the current scene. Extract the specific value of the required user label in the user portrait. Match the specific value of the user label with the rule conditions of the filtered experiment rule group. If at least one rule is hit, stop rule calculation, obtain the experiment identifier of the hit experiment rule group, and bind the corresponding experiment plan identifier in the hit experiment rule group to the user portrait.

[0011] Preferably, it further includes conflict processing, specifically: If multiple experimental rule groups are hit at the same time, the highest priority experimental rule group is selected as the hit experimental rule group according to a preset experimental rule group priority.

[0012] Preferably, the method further comprises observing the application effect after the distribution model, and dynamically adjusting the experimental plan configuration and the experimental rule group grouping of the AB experiment based on the application effect.

[0013] In another aspect, the application also provides an application system of the plug-in AB experiment, which comprises: The initialization module is used for initializing the experimental plug-in of the AB experiment management system, including the experimental plan configuration and the experimental rule group grouping; each experimental rule group comprises a rule condition, a user label dictionary and an experimental identifier; The request module is used for triggering the corresponding scene node to initiate the AB experiment request based on the current scene by the request end; The execution module is used for determining whether there is an executable experimental plan for the current scene node after the request end receives the experimental request, and reading the experimental rule group corresponding to the current experimental plan if there is an executable experimental plan; the user portrait is constructed based on the experimental rule group corresponding to the current experimental plan; The user portrait is input into the rule calculation engine to determine whether the user portrait hits the rule condition in the experimental rule group, and the special risk control model is distributed to the hit experimental rule group, and the general risk control model is distributed to the unhit experimental rule group.

[0014] The application has the following beneficial effects: 1. The application provides an application method and system of the plug-in AB experiment, which is based on the principles of “modular disassembly” and “configuration driving”, disassembles experimental elements into independently configurable modules, realizes combination and adjustment through a visual interface, and is independent of hard coding dependence, thereby improving the experimental configuration efficiency and enhancing the experimental flexibility. 2. The application provides an application method and system of the plug-in AB experiment, which is based on the principles of “rule engine” and “automatic decision”, determines the experimental executability automatically by the request end after triggering the scene node, automatically analyzes the rule condition, matches the user portrait by the rule calculation engine, and processes the conflict through priority. The whole process does not need manual intervention, is executed by the system according to the preset logic, improves the experimental execution speed, enhances the accuracy of experimental determination, and ensures the unique and effective hit in the multi-rule group scene through the conflict processing. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 The specific flowchart of the embodiment of the application is shown. DETAILED DESCRIPTION

[0016] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts are within the scope of the present application.

[0017] It should be understood that the step numbers used herein are only for the convenience of description, and are not limited to the execution sequence of the steps.

[0018] It should be understood that the terms used in the specification of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the specification and the appended claims of the present application, the singular forms "a", "an" and "the" are intended to include the plural forms, unless the context clearly indicates otherwise.

[0019] The terms "comprise" and "include" indicate the presence of the described features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0020] The term "and / or" means any combination of one or more of the associated listed items and all possible combinations thereof, and includes these combinations.

[0021] Embodiment one: With reference to Figure 1 The present application provides an application method of a plug-in AB experiment, which comprises the following steps: S1, initializing an experiment plug-in of an AB experiment management system, including experiment plan configuration and experiment rule group grouping; each experiment rule group comprises a rule condition, a user label dictionary and an experiment identification; The experiment plan comprises an experiment plan name, a validity period, a trigger node, a state, etc. Each experiment plug-in contains complete functional logic and interface, and can be defined, configured and maintained independently without relying on hard-coded association of underlying codes or other modules; Each experiment plan and experiment rule group grouping is an experiment plug-in, each experiment plan can be independently configured with a validity period, associated with a scene node (such as order application, risk control audit), and can be flexibly bound to multiple rule group plug-ins to realize a combination mode of "one plan + multiple rule group plug-ins" 1 to n; S2, the request end initiates an AB experiment request based on the current scene trigger of the corresponding scene node; In the present embodiment, the trigger node is a business node in the Internet financial scene, including order application, repayment, risk control audit, etc. The user label dictionary contains test variables in the Internet finance scenario, and the test variables include page layout, text, risk control policy parameters, pricing parameters, and marketing parameters, etc. The configuration of the rule set is a combination logic of test variables, and the combination logic is configured through a visual interface of a plug-in AB experiment management system. S3, after receiving the experiment request, the requested end judges whether there is an executable experiment plan for the current scene node, if there is, reads the experiment rule set corresponding to the current experiment plan, constructs a user portrait based on the experiment rule set corresponding to the current experiment plan, judges whether there is an executable experiment plan for the current scene node, if there is not, does not execute the AB experiment; The user historical data and the experiment rule set corresponding to the current experiment plan are obtained, the user features in the user label dictionary in the experiment rule set are extracted, and the user label is obtained. The user features include risk level, transaction frequency, user level, historical behavior preference, etc. The user historical data includes historical behavior records (such as past transaction amount, frequency, overdue situation) of the user in the Internet finance scenario, account attributes (such as registration time, authentication level), historical label results (such as previous risk rating), scene information of the user triggering the experiment (such as whether the current operation is “order application” or “repayment”), real-time behavior data (such as the device, time, and location of the current operation), etc. Based on the preset label generation logic in the user label dictionary, the user historical data is calculated to generate the specific value of each user label; for example, if the current user label is “transaction frequency in the past 30 days”, the corresponding label generation logic is “count the total number of all successful transaction records of the user in the past 30 days”, then the transaction database is called to filter and count according to the time range to obtain the specific value of the current user label; If the current user label is “risk level”, the corresponding label generation logic is “based on historical overdue times, credit score, debt ratio, etc. to calculate the three-level result of ‘high / medium / low’”, and the corresponding level is output as the specific value of the current user label; The user portrait is obtained by integrating the user label and the specific value of the corresponding user label; for example, the user portrait is represented as {user ID = 123, risk level = low, transaction frequency in the past 30 days = 8, user level = gold}. S4, input the user portrait into the rule calculation engine to judge whether the user portrait hits the rule condition in the experiment rule set. S41, the rule calculation engine analyzes each experiment rule set to obtain the analyzed rule condition. For example, the rule condition of the current experimental rule set is parsed as " (risk level = low risk and transaction frequency in the last 30 days >= 8) or user level = diamond" to obtain: Tag dimensions: risk level, transaction frequency in the last 30 days, user level; Logical operators: "and", "or", and other logical operators; Target values: low risk, 8 times, diamond; S42, match the user portrait with the parsed rule condition, including single condition matching and combined condition matching; The single condition matching is to compare whether the specific value of the user tag is consistent with the target value in the parsed rule condition, for example, whether "risk level = low risk" is true; The combined condition matching is to combine the user tags in the user portrait based on the logical operators, for example, the current experimental rule set condition is "risk level = low risk and transaction frequency in the last 30 days >= 8", if both sub-conditions in the user portrait are satisfied, the current rule set matching is successful; if any sub-condition is not satisfied, the matching fails; S43, if at least one rule is hit, stop rule calculation, get the experimental identifier of the hit experimental rule set, and bind the corresponding experimental plan identifier in the hit experimental rule set with the user portrait; S44, also includes conflict processing, specifically: If multiple experimental rule sets are hit at the same time, select the highest priority experimental rule set as the hit experimental rule set according to the preset experimental rule set priority; S5, distribute a special risk control model to the hit experimental rule set, and distribute a general risk control model to the unhit experimental rule set; The special model is a model customized for a specific experimental rule set for testing new strategies, while the general model is a standard model that has been verified and is suitable for most users; For example: I. The hit experimental rule set is "user registration duration <= 90 days and credit rating level >= B level and login frequency in the last 30 days >= 5 times"; The distributed special risk control model is defined as: increase the credit limit by 20% based on the original basis; reduce the approval pass rate threshold by 5%; omit some non-core review items; The distributed general risk control model is defined as: the limit is calculated according to the fixed formula "income level x 0.8 + credit rating coefficient"; the approval pass rate threshold is strictly executed as ">= 70 points"; the four-factor full-quantity review of "identity + work + income + credit" is required; II. The hit experimental rule set is "transaction frequency in the last 30 days >= 15 times and historical overdue times = 0 and user level >= gold level" The distributed special risk control model is defined as: the weight of "transaction frequency" is 30% in risk assessment; users with "1 outstanding small loan" are still allowed to pass the audit; the loan interest rate is reduced by 1 percentage point; The distributed general risk control model is defined as: the weight of each indicator is fixed (transaction frequency 10%, debt ratio 30%, credit rating 40%, user level 20%); users with "outstanding loans" are strictly prohibited from adding new credit; the interest rate is fixed in the user level interval; S6, the method further comprises observing the application effect after the distribution model, and dynamically adjusting the experimental plan configuration and experimental rule group grouping based on the application effect; In one specific embodiment, it is tested whether "relaxing the credit limit for a specific new user group" can improve loan conversion rate while controlling the bad debt rate within an acceptable range (≤3%); Configure the experimental plan plug-in, including the experimental plan name: new user first loan amount test, effective period: July 1, 2025-August 31, 2025, trigger node: when a new user submits a loan application, scene node binding "order application", status: enabled; Configure the experimental rule group plug-in, including rule group ID: RG001, rule condition: user registration duration ≤90 days and credit rating ≥B level and APP login frequency in the last 30 days ≥5 times, user tag dictionary: registration duration (days from user registration time to date), credit rating (obtained from third-party credit interface), login frequency in the last 30 days (statistical from user behavior log), experimental identifier: TAG_EXP202501_RG001; Request side triggers the experiment: on July 10, 2025, user "Wang Xiaoming" submits a first loan application in the APP, triggering the "order application" scene node; After the requested side receives the request, it checks whether there is an executable experimental plan in the current scene node, matches the experimental plan EXP202501 (in the effective period, the status is enabled), and reads its associated rule group RG001; Obtain Wang Xiaoming's historical user data, including registration time: May 20, 2025, credit rating: B level, and login record in the last 30 days: 7 times; Calculate the specific value of the user tag and generate a structured user portrait: {user ID=8899, registration duration=51 days, credit rating=B level, login frequency in the last 30 days=7 times}; The rule calculation engine parses the rule condition of RG001 as: Tag dimensions: registration duration, credit rating, and login frequency in the last 30 days; Logical relationship: (registration duration ≤90 days and credit rating ≥B level) and login frequency in the last 30 days ≥5 times; Target value: 90 days, B level, 5 times; Single condition matching is performed: registration duration 51 days ≤ 90 days → meets; credit level B level ≥ B level → meets; login 7 times in the last 30 days ≥ 5 times → meets; Combined condition matching is performed: all three sub-conditions meet the "and" relationship → overall matching is successful, and it is determined that the rule group RG001 is hit; The experiment identifier TAG_EXP202501_RG001 is bound to the user ID = 8899; The hit user is distributed with a special risk control model: credit limit calculation: additional 20% on the basis of the limit; the comprehensive score ≥ 65 points can pass; omit "work unit verification", only verify the ID card and bank card; After the experiment runs for 1 month, the loan conversion rate of the hit user is 28%, and the bad account rate is 2.5% ≤ 3%, which meets the expectation, and the effective period of the experiment plan is extended through the plug-in interface.

[0022] Embodiment Two The embodiment provides an application method of a plug-in AB experiment, and the specific steps are the same as those of Embodiment 1, and the difference lies in that in step S42, whether the user portrait hits the rule condition in the experiment rule group is judged, and the specific steps are as follows: T1, select the experiment rule group currently in an enabled state, and filter the experiment rule group matching the current scene; T2, extract the specific value of the user tag in the user portrait; T3, match the specific value of the user tag with the rule condition of the filtered experiment rule group, including atomic condition matching and combined logic matching; The atomic condition matching is to parse the smallest judgment unit in the rule one by one, for example: numerical comparison: credit score > 700; The combined logic matching is AND logic: sequentially execute the conditions, terminate immediately when an error is encountered, and return a miss; for example: condition A AND B, if A is false, skip the B judgment, and return a miss; OR logic: sequentially execute the conditions, terminate immediately when a correct result is encountered, and return a hit; NOT logic: take the inverse of the atomic condition result; T4, if at least one rule is hit, stop rule calculation, get the experiment identifier of the hit experiment rule group, and bind the corresponding experiment plan identifier in the hit experiment rule group to the user portrait; In a specific embodiment, the experiment rule group currently in an enabled state is selected, and the experiment rule group bound to the current scene node is filtered as RG001; From the user portrait, the specific values of the 3 user tags required by the rule group RG001 are: registration duration: 51 days, credit rating: B level, login frequency in the past 30 days: 7 times; Perform atomic condition matching: Atomic condition 1: registration duration ≤ 90 days → user value 51 days ≤ 90 days → match success; Atomic condition 2: Credit rating ≥ B level → user B level ≥ B level → match success; Atomic condition 3: Login frequency in the past 30 days ≥ 5 times → user value 7 times ≥ 5 times → match success; Perform combined logic matching: The combined logic of the experimental rule group RG001 is "AND" (all atomic conditions must be met), and the judgment is executed in order: First, judge atomic condition 1 → the result is true, continue to judge atomic condition 2; The result of atomic condition 2 is true, continue to judge atomic condition 3; The result of atomic condition 3 is true, the "AND" logic is satisfied as a whole → match success.

[0023] Example three: The embodiment provides an application system of a plug-in AB experiment, and the system comprises: An initialization module is used to initialize the experimental plug-in of the AB experiment management system, including experimental plan configuration and experimental rule group grouping; each experimental rule group comprises a rule condition, a user tag dictionary, and an experimental identifier; A request module is used to request the corresponding scene node to initiate an AB experiment request based on the current scene; An execution module is used to determine whether there is an executable experimental plan for the current scene node after the requested end receives the experimental request, and if so, read the experimental rule group corresponding to the current experimental plan; construct a user portrait based on the experimental rule group corresponding to the current experimental plan; Input the user portrait into a rule calculation engine, judge whether the user portrait hits the rule condition in the experimental rule group, distribute a special risk control model to the hit experimental rule group, and distribute a general risk control model to the miss experimental rule group.

[0024] In the embodiments of the present application, "at least one" means one or more, and "multiple" means two or more. The "and / or" describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the cases of A alone, A and B together, and B alone. Wherein A and B can be singular or plural. The character " / " generally represents an "or" relationship between the front and rear associated objects. "At least one of the following" and the like means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0025] Those of ordinary skill in the art can realize that the units and algorithm steps described in the embodiments disclosed herein can be realized in electronic hardware, computer software, and a combination of electronic hardware and computer software. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0026] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0027] In several embodiments provided in the present application, any function realized in the form of a software function unit and sold or used as an independent product can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (Read-Only Memory; hereinafter referred to as: ROM), a random access memory (Random Access Memory; hereinafter referred to as: RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0028] The above is only an embodiment of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation based on the content of the specification and drawings of the present application, or direct or indirect application in other related technical fields, is also included in the patent protection scope of the present application.

Claims

1. A plug-in AB experiment application method, characterized in that: The method comprises: Initialize the experiment plug-in of the AB experiment management system, including experiment plan configuration and experiment rule grouping; each experiment rule group includes rule conditions, user tag dictionary and experiment identifier; The requester initiates an AB experiment request based on the current scene triggering the corresponding scene node; After receiving the experiment request, the requested end determines whether there is an executable experiment plan for the current scene node. If so, it reads the experiment rule group corresponding to the current experiment plan; and builds a user profile based on the experiment rule group corresponding to the current experiment plan; The user profile is input into the rule calculation engine to determine whether the user profile hits the rule conditions in the experimental rule group. A dedicated risk control model is distributed to the experimental rule group that hits the condition, and a general risk control model is distributed to the experimental rule group that does not hit the condition.

2. The application method of a plug-in AB experiment according to claim 1, characterized in that: The experimental plan configuration specifically configures a preset number of experimental plans for the AB experiment management system; The experimental rule grouping is specifically to divide each experimental plan into at least one experimental rule group according to preset rule conditions, and each experimental rule group includes a unique experimental identifier.

3. The application method of a plug-in AB experiment according to claim 2, characterized in that: Build a user profile based on the configuration of the current experimental plan. The specific steps are: Obtain the user's historical data and the experimental rule group corresponding to the current experimental plan, extract the user features in the user label dictionary in the experimental rule group, and obtain the user label; Based on the tag generation logic preset in the user tag dictionary, the user's historical data is calculated to generate the specific value of each user tag; Integrate user tags and the specific values ​​of the corresponding user tags to obtain user portraits.

4. The application method of a plug-in AB experiment according to claim 1, characterized in that: Determine whether the user profile matches the rule conditions in the experiment rule group. The specific steps are as follows: The rule calculation engine parses each experimental rule group to obtain the parsed rule conditions; Match the user profile with the parsed rule conditions. If at least one rule is hit, stop the rule calculation, obtain the experiment identifier of the hit experiment rule group, and bind the corresponding experiment plan identifier in the hit experiment rule group to the user profile.

5. The application method of a plug-in AB experiment according to claim 1, characterized in that: Determine whether the user profile matches the rule conditions in the experiment rule group. The specific steps are as follows: Select the currently enabled experimental rule group and filter the experimental rule groups that match the current scenario; Extract the specific values ​​of user tags required in user portraits; The specific value of the user tag is matched with the rule conditions of the filtered experimental rule group. If at least one rule is hit, the rule calculation is stopped, and the experiment identifier of the hit experimental rule group is obtained. The corresponding experimental plan identifier in the hit experimental rule group is bound to the user portrait.

6. The application method of the plug-in AB experiment according to claims 4 and 5, characterized in that: It also includes conflict handling, specifically: If multiple experimental rule groups are hit at the same time, the experimental rule group with the highest priority is selected as the hitting experimental rule group according to the preset experimental rule group priority.

7. The application method of a plug-in AB experiment according to claim 1, characterized in that: The method further includes observing the application effect after the distribution model is distributed, and dynamically adjusting the experimental plan configuration and experimental rule grouping of the AB experiment based on the application effect.

8. A plug-in AB experiment application system, characterized in that: The system comprises: The initialization module is used to initialize the experiment plug-in of the AB experiment management system, including the configuration of the experiment plan and the grouping of the experiment rule groups; each experiment rule group includes rule conditions, user tag dictionary and experiment identifier; The request module is used by the requesting end to trigger the corresponding scene node based on the current scene to initiate an AB experiment request; The execution module is used to determine whether there is an executable experiment plan for the current scene node after the requested end receives the experiment request. If so, it reads the experiment rule group corresponding to the current experiment plan; and builds a user profile based on the experiment rule group corresponding to the current experiment plan; The user profile is input into the rule calculation engine to determine whether the user profile hits the rule conditions in the experimental rule group. A dedicated risk control model is distributed to the experimental rule group that hits the condition, and a general risk control model is distributed to the experimental rule group that does not hit the condition.

Images