CN109299875A - 数据跟踪处理方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及大数据技术领域中的一种数据跟踪处理方法、装置、计算机设备和存储介质。该方法包括：接收用户终端上传的询价请求，根据询价请求生成对应的询价单，将询价单返回至用户终端；接收用户终端根据询价单上传的询价信息；根据询价信息生成相应的报价单，将报价单返回至用户终端，并且对报价单进行保存；接收到用户终端基于报价单上传的投保请求，利用投保请求中携带的投保信息生成对应的投保单，对报价单进行保存；对预设时间段内的报价单以及投保单进行统计，得到报价单数量以及投保单数量；利用报价单数量以及投保单数量计算报价单与投保单之间的转化率。采用本方法能够在统计报价单转化为投保单时能够有效提高转化率计算准确性。

Description

数据跟踪处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种数据跟踪处理方法、装置、计算机设备和存储介质。

背景技术

保险已经成为日常生活中重要的保障机制。用户有投保需求时，会向业务人员进行询价。业务人员会根据用户需求进行报价。用户在收到报价后，有些可能会投保，有些也可能并未投保。对于未投保的情况，保险公司通常没有相应的数据记录，由此导致在统计报价单转化为投保单时，转化率的计算不够准确。

发明内容

基于此，有必要针对上述技术问题，提供一种在统计报价单转化为投保单时能够有效提高转化率计算准确性的数据跟踪处理方法、装置、计算机设备和存储介质。

一种数据跟踪处理方法，所述方法包括：

接收用户终端上传的询价请求，根据所述询价请求生成对应的询价单，将所述询价单返回至用户终端；

接收所述用户终端根据所述询价单上传的询价信息；

根据所述询价信息生成相应的报价单，将所述报价单返回至所述用户终端，并且对所述报价单进行保存；

接收到所述用户终端基于所述报价单上传的投保请求，利用所述投保请求中携带的投保信息生成对应的投保单，对所述报价单进行保存；

对预设时间段内的报价单以及投保单进行统计，得到报价单数量以及投保单数量；

利用所述报价单数量以及所述投保单数量计算报价单与投保单之间的转化率。

在其中一个实施例中，所述报价单中包括推荐险种；所述投保单中包括投保险种；在所述利用所述投保请求中携带的投保信息生成对应的投保单之后，还包括：

对预设时间段内报价单中的推荐险种的数量进行统计，以及对预设时间段内投保单中的投保险种的数量进行统计；

利用所述推荐险种的统计数量以及所述投保险种的统计数量计算所述推荐险种的成功率；

当所述成功率小于阈值时，生成相应的提示信息。

在其中一个实施例中，所述报价单中包括用户标识；在根据所述询价信息生成相应的报价单之后，所述方法还包括：

接收到来自不同渠道的多个询价请求，识别每个询价请求对应的用户标识；

根据所述用户标识在数据库中查询是否存在已有的报价单；

若存在已有的报价单，则对应渠道返回所述已有的报价单。

在其中一个实施例中，所述方法还包括：

获取规则配置文件，根据所述规则配置文件对业务类型配置相应的业务规则；所述业务类型包括报价业务；

所述根据所述询价信息生成相应的报价单包括：根据所述报价业务调用对应的报价规则逻辑代码，利用所述报价规则逻辑代码对所述询价信息进行运算，生成相应的报价单。

在其中一个实施例中，所述根据所述规则配置文件对业务类型配置相应的业务规则包括：

运行配置脚本读取所述规则配置文件，所述规则配置文件中记录了业务类型以及对应的业务规则；

根据所述业务类型进入对应的规则配置页面；所述规则配置页面中包括多个配置项；

模拟键盘和鼠标操作将多项业务规则输入至对应的配置项。

一种数据跟踪处理装置，所述装置包括：

通信模块，用于接收用户终端上传的询价请求；

询价单生成模块，用于根据所述询价请求生成对应的询价单；

所述通信模块还用于将所述询价单返回至用户终端；接收所述用户终端根据所述询价单上传的询价信息；

报价单生成模块，用于根据所述询价信息生成相应的报价单；对所述报价单进行保存；

所述通信模块还用于将所述报价单返回至所述用户终端；

投保单生成模块，用于接收到所述用户终端基于所述报价单上传的投保请求，利用所述投保请求中携带的投保信息生成对应的投保单；对所述报价单进行保存；

