Insurance service push method, electronic device, and storage medium

Abstract

The present application relates to the fields of insurance and data processing technology, and in particular to an insurance service push method, electronic device, and storage medium. According to the insurance service push method of the embodiment of the present application, it is necessary to first obtain historical service usage records corresponding to a variety of insurance service types; wherein, insurance service types include insurance native services and insurance derivative services; then, according to each historical service usage record, configure service feature parsing information for the corresponding insurance service type; according to each insurance service type and the service feature parsing information corresponding to each insurance service type, generate service feature display information; based on the service feature display information, perform a push operation on the insurance native service or insurance derivative service. In this way, a synergistic effect can be generated between the insurance native service and the insurance derivative service, thereby improving the efficiency and effectiveness of insurance service push.

Description

Technical Field

[0001] The present application relates to the fields of insurance and data processing technology, and in particular to an insurance service push method, electronic device, and storage medium. Background Art

[0002] Currently, the insurance industry's services are no longer limited to policy-specific services such as underwriting, underwriting, and claims payments. As the times change, the insurance industry's services are gradually expanding into various fields, generating a host of additional insurance derivative services. These insurance derivative services refer to services derived from the policy content, such as elderly care, critical illness testing, home care, and outpatient medical treatment.

[0003] In related technologies, a wide variety of insurance derivative services and native insurance services are provided by separate insurance service departments, without a unified service system. Consequently, there is a lack of synergy between insurance services, making it difficult to form a comprehensive service framework, which in turn hinders users' understanding and use of various insurance services. Therefore, improving the quality and efficiency of insurance service delivery remains a pressing issue in the industry. Summary of the Invention

[0004] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes an insurance service push method, electronic device, and storage medium, which can improve the push quality and push efficiency of insurance services.

[0005] According to the first embodiment of the present application, the insurance service push method includes:

[0006] Obtaining historical service usage records corresponding to multiple insurance service types; wherein the insurance service types include insurance native services and insurance derivative services;

[0007] According to each of the historical service usage records, configuring service feature parsing information for the corresponding insurance service type;

[0008] generating service feature display information according to each of the insurance service types and the service feature parsing information corresponding to each of the insurance service types;

[0009] Based on the service feature display information, a push operation is performed on the insurance native service or the insurance derivative service.

[0010] According to some embodiments of the present application, configuring service feature parsing information for the corresponding insurance service type based on each historical service usage record includes:

[0011] Based on a plurality of preset service feature dimensions, extracting corresponding service feature sub-information from the historical service usage records;

[0012] The service feature sub-information corresponding to each of the service feature dimensions is integrated to obtain the service feature parsing information corresponding to the insurance service type.

[0013] According to some embodiments of the present application, the service feature dimension includes a service frequency dimension, a service attribute dimension, and a service time dimension. The extracting corresponding service feature sub-information from the historical service usage record based on multiple preset service feature dimensions includes:

[0014] Extracting the service usage frequency corresponding to the insurance service type from the historical service usage record as the service feature sub-information of the service frequency dimension;

[0015] Extracting service usage attribute information corresponding to the insurance service type from the historical service usage record as the service feature sub-information of the service attribute dimension;

[0016] The service usage time distribution corresponding to the insurance service type is extracted from the historical service usage record as the service feature sub-information of the service time dimension.

[0017] According to some embodiments of the present application, generating service feature display information according to each insurance service type and the service feature parsing information corresponding to each insurance service type includes:

[0018] Based on the plurality of service feature parsing information, each insurance service type is compared in each service feature dimension to obtain service comparison reference data matching each service feature dimension;

[0019] The service feature display information is generated according to the service comparison reference data of each of the service feature dimensions.

[0020] According to some embodiments of the present application, generating the service feature display information based on the service comparison reference data of each service feature dimension includes:

[0021] In response to the service feature dimension being a service frequency dimension, selecting a first number of high-frequency service types from the plurality of insurance service types based on the service comparison reference data of the service frequency dimension;

[0022] The service feature display information is generated based on a first number of the high-frequency service types.

[0023] According to some embodiments of the present application, generating the service feature display information based on the service comparison reference data of each service feature dimension includes:

[0024] In response to the service feature dimension being a service attribute dimension, selecting a second number of value-added service types from the plurality of insurance service types based on the service comparison reference data of the service attribute dimension;

[0025] The service feature display information is generated based on the second number of the value-added service types.

[0026] According to some embodiments of the present application, generating the service feature display information based on the service comparison reference data of each service feature dimension includes:

[0027] In response to the service feature dimension being a service time dimension, the plurality of insurance service types are divided into a third number of service time groups based on the service comparison reference data of the service time dimension; wherein the insurance service types in the same service time group have the same service usage time distribution;

[0028] The service feature display information is generated based on a third number of the service time groups and the insurance service type in each of the service time groups.

[0029] According to some embodiments of the present application, obtaining historical service usage records corresponding to multiple insurance service types includes:

[0030] Get the insurance service push request and push object tag;

[0031] In response to the insurance service push request, performing an object rights query in a real-time updated insurance business database according to the push object tag to determine the multiple insurance service types that match the push object tag;

[0032] In the insurance business database, historical service usage records corresponding to the multiple insurance service types are retrieved.

[0033] In a second aspect, an embodiment of the present application provides an electronic device comprising: a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the insurance service push method as described in any one of the embodiments of the first aspect of the present application.

[0034] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a program, and the program is executed by a processor to implement the insurance service push method as described in any one of the embodiments of the first aspect of the present application.

[0035] The insurance service push method, electronic device, and storage medium according to the embodiments of the present application have at least the following beneficial effects:

[0036] According to the insurance service push method of the embodiment of the present application, it is necessary to first obtain historical service usage records corresponding to multiple insurance service types; wherein the insurance service types include insurance native services and insurance derivative services; then, based on each historical service usage record, configure service feature parsing information for the corresponding insurance service type; generate service feature display information based on each insurance service type and the service feature parsing information corresponding to each insurance service type; and based on the service feature display information, perform a push operation on the insurance native service or insurance derivative service. In this way, a synergistic effect can be generated between the insurance native service and the insurance derivative service, thereby improving the efficiency and effectiveness of insurance service push.

[0037] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become obvious from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0039] Figure 1 A flowchart of the insurance service push method provided in an embodiment of the present application;

[0040] Figure 2 For the embodiment of this application Figure 1 A flow chart of step S101;

[0041] Figure 3 For the embodiment of this application Figure 1 A schematic flow chart of step S102;

[0042] Figure 4 For the embodiment of this application Figure 3 A schematic flow chart of step S301;

[0043] Figure 5 For the embodiment of this application Figure 4 A schematic flow chart of step S103;

[0044] Figure 6 For the embodiment of this application Figure 5 A flow chart of step S502;

[0045] Figure 7 For the embodiment of this application Figure 5 Another flow chart of step S502;

[0046] Figure 8 For the embodiment of this application Figure 5 Another flow chart of step S502;

[0047] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The following describes in detail embodiments of the present application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application and are not to be construed as limiting the present application.

[0049] In the description of this application, "several" means one or more, "many" means more than two, "greater than," "less than," and "exceed" are understood to exclude the number itself, while "above," "below," and "within" are understood to include the number itself. The terms "first" and "second" are used solely to distinguish technical features and are not to be construed as indicating or implying relative importance, or as implicitly specifying the number or order of the technical features indicated.

[0050] In the description of this application, it should be understood that descriptions involving orientations, such as up, down, left, right, front, and back, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, they cannot be understood as limitations on this application.

[0051] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0052] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "set," "install," and "connect" should be understood in a broad sense, and those skilled in the art can reasonably determine the specific meanings of the above terms in this application based on the specific content of the technical solution. In addition, the identification of specific steps below does not represent a limitation on the order of steps and execution logic. The execution order and execution logic between each step should be understood and inferred with reference to the content described in the embodiments.

[0053] It should be noted that in each specific embodiment of the present application, when it comes to the need to perform relevant processing based on data related to the user's identity or characteristics, such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first, and the collection, use, and processing of such data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0054] Currently, the insurance industry's services are no longer limited to policy-specific services such as underwriting, underwriting, and claims payments. As the times change, the insurance industry's services are gradually expanding into various fields, generating a host of additional insurance derivative services. These insurance derivative services refer to services derived from the policy content, such as elderly care, critical illness testing, home care, and outpatient medical treatment.

[0055] In related technologies, a wide variety of insurance derivative services and native insurance services are provided by separate insurance service departments, without a unified service system. Consequently, there is a lack of synergy between insurance services, making it difficult to form a comprehensive service framework, which in turn hinders users' understanding and use of various insurance services. Therefore, improving the quality and efficiency of insurance service delivery remains a pressing issue in the industry.

[0056] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes an insurance service push method, electronic device, and storage medium, which can improve the push quality and push efficiency of insurance services.

[0057] The following is a further explanation based on the accompanying drawings.

[0058] Reference Figure 1 The insurance service push method according to the embodiment of the present application may include:

[0059] Step S101: Acquire historical service usage records corresponding to multiple insurance service types; wherein the insurance service types include insurance native services and insurance derivative services;

[0060] Step S102, configuring service feature parsing information for the corresponding insurance service type based on each historical service usage record;

[0061] Step S103, generating service feature display information based on each insurance service type and the service feature parsing information corresponding to each insurance service type;

[0062] Step S104: Based on the service feature display information, a push operation is performed on the insurance native service or the insurance derivative service.

[0063] In order to solve the problem of low service push efficiency in the insurance industry, especially when there is a lack of synergy between insurance derivative services and insurance native services, the embodiment of the present application adopts a systematic insurance service push method to improve the push efficiency of insurance services.

[0064] The insurance service push method of the embodiment of the present application first collects and analyzes historical service usage records related to multiple target service insurance types. These historical service usage records include both traditional insurance native services, such as underwriting, underwriting, and compensation, as well as insurance derivative services, such as pension, serious illness detection, home care, and outpatient medical treatment. It should be pointed out that these historical service usage records reflect the customer's usage habits and preferences for different types of insurance services. Next, for each historical service usage record, the embodiment of the present application will configure service feature analysis information, such as the frequency of use of different insurance service types, user satisfaction, service usage time distribution, and service satisfaction. These service feature analysis information can reflect the key features and performance indicators of different insurance service types.

[0065] Furthermore, the embodiment of the present application generates service feature display information based on the service feature parsing information. The service feature display information can present the characteristics of different insurance service types in an intuitive manner.

[0066] Finally, based on these service feature display information, the embodiment of the present application can perform push operations on insurance native services or insurance derivative services. This means that the push operations performed on insurance native services or insurance derivative services are closely related to information such as the customer's service usage history, preferences, and user feedback. Therefore, the embodiment of the present application can push the most relevant and most likely to arouse the customer's interest in insurance native services or insurance derivative services to the customer in a personalized manner. For example, if the service feature display information shows that a customer frequently uses outpatient medical services, the embodiment of the present application can push insurance derivative services related to health management plans or specific disease prevention to the customer.

[0067] Based on this, the service push method of the embodiment of the present application can enhance the personalization of insurance service push, thereby improving the push quality and push efficiency of insurance services.

[0068] In some embodiments, step S101 is to obtain historical service usage records corresponding to multiple insurance service types, wherein the insurance service types include insurance native services and insurance derivative services;

[0069] It should be noted that insurance services include both primary and derivative services. Primary services refer to basic services directly related to the insurance contract, such as underwriting, underwriting, and claims payments. These services are the core of the insurance business. Derivative services, on the other hand, are additional services derived from the policy content, such as elderly care services, critical illness testing, home care, and outpatient medical treatment. These services are designed to provide users with more comprehensive protection and support.

[0070] In actual operation, embodiments of the present application can extract relevant historical service usage records from a pre-established user relationship management system, claims system, or service record database. These historical service usage records may include information such as the user's usage of various services over a period of time, the frequency of services, user feedback, and satisfaction. By collecting these historical service usage records, embodiments of the present application can gain deep insights into user behavior, understand which services are favored by users, which services are used less frequently, and how satisfied users are with different services.

[0071] Reference Figure 2 According to some embodiments of the present application, step S101 of obtaining historical service usage records corresponding to multiple insurance service types may include:

[0072] Step S201: Obtain an insurance service push request and a push object tag;

[0073] Step S202: In response to the insurance service push request, an object rights query is performed in a real-time updated insurance business database based on the push object tag to determine multiple insurance service types that match the push object tag;

[0074] Step S203: retrieve historical service usage records corresponding to multiple insurance service types from the insurance business database.

[0075] According to some embodiments of the present application, the process of obtaining historical service usage records corresponding to multiple insurance service types involves a series of specific operational steps.

[0076] In some embodiments, step S201 is to obtain an insurance service push request and a push object tag;

[0077] It should be noted that insurance service push requests are intended to push certain insurance services to a specific user group. The push target tag is an information tag used to identify the target user group. Specifically, it may include user profile characteristics, insurance purchase history, claims records, or other attribute information tags related to insurance services.

[0078] In step S202 of some embodiments, in response to the insurance service push request, an object rights query is performed in a real-time updated insurance business database based on the push object tag to determine a plurality of insurance service types that match the push object tag;

[0079] It should be noted that object rights and interests are queried in the insurance business database that is updated in real time based on the pushed object tag. The purpose of this step is to determine the multiple insurance service types that match the pushed object tag. It should be noted that the insurance business database that is updated in real time contains the latest user information and insurance service data, so that the embodiment of the present application can accurately identify user groups that meet specific tags and determine the types of insurance services that these user groups may be interested in, whether they are insurance native services or insurance derivative services.

[0080] In step S203 of some embodiments, historical service usage records corresponding to multiple insurance service types are retrieved from an insurance business database.

[0081] It should be noted that embodiments of the present application can retrieve historical service usage records corresponding to these insurance service types from the insurance business database. These historical service usage records can include detailed information about a user's past use of various insurance service types, such as the number of times a service was used, the duration of use, and service satisfaction scores. By analyzing these historical service usage records, embodiments of the present application can gain a deeper understanding of user service preferences and behavior patterns, which is crucial for developing effective service delivery strategies.

[0082] The embodiment of the present application shown in steps S201 to S203 can ensure the accuracy and personalization of service push, while improving the efficiency and effectiveness of service push.

[0083] In step S102 of some embodiments, service feature parsing information is configured for the corresponding insurance service type based on each historical service usage record;

[0084] In some embodiments, step S102 involves conducting an in-depth analysis of each historical service usage record and configuring service feature analysis information for the corresponding insurance service type. This process aims to extract valuable information from historical data to better understand service usage and user preferences. This service feature analysis information may include, but is not limited to, key metrics such as service usage frequency, user groups, time distribution, user feedback, and satisfaction.

[0085] Specifically, the embodiments of the present application can perform detailed feature extraction and analysis on historical service usage records of various insurance service types.

[0086] For example, for the claims service in insurance native services, the service feature analysis information may include the average claims time, the distribution of claims amount, the frequency of claims requests, etc.

[0087] For another example, for insurance-derived services such as home care, service feature analysis information may include service usage frequency, user evaluation of the service personnel's professionalism, convenience of service appointments, etc. By analyzing this service feature analysis information, embodiments of the present application can identify the characteristics corresponding to various insurance service types.

[0088] In some more specific embodiments, the process of configuring service feature parsing information may involve the application of data mining and machine learning. It should be understood that data mining and machine learning can help the embodiments of the present application identify valuable information from a large amount of historical service usage records.

[0089] Reference Figure 3 According to some embodiments of the present application, step S102 configures service feature parsing information for the corresponding insurance service type based on each historical service usage record, which may include:

[0090] Step S301: extracting corresponding service feature sub-information from historical service usage records based on multiple preset service feature dimensions;

[0091] Step S302 : Integrate the service feature sub-information corresponding to each service feature dimension to obtain service feature parsing information corresponding to the insurance service type.

[0092] In step S301 of some embodiments, corresponding service feature sub-information is extracted from historical service usage records based on a plurality of preset service feature dimensions;

[0093] It should be noted that the preset service feature dimensions may include frequency of service usage, user satisfaction, service response time, seasonal variations in service usage, demographic characteristics of the user group, etc. For each service feature dimension, embodiments of the present application extract data related to these dimensions from historical service usage records. For example, for home care services, service feature sub-information of service feature dimensions such as the number of service uses, user satisfaction ratings, and wait times for service appointments can be extracted from historical service usage records. It should be understood that this service feature sub-information can be used to generate service feature display information in subsequent steps, providing detailed information related to service performance and user feedback.

[0094] Reference Figure 4 According to some embodiments of the present application, the service feature dimensions include a service frequency dimension, a service attribute dimension, and a service time dimension. Step S301 extracts corresponding service feature sub-information from historical service usage records based on multiple preset service feature dimensions, which may include:

[0095] Step S401: extracting the service usage frequency corresponding to the insurance service type from the historical service usage records as the service feature sub-information in the service frequency dimension;

[0096] Step S402: extracting service usage attribute information corresponding to the insurance service type from the historical service usage records as service feature sub-information in the service attribute dimension;

[0097] Step S403: extract the service usage time distribution corresponding to the insurance service type from the historical service usage records as the service feature sub-information in the service time dimension.

[0098] In some embodiments of the present application, extracting corresponding service feature sub-information from historical service usage records can be done by considering multiple service feature dimensions, including service frequency, service attribute, and service time. Such classification helps to gain a deeper understanding of the usage of insurance-based services or insurance-derived services from different perspectives.

[0099] In some embodiments, step S401 is to extract the service usage frequency corresponding to the insurance service type from the historical service usage record as the service feature sub-information in the service frequency dimension;

[0100] It should be noted that the frequency of service usage is used to reflect the user's enthusiasm and dependence on a certain service, which can be determined based on the total number of times the service is used, the average daily or monthly usage rate, and the peak period of service usage.

[0101] In step S402 of some embodiments, service usage attribute information corresponding to the insurance service type is extracted from the historical service usage record as service feature sub-information in the service attribute dimension;

[0102] It should be noted that service usage attribute information covers the specific characteristics of insurance services within a specific insurance service type, such as service content, service quality, and the professional capabilities of the service provider. This service usage attribute information helps evaluate the attributes of different insurance services, and can be used to determine the attributes of both native insurance services and derivative insurance services.

[0103] In step S403 of some embodiments, the service usage time distribution corresponding to the insurance service type is extracted from the historical service usage records as the service feature sub-information in the service time dimension.

[0104] It should be noted that the service usage time distribution relates to the timing of service usage, which may include seasonal trends, holiday effects, the impact of specific events or cycles, etc. By analyzing these service usage time distributions, embodiments of the present application can predict fluctuations in service demand.

[0105] By integrating the service feature sub-information of the service frequency dimension, the service feature sub-information of the service attribute dimension, and the service feature sub-information of the service time dimension, the embodiment of the present application can construct a multi-dimensional service feature analysis framework, which not only helps to fully understand the characteristics of different insurance service types, but also can provide support for some personalized push operations.

[0106] In step S302 of some embodiments, the service feature sub-information corresponding to each service feature dimension is integrated to obtain service feature parsed information corresponding to the insurance service type.

[0107] It should be noted that integrating the service feature sub-information corresponding to each service feature dimension may be aggregating and analyzing the extracted service feature sub-information to form service feature parsing information corresponding to the insurance service type.

[0108] Through the embodiment of the present application shown in steps S301 to S302, corresponding service feature analysis information can be constructed for each insurance service type. This service feature analysis information is relatively comprehensive and can clearly reflect the characteristics of the insurance service type from multiple service feature dimensions.

[0109] In step S103 of some embodiments, service feature display information is generated based on each insurance service type and the service feature parsing information corresponding to each insurance service type;

[0110] In some embodiments, the core task of step S103 is to convert each insurance service type and its corresponding service feature analysis information into intuitive service feature display information. The purpose of this step is to present the complex data analysis results in an easy-to-understand manner.

[0111] It should be noted that for each type of insurance service, including insurance native services and insurance derivative services, the embodiment of the present application can generate detailed and intuitive service feature display information based on the service feature analysis information configured in the previous steps, such as key indicators such as usage frequency, user satisfaction, and service efficiency.

[0112] For example, for a native insurance service like fast claims, service feature information might include a chart showing average claim payment time, a distribution chart showing claim amounts, and a seasonal trend chart showing claims requests. These charts and trend charts, as service feature information, provide a visual representation of the overall performance of the claims service and potential areas for improvement.

[0113] For example, for insurance-derived services, such as health management services, service feature display information may include statistical data on user participation, peak service usage periods, and user satisfaction score distribution. Using this information as service feature display information can help intuitively reflect the market acceptance and user satisfaction of health management services.

[0114] In some more specific embodiments, the service feature display information may include, but is not limited to, charts, dashboards, or reports, which may be static or dynamically updated to reflect the latest service usage data.

[0115] Reference Figure 5 According to some embodiments of the present application, step S103 generates service feature display information based on each insurance service type and the service feature parsing information corresponding to each insurance service type, which may include:

[0116] Step S501: Based on multiple service feature parsing information, each insurance service type is compared in each service feature dimension to obtain service comparison reference data matching each service feature dimension;

[0117] Step S502 : generating service feature display information based on service comparison reference data of each service feature dimension.

[0118] In step S501 of some embodiments, based on the plurality of service feature parsing information, each insurance service type is compared in each service feature dimension to obtain service comparison reference data matching each service feature dimension;

[0119] It should be noted that step S501 involves comparing various insurance service types based on multiple service feature parsing information, along each service feature dimension, to obtain service comparison reference data matching each service feature dimension. This means that embodiments of the present application can perform horizontal comparisons of insurance services of different insurance service types across service feature dimensions such as usage frequency, service attributes, and usage time distribution.

[0120] For example, embodiments of the present application can compare the frequency of insurance usage of different insurance service types to determine which types of services are most popular; for another example, by comparing the service attributes of different insurance service types in terms of user evaluations, it can be identified which insurance service types have higher satisfaction.

[0121] By comparing various insurance service types based on multiple service feature parsing information in each service feature dimension, embodiments of the present application can obtain service comparison reference data that matches each service feature dimension. The service comparison reference data provides the relative performance of insurance services in each service feature dimension.

[0122] In step S502 of some embodiments, service feature display information is generated based on service comparison reference data of each service feature dimension.

[0123] It should be noted that the embodiments of the present application can use charts, dashboards or other visualization tools to convert service comparison reference data into intuitive display information, that is, service feature display information.

[0124] For example, embodiments of the present application can generate a chart to show a comparison of the usage frequency of different services; or embodiments of the present application can create a dashboard to show the distribution of service satisfaction. These service feature display information can intuitively reflect the differences and characteristics of different insurance service types, helping to improve the efficiency and effectiveness of insurance service push in subsequent steps.

[0125] Reference Figure 6 According to some embodiments of the present application, step S502 generates service feature display information based on service comparison reference data of each service feature dimension, which may include:

[0126] Step S601 , in response to the service feature dimension being the service frequency dimension, selecting a first number of high-frequency service types from a plurality of insurance service types based on service comparison reference data of the service frequency dimension;

[0127] Step S602: Generate service feature display information based on a first number of high-frequency service types.

[0128] In step S601 of some embodiments, in response to the service feature dimension being a service frequency dimension, a first number of high-frequency service types are selected from a plurality of insurance service types based on service comparison reference data of the service frequency dimension;

[0129] It should be noted that in response to the service feature dimension being the service frequency dimension, step S601 may select a first number of high-frequency service types from multiple insurance service types based on the service comparison reference data of the service frequency dimension, where high-frequency service types are services whose usage frequency exceeds a specific frequency threshold. The logic of this step is that more frequently used service types are likely to be more popular with users or better meet their needs. Therefore, in subsequent steps, service feature display information may be generated based on the push of high-frequency service types, which helps prioritize the push of insurance services that match the high-frequency service types.

[0130] In step S602 of some embodiments, service feature display information is generated based on a first number of high-frequency service types.

[0131] It should be noted that after identifying these high-frequency service types, step S602 generates service feature display information based on these first number of high-frequency service types. These service feature display information may include information such as the specific service name, the specific value of the frequency of use, a trend chart of service use, and a comparison of the frequency of use with other service types. In some embodiments, these service feature display information can be specifically presented in the form of charts, lists, or heat maps to more intuitively show the characteristics of high-frequency service types. In this way, limited computing power resources can be concentrated on the insurance service push link of high-frequency service types to improve the efficiency and effectiveness of insurance service push.

[0132] Reference Figure 7 According to some embodiments of the present application, step S502 generates service feature display information based on service comparison reference data of each service feature dimension, which may include:

[0133] Step S701 , in response to the service feature dimension being a service attribute dimension, selecting a second number of value-added service types from a plurality of insurance service types based on service comparison reference data of the service attribute dimension;

[0134] Step S702: Generate service feature display information based on the second number of value-added service types.

[0135] In step S701 of some embodiments, in response to the service feature dimension being a service attribute dimension, a second number of value-added service types are selected from a plurality of insurance service types based on service comparison reference data of the service attribute dimension;

[0136] It should be noted that in step S701, in response to the service feature dimension being the service attribute dimension, a second number of value-added service types are selected from the multiple insurance service types based on the service comparison reference data of the service attribute dimension. Value-added service types are those services that excel in terms of service attributes. These value-added service types are favored by users because they provide additional value or advantages. For example, they may result in higher user satisfaction, a better user service experience, or include innovative service content.

[0137] In step S702 of some embodiments, service feature display information is generated based on a second number of value-added service types.

[0138] After identifying these value-added service types, step S702 generates service feature display information based on these second number of value-added service types. This service feature display information can reflect the key attributes of the insurance services of these value-added service types, such as the specific content of the service, user satisfaction ratings, and unique selling points of the service. In some embodiments, the service feature display information can be presented in various charts, reports, or dashboards to intuitively reflect the characteristics of the insurance services of the value-added service types. In this way, limited computing resources can be concentrated on the insurance service push link of the value-added service types, thereby improving the efficiency and effectiveness of insurance service push.

[0139] Reference Figure 8 According to some embodiments of the present application, step S502 generates service feature display information based on service comparison reference data of each service feature dimension, which may include:

[0140] Step S801: In response to the service feature dimension being a service time dimension, the plurality of insurance service types are divided into a third number of service time groups based on service comparison reference data of the service time dimension; wherein each insurance service type in the same service time group has the same service usage time distribution;

[0141] Step S802 : Generate service feature display information based on a third number of service time groups and the insurance service type in each service time group.

[0142] In some embodiments, step S801 includes, in response to the service feature dimension being a service time dimension, grouping the plurality of insurance service types into a third number of service time groups based on service comparison reference data of the service time dimension; wherein each insurance service type in the same service time group has the same service usage time distribution;

[0143] It should be noted that step S801 responds to the situation where the service feature dimension is the service time dimension. Based on the service comparison reference data of the service time dimension, the embodiment of the present application can divide multiple insurance service types into a third number of service time groups. This division is based on the time distribution characteristics of each insurance service type, ensuring that each insurance service type in the same service time group has the same service usage time distribution. For example, some insurance service types may be used more frequently in winter, while other insurance service types may be more popular in summer. In this way, the embodiment of the present application can identify service types with similar usage time patterns.

[0144] In step S802 of some embodiments, service feature display information is generated based on a third number of service time groups and the insurance service type in each service time group.

[0145] It should be noted that step S802 generates service feature display information based on these third number of service time groups and the insurance service types in each service time group. These service feature display information can display the characteristics of different service time groups in detail. In some embodiments, the service feature display information may specifically include the insurance service type of each service time group, the time distribution of service usage, and the peak and trough periods of service usage. It should be pointed out that these service feature display information can be presented in the form of charts, heat maps or time series graphs to intuitively reflect the characteristics of insurance services in different service time groups. In this way, limited computing resources can be concentrated on the insurance service push links of some service time groups according to different service time groups to improve the efficiency and effectiveness of insurance service push.

[0146] In step S104 of some embodiments, a push operation is performed on the insurance native service or the insurance derivative service based on the service feature display information.

[0147] In some embodiments, step S104 is a key step in the entire service push process, which involves using the service feature display information generated in the previous step to guide the specific service push strategy to perform push operations on insurance native services or insurance derivative services.

[0148] It should be noted that embodiments of the present application can perform targeted push operations on native insurance services or insurance-derived services based on the key performance indicators and market performance data reflected in the service feature display information. For example, if the service feature display information shows that a specific user group frequently uses health management services and exhibits high satisfaction, embodiments of the present application can push more relevant health management services to this group, such as customized health consultations or preventive medical examination services.

[0149] When executing push operations, embodiments of the present application can utilize multiple channels, including email, SMS, mobile app notifications, or social media platforms, to push insurance native services or insurance derivative services. This ensures that these insurance native services or insurance derivative services are accurately and promptly delivered to the corresponding target users. This ensures that the content of the pushed insurance native services or insurance derivative services is more in line with user preferences and needs, improving the relevance and effectiveness of the push operation.

[0150] For example, for young users who frequently use online services, the embodiments of the present application can push service information through mobile applications; while for elderly users who prefer traditional communication methods, service information can be pushed through telephone or email.

[0151] In some more specific embodiments, the timing and frequency of push notifications can be adjusted based on the service feature display information. For example, if the service feature display information shows that the user's demand for a certain service has increased during a specific time period, the frequency of service push notifications can be increased during this time period to meet the user's needs. At the same time, the embodiments of the present application will also avoid excessive push notifications, so as not to cause user disgust.

[0152] Based on this, through the above-mentioned insurance service push method, the embodiment of the present application can achieve precision and personalization of insurance service push operations, thereby improving the push quality and push efficiency of insurance services.

[0153] Reference Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is shown. The electronic device may include:

[0154] The processor 901 may be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is configured to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0155] The memory 902 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called by the processor 901 to execute the insurance service push method of the embodiments of this application.

[0156] Input / output interface 903, used to implement information input and output;

[0157] Communication interface 904, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.);

[0158] Bus 905 , which transmits information between various components of the device (e.g., processor 901 , memory 902 , input / output interface 903 , and communication interface 904 );

[0159] The processor 901 , the memory 902 , the input / output interface 903 and the communication interface 904 are connected to each other in communication within the device via a bus 905 .

[0160] The present application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, so that the computer device implements the above-mentioned insurance service push method.

[0161] The terms "first," "second," "third," "fourth," and the like (if any) in the specification of the present disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein, for example, can be implemented in orders other than those illustrated or described herein. In addition, the terms "comprises" and "comprising," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0162] It should be understood that in the present disclosure, "at least one (item)" refers to one or more, and "plurality" refers to two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0163] It should be understood that in the description of the embodiments of the present application, multiple (or multiple items) means more than two, greater than, less than, exceed, etc. are understood to exclude the number itself, and above, below, within, etc. are understood to include the number itself.

[0164] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0165] Units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0166] In addition, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0167] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium may include: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., various media that can store program codes.

[0168] It should also be understood that the various implementation methods provided in the embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0169] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A method for pushing insurance services, characterized in that: include: Obtaining historical service usage records corresponding to multiple insurance service types; wherein the insurance service types include insurance native services and insurance derivative services; According to each of the historical service usage records, configuring service feature parsing information for the corresponding insurance service type; generating service feature display information according to each of the insurance service types and the service feature parsing information corresponding to each of the insurance service types; Based on the service feature display information, performing a push operation on the insurance native service or the insurance derivative service; The insurance service type is obtained by following the steps below: Get the insurance service push request and push object tag; In response to the insurance service push request, performing an object rights query in a real-time updated insurance business database according to the push object tag to determine the multiple insurance service types that match the push object tag; Generating service feature display information according to each insurance service type and the service feature parsing information corresponding to each insurance service type includes: Based on the plurality of service feature parsing information, each of the insurance service types is compared on each preset service feature dimension to obtain service comparison reference data matching each of the service feature dimensions; wherein the service feature dimensions include a service frequency dimension, a service attribute dimension, and a service time dimension; The service feature display information is generated according to the service comparison reference data of each of the service feature dimensions.

2. The method according to claim 1, characterized in that The configuring service feature parsing information for the corresponding insurance service type according to each of the historical service usage records includes: Based on a plurality of preset service feature dimensions, extracting corresponding service feature sub-information from the historical service usage records; The service feature sub-information corresponding to each of the service feature dimensions is integrated to obtain the service feature parsing information corresponding to the insurance service type.

3. The method according to claim 2, characterized in that The extracting corresponding service feature sub-information from the historical service usage record based on a plurality of preset service feature dimensions includes: Extracting the service usage frequency corresponding to the insurance service type from the historical service usage record as the service feature sub-information of the service frequency dimension; Extracting service usage attribute information corresponding to the insurance service type from the historical service usage record as the service feature sub-information of the service attribute dimension; The service usage time distribution corresponding to the insurance service type is extracted from the historical service usage record as the service feature sub-information of the service time dimension.

4. The method according to claim 1, wherein Generating the service feature display information according to the service comparison reference data of each service feature dimension includes: In response to the service feature dimension being a service frequency dimension, selecting a first number of high-frequency service types from the plurality of insurance service types based on the service comparison reference data of the service frequency dimension; The service feature display information is generated based on a first number of the high-frequency service types.

5. The method according to claim 1, characterized in that Generating the service feature display information according to the service comparison reference data of each service feature dimension includes: In response to the service feature dimension being a service attribute dimension, selecting a second number of value-added service types from the plurality of insurance service types based on the service comparison reference data of the service attribute dimension; The service feature display information is generated based on the second number of the value-added service types.

6. The method according to claim 1, wherein Generating the service feature display information according to the service comparison reference data of each service feature dimension includes: In response to the service feature dimension being a service time dimension, the plurality of insurance service types are divided into a third number of service time groups based on the service comparison reference data of the service time dimension; wherein the insurance service types in the same service time group have the same service usage time distribution; The service feature display information is generated based on a third number of the service time groups and the insurance service type in each of the service time groups.

7. The method according to claim 1, characterized in that The obtaining of historical service usage records corresponding to multiple insurance service types includes: In the insurance business database, historical service usage records corresponding to the multiple insurance service types are retrieved.

8. An electronic device, characterized in that: include: A memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the insurance service push method according to any one of claims 1 to 7 is implemented.

9. A computer-readable storage medium, characterized in that The storage medium stores a program, and the program is executed by a processor to implement the insurance service push method according to any one of claims 1 to 7.

Images