Life insurance customer group screening method and device, electronic equipment and storage medium

Abstract

The invention provides a life insurance customer group screening method and device, electronic equipment and a storage medium, and the method comprises the steps: carrying out the deduplication processing, format standardization processing and abnormal value processing of a plurality of pieces of customer data information in each source system, and determining a plurality of pieces of preprocessed customer data information; performing multi-dimensional customer label construction processing on the plurality of pieces of preprocessed customer data information to generate customer label data; inputting the customer tag data into an SOLR cluster, performing distributed index construction on the customer tag data, and configuring corresponding index strategies for different field types; and after the index construction is completed, inputting a customer group screening request into the SOLR cluster, executing retrieval processing by each SOLR node, and determining target customer group information meeting the customer group screening request. Efficient retrieval under the scale of hundred million customer data is achieved, the query efficiency of customer groups is greatly improved, and quasi-real-time response is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer big data processing and information retrieval, and in particular to a life insurance customer group screening method and device, an electronic device and a storage medium. BACKGROUND

[0002] In the life insurance business scenario, the customer group is large in scale, the policy period is long, and the data structure is complex. Customer information is scattered in multiple business systems, such as a core business system (storing policies, premiums, premium payment periods, etc.), a CRM system (customer relationship management), an ECIF system (enterprise-level customer information integration platform), and a human management system (marketing employee management), etc. To support accurate marketing and customer operation, insurance companies need to build portraits based on customer characteristics and perform customer group screening to identify high-value customers, potential insurance groups, or specific behavior characteristic groups, and then carry out targeted activity pushing and marketing strategy formulation. The traditional customer group screening method mainly relies on relational databases such as Oracle or manually writes scripts to extract data through HiveSQL. However, with the total number of life insurance customers reaching 580 million, and the customer tag dimensions constantly enriching, the traditional solution faces serious bottlenecks: on the one hand, when executing multi-condition combined queries on an order of 100 million data, the response time is as long as tens of minutes or even hours, which is difficult to meet the timeliness requirements of marketing activities; on the other hand, SQL statement writing relies on technical personnel intervention, and changes in screening conditions require re-development, which has poor flexibility and cannot adapt to rapidly changing marketing needs. Therefore, there is an urgent need for a high-performance retrieval advantage technical solution to solve the problems of low query efficiency, limited screening dimensions, and insufficient flexibility in current life insurance customer group screening. SUMMARY

[0003] Therefore, the purpose of the present application is to provide a life insurance customer group screening method and device, an electronic device and a storage medium. By constructing a distributed index library based on SOLR, using its inverted index mechanism, memory caching technology and parallel query capability, efficient retrieval is achieved on an order of 100 million customer data, greatly improving the query efficiency of the customer group and realizing quasi-real-time response.

[0004] The present application provides a life insurance customer group screening method, which comprises: performing deduplication processing, format standardization processing and outlier processing on a plurality of customer data information in each source system to determine a plurality of pre-processed customer data information; performing multi-dimensional customer tag construction processing on the plurality of pre-processed customer data information to generate customer tag data; inputting the customer tag data into a SOLR cluster, constructing a distributed index for the customer tag data, and configuring a corresponding index strategy for different field types; After the index construction is completed, a customer group screening request is input into the SOLR cluster, retrieval processing is performed by each SOLR node, and target customer group information meeting the customer group screening request is determined.

[0005] In a possible implementation, the multi-dimensional customer label construction processing on the plurality of preprocessed customer data information to generate customer label data includes: Based on business analysis requirements, a multi-dimensional customer label system is designed and processed in the HIVE data warehouse according to an ODS, MID, and APP three-level data warehouse structure; the label system includes customer basic data labels, behavior attribute labels, and marketing response capability labels. The label calculation logic of the multi-dimensional customer label system is periodically executed by a batch processing task, each dimensional feature of the preprocessed customer data information is converted into a structured field, and is assigned as an enumerated type, numerical type, or Boolean type label item to generate the customer label data.

[0006] In a possible implementation, after the multi-dimensional customer label construction processing on the plurality of preprocessed customer data information to generate customer label data, the screening method further includes: Based on historical marketing activity records and customer response logs, actual conversion data of each customer group in the last or continuous multiple marketing activities is collected; the conversion data includes an activity participation state, a number of insurance policy promotions, an insurance premium contribution amount, and a response time limit. The actual conversion data is associated with the customer label data used by the corresponding customer group to determine information gain of each label item. Based on the information gain and a preset threshold, high-value labels and low-efficiency labels are identified, and a dynamic update operation of the label system is performed based on an analysis result.

[0007] In a possible implementation, the customer label data is input into the SOLR cluster, distributed index construction is performed on the customer label data, and corresponding index strategies are configured for different field types, including: The customer label data is exported as an intermediate format file and is loaded into the SOLR cluster by a batch import tool; the SOLR cluster is composed of a plurality of high-configuration servers. The customer label data is subjected to hash fragmentation processing based on customer identification, and is uniformly distributed to a plurality of SOLR nodes of a SOLR cluster to form a distributed storage structure, and a differentiated index strategy is configured for different types of label fields; wherein each SOLR node is responsible for maintaining a local inverted index of the data subset allocated thereto.

[0008] In a possible implementation, the differentiated index strategy configured for different types of label fields comprises: A range query index is enabled for a numerical field, an exact match index is enabled for an enumerated field, and a Chinese word segmentation index is enabled for a text field. In a possible implementation, after the customer label data is input into the SOLR cluster, the distributed index construction is performed on the customer label data, and a corresponding index strategy is configured for different field types, the screening method further comprises: An offline monitoring task is established to continuously monitor the change events of the customer data information, and when a label data update is detected, an incremental update process of the SOLR index is automatically triggered.

[0009] In a possible implementation, the customer group screening request is input into the SOLR cluster, and retrieval processing is performed by each SOLR node to determine target customer group information satisfying the customer group screening request, comprising: The screening conditions in the customer group screening request are automatically converted into a standard SOLR query syntax by a condition analysis engine; The converted SOLR query syntax is submitted to the SOLR cluster through an HTTP API to perform parallel retrieval, each SOLR node independently performs query tasks based on the local index, and returns customer identification satisfying the screening conditions; The customer identification of all SOLR nodes of the SOLR cluster is subjected to deduplication and sorting to generate a target customer identification set satisfying the screening conditions; Complete attribute information of customers is extracted from a customer resource library based on the target customer identification set to generate structured target customer group information.

[0010] Embodiments of the present application also provide a life insurance customer group screening device, comprising: A data preprocessing module is configured to perform deduplication processing, format standardization processing and outlier processing on a plurality of customer data information in each source system, and determine a plurality of preprocessed customer data information. A label construction module is configured to perform multi-dimensional customer label construction processing on the plurality of preprocessed customer data information, and generate customer label data. The index building module is used to input customer tag data into the SOLR cluster, build a distributed index on the customer tag data, and configure corresponding indexing strategies for different field types. The filtering module is used to input customer group filtering requests into the SOLR cluster after the index is built. Each SOLR node then performs the retrieval process to determine the target customer group information that meets the customer group filtering request.

[0011] This application also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the life insurance customer screening method described above are performed.

[0012] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the life insurance customer screening method described above.

[0013] The life insurance customer screening method, apparatus, electronic device, and storage medium provided in this application embodiment include: performing deduplication, format standardization, and outlier handling on multiple customer data information from various source systems to determine multiple preprocessed customer data information; constructing multi-dimensional customer tags on the multiple preprocessed customer data information to generate customer tag data; inputting the customer tag data into an SOLR cluster, constructing a distributed index on the customer tag data, and configuring corresponding index strategies for different field types; after completing the index construction, inputting a customer screening request into the SOLR cluster, where each SOLR node performs retrieval processing to determine the target customer group information that meets the customer screening request. By constructing a distributed index library based on SOLR, utilizing its inverted index mechanism, memory caching technology, and parallel query capabilities, efficient retrieval is achieved on a scale of hundreds of millions of customer data, significantly improving the query efficiency of customer groups and achieving near real-time response.

[0014] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a method for screening a life insurance customer group provided in an embodiment of this application; Figure 2 One of the structural schematic diagrams of a life insurance customer screening device provided in the embodiments of this application; Figure 3 A second schematic diagram of a life insurance customer screening device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0018] First, the applicable application scenarios of this application are introduced. This application can be applied to the technical field of computer big data processing and information retrieval.

[0019] Research has revealed that in the life insurance business scenario, the customer base is massive, policy cycles are long, and data structures are complex. Customer information is scattered across multiple business systems, such as core business systems (storing policies, premiums, payment periods, etc.), CRM systems (Customer Relationship Management), ECIF systems (Enterprise Customer Information Integration Platforms), and personnel management systems (salesperson management). To support precision marketing and customer operations, insurance companies need to build customer profiles based on customer characteristics and conduct customer segmentation to identify high-value customers, potential policyholders, or groups with specific behavioral characteristics, thereby enabling targeted campaign pushes and marketing strategy development. Traditional customer segmentation methods mainly rely on relational databases such as Oracle or manually written scripts using HiveSQL to extract data. However, with the total number of life insurance customers reaching 580 million and the dimensions of customer tags constantly enriching, traditional solutions face serious bottlenecks: on the one hand, when executing multi-condition combined queries on hundreds of millions of data points, the response time can be as long as tens of minutes or even hours, making it difficult to meet the timeliness requirements of marketing activities; on the other hand, SQL statement writing relies on the intervention of technical personnel, and changes in screening conditions require redevelopment, resulting in poor flexibility and an inability to adapt to rapidly changing marketing needs. Therefore, there is an urgent need for a high-performance retrieval solution to address the current problems of low query efficiency, limited filtering dimensions, and insufficient flexibility in life insurance customer screening.

[0020] Based on this, this application provides a method for screening life insurance customers. By constructing a distributed index library based on SOLR and utilizing its inverted index mechanism, memory caching technology and parallel query capabilities, it achieves efficient retrieval on a scale of hundreds of millions of customer data, significantly improves the query efficiency of customer groups, and achieves near real-time response.

[0021] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for screening a life insurance customer group, as provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the screening method includes: S101: Perform deduplication, format standardization, and outlier handling on multiple customer data information from various source systems to determine multiple preprocessed customer data information.

[0022] In this step, multiple customer data information from various source systems are deduplicated, formatted, and outliers are handled to determine multiple preprocessed customer data information.

[0023] Here, a unified data platform and various data collection tools and methods such as Sqoop and DSG+Kafka are used to connect with data from various source systems within the core system. This includes data such as the sum insured and payment period from the policy tables in the core system, customer data from the CRM and ECIF systems, and sales agent data from the personnel management system. The data is then extracted to the big data platform. The raw data is processed, including deduplication, format standardization, outlier handling, and correlation integration, to consolidate the scattered customer data within the life insurance company and build a unified customer resource database, providing a data foundation for subsequent tag extraction and index construction. S102: Perform multi-dimensional customer tag construction processing on multiple pre-processed customer data information to generate customer tag data.

[0024] In this step, multiple preprocessed customer data are processed to construct multi-dimensional customer tags, generating customer tag data.

[0025] Here, customer tagging data includes basic attribute tags, which describe the customer's natural attributes and basic identity information; behavioral attribute tags, which capture the customer's activity and preferences in digital channels and services; and marketing responsiveness tags, which reflect the customer's relationship with other entities and expand the dimensions of analysis.

[0026] In one possible implementation, the step of performing multi-dimensional customer tag construction processing on multiple preprocessed customer data information to generate customer tag data includes: (1): Based on business analysis needs, a multi-dimensional customer tag system was designed and processed in the HIVE data warehouse according to the three-layer data warehouse structure of ODS, MID and APP; wherein, the tag system includes customer basic data tags, behavioral attribute tags and marketing response capability tags.

[0027] Here, the tagging system construction process includes the following steps: 1. Data access and cleaning of the Operational Data Layer (ODS layer): Using data integration tools such as Sqoop, DSG, and Kafka, raw customer data is extracted from business source systems (including core business systems, CRM systems, ECIF customer information systems, human resources management systems, etc.) and aggregated to the HIVE ODS layer according to subject domains. This layer retains the most original state of the data and only performs basic data cleaning operations, such as null value filling, format standardization, deduplication, and outlier filtering, to ensure data integrity and consistency. At the same time, an incremental extraction mechanism is established to support daily scheduled synchronization of newly added or changed data to ensure data timeliness. 2. Data fusion and feature derivation of the intermediate integration layer (MID layer): Based on the ODS layer, the MID layer completes the cross-system data association integration and wide table construction. Based on a unified customer identifier (such as ECIF_ID), policy information (such as sum assured, payment period, product type), basic customer information (such as age, gender, occupation), behavioral data (such as insurance frequency, renewal records), and service interaction records (such as complaint history, customer service contact) scattered across different systems are aligned by primary keys and horizontally concatenated to form a fine-grained wide table of customer facts. Furthermore, preliminary feature calculations are performed at this layer, such as customer lifecycle stage segmentation (new customer, growth stage, maturity stage, decline stage), initial value assessment (based on AUM or annual premium stratification), and initial risk preference judgment, serving as the basic input for upper-layer tag processing. 3. Application Marketplace Layer (APP Layer) Tag System Modeling and Management: The APP layer is geared towards specific business scenarios, realizing the definition, generation, and output of standardized customer tags. The tag system is divided into multiple categories according to business dimensions.

[0028] (2): The tag calculation logic of the multi-dimensional customer tag system is executed periodically by batch processing tasks, and the features of each dimension of the preprocessed customer data information are converted into structured fields and assigned as enumeration type, numeric type or Boolean type tag items to generate the customer tag data.

[0029] To improve the accuracy and automation of customer profiling, this application constructs periodic batch processing tasks to systematically scan and analyze the wide customer fact table integrated into the MID layer of the HIVE data warehouse. Based on predefined tag calculation logic, the multi-source heterogeneous data features of customers are transformed into standardized and structured tag fields, and assigned as enumeration, numeric, or boolean tag items according to data type, ultimately generating a customer tag dataset that can be used for index building and querying.

[0030] This involves registering and configuring batch processing workflows in a big data scheduling platform (such as Apache Airflow), setting execution frequencies (e.g., during off-peak hours in the early morning each day), and enabling scheduled processing of full or incremental customer data. Each tag is associated with an independent calculation rule script, covering field sources, judgment conditions, value ranges, and update strategies. These rules are stored in a configurable manner in the metadata management system, allowing business personnel to flexibly adjust them according to marketing needs without modifying the underlying code. Multi-dimensional feature extraction and type mapping: After the batch processing task starts, the cleaned and integrated wide table of customer facts is loaded from the MID layer. The original feature fields contained within each item are parsed, and the data is categorized into the corresponding tag dimensions based on business semantics. For different types of features, a differentiated processing logic is used for structured transformation: For continuous numerical features (such as customer age, cumulative sum assured, annual premium, etc.), interval division or binning is performed to generate numerical labels (such as "age=45", "cumulative sum assured=800000"); For discrete categorical features (such as gender, occupation category, product preference, etc.), they are directly mapped to enumerated labels (such as "gender=male", "occupation=teacher", "main investment product=critical illness insurance"), and multi-value enumeration is supported (such as "hobbies=travel, fitness"); For binary state or conditional judgment features (such as whether health declaration has been completed, whether the most recent marketing campaign has been responded to, whether a long-term policy has been held, etc.), Boolean expressions are used to evaluate and generate Boolean labels (such as "renewed=true", "high response potential=false").

[0031] In one possible implementation, after periodically executing the tag calculation logic of the multi-dimensional customer tag system through a batch processing task to convert the various dimensional features of the preprocessed customer data information into structured fields and assigning them as enumerated, numeric, or Boolean tag items to generate the customer tag data, the filtering method further includes: A: Based on historical marketing campaign records and customer response logs, collect actual conversion data for each customer group in the most recent or consecutive marketing campaigns; among which, conversion data includes campaign participation status, number of policies converted, premium contribution amount, and response time.

[0032] Here, based on historical marketing campaign records and customer response logs, we collect actual conversion data for each customer group in the most recent or consecutive marketing campaigns.

[0033] B: Perform correlation analysis between the actual conversion data and the customer tag data used by the corresponding customer groups to determine the information gain of each tag item.

[0034] Here, based on the principles of information theory, entropy is used to measure the uncertainty of customer group conversion status. First, the initial entropy of conversion categories in the overall sample set is calculated; then, for each tag, customer subsets are divided according to their different values, and the conditional entropy is calculated separately, finally yielding the information gain of that tag.

[0035] C: Based on the information gain and preset threshold, identify high-value tags and inefficient tags, and perform dynamic update operation of the tag system based on the analysis results.

[0036] Here, if the information gain of a tag is greater than or equal to the high-value threshold, it is marked as a "high-value tag" and included in the key recommendation list for priority screening suggestions in similar scenarios. If the information gain of a tag is less than or equal to the low-efficiency threshold and remains low for several consecutive periods, it is marked as an "inefficient tag," indicating that it may have lost its business distinguishing significance or has insufficient data coverage. For tags in the middle range, they are kept under observation, and their trend changes are continuously tracked. Tag management suggestions are automatically generated based on the classification results. For example, for newly added or adjusted high-value tags, their metadata definitions are updated in the HIVE APP layer tag model and synchronized to the SOLR index field configuration. For inefficient tags that are confirmed to be offline, the corresponding fields are removed from the tag wide table (or marked as "invalid"), their calculation logic in batch processing tasks is stopped, and computing resources are released. After the update is completed, the tag dictionary cache of the SOLR query engine is reloaded to ensure that the front-end filtering function reflects the latest tag set in real time.

[0037] S103: Input customer tag data into the SOLR cluster, construct a distributed index for the customer tag data, and configure corresponding index strategies for different field types.

[0038] In this step, customer tag data is input into the SOLR cluster, a distributed index is built on the customer tag data, and corresponding indexing strategies are configured for different field types.

[0039] In one possible implementation, the step of inputting customer tag data into the SOLR cluster, constructing a distributed index for the customer tag data, and configuring corresponding indexing strategies for different field types includes: a: Export the customer tag data as an intermediate format file and load it into the SOLR cluster using a batch import tool; wherein, the SOLR cluster consists of multiple high-configuration servers.

[0040] b: Perform hash sharding on customer tag data based on customer identifiers, and distribute the customer tag data evenly across multiple SOLR nodes in the SOLR cluster to form a distributed storage structure, and configure differentiated indexing strategies for different types of tag fields; wherein, each SOLR node is responsible for maintaining the local inverted index of its allocated data subset. Here, the customer's unique identifier field (ECIF_ID) is used as the shard key. A consistent hashing algorithm is used to calculate its corresponding hash value, and data is mapped to specific SOLR nodes according to a preset number of shards (e.g., 10 shards). This sharding strategy ensures that customer records with the same ECIF_ID are always routed to the same physical node, guaranteeing data locality. Simultaneously, due to the good dispersion of ECIF_ID, the overall data is evenly distributed across nodes, avoiding hotspot issues and achieving load balancing. The SOLR cluster consists of multiple SOLR nodes, each running an independent SolrServer instance and hosting one or more logical shards. Subsets of customer tag data after hash sharding are written to the corresponding SOLR node's Core, forming a physically distributed but logically unified distributed document collection. The cluster uses ZooKeeper for metadata coordination and automatic failover, ensuring high availability and scalability of the system.

[0041] In one possible implementation, configuring differentiated indexing strategies for different types of tag fields includes: enabling range query indexes for numeric fields, enabling exact match indexes for enumerated fields, and enabling Chinese word segmentation indexes for text fields.

[0042] Here, for fields with different semantic types in customer tag data, corresponding SOLR field types are defined and matching index optimization mechanisms are enabled: For numeric tags (such as age, cumulative sum assured, annual premium, etc.), the field type is set to `int` or `long`, and range indexing is enabled to support efficient execution of filtering conditions such as "greater than", "less than", and "within a range"; For enumerated tags (such as gender, occupation category, product preference, etc.), the field type is set to `string`, normalization is disabled (omitNorms="true"), and exact match indexing is enabled to improve the efficiency of equality queries; For multi-value tags (such as hobbies, product list, etc.), the field type is set to `strings` (multiValued="true"), supporting the storage of multiple values ​​in one field, and allowing the use of "containing any one item" or "containing all items" logical judgments during queries; For text tags (such as occupation descriptions, health notes, and other unstructured information), the field type is set to `text_ik`, integrating a Chinese word segmentation plugin (IK). The Analyzer class builds a word segmentation inverted index, supporting fuzzy matching, keyword extraction, and full-text search. For boolean tags (such as "whether to renew insurance" or "whether to respond to marketing"), the field type is set to `boolean` to quickly filter customer groups that meet specific statuses.

[0043] In one possible implementation, after inputting customer tag data into the SOLR cluster, constructing a distributed index for the customer tag data, and configuring corresponding indexing strategies for different field types, the filtering method further includes: Establish an offline monitoring task to continuously listen for changes in customer data. When a tag data update is detected, the incremental update process of the SOLR index will be automatically triggered.

[0044] Here, a scheduled batch processing task monitors changes to customer tag data in HIVE, identifying newly added, modified, or deleted customer records. The Real-Time Get and Update Request Handler interfaces provided by SOLR enable precise push of incremental data and index updates. During the update process, query services remain uninterrupted, ensuring index real-time performance and business continuity.

[0045] This application employs an offline incremental update mechanism, combined with data synchronization tools such as Kafka and Sqoop, to periodically detect changes in the source system and trigger incremental updates to the SOLR index, ensuring the timeliness and consistency of customer tag data. Simultaneously, the SOLR cluster utilizes a sharded deployment architecture, providing excellent fault tolerance; a single node failure does not affect overall service availability, significantly enhancing system stability.

[0046] S104: After the index construction is completed, the customer group screening request is input into the SOLR cluster, and each SOLR node performs the retrieval process to determine the target customer group information that meets the customer group screening request.

[0047] In this step, after the index is built, the customer group screening request is input into the SOLR cluster, and each SOLR node performs the retrieval process to determine the target customer group information that meets the customer group screening request.

[0048] In one possible implementation, the step of inputting the customer screening request into the SOLR cluster, whereby each SOLR node performs a retrieval process to determine the target customer group information that meets the customer screening request, includes: I: The filtering conditions in the customer group filtering request are automatically converted into standard SOLR query syntax through the condition parsing engine.

[0049] Here, a visual interface for customer segmentation is developed in the CRM and customer management system, allowing marketers to set filtering conditions through "point selection + input". These conditions include basic conditions, enumeration labels, range labels, multi-value labels, and logical combination areas (multiple combinations of AND, OR, and NOT). For nested logic (such as parenthesis priority), multiple negations (NOT operation), or multi-value matching (IN set), the parsing engine uses an abstract syntax tree (AST) for recursive parsing to ensure logical integrity and conversion accuracy.

[0050] II: Submit the converted SOLR query syntax to the SOLR cluster via HTTP API for parallel retrieval. Each SOLR node independently executes the query task based on its local index and returns customer identifiers that meet the filtering criteria.

[0051] Here, the transformed SOLR query statement is submitted to the query coordinating node of the SOLR cluster via the HTTP API protocol. The cluster broadcasts the query request to all relevant SOLR nodes according to a predefined sharding strategy (based on ECIF_ID hash distribution). Each SOLR node independently executes the query task on its maintained local inverted index, utilizing optimization mechanisms such as memory caching, range indexes, and token matching to quickly locate documents (i.e., customer records) that meet the conditions, and returns a list of unique identifiers (ECIF_ID) for the corresponding customer and the total number of documents that match.

[0052] III: After deduplicating and sorting the customer identifiers of all SOLR nodes in the SOLR cluster, a set of target customer identifiers that meet the filtering conditions is generated.

[0053] Here, after each SOLR node completes its local retrieval, it sends its result set to the coordinating node for unified aggregation. The coordinating node performs deduplication processing on all received ECIF_ID lists (e.g., using a Bloom filter or sort-merge algorithm) to eliminate duplicates caused by data redundancy or query broadcasting, and performs sorting operations according to business needs (e.g., ascending by customer ID or descending by match score). Finally, a globally unique set of target customer identifiers that meets all filtering criteria is generated, serving as the basic input for subsequent data completion. IV: Based on the target customer identifier set, extract complete customer attribute information from the customer resource database to generate structured target customer group information.

[0054] Here, based on the obtained target customer identifier set, the system uses a high-performance data interface to access the customer resource database stored in HIVE or a real-time database. It then batch-associates and extracts all customer attribute information based on the ECIF_ID primary key, including but not limited to: basic information (name, gender, date of birth), policy details (coverage amount, payment period, effective status), contact information (phone number, address), and service history (complaint records, number of claims). This information is then formatted and integrated to generate a complete, structured target customer information file, supporting multiple export formats (such as Excel and CSV) and pushed to a CRM system or marketing campaign management platform for subsequent targeted outreach, campaign organization, or data analysis.

[0055] In this application, a distributed indexing system was constructed by introducing the SOLR full-text search engine. Utilizing inverted indexing, memory caching technology, and parallel computing capabilities, efficient retrieval of hundreds of millions of life insurance customer data was achieved. In complex multi-condition query scenarios, the response time for queries involving millions of data points was reduced to seconds, and filtering of billions of data points could be completed within minutes. This represents a qualitative leap in query efficiency compared to the previous time-consuming or even impossible queries, significantly improving the timeliness of marketing campaign preparation.

[0056] This application achieves a seamless transition from "human-computer interaction configuration" to "automatic machine execution," significantly improving the response speed and result availability for complex screening tasks in environments with hundreds of millions of customers. The solution fully leverages SOLR's advantages in full-text search and distributed computing, combined with the capabilities of the backend data platform, to construct a highly efficient, accurate, and easily scalable closed-loop system for life insurance customer screening.

[0057] This application provides a method for screening life insurance customers. The screening method includes: performing deduplication, format standardization, and outlier handling on multiple customer data information from various source systems to determine multiple preprocessed customer data information; constructing multi-dimensional customer tags on the multiple preprocessed customer data information to generate customer tag data; inputting the customer tag data into a SOLR cluster, constructing a distributed index on the customer tag data, and configuring corresponding index strategies for different field types; after completing the index construction, inputting a customer screening request into the SOLR cluster, where each SOLR node performs retrieval processing to determine the target customer group information that meets the customer screening request. By constructing a distributed index library based on SOLR, utilizing its inverted index mechanism, memory caching technology, and parallel query capabilities, efficient retrieval is achieved on a scale of hundreds of millions of customer data, significantly improving the query efficiency of customer groups and achieving near real-time response.

[0058] Please see Figure 2 , Figure 3 , Figure 2 One of the structural schematic diagrams of a life insurance customer screening device provided in the embodiments of this application; Figure 3 This is a second schematic diagram of a life insurance customer screening device provided in an embodiment of this application. Figure 2 As shown, the screening device 200 includes: The data preprocessing module 210 is used to perform deduplication, format standardization, and outlier handling on multiple customer data information from various source systems, and to determine multiple preprocessed customer data information. The tag building module 220 is used to perform multi-dimensional customer tag building processing on multiple pre-processed customer data information to generate customer tag data. The index building module 230 is used to input customer tag data into the SOLR cluster, build a distributed index on the customer tag data, and configure corresponding index strategies for different field types. The filtering module 240 is used to input customer group filtering requests into the SOLR cluster after completing the index construction, and each SOLR node performs retrieval processing to determine the target customer group information that meets the customer group filtering request.

[0059] Furthermore, the tag construction module 220 is used to perform multi-dimensional customer tag construction processing on multiple preprocessed customer data information to generate customer tag data: Based on business analysis needs, a multi-dimensional customer tagging system was designed and processed in the HIVE data warehouse according to a three-tier data warehouse structure of ODS, MID, and APP; the tagging system includes basic customer data tags, behavioral attribute tags, and marketing response capability tags. The batch processing task periodically executes the tag calculation logic of the multi-dimensional customer tag system, transforms the features of each dimension of the preprocessed customer data information into structured fields, and assigns them as enumeration type, numeric type or Boolean type tag items to generate the customer tag data.

[0060] Furthermore, such as Figure 3 As shown, the screening device 200 also includes an update module 250, which is used for: Based on historical marketing campaign records and customer response logs, actual conversion data for each customer group in the most recent or consecutive marketing campaigns is collected; among which, conversion data includes campaign participation status, number of policies converted, premium contribution amount, and response time. The actual conversion data is correlated with the customer tag data used by the corresponding customer groups to determine the information gain of each tag item. Based on the information gain and preset threshold, high-value tags and inefficient tags are identified, and dynamic updates of the tag system are performed based on the analysis results. Furthermore, the index building module 230 is used to input customer tag data into the SOLR cluster, perform distributed index building on the customer tag data, and configure corresponding indexing strategies for different field types: The customer tag data is exported as an intermediate format file and loaded into the SOLR cluster using a batch import tool; wherein, the SOLR cluster consists of multiple high-configuration servers; Based on the customer identifier, the customer tag data is hashed and sharded, and the customer tag data is evenly distributed across multiple SOLR nodes in the SOLR cluster to form a distributed storage structure. Differentiated indexing strategies are configured for different types of tag fields. Each SOLR node is responsible for maintaining a local inverted index of its allocated data subset.

[0061] Furthermore, the update module 250 is also used for: Establish an offline monitoring task to continuously listen for changes in customer data. When a tag data update is detected, the incremental update process of the SOLR index will be automatically triggered.

[0062] Furthermore, the filtering module 340 is used to input the customer group filtering request into the SOLR cluster, whereby each SOLR node performs retrieval processing to determine the target customer group information that meets the customer group filtering request. The condition parsing engine automatically converts the filtering conditions in the customer group filtering request into standard SOLR query syntax. The converted SOLR query syntax is submitted to the SOLR cluster via HTTP API for parallel retrieval. Each SOLR node independently executes the query task based on its local index and returns the customer identifier that meets the filtering criteria. After deduplication and sorting of the customer identifiers of all SOLR nodes in the SOLR cluster, a set of target customer identifiers that meet the filtering criteria is generated. Based on the target customer identifier set, complete customer attribute information is extracted from the customer resource database to generate structured target customer group information.

[0063] This application provides a life insurance customer screening device, comprising: a data preprocessing module for deduplication, format standardization, and outlier handling of multiple customer data from various source systems to determine multiple preprocessed customer data; a tag construction module for constructing multi-dimensional customer tags from the multiple preprocessed customer data to generate customer tag data; an index building module for inputting the customer tag data into a SOLR cluster, constructing a distributed index on the customer tag data, and configuring corresponding indexing strategies for different field types; and a screening module for inputting customer screening requests into the SOLR cluster after completing the index construction, whereby each SOLR node performs retrieval processing to determine the target customer information that meets the customer screening request. By constructing a distributed index based on SOLR, utilizing its inverted index mechanism, memory caching technology, and parallel query capabilities, efficient retrieval is achieved on a scale of hundreds of millions of customer data, significantly improving the query efficiency of customer groups and achieving near real-time response.

[0064] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0065] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, they can perform the operations described above. Figure 1 The steps of the life insurance customer screening method in the method embodiment can be found in the method embodiment for specific implementation, and will not be repeated here.

[0066] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the life insurance customer screening method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0067] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0068] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0069] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0070] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0071] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0072] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for screening life insurance customer groups, characterized in that, The screening method includes: The system performs deduplication, format standardization, and outlier handling on multiple customer data from various source systems to identify multiple pre-processed customer data. Multiple preprocessed customer data are processed to construct multi-dimensional customer tags, generating customer tag data; Customer tag data is input into the SOLR cluster, a distributed index is built on the customer tag data, and corresponding indexing strategies are configured for different field types; After the index is built, the customer group screening request is input into the SOLR cluster, and each SOLR node performs the retrieval process to determine the target customer group information that meets the customer group screening request.

2. The screening method according to claim 1, characterized in that, The process of constructing multi-dimensional customer tags from multiple preprocessed customer data to generate customer tag data includes: Based on business analysis needs, a multi-dimensional customer tagging system was designed and processed in the HIVE data warehouse according to a three-tier data warehouse structure of ODS, MID, and APP; the tagging system includes basic customer data tags, behavioral attribute tags, and marketing response capability tags. The batch processing task periodically executes the tag calculation logic of the multi-dimensional customer tag system, transforms the features of each dimension of the preprocessed customer data information into structured fields, and assigns them as enumeration type, numeric type or Boolean type tag items to generate the customer tag data.

3. The screening method according to claim 2, characterized in that, The step of periodically executing the tag calculation logic of the multi-dimensional customer tag system through batch processing tasks, converting the multi-dimensional features of the preprocessed customer data information into structured fields, and assigning them as enumerated, numeric, or Boolean tag items to generate the customer tag data, further includes the following filtering method: Based on historical marketing campaign records and customer response logs, actual conversion data for each customer group in the most recent or consecutive marketing campaigns is collected; among which, conversion data includes campaign participation status, number of policies converted, premium contribution amount, and response time. The actual conversion data is correlated with the customer tag data used by the corresponding customer groups to determine the information gain of each tag item. Based on the information gain and preset threshold, high-value tags and inefficient tags are identified, and dynamic updates of the tag system are performed based on the analysis results.

4. The screening method according to claim 1, characterized in that, The process of inputting customer tag data into the SOLR cluster, constructing a distributed index for the customer tag data, and configuring corresponding indexing strategies for different field types includes: The customer tag data is exported as an intermediate format file and loaded into the SOLR cluster using a batch import tool; wherein, the SOLR cluster consists of multiple high-configuration servers; Based on the customer identifier, the customer tag data is hashed and sharded, and the customer tag data is evenly distributed across multiple SOLR nodes in the SOLR cluster to form a distributed storage structure. Differentiated indexing strategies are configured for different types of tag fields. Each SOLR node is responsible for maintaining a local inverted index of its allocated data subset.

5. The screening method according to claim 4, characterized in that, The differentiated indexing strategy configured for different types of tag fields includes: Enable range query indexes for numeric fields, exact match indexes for enumeration fields, and Chinese word segmentation indexes for text fields.

6. The screening method according to claim 1, characterized in that, After inputting customer tag data into the SOLR cluster, constructing a distributed index for the customer tag data, and configuring corresponding indexing strategies for different field types, the filtering method further includes: Establish an offline monitoring task to continuously listen for changes in customer data. When a tag data update is detected, the incremental update process of the SOLR index will be automatically triggered.

7. The screening method according to claim 1, characterized in that, The process of inputting customer group screening requests into the SOLR cluster, whereby each SOLR node performs retrieval processing to determine target customer group information that meets the customer group screening requests, includes: The condition parsing engine automatically converts the filtering conditions in the customer group filtering request into standard SOLR query syntax. The converted SOLR query syntax is submitted to the SOLR cluster via HTTP API for parallel retrieval. Each SOLR node independently executes the query task based on its local index and returns the customer identifier that meets the filtering criteria. After deduplication and sorting of the customer identifiers of all SOLR nodes in the SOLR cluster, a set of target customer identifiers that meet the filtering criteria is generated. Based on the target customer identifier set, complete attribute information of customers is extracted from the customer resource database to generate structured target customer group information.

8. A device for screening life insurance customers, characterized in that, The screening device includes: The data preprocessing module is used to perform deduplication, format standardization, and outlier handling on multiple customer data information from various source systems, and to determine multiple preprocessed customer data information. The tag building module is used to perform multi-dimensional customer tag building on multiple pre-processed customer data information to generate customer tag data. The index building module is used to input customer tag data into the SOLR cluster, build a distributed index on the customer tag data, and configure corresponding indexing strategies for different field types. The filtering module is used to input customer group filtering requests into the SOLR cluster after the index is built. Each SOLR node then performs the retrieval process to determine the target customer group information that meets the customer group filtering request.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the life insurance customer screening 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 a computer program that, when executed by a processor, performs the steps of the life insurance customer screening method as described in any one of claims 1 to 7.

Images