统计模块，用于对预设时间段内的报价单以及投保单进行统计，得到报价单数量以及投保单数量；利用所述报价单数量以及所述投保单数量计算报价单与投保单之间的转化率。

在其中一个实施例中，所述报价单中包括推荐险种；所述投保单中包括投保险种；所述统计模块还用于对预设时间段内报价单中的推荐险种的数量进行统计，以及对预设时间段内投保单中的投保险种的数量进行统计；利用所述推荐险种的统计数量以及所述投保险种的统计数量计算所述推荐险种的成功率；当所述成功率小于阈值时，生成相应的提示信息。

在其中一个实施例中，所述报价单中包括用户标识；所述装置还包括：

报价统一模块，用于接收到来自不同渠道的多个询价请求，识别每个询价请求对应的用户标识；根据所述用户标识在数据库中查询是否存在已有的报价单；若存在已有的报价单，则对应渠道返回所述已有的报价单。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述各个方法实施例中的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述各个方法实施例中的步骤。

上述数据跟踪处理方法、装置、计算机设备和存储介质，当用户有投保需求时，可以通过用户终端进行询价，服务器根据用户终端的询价请求生成对应的询价单。用户终端可以根据询价单上传相应的询价信息，服务器根据询价信息生成报价单，并且对报价单进行保存。当服务器接收到用户终端基于报价单而上传的投保请求时，利用投保请求中携带的投保信息生成对应的投保单，同时也对投保单进行保存。在用户开始询价直至投保的整个过程中，对相应的数据进行了跟踪和保存。由此可以对预设时间段内的报价单以及投保单进行统计，从而能够利用报价单数量以及投保单数量计算得到报价单与投保单之间的转化率，有效提高了转化率计算的准确性。

附图说明

图1为一个实施例中数据跟踪处理方法的应用场景图；

图2为一个实施例中数据跟踪处理方法的流程示意图；

图3为一个实施例中报价统一步骤的流程示意图；

图4为一个实施例中根据规则配置文件对业务类型配置相应的业务规则步骤的流程示意图；

图5为一个实施例中数据跟踪处理装置的结构框图；

图6为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的数据跟踪处理方法，可以应用于如图1所示的应用环境中。其中，用户终端102通过网络与服务器104进行通信。其中，用户终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。用户可以通过用户终端102对所需的保险进行询价，向服务器104上传询价请求。服务器104根据询价请求生成对应的询价单，将询价单返回至用户终端102。该询价单中包括多个询价问题以及对应的输入框。用户终端102在输入框内输入相应的询价信息，将询价信息上传至服务器104。服务器104根据询价信息生成相应的报价单，将报价单返回至用户终端102，并且对报价单进行保存。用户如果接受该报价单，可以根据报价单中的推荐险种通过用户终端102进入相应的投保页面，在投保页面中录入投保信息。利用投保请求中携带的投保信息生成对应的投保单，对报价单进行保存。服务器104对预设时间段内的报价单以及投保单进行统计，分别得到报价单数量以及投保单数量。服务器104将投保单数量除以报价单数量，以此计算报价单与投保单之间的转化率。通过对询价至投保过程中的数据进行跟踪记录，从而在计算报价单与投保单之间的转化率时有效提高了准确性。

在一个实施例中，如图2所示，提供了一种数据跟踪处理方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤202，接收用户终端上传的询价请求，根据询价请求生成对应的询价单，将询价单返回至用户终端。

步骤204，接收用户终端根据询价单上传的询价信息。

用户可以通过用户终端对所需的保险进行询价。用户终端可以是移动终端也可以是台式计算机或个人笔记本电脑等。用户终端可以安装应用程序，与可以安装浏览器。用户可以通过用户终端的应用程序向服务器发送询价请求，也可以通过用户终端的浏览器向服务器发送询价请求。

服务器接收询价请求，对询价请求进行解析，识别相应的保险类型。例如，保险类型可以是财产类型、人身意外类型等多种。服务器根据保险类型生成对应的询价单，将询价单返回至用户终端。同时，服务器将该询价单存入数据库，以便进行保存。用户终端接收服务器返回的询价单，将询价单进行展示。该询价单中包括多个询价问题以及对应的输入框。用户在询价单中针对每个询价问题进行回答，通过用户终端将相应的答复内容录入输入框内。答复内容也可以称为询价信息。

例如，服务器对询价请求进行解析后，得到的内容为：“我想对自己公司财产购买保障。”服务器识别到相应的保险类型为财产类型，则根据财产类型获取对应的询价单。该询价单中包括“请问您公司名称、公司规模、主营业务、地址…等？”用户可以通过用户终端进行答复，将答复内容(即询价信息)以询价单的形式上传至服务器。

步骤206，根据询价信息生成相应的报价单，将报价单返回至用户终端，并且对报价单进行保存。

服务器根据询价信息生成相应的报价单。服务器针对不同的询价信息所生成的报价单可以相同，也可以不同。报价单中包括推荐险种以及价格等内容。其中，推荐险种包括主险和附加险。推荐险种可以只有主险，也可以有主险和附加险。报价单中的附加险可以是一种也可以是多种。服务器将报价单返回至用户终端，同时将报价单存入数据库，以便进行保存。

步骤208，接收到用户终端基于报价单上传的投保请求，利用投保请求中携带的投保信息生成对应的投保单，对报价单进行保存。

用户终端接收服务器返回的报价单，将报价单进行展示。用户如果接受该报价单，可以根据报价单中的推荐险种通过用户终端进入相应的投保页面，在投保页面中录入投保信息。用户终端利用投保信息生成相应的投保请求，将投保请求上传至服务器。服务器利用投保请求中所携带的投保信息生成对应的投保单，将投保单存入数据库进行保存。服务器对投保单进行核保，以便识别用户是否满足投保要求。若满足投保要求，则服务器生成相应的保单。

步骤210，对预设时间段内的报价单以及投保单进行统计，得到报价单数量以及投保单数量。

步骤212，利用报价单数量以及投保单数量计算报价单与投保单之间的转化率。

服务器可以按照特定频率在数据库中读取预设时间段的报价单和投保单。服务器对预设时间段内的报价单以及投保单进行统计，分别得到报价单数量以及投保单数量。服务器将投保单数量除以报价单数量，以此计算报价单与投保单之间的转化率。

本实施例中，当用户有投保需求时，可以通过用户终端进行询价，服务器根据用户终端的询价请求生成对应的询价单。用户终端可以根据询价单上传相应的询价信息，服务器根据询价信息生成报价单，并且对报价单进行保存。当服务器接收到用户终端基于报价单而上传的投保请求时，利用投保请求中携带的投保信息生成对应的投保单，同时也对投保单进行保存。在用户开始询价直至投保的整个过程中，对相应的数据进行了跟踪和保存。由此可以对预设时间段内的报价单以及投保单进行统计，从而能够利用报价单数量以及投保单数量计算得到报价单与投保单之间的转化率，有效提高了转化率计算的准确性。

在一个实施例中，报价单中包括推荐险种；投保单中包括投保险种；在利用投保请求中携带的投保信息生成对应的投保单之后，还包括：对预设时间段内报价单中的推荐险种的数量进行统计，以及对预设时间段内投保单中的投保险种的数量进行统计；利用推荐险种的统计数量以及投保险种的统计数量计算推荐险种的成功率；当成功率小于阈值时，生成相应的提示信息。

报价单中包括推荐险种以及价格等内容。其中，推荐险种包括主险和附加险。推荐险种可以只有主险，也可以有主险和附加险。报价单中的附加险可以是一种也可以是多种。用户可以根据报价单中的推荐险种通过用户终端进入相应的投保页面，在投保页面中录入投保信息。用户可以通过用户终端只在主险的投保页面中录入投保信息，也可以既在主险的投保页面中录入投保信息，又在附加险的投保页面中录入投保信息。如果报价单中有多种附加险，用户可以选择一种附加险，也可以选择多种附加险。每种推荐险种(主险或附加险)对应的投保信息上传至服务器后，服务器根据投保信息生成相应的投保单。投保单中包括主险或者包含主险与附加险。投保单中的主险以及附加险又可以统称为投保险种。

服务器还可以按照特定频率在数据库中读取报价单以及投保单时，获取报价单中的推荐险种以及投保单中的投保险种。具体的，服务器对预设时间段内报价单中的推荐险种的数量进行统计，得到每种推荐险种的统计数量。服务器对预设时间段内投保单中的投保险种的数量进行统计，得到每种投保险种的统计数量。服务器根据险种，利用投保险种的统计数量以及推荐险种的统计数量计算推荐险种的成功率。当推荐险种的成功率超过阈值时，表示该推荐险种与用户的需求相适应，可以继续推荐。当推荐险种的成功率小于阈值时，表示该推荐险种与用户的需求不相适应，服务器生成相应的提示信息，以便工作人员即使对该推荐险种进行调整。例如，当推荐险种的成功率小于阈值时，服务器可以生成推荐险种与用户需求不匹配，需要更换推荐险种的提示信息，或者当推荐险种的成功率小于阈值时，服务器可以生成该推荐险种成功率过低，建议后续不再继续推荐的提示信息，以便工作人员根据用户需求调整相应的推荐险种。

由于用户是基于报价单中的推荐险种进行投保的，推荐险种的成功率能够反映报价单与投保单之间的转化率。因此，在推荐险种的成功率小于阈值时，及时发出提示，进行调整，从而能够使得报价单中的推荐险种更符合用户需求，进而提高报价单与投保单之间的转化率。

在一个实施例中，在根据询价信息生成相应的报价单之后，方法还包括：报价统一的步骤。如图3所示，报价统一的步骤具体包括：

步骤302，接收到来自不同渠道的多个询价请求，识别每个询价请求对应的用户标识。

步骤304，根据用户标识在数据库中查询是否存在已有的报价单。

步骤306，若存在已有的报价单，则对应渠道返回已有的报价单。

用户除了通过用户终端进行询价之外，还可以通过其他渠道进行询价，例如，用户可以向不同的业务人员询价，也可以拨打客服电话向客户询价。为了避免用户通过不同渠道询价时得到的报价不同，需要统一多个渠道的报价。服务器在接收到用户的第一询价请求时，生成与用户标识对应的报价单，并且将报价单存入数据库。当服务器接收到来自不同渠道的多个询价请求时，对每个询价请求进行解析，得到询价请求中所携带的用户标识。服务器根据用户标识在数据库中查询是否存在已有的报价单。若数据库中存在已有的报价单，则服务器直接获取已有的报价单，对应渠道返回已有的报价单。由此可以确保用户从多种渠道获取到的报价单是一致的，有效避免了不同渠道报价不同的问题。

进一步的，在生成报价单之前，服务器还会对用户进行甄别。其中，服务器可以通过数据库或第三方平台获取用户的历史记录、信用信息、资产信息等。服务器利用需求信息、历史记录、信用信息、资产信息识别用户是否为拒保对象。如果用户的信用等级较低、或者主营业务属于高污染、或者资产状况不良或者被列为黑名单用户等，则将该用户标记为拒保对象。反之，将用户标记为报价对象。如果用户被标记为拒保对象，则服务器直接生成拒保提示信息，将该拒保提示信息发送给用户终端。如果用户被标记为报价对象，则服务器根据需求信息进行报价，生成相应的报价单。通过对用户进行甄别，有效避免了不必要的报价，节省了服务器资源。

进一步的，数据库中的用户的历史记录、信用信息、资产信息等可以按照预设频率进行更新。如果在更新后，用户的信用等级升高或者主营业务不再属于高污染行业或者资产状况得到改善或者从黑名单中被移除，则服务器可以根据更新后的用户信息生成投保邀请提示信息，将投保邀请提示信息发送至用户终端。以便用户可以根据其业务需求重新发起询价请求。通过对用户信息进行定时更新，进一步对用户进行甄别，继而能够有效提高投保数量。

在一个实施例中，该方法还包括：获取规则配置文件，根据规则配置文件对业务类型配置相应的业务规则；业务类型包括报价业务；根据询价信息生成相应的报价单包括：根据报价业务调用对应的报价规则逻辑代码，利用报价规则逻辑代码对询价信息进行运算，生成相应的报价单。

服务器在报价时以及在处理投保业务等时，可以调用相应的业务规则进行自动处理。在传统的方式中，业务规则在代码中通常是写死的。如果业务流程有变化或者业务规则有变化，则需要重新代码，从而导致开发人员的工作量增加。本实施例，业务规则可以由服务器根据规则配置文件自行配置。规则配置文件可以是由开发人员通过开发终端预先上传服务器的。不同的业务类型可以配置不同的业务规则。不同的险种可以有不同的业务类型，业务类型可以包括：报价业务、核保业务、批改业务等等。服务器可以根据配置后的业务规则调用相应的业务规则逻辑代码，进行自动处理。其中包括，服务器根据报价业务调用对应的报价规则逻辑代码，利用报价规则逻辑代码对询价信息进行运算，生成相应的报价单。服务器根据核保业务调用对应的核保规则逻辑代码，进行核保处理等。

当业务规则发生变化时，开发人员可以通过开发终端上传更新后的规则配置文件。服务器利用更新后的规则配置文件重新进行配置即可，无需开发人员重新编写代码，有效节省了开发人员的工作量。

在一个实施例中，如图4所示，根据规则配置文件对业务类型配置相应的业务规则的步骤具体包括：

步骤402，运行配置脚本读取规则配置文件，规则配置文件中记录了业务类型以及对应的业务规则。

步骤404，根据业务类型进入对应的规则配置页面；规则配置页面中包括多个配置项。

步骤406，模拟键盘和鼠标操作将多项业务规则输入至对应的配置项。

每种业务类型都具有多项业务规则。例如，核保业务对应的业务规则可能达到几千项。当业务类型较多时，业务规则的配置的工作就更加繁重。为了有效提高业务规则的配置效率，服务器可以根据规则配置文件自行进行配置。

服务器接收到用户终端上传的规则配置文件后，可以触发配置脚本，通过运行配置脚本可以读取规则配置文件中的业务类型以及与业务类型对应的业务规则。不同的业务类型可以通过不同的规则配置页面进行配置，以此确保每种业务类型都能准确配置。

服务器通过配置脚本将读取到业务规则存入与业务类型对应的数组。通过配置脚本进入相应的规则配置页面后，在数组中读取相应业务规则，模拟键盘与鼠标操作将多项业务规则输入至对应的配置项，直至该业务类型的业务规则配置完毕。配置脚本从该规则配置页面中退出，进入下一业务类型对应的规则配置页面，继续进行业务规则的自动配置，直至规则配置文件中的所有业务规则全部配置完毕。

通过运行配置脚本，可以根据规则配置文件自动进行业务规则配置，不仅节省了人工配置操作，而且有效提高了业务规则的配置效率。

应该理解的是，虽然图2-4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图5所示，提供了一种数据跟踪处理装置，包括：通信模块502、询价单生成模块504、报价单生成模块506、投保单生成模块508和统计模块510，其中：

通信模块502，用于接收用户终端上传的询价请求。

询价单生成模块504，用于根据询价请求生成对应的询价单。

通信模块502还用于将询价单返回至用户终端；接收用户终端根据询价单上传的询价信息。

报价单生成模块506，用于根据询价信息生成相应的报价单；对报价单进行保存。

通信模块502还用于将报价单返回至用户终端。

投保单生成模块508，用于接收到用户终端基于报价单上传的投保请求，利用投保请求中携带的投保信息生成对应的投保单；对报价单进行保存。

统计模块510，用于对预设时间段内的报价单以及投保单进行统计，得到报价单数量以及投保单数量；利用报价单数量以及投保单数量计算报价单与投保单之间的转化率。

在一个实施例中，报价单中包括推荐险种；投保单中包括投保险种；统计模块还用于对预设时间段内报价单中的推荐险种的数量进行统计，以及对预设时间段内投保单中的投保险种的数量进行统计；利用推荐险种的统计数量以及投保险种的统计数量计算推荐险种的成功率；当成功率小于阈值时，生成相应的提示信息。

在一个实施例中，报价单中包括用户标识；装置还包括：报价统一模块，用于接收到来自不同渠道的多个询价请求，识别每个询价请求对应的用户标识；根据用户标识在数据库中查询是否存在已有的报价单；若存在已有的报价单，则对应渠道返回已有的报价单。

在一个实施例中，该装置还包括：配置模块，用于获取规则配置文件，根据规则配置文件对业务类型配置相应的业务规则；业务类型包括报价业务；报价单生成模块还用于根据报价业务调用对应的报价规则逻辑代码，利用报价规则逻辑代码对询价信息进行运算，生成相应的报价单。

在一个实施例中，配置模块还用于运行配置脚本读取规则配置文件，规则配置文件中记录了业务类型以及对应的业务规则；根据业务类型进入对应的规则配置页面；规则配置页面中包括多个配置项；模拟键盘和鼠标操作将多项业务规则输入至对应的配置项。

关于数据跟踪处理装置的具体限定可以参见上文中对于数据跟踪处理方法的限定，在此不再赘述。上述数据跟踪处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过***总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***、计算机程序和数据库。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用于存储询价信息以及投保信息等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种数据跟踪处理方法。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各个方法实施例中的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种数据跟踪处理方法，所述方法包括：

接收用户终端上传的询价请求，根据所述询价请求生成对应的询价单，将所述询价单返回至用户终端；

接收所述用户终端根据所述询价单上传的询价信息；

根据所述询价信息生成相应的报价单，将所述报价单返回至所述用户终端，并且对所述报价单进行保存；

接收到所述用户终端基于所述报价单上传的投保请求，利用所述投保请求中携带的投保信息生成对应的投保单，对所述报价单进行保存；

对预设时间段内的报价单以及投保单进行统计，得到报价单数量以及投保单数量；

利用所述报价单数量以及所述投保单数量计算报价单与投保单之间的转化率。

2.根据权利要求1所述的方法，其特征在于，所述报价单中包括推荐险种；所述投保单中包括投保险种；在所述利用所述投保请求中携带的投保信息生成对应的投保单之后，还包括：

对预设时间段内报价单中的推荐险种的数量进行统计，以及对预设时间段内投保单中的投保险种的数量进行统计；

利用所述推荐险种的统计数量以及所述投保险种的统计数量计算所述推荐险种的成功率；

当所述成功率小于阈值时，生成相应的提示信息。

3.根据权利要求1所述的方法，其特征在于，所述报价单中包括用户标识；在根据所述询价信息生成相应的报价单之后，所述方法还包括：

接收到来自不同渠道的多个询价请求，识别每个询价请求对应的用户标识；

根据所述用户标识在数据库中查询是否存在已有的报价单；

若存在已有的报价单，则对应渠道返回所述已有的报价单。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取规则配置文件，根据所述规则配置文件对业务类型配置相应的业务规则；所述业务类型包括报价业务；

所述根据所述询价信息生成相应的报价单包括：根据所述报价业务调用对应的报价规则逻辑代码，利用所述报价规则逻辑代码对所述询价信息进行运算，生成相应的报价单。

5.根据权利要求4所述的方法，其特征在于，所述根据所述规则配置文件对业务类型配置相应的业务规则包括：

运行配置脚本读取所述规则配置文件，所述规则配置文件中记录了业务类型以及对应的业务规则；

根据所述业务类型进入对应的规则配置页面；所述规则配置页面中包括多个配置项；

模拟键盘和鼠标操作将多项业务规则输入至对应的配置项。

6.一种数据跟踪处理装置，其特征在于，所述装置包括：

通信模块，用于接收用户终端上传的询价请求；

询价单生成模块，用于根据所述询价请求生成对应的询价单；

所述通信模块还用于将所述询价单返回至用户终端；接收所述用户终端根据所述询价单上传的询价信息；

报价单生成模块，用于根据所述询价信息生成相应的报价单；对所述报价单进行保存；

所述通信模块还用于将所述报价单返回至所述用户终端；

投保单生成模块，用于接收到所述用户终端基于所述报价单上传的投保请求，利用所述投保请求中携带的投保信息生成对应的投保单；对所述报价单进行保存；

统计模块，用于对预设时间段内的报价单以及投保单进行统计，得到报价单数量以及投保单数量；利用所述报价单数量以及所述投保单数量计算报价单与投保单之间的转化率。

7.根据权利要求6所述的装置，其特征在于，所述报价单中包括推荐险种；所述投保单中包括投保险种；所述统计模块还用于对预设时间段内报价单中的推荐险种的数量进行统计，以及对预设时间段内投保单中的投保险种的数量进行统计；利用所述推荐险种的统计数量以及所述投保险种的统计数量计算所述推荐险种的成功率；当所述成功率小于阈值时，生成相应的提示信息。

8.根据权利要求6所述的装置，其特征在于，所述报价单中包括用户标识；所述装置还包括：

报价统一模块，用于接收到来自不同渠道的多个询价请求，识别每个询价请求对应的用户标识；根据所述用户标识在数据库中查询是否存在已有的报价单；若存在已有的报价单，则对应渠道返回所述已有的报价单。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至5中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至5中任一项所述的方法的步骤。