An insurance customer value explainability assessment method, system, device and medium

Abstract

This invention relates to the field of data processing technology, specifically disclosing a method, system, device, and medium for interpretable assessment of insurance customer value. The invention defines data factor paths by configuring mapping rules for multiple insurance business scenarios, establishing a relational detailed database to store multidimensional detailed customer data, and constructing a high-speed cache mapping table with a primary key index. Upon receiving a front-end request, it extracts detailed fields of premium, claims, and estimated costs based on the business scenario identifier, calculates a customer value score, and returns detailed data. This solves the problems of gaps between aggregated and detailed data, lack of interpretability in tiered results, and disconnect between customer value assessment and business scenarios, thereby improving the interpretability of insurance customer value assessment results and enhancing the dynamic responsiveness of front-end business scenarios.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, system, device, and medium for assessing the interpretability of insurance customer value. Background Technology

[0002] In the construction of customer classification and tiering systems in the insurance industry, the mainstream technical architecture generally adopts a model that separates backend modeling and calculation, frontend reporting and display, and independent marketing tools. Under this model, the data team typically completes customer scoring and tag calculation in the data warehouse, stores the results in a wide table, and then provides management with summary statistics through business intelligence tools, or pushes a simple customer list to frontline agents through the customer relationship management system.

[0003] However, the existing solution has three core flaws: First, there is a gap between the aggregated data and the detailed data. The macro statistics seen by management in the dashboard cannot be traced back to the micro-level individuals, resulting in unclear decision-making basis. Second, the hierarchical logic is "black box" in nature. Agents can only know the final level result and cannot view the details of the rating generation, which seriously lacks interpretability and business trust. Third, the front-end application is rigidly connected. The hierarchical labels exist only as static attributes and fail to dynamically trigger differentiated marketing strategies based on the front-end operation context, resulting in a disconnect between customer value assessment and business scenarios.

[0004] Therefore, there is an urgent need to provide a technical solution to address the above problems. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method, system, device, and medium for assessing the interpretability of insurance customer value.

[0006] Firstly, the present invention provides a method for assessing the interpretability of insurance customer value, the technical solution of which is as follows: For multiple insurance business scenarios, mapping rule configuration information is defined respectively. The mapping rule configuration information includes the data factor path required to retrieve customer value assessment factors related to the corresponding insurance business scenario from the database. The customer's multidimensional detailed data is stored in a relational detailed database, and a high-speed cache mapping table is established using the customer's primary key identifier. The high-speed cache mapping table is used to point to the storage location of the corresponding customer's multidimensional detailed data in the relational detailed database. Receive customer value assessment requests sent by the front-end application, which carry customer primary key identifiers and business scenario identifiers; The premium details, claims cost details, and estimated cost details associated with the customer's primary key identifier are read from the relational details database through the cache mapping table. Based on the data factor path in the mapping rule configuration information corresponding to the business scenario identifier, the target detail field is extracted from the premium detail data, the claims cost detail data, and the estimated cost detail data; Calculate the customer value score corresponding to the customer primary key identifier based on the target detail field, and return the customer value score and the target detail field to the front-end application.

[0007] The beneficial effects of the insurance customer value interpretability assessment method of the present invention are as follows: The method of this invention defines data factor paths by configuring mapping rules for multiple insurance business scenarios, establishing a relational detailed database to store multidimensional detailed customer data, and constructing a high-speed cache mapping table to establish a primary key index. After receiving front-end requests, it extracts detailed fields of premium, claims, and estimated costs based on business scenario identifiers, calculates customer value scores, and returns detailed data. This solves the problems of gaps between aggregated data and detailed data, lack of interpretability of hierarchical results, and disconnect between customer value assessment and business scenarios. It improves the interpretability of insurance customer value assessment results and enhances the dynamic response capability of front-end business scenarios.

[0008] Based on the above scheme, the insurance customer value interpretability assessment method of the present invention can be further improved as follows.

[0009] In one optional approach, the steps for defining mapping rule configuration information for multiple insurance business scenarios include: Obtain the business scenario identifiers corresponding to multiple insurance business scenarios; For each business scenario identifier, receive at least one customer value assessment factor specified for that business scenario identifier and the data factor path corresponding to each customer value assessment factor; Each data factor path is validated for validity, including determining whether the data factor path points to an accessible field in the database that stores detailed data. The verified data factor paths are associated with and stored with the corresponding business scenario identifiers and customer value assessment factors to form mapping rule configuration information corresponding to the multiple insurance business scenarios.

[0010] The advantages of adopting the above optional approach are as follows: by further specifying customer value assessment factors and corresponding data factor paths for each business scenario identifier and validating the effectiveness of the paths, the problem of lack of standardized verification process in mapping rule configuration is solved, and the accurate association and storage of data factor paths with business scenario identifiers and customer value assessment factors is realized, thereby improving the accuracy and reliability of mapping rule configuration.

[0011] In one alternative approach, the steps of storing the customer's multidimensional detail data in a relational detail database and establishing a cache mapping table using the customer's primary key identifier include: In the relational detail database, a wide table is constructed using the customer's primary key identifier as a clustered index. The wide table is used to store the customer's multidimensional detail data. Write the multidimensional detailed data of each customer as a row in the wide table corresponding to the customer's primary key identifier; Determine the storage location of each record in the wide table, and associate the client primary key identifier with the corresponding storage location in the cache mapping table.

[0012] The advantages of adopting the above optional approach are as follows: by further constructing a wide table in the relational detail database with the customer primary key identifier as the clustered index to store multidimensional detail data, and establishing a high-speed cache mapping table to point to the storage location, the problem of loose data storage structure and low access efficiency of customer detail data is solved, and the rapid location and efficient reading of multidimensional detail data are realized, thus optimizing the data storage architecture and access performance.

[0013] In one alternative approach, the step of receiving a customer value assessment request sent by the front-end application, carrying a customer primary key identifier and a business scenario identifier, includes: The system listens for and receives Hypertext Transfer Protocol (HTTP) requests sent by the front-end application through a preset application programming interface. The message body of the HTTP request contains the client primary key identifier and the business scenario identifier. The customer primary key identifier and the business scenario identifier are parsed from the message body; Verify whether the business scenario identifier belongs to a predefined set of business scenario identifiers corresponding to multiple insurance business scenarios; If the verification is successful, it is confirmed that the customer value assessment request has been received.

[0014] The advantages of adopting the above optional method are as follows: by further listening to the Hypertext Transfer Protocol request and parsing the customer primary key identifier and business scenario identifier through the preset application programming interface, and performing predefined set verification on the business scenario identifier, the problem of lack of standardized interface and legality verification for receiving customer value assessment requests is solved, the standardization and security of request reception are guaranteed, and the stability of the request processing flow is enhanced.

[0015] In one alternative approach, the step of reading premium details, claims cost details, and estimated cost details associated with the customer's primary key identifier from the relational detail database via the cache mapping table includes: The cache mapping table is queried using the customer primary key identifier as the query condition to obtain the storage location corresponding to the customer primary key identifier; Based on the storage location, locate the record row corresponding to the customer primary key identifier in the wide table of the relational detail database; Read the premium details, claims cost details, and estimated cost details from the record row.

[0016] The advantages of adopting the above optional method are as follows: by further querying the storage location and locating the wide table record row by using the cache mapping table, the detailed data of premium, claims cost and estimated cost can be read from the record row, which solves the problems of long reading path and insufficient query efficiency of detailed data, realizes the rapid and accurate extraction of detailed data and shortens the data reading response time.

[0017] In one optional approach, the step of extracting target detail fields from the premium detail data, the claims cost detail data, and the estimated cost detail data based on the data factor path in the mapping rule configuration information corresponding to the business scenario identifier includes: The corresponding set of data factor paths is obtained from the mapping rule configuration information based on the business scenario identifier; For each data factor path in the data factor path set, extract the corresponding detailed field values ​​from the premium details data, the claims cost details data, and the estimated cost details data according to the data factor path; All extracted detail field values ​​are merged into the target detail field.

[0018] The advantages of adopting the above optional method are as follows: by further obtaining the data factor path set according to the business scenario identifier and extracting the detailed field values ​​according to the path and merging them into the target detailed field, the problem of lack of scenario-based adaptation and automated aggregation in the detailed field extraction is solved, and the flexible configuration and efficient extraction of the target detailed field are realized, thereby improving the targeting and completeness of data extraction.

[0019] In one optional approach, the step of calculating the customer value score corresponding to the customer primary key identifier based on the target detail field, and returning the customer value score and the target detail field to the front-end application includes: Obtain the scoring rules corresponding to the business scenario identifier; The customer value score corresponding to the customer primary key identifier is obtained by calculating the value of the detailed field in the target detailed field according to the scoring rules. The customer value score and the target detail field are encapsulated into response data, and the response data is sent to the front-end application.

[0020] The advantages of adopting the above optional method are as follows: by further obtaining the scoring rules corresponding to the business scenario identifier to calculate the customer value score, and encapsulating the score and target detail fields into response data and sending it to the front-end application, the problem of lack of scenario-based rule adaptation in score calculation and the single result return format is solved. The scenario-based customization of customer value score and the visualization of detailed data are realized, which enhances the practicality and transparency of the evaluation results.

[0021] Secondly, this invention provides an insurance customer value interpretability assessment system, the technical solution of which is as follows: The configuration module is used to define mapping rule configuration information for multiple insurance business scenarios. The mapping rule configuration information includes the data factor path required to retrieve customer value assessment factors related to the corresponding insurance business scenario from the database. A module is established to store the customer's multidimensional detailed data in a relational detailed database, and a cache mapping table is established using the customer's primary key identifier. The cache mapping table is used to point to the storage location of the corresponding customer's multidimensional detailed data in the relational detailed database. The request module is used to receive customer value assessment requests sent by the front-end application, which carry customer primary key identifiers and business scenario identifiers. The reading module is used to read premium details, claims cost details, and estimated cost details associated with the customer primary key identifier from the relational details database through the cache mapping table. The extraction module is used to extract target detail fields from the premium detail data, the claims cost detail data, and the estimated cost detail data according to the data factor path in the mapping rule configuration information corresponding to the business scenario identifier. The evaluation module is used to calculate the customer value score corresponding to the customer primary key identifier based on the target detail field, and return the customer value score and the target detail field to the front-end application.

[0022] The beneficial effects of the insurance customer value interpretability assessment system of the present invention are as follows: The system of this invention defines data factor paths by configuring mapping rules for multiple insurance business scenarios, establishes a relational detailed database to store multidimensional detailed customer data, and constructs a high-speed cache mapping table to establish a primary key index. After receiving front-end requests, it extracts detailed fields of premium, claims, and estimated costs based on business scenario identifiers, calculates customer value scores, and returns detailed data. This solves the problems of gaps between aggregated data and detailed data, lack of interpretability of hierarchical results, and disconnect between customer value assessment and business scenarios. It improves the interpretability of insurance customer value assessment results and enhances the dynamic response capability of front-end business scenarios.

[0023] Thirdly, the technical solution of an electronic device according to the present invention is as follows: It includes a memory, a processor, and a program stored in the memory and running on the processor, wherein the processor executes the program to implement the steps of the insurance customer value interpretability assessment method of the present invention.

[0024] Fourthly, the technical solution of a computer-readable storage medium provided by the present invention is as follows: The computer-readable storage medium stores instructions that, when read, cause the computer-readable storage medium to perform the steps of the insurance customer value interpretability assessment method of the present invention.

[0025] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0026] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating an embodiment of an insurance customer value interpretability assessment method according to the present invention. Figure 2 This is a schematic diagram of an embodiment of an insurance customer value interpretability assessment system according to the present invention; Figure 3 This is a schematic diagram of an embodiment of an electronic device according to the present invention. Detailed Implementation

[0027] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0028] Figure 1This diagram illustrates a flowchart of an embodiment of an insurance customer value interpretability assessment method provided by the present invention. This method can be executed by electronic devices such as terminal devices or servers. The terminal device can be any fixed or mobile terminal, such as user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, or wearable device. The server can be a single server or a server cluster consisting of multiple servers. Any electronic device can implement the insurance customer value interpretability assessment method by having its processor call computer-readable instructions stored in its memory. Figure 1 As shown, it includes the following steps: S1. For multiple insurance business scenarios, define mapping rule configuration information respectively. The mapping rule configuration information includes the data factor path required to retrieve customer value assessment factors related to the corresponding insurance business scenario from the database.

[0029] Here, "insurance business scenarios" refers to different specific situations or process stages involved in an insurance company's business operations, such as underwriting, claims processing, renewal, and marketing. For example, in property insurance, auto insurance underwriting and home insurance claims are two different insurance business scenarios, and each scenario may focus on different aspects of customer value. "Mapping rule configuration information" refers to a predefined set of configuration data for each insurance business scenario, specifying which data factors to retrieve from the database and how to retrieve them. For example, for the auto insurance underwriting scenario, the mapping rule configuration information specifies the data factors to be retrieved, such as premium payment records and historical claim counts, and their corresponding specific field paths in the database.

[0030] Here, "database" refers to a storage system used for persistently storing insurance business-related data, which can be a relational database or a data warehouse. For example, Insurance Company B stores customer information, policy data, and claims records in a database called "Insurance Data Center." "Customer value assessment factor" refers to specific indicators or data items used to measure the value of a customer to the insurance company, such as the total premiums paid by the customer, claims costs, and customer interaction frequency. For example, in a car insurance scenario, customer value assessment factors include customer A's total premiums and number of claims over the past year. "Data factor path" refers to the specific access path from the database to the data field corresponding to a specific customer value assessment factor, typically including the table name and field name. For example, the data factor path "policy_table.premium_amount" indicates retrieving the premium amount field from the policy table.

[0031] S2. Store the customer's multidimensional detailed data in a relational detailed database, and establish a high-speed cache mapping table using the customer's primary key identifier. The high-speed cache mapping table is used to point to the storage location of the corresponding customer's multidimensional detailed data in the relational detailed database.

[0032] Multidimensional detailed data refers to detailed raw customer data recorded from multiple dimensions, including basic customer information, transaction records, and interaction history. For example, customer A's multidimensional detailed data includes information about insured vehicles, details of premiums paid over the years, and the amount and time of each claim. A relational detailed database refers to a database designed using a relational model to store customer multidimensional detailed data, organized in structured tabular form. For example, Insurance Company B uses a relational database as its relational detailed database, which includes customer tables, policy tables, and claims tables.

[0033] Here, the customer primary key identifier refers to a unique identifier, such as a customer ID; for example, customer A's primary key identifier in Insurance Company B's system is "CUST100001". The cache mapping table is a key-value pair mapping table stored in a cache, where the key is the customer primary key identifier and the value is the physical storage location of the customer's data in the relational database, used for quick data location; for example, the cache mapping table stores the starting address of data block 3 in the relational database corresponding to "CUST100001". The storage location refers to the specific physical address of the customer's multidimensional detailed data in the relational database, such as a data block number or record pointer; for example, customer A's multidimensional detailed data is stored in row 5 of data block 3 in the relational database.

[0034] S3. Receive a customer value assessment request sent by the front-end application, which carries the customer primary key identifier and business scenario identifier.

[0035] Among them, front-end applications refer to software systems that are directly used by insurance company business personnel or customers, such as customer relationship management interfaces or agent workbenches; for example, customer management applications on tablet computers used by insurance agents are front-end applications.

[0036] The business scenario identifier refers to a unique code used to distinguish different insurance business scenarios, such as a scenario number or name; for example, the business scenario identifier for a car insurance underwriting scenario is "SCENE_CAR_APPLY", and for a home insurance claims scenario it is "SCENE_HOUSE_CLAIM". A customer value assessment request refers to a command message sent by the front-end application to the server to obtain a customer's value score, which includes the customer's primary key identifier and the business scenario identifier; for example, an agent sends a request through the front-end application to inquire about customer A's value score in a car insurance underwriting scenario.

[0037] S4. Using the cache mapping table, read the premium details, claims cost details, and estimated cost details associated with the customer's primary key identifier from the relational details database.

[0038] The premium details data refers to a detailed record of the customer's insurance premium payments, including payment time, payment amount, and corresponding policy number. For example, customer A's premium details show that a car insurance premium of 3,000 yuan was paid on January 1, 2026, with the corresponding policy number "POLICY2026001". The claims cost details data refers to a detailed record of compensation payments made by the insurance company after a customer's claim event, including claim time, claim amount, and claim case number. For example, customer A's claims cost details show that a claim of 2,000 yuan was made on March 1, 2026, for a minor vehicle collision, with the claim case number "CLAIM2026001". The estimated cost details data refers to a detailed estimate of future claims costs or other service costs based on the customer's historical data and risk assessment model. For example, based on customer A's driving record and vehicle condition, the estimated claims cost for the next year is 1,500 yuan.

[0039] S5. Based on the data factor path in the mapping rule configuration information corresponding to the business scenario identifier, extract the target detail field from the premium detail data, the claims cost detail data, and the estimated cost detail data.

[0040] Among them, the target detail field refers to the set of specific data items extracted from the premium detail data, claims cost detail data, and estimated cost detail data according to the mapping rules corresponding to the business scenario identifier, which are used to calculate the customer value score; for example, in the car insurance scenario, the target detail field includes "total premium in the past year", "total number of claims in the past three years" and "estimated annual claims cost".

[0041] S6. Calculate the customer value score corresponding to the customer primary key identifier based on the target detail field, and return the customer value score and the target detail field to the front-end application.

[0042] Customer value score refers to a numerical value or level that reflects a customer's value to the insurance company, calculated based on target detail fields. For example, customer A's customer value score is 85 points (out of 100), and he is classified as a high-value customer.

[0043] The technical solution of this embodiment defines data factor paths by configuring mapping rules for multiple insurance business scenarios, establishing a relational detailed database to store multidimensional detailed customer data, and constructing a high-speed cache mapping table to establish a primary key index. After receiving front-end requests, it extracts detailed fields of premium, claims, and estimated costs based on business scenario identifiers, calculates customer value scores, and returns detailed data. This solves the problems of gaps between aggregated data and detailed data, lack of interpretability of hierarchical results, and disconnect between customer value assessment and business scenarios. It improves the interpretability of insurance customer value assessment results and enhances the dynamic response capability of front-end business scenarios.

[0044] In one alternative approach, S1 specifically includes: Obtain the business scenario identifiers corresponding to multiple insurance business scenarios.

[0045] For each business scenario identifier, receive at least one customer value assessment factor specified for that business scenario identifier and the data factor path corresponding to each customer value assessment factor.

[0046] Each data factor path is validated for validity, including determining whether the data factor path points to an accessible field in the database that stores detailed data.

[0047] Validation refers to checking the data factor path to ensure it correctly points to an accessible field in the database, preventing data retrieval failures due to incorrect paths. For example, when defining mapping rules, it checks whether the data factor path "policy_table.premium_amount" truly corresponds to the premium amount field in the policy table and whether that field has read permissions. An accessible field is a field that exists in the database and the current user has read permissions for; for example, if the "policy_table.premium_amount" field exists in the database and has read permissions configured, then that field is an accessible field.

[0048] The verified data factor paths are associated with and stored with the corresponding business scenario identifiers and customer value assessment factors to form mapping rule configuration information corresponding to the multiple insurance business scenarios.

[0049] In the above-mentioned optional methods, by further specifying customer value assessment factors and corresponding data factor paths for each business scenario identifier and validating the paths, the problem of lack of standardized verification process in mapping rule configuration is solved, and the accurate association and storage of data factor paths with business scenario identifiers and customer value assessment factors is realized, thereby improving the accuracy and reliability of mapping rule configuration.

[0050] In one alternative approach, S2 specifically includes: In the relational detail database, a wide table is constructed using the customer's primary key identifier as a clustered index. This wide table is used to store the customer's multidimensional detail data.

[0051] Clustered indexes refer to a database index structure where the physical storage order of data in a table matches the logical order of the index key, thus speeding up queries by primary key. For example, in a relational database, a wide table is built using the customer's primary key as the clustered index, allowing for contiguous storage of data for the same customer and enabling rapid location during queries. Wide tables, on the other hand, are database tables containing a large number of fields. They typically combine attributes of multiple related entities into a single table to reduce join queries. For instance, Insurance Company B has built a wide customer table containing fields for various dimensions, including basic customer information, policy information, and claims information, with each row corresponding to one customer.

[0052] Write the multidimensional detailed data of each customer as a row in the wide table corresponding to the customer's primary key identifier.

[0053] Determine the storage location of each record in the wide table, and associate the client primary key identifier with the corresponding storage location in the cache mapping table.

[0054] Each row of records refers to a single line of data in the wide table, representing a customer's complete multidimensional detailed data. For example, the row of records corresponding to customer A in the wide table includes name, contact information, all premium payment records, claims records, etc.

[0055] In the above optional methods, a wide table is further constructed in the relational detail database using the customer's primary key as the clustered index to store multidimensional detail data, and a high-speed cache mapping table is established to point to the storage location. This solves the problems of loose data storage structure and low access efficiency of customer detail data, realizes fast location and efficient reading of multidimensional detail data, and optimizes data storage architecture and access performance.

[0056] In one alternative approach, S3 specifically includes: The system listens for and receives Hypertext Transfer Protocol (HTTP) requests sent by the front-end application through a pre-defined application programming interface. The HTTP request message body contains the client primary key identifier and the business scenario identifier.

[0057] Application Programming Interface (API) refers to a set of predefined functions or interfaces that front-end applications can call to interact with back-end services. For example, Insurance Company B provides a RESTful API, which the front-end application can call via HTTP requests to obtain customer value scores.

[0058] In this context, a Hypertext Transfer Protocol (HTTP) request refers to a network request sent based on the HTTP protocol for communication between a client and a server. For example, a front-end application might send a GET or POST type HTTP request to a server-side interface address. The message body refers to the main part of the HTTP request that carries the actual data, typically used to transmit parameters in JSON or XML format. For instance, a front-end application might include the client primary key "CUST100001" and the business scenario identifier "SCENE_CAR_APPLY" in the HTTP request's message body.

[0059] The customer primary key identifier and the business scenario identifier are parsed from the message body.

[0060] Verify whether the business scenario identifier belongs to a predefined set of business scenario identifiers corresponding to multiple insurance business scenarios.

[0061] The business scenario identifier set refers to the predefined set of all valid business scenario identifiers used to verify whether the business scenario identifiers in the request are valid; for example, the business scenario identifier set is {"SCENE_CAR_APPLY", "SCENE_HOUSE_CLAIM", "SCENE_RENEWAL"}.

[0062] If the verification is successful, it is confirmed that the customer value assessment request has been received.

[0063] In the above optional methods, a pre-defined application programming interface is used to listen for Hypertext Transfer Protocol requests and parse customer primary key identifiers and business scenario identifiers. The business scenario identifiers are then validated using a predefined set. This solves the problem of the lack of standardized interfaces and legality checks in receiving customer value assessment requests, and ensures the standardization and security of request reception, thereby enhancing the stability of the request processing flow.

[0064] In one alternative approach, S4 specifically includes: The cache mapping table is queried using the customer primary key identifier as the query condition to obtain the storage location corresponding to the customer primary key identifier.

[0065] The query condition refers to the key value used when searching in the cache mapping table, which is usually the client's primary key identifier. For example, using the client's primary key identifier "CUST100001" as the query condition, the corresponding storage location is found in the cache mapping table.

[0066] Based on the storage location, locate the record row corresponding to the customer primary key identifier in the wide table of the relational detail database.

[0067] Here, a record row refers to the row of data located in the wide table of the relational detail database that corresponds to the primary key identifier of a specific customer; for example, if the 100th row of the wide table is located by the storage location, that row is the record row of customer A.

[0068] Read the premium details, claims cost details, and estimated cost details from the record row.

[0069] In the above-mentioned optional methods, the storage location is further queried by using a high-speed cache mapping table to locate the wide table record row, and the detailed data of premium, claims cost and estimated cost are read from the record row. This solves the problems of long detailed data reading path and insufficient query efficiency, realizes the fast and accurate extraction of detailed data, and shortens the data reading response time.

[0070] In one alternative approach, S5 specifically includes: The corresponding set of data factor paths is obtained from the mapping rule configuration information based on the business scenario identifier.

[0071] The data factor path set refers to a list of multiple data factor paths corresponding to a certain business scenario identifier, obtained from the mapping rule configuration information. For example, for the auto insurance scenario, the data factor path set includes "policy_table.premium_sum", "claim_table.times", and "estimate_table.cost".

[0072] For each data factor path in the data factor path set, the corresponding detailed field values ​​are extracted from the premium details data, the claims cost details data, and the estimated cost details data according to the data factor path.

[0073] Among them, the detailed field value refers to the specific value extracted from the premium detailed data, claims cost detailed data and estimated cost detailed data according to the data factor path; for example, the detailed field value extracted according to the path "policy_table.premium_sum" is 3500 yuan.

[0074] All extracted detail field values ​​are merged into the target detail field.

[0075] In the above optional methods, the data factor path set is further obtained according to the business scenario identifier, and the detailed field values ​​are extracted and merged into the target detailed field by the path. This solves the problem of lack of scenario-based adaptation and automated aggregation in the extraction of detailed fields, realizes flexible configuration and efficient extraction of target detailed fields, and improves the targeting and completeness of data extraction.

[0076] In one alternative approach, S6 specifically includes: Obtain the scoring rules corresponding to the business scenario identifier.

[0077] The scoring rules refer to the algorithms or formulas used to calculate customer value scores, which may include weighted summation, threshold judgment, etc. For example, the scoring rules for car insurance scenarios are: Customer value score = Total premium × 0.6 - Total claims cost × 0.3 - Estimated cost × 0.1.

[0078] The customer value score corresponding to the customer primary key identifier is obtained by calculating the value of the detailed field in the target detailed field according to the scoring rules.

[0079] The response data refers to the data packet returned by the server to the front-end application after processing the customer value assessment request. It usually contains customer value score and target detail fields. For example, the response data returned by the server is in JSON format and contains "score": 85, "details": {"premium": 3500, "claims": 2000, "estimate": 1500}.

[0080] The customer value score and the target detail field are encapsulated into response data, and the response data is sent to the front-end application.

[0081] In the above optional methods, the customer value score is further calculated by obtaining the scoring rules corresponding to the business scenario identifier, and the score and target detail fields are encapsulated into response data and sent to the front-end application. This solves the problems of lack of scenario-based rule adaptation in score calculation and single result return format, realizes scenario-based customization of customer value score and visualization of detailed data, and enhances the practicality and transparency of evaluation results.

[0082] In another embodiment of the insurance customer value interpretability assessment method of the present invention, the following steps are specifically included: S10. Configure mapping rules for multiple insurance business scenarios, including auto insurance renewal, auto insurance purchase, and home property insurance claims. The mapping rules include the data factor paths required to retrieve customer value assessment factors related to the corresponding insurance business scenario from the database, setting an initial weight coefficient for each customer value assessment factor, and associating and storing the business scenario identifier with the mapping rules.

[0083] S20. In the relational detail database, construct a wide table with the customer's primary key identifier as the clustered index. Write the customer's multidimensional detail data as a row record in the wide table corresponding to the customer's primary key identifier. Determine the storage location of each row record in the wide table. Associate the customer's primary key identifier with the corresponding storage location and store it in the cache mapping table.

[0084] S30. Listen for and receive Hypertext Transfer Protocol (HTTP) requests sent by the front-end application through a preset application programming interface. The body of the HTTP request contains the customer primary key identifier and the business scenario identifier. Parse the customer primary key identifier and the business scenario identifier from the body. Verify whether the business scenario identifier belongs to a set of predefined business scenario identifiers corresponding to multiple insurance business scenarios. If the verification is successful, confirm that the customer value assessment request has been received.

[0085] S40. Using the customer's primary key identifier as the query condition, retrieve the corresponding storage location in the cache mapping table. Based on the storage location, locate the corresponding record row in the wide table of the relational detail database, and read the premium details, claims cost details, and estimated cost details from the record row.

[0086] S50. Based on the business scenario identifier, obtain the corresponding set of data factor paths and the weight coefficient corresponding to each data factor path from the mapping rules. For each data factor path in the set of data factor paths, extract the corresponding detailed field values ​​from the premium details data, claims cost details data and estimated cost details data according to the data factor path, and merge all the extracted detailed field values ​​into the target detailed field.

[0087] S60. Obtain the scoring rules corresponding to the business scenario identifier. The scoring rules are based on the weighted sum of the values ​​of each detailed field in the target detailed field and the corresponding weight coefficients to calculate the customer value score corresponding to the customer primary key identifier. At the same time, calculate the contribution of each detailed field value to the customer value score according to the values ​​of each detailed field and their weight coefficients, and generate attribution analysis data.

[0088] S70: Encapsulate customer value scores, target detail fields, and attribution analysis data into response data, and send the response data to the front-end application.

[0089] S80: Receive user operation feedback information returned by the front-end application, adjust the weight coefficients of the corresponding business scenario according to the feedback information, and update the weight coefficients stored in the mapping rules.

[0090] This embodiment configures mapping rules with weighted coefficients for multiple insurance business scenarios and constructs a hybrid storage structure of a high-speed cache mapping table and a relational detail database based on the customer's primary key identifier. This enables rapid location and retrieval of multi-dimensional customer detail data. By extracting the corresponding detail fields and weighted coefficients based on the business scenario identifier, customer value scores are calculated and attribution analysis data is generated. The scores, detail fields, and attribution data are then returned to the front-end application. Furthermore, the weighted coefficients are dynamically adjusted based on front-end feedback. This solves the problems of gaps between summary data and detail data, lack of interpretability of hierarchical results, and disconnect between customer value assessment and business scenarios. It improves the interpretability of customer value assessment results, enhances the dynamic response capability of front-end business scenarios, and continuously optimizes the assessment model.

[0091] Figure 2 This diagram illustrates a structural schematic of an embodiment of an insurance customer value interpretability assessment system 200 provided by the present invention. Figure 2 As shown, the insurance customer value interpretability assessment system 200 includes: Configuration module 201 is used to define mapping rule configuration information for multiple insurance business scenarios. The mapping rule configuration information includes the data factor path to be called from the database to obtain customer value assessment factors related to the corresponding insurance business scenario. Module 202 is used to store the customer's multidimensional detailed data in a relational detailed database and to establish a cache mapping table with the customer's primary key identifier. The cache mapping table is used to point to the storage location of the corresponding customer's multidimensional detailed data in the relational detailed database. Request module 203 is used to receive a customer value assessment request sent by the front-end application, which carries the customer primary key identifier and business scenario identifier. The reading module 204 is used to read premium detail data, claims cost detail data, and estimated cost detail data associated with the customer primary key identifier from the relational detail database through the cache mapping table; Extraction module 205 is used to extract target detail fields from the premium detail data, the claims cost detail data and the estimated cost detail data according to the data factor path in the mapping rule configuration information corresponding to the business scenario identifier; The evaluation module 206 is used to calculate the customer value score corresponding to the customer primary key identifier based on the target detail field, and return the customer value score and the target detail field to the front-end application.

[0092] In an alternative embodiment, the configuration module 201 is specifically used for: Obtain the business scenario identifiers corresponding to multiple insurance business scenarios; For each business scenario identifier, receive at least one customer value assessment factor specified for that business scenario identifier and the data factor path corresponding to each customer value assessment factor; Each data factor path is validated for validity, including determining whether the data factor path points to an accessible field in the database that stores detailed data. The verified data factor paths are associated with and stored with the corresponding business scenario identifiers and customer value assessment factors to form mapping rule configuration information corresponding to the multiple insurance business scenarios.

[0093] In an alternative embodiment, the establishment module 202 is specifically used for: In the relational detail database, a wide table is constructed using the customer's primary key identifier as a clustered index. The wide table is used to store the customer's multidimensional detail data. Write the multidimensional detailed data of each customer as a row in the wide table corresponding to the customer's primary key identifier; Determine the storage location of each record in the wide table, and associate the client primary key identifier with the corresponding storage location in the cache mapping table.

[0094] In an alternative embodiment, the request module 203 is specifically used for: The system listens for and receives Hypertext Transfer Protocol (HTTP) requests sent by the front-end application through a preset application programming interface. The message body of the HTTP request contains the client primary key identifier and the business scenario identifier. The customer primary key identifier and the business scenario identifier are parsed from the message body; Verify whether the business scenario identifier belongs to a predefined set of business scenario identifiers corresponding to multiple insurance business scenarios; If the verification is successful, it is confirmed that the customer value assessment request has been received.

[0095] In an alternative embodiment, the reading module 204 is specifically used for: The cache mapping table is queried using the customer primary key identifier as the query condition to obtain the storage location corresponding to the customer primary key identifier; Based on the storage location, locate the record row corresponding to the customer primary key identifier in the wide table of the relational detail database; Read the premium details, claims cost details, and estimated cost details from the record row.

[0096] In an alternative embodiment, the extraction module 205 is specifically used for: The corresponding set of data factor paths is obtained from the mapping rule configuration information based on the business scenario identifier; For each data factor path in the data factor path set, extract the corresponding detailed field values ​​from the premium details data, the claims cost details data, and the estimated cost details data according to the data factor path; All extracted detail field values ​​are merged into the target detail field.

[0097] In an alternative embodiment, the evaluation module 206 is specifically used for: Obtain the scoring rules corresponding to the business scenario identifier; The customer value score corresponding to the customer primary key identifier is obtained by calculating the value of the detailed field in the target detailed field according to the scoring rules. The customer value score and the target detail field are encapsulated into response data, and the response data is sent to the front-end application.

[0098] It should be noted that the beneficial effects of the insurance customer value interpretability assessment system 200 provided in the above embodiments are the same as those of the insurance customer value interpretability assessment method described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0099] The insurance customer value interpretability assessment system 200 of the present invention can be a computer program (including program code) running on a computer device. For example, the insurance customer value interpretability assessment system 200 of the present invention is an application software that can be used to execute the corresponding steps in the insurance customer value interpretability assessment method of the present invention.

[0100] In some embodiments, the insurance customer value interpretability assessment system 200 of the present invention can be implemented in a combination of hardware and software. As an example, the insurance customer value interpretability assessment system 200 of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the insurance customer value interpretability assessment method of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0101] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0102] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned insurance customer value interpretability assessment methods. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the insurance customer value interpretability assessment method shown in any embodiment of the present invention by calling the computer program.

[0103] In one alternative embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0104] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0105] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0106] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0107] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0108] Among them, electronic devices can also be terminal devices. A terminal device can be any terminal device that can install applications and access web pages through applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0109] It should be noted that, Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0110] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described insurance customer value interpretability assessment methods.

[0111] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0112] In an exemplary embodiment, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned insurance customer value interpretability assessment method.

[0113] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0114] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0115] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0116] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0117] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0118] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0119] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0120] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for assessing the interpretability of insurance customer value, characterized in that, include: For multiple insurance business scenarios, mapping rule configuration information is defined respectively. The mapping rule configuration information includes the data factor path required to retrieve customer value assessment factors related to the corresponding insurance business scenario from the database. The customer's multidimensional detailed data is stored in a relational detailed database, and a high-speed cache mapping table is established using the customer's primary key identifier. The high-speed cache mapping table is used to point to the storage location of the corresponding customer's multidimensional detailed data in the relational detailed database. Receive customer value assessment requests sent by the front-end application, which carry customer primary key identifiers and business scenario identifiers; The premium details, claims cost details, and estimated cost details associated with the customer's primary key identifier are read from the relational details database through the cache mapping table. Based on the data factor path in the mapping rule configuration information corresponding to the business scenario identifier, the target detail field is extracted from the premium detail data, the claims cost detail data, and the estimated cost detail data; Calculate the customer value score corresponding to the customer primary key identifier based on the target detail field, and return the customer value score and the target detail field to the front-end application.

2. The insurance customer value explainability assessment method according to claim 1, characterized in that, The steps for defining mapping rule configuration information for multiple insurance business scenarios include: Obtain the business scenario identifiers corresponding to multiple insurance business scenarios; For each business scenario identifier, receive at least one customer value assessment factor specified for that business scenario identifier and the data factor path corresponding to each customer value assessment factor; Each data factor path is validated for validity, including determining whether the data factor path points to an accessible field in the database that stores detailed data. The verified data factor paths are associated with and stored with the corresponding business scenario identifiers and customer value assessment factors to form mapping rule configuration information corresponding to the multiple insurance business scenarios.

3. The insurance customer value explainability assessment method of claim 1, wherein, The steps of storing customer multidimensional detailed data in a relational detailed database and establishing a cache mapping table using the customer's primary key include: In the relational detail database, a wide table is constructed using the customer's primary key identifier as a clustered index. The wide table is used to store the customer's multidimensional detail data. Write the multidimensional detailed data of each customer as a row in the wide table corresponding to the customer's primary key identifier; Determine the storage location of each record in the wide table, and associate the client primary key identifier with the corresponding storage location in the cache mapping table.

4. The insurance customer value explainability assessment method of claim 1, wherein, The steps for receiving a customer value assessment request sent by the front-end application, carrying the customer's primary key identifier and business scenario identifier, include: The system listens for and receives Hypertext Transfer Protocol (HTTP) requests sent by the front-end application through a preset application programming interface. The message body of the HTTP request contains the client primary key identifier and the business scenario identifier. The customer primary key identifier and the business scenario identifier are parsed from the message body; Verify whether the business scenario identifier belongs to a predefined set of business scenario identifiers corresponding to multiple insurance business scenarios; If the verification is successful, it is confirmed that the customer value assessment request has been received.

5. The insurance customer value explainability assessment method according to claim 4, characterized in that, The steps of reading premium details, claims cost details, and estimated cost details associated with the customer's primary key identifier from the relational detail database through the high-speed cache mapping table include: The cache mapping table is queried using the customer primary key identifier as the query condition to obtain the storage location corresponding to the customer primary key identifier; Based on the storage location, locate the record row corresponding to the customer primary key identifier in the wide table of the relational detail database; Read the premium details, claims cost details, and estimated cost details from the record row.

6. The insurance customer value explainability assessment method according to claim 5, characterized in that, The steps of extracting target detail fields from the premium detail data, the claims cost detail data, and the estimated cost detail data based on the data factor path in the mapping rule configuration information corresponding to the business scenario identifier include: The corresponding set of data factor paths is obtained from the mapping rule configuration information based on the business scenario identifier; For each data factor path in the data factor path set, extract the corresponding detailed field values ​​from the premium details data, the claims cost details data, and the estimated cost details data according to the data factor path; All extracted detail field values ​​are merged into the target detail field.

7. The insurance customer value explainability assessment method according to any one of claims 1 to 6, characterized in that, The steps of calculating the customer value score corresponding to the customer primary key identifier based on the target detail field, and returning the customer value score and the target detail field to the front-end application include: Obtain the scoring rules corresponding to the business scenario identifier; The customer value score corresponding to the customer primary key identifier is obtained by calculating the value of the detailed field in the target detailed field according to the scoring rules. The customer value score and the target detail field are encapsulated into response data, and the response data is sent to the front-end application.

8. An insurance customer value explainability assessment system, characterized by, include: The configuration module is used to define mapping rule configuration information for multiple insurance business scenarios. The mapping rule configuration information includes the data factor path required to retrieve customer value assessment factors related to the corresponding insurance business scenario from the database. A module is established to store the customer's multidimensional detailed data in a relational detailed database, and a cache mapping table is established using the customer's primary key identifier. The cache mapping table is used to point to the storage location of the corresponding customer's multidimensional detailed data in the relational detailed database. The request module is used to receive customer value assessment requests sent by the front-end application, which carry customer primary key identifiers and business scenario identifiers. The reading module is used to read premium details, claims cost details, and estimated cost details associated with the customer primary key identifier from the relational details database through the cache mapping table. The extraction module is used to extract target detail fields from the premium detail data, the claims cost detail data, and the estimated cost detail data according to the data factor path in the mapping rule configuration information corresponding to the business scenario identifier. The evaluation module is used to calculate the customer value score corresponding to the customer primary key identifier based on the target detail field, and return the customer value score and the target detail field to the front-end application.

9. An electronic device, comprising: The electronic device includes a processor coupled to a memory storing at least one computer program, which is loaded and executed by the processor to enable the electronic device to implement the insurance customer value interpretability assessment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which, when executed by a processor, implements the insurance customer value interpretability assessment method as described in any one of claims 1 to 7.

Images