CN108510284A - 一种数据业务投诉的原因定位方法及装置 - Google Patents

Abstract

本发明实施例公开一种数据业务投诉的原因定位方法及装置，所述方法包括：根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因。所述装置用于实现所述方法。本发明实施例提供的数据业务投诉的原因定位方法可快速、准确地定位数据业务投诉的原因。

Description

一种数据业务投诉的原因定位方法及装置

技术领域

本发明涉及网络通信领域，具体涉及一种数据业务投诉的原因定位方法及装置。

背景技术

随着移动互联网业务的不断发展，用户对数据业务感知越来越重视，关于数据业务的投诉也越来越多。

传统数据业务投诉处理流程为：

(1)客服收取投诉信息，建立投诉工单并派给专业人员处理；

(2)专业人员根据工单上的相关信息(用户标识和投诉时间等)，查看投诉的用户业务信令记录，结合自身经验判断并定位投诉问题，得出结论后回复工单；

(3)客服人员参考工单中的回复，回访客户并解释问题原因。

然而，上述方案存在如下问题：

1、客服人员不具备专业判断能力，收集投诉信息后需要转给专业人员处理，使得投诉处理流程较长，不能实时解决用户问题。

2、专业人员通过人工分析投诉工单，需要大量时间和人力支持。

3、最终的投诉原因定位由专业人员的经验确定，由于专业人员经验存在差异，因此投诉定位的准确率并不稳定。

因此，如何提出一种方法，可快速、准确地定位数据业务投诉的原因，具有十分重要的意义。

发明内容

针对现有技术中的缺陷，本发明实施例提供一种数据业务投诉的原因定位方法及装置。

一方面，本发明实施例提出一种数据业务投诉的原因定位方法，包括：

根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；

根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；

根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因。

本发明实施例提出的数据业务投诉的原因定位方法，由于可通过通用数据业务模型过滤出业务数据，并根据预设的决策树投诉原因定位算法，定位投诉的原因，因此，可快速确定投诉的原因；另外，由于使用了定位算法，因此避免了人工因素造成的投诉原因定位不准确的情况，提高了原因定位的准确性。

另一方面，本发明实施例还提供一种数据业务投诉的原因定位装置，其特征在于，包括：

获取模块，用于根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；

过滤模块，用于根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；

定位模块，用于根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因。

本发明实施例提出的数据业务投诉的原因定位装置，由于可通过通用数据业务模型过滤出业务数据，并根据预设的决策树投诉原因定位算法，定位投诉的原因，因此，可快速确定投诉的原因；另外，由于使用了定位算法，因此避免了人工因素造成的投诉原因定位不准确的情况，提高了原因定位的准确性。

附图说明

图1为本发明数据业务投诉的原因定位方法实施例的流程示意图；

图2为本发明数据业务投诉的原因定位方法实施例中的通用数据业务模型示意图；

图3为本发明数据业务投诉的原因定位方法实施例中的预设的决策树投诉原因定位算法流程图；

图4为本发明数据业务投诉的原因定位装置实施例的结构示意图；

图5为本发明数据业务投诉的原因定位装置实施例的结构框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明数据业务投诉的原因定位方法实施例的流程示意图，参看图1，本实施例公开一种数据业务投诉的原因定位方法，包括：

S1、根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；

S2、根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；

S3、根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因。

本发明实施例提出的数据业务投诉的原因定位方法，由于可通过通用数据业务模型过滤出业务数据，并根据预设的决策树投诉原因定位算法，定位投诉的原因，因此，可快速确定投诉的原因；另外，由于使用了定位算法，因此避免了人工因素造成的投诉原因定位不准确的情况，提高了原因定位的准确性。

需要说明的是，本方法实施例的执行主体为计算机。

具体地，在步骤S1中，在接到数据业务投诉后，可根据该业务投诉对应的用户号码以及该业务投诉的时间，获取所述时间前的预设时段内，例如12小时内，该用户号码的所有业务的原始信令。

可以理解的是，所述预设时段的具体时长可根据实际情况进行调整，本实施例对此不作限定。

在步骤S2中，可根据通用数据业务模型，对步骤S1中获取到的所述原始信令进行过滤，进而获取所述用户号码的业务数据。

其中，所述通用数据业务模型基于用户进行数据业务需要进行的ATTACH流程、PDP_ACTIVE流程、DNS流程、TCP流程、GET流程、RAU流程、PDP_DEACTIVE流程以及DETACH流程。

具体地，可先提取ATTACH流程、PDP_ACTIVE流程、DNS流程、TCP流程、GET流程、RAU流程、PDP_DEACTIVE流程以及DETACH流程共52个关键字段，如表1所示：

表1：通用数据业务模型关键字段

进一步地，可根据表1所示的关键字段，提取各业务流程的关键字段，建立如图2所示的通用数据业务模型。

在通用数据业务模型建立完成后，则可根据通用数据业务模型，对步骤S1中获取到的所述原始信令进行过滤，以获取所述用户号码的业务数据。

需要注意的是，对所述步骤S1中获取到的所述原始信令进行过滤包括：

1、通过判断ATTACH业务流程中的IMEI是否改变，获取用户更换终端的次数信息。通常，在使用数据业务过程中，若IMEI改变，则表示用户更换了终端。

2、计算在所述预设时段内，终端进行PDP激活、PDP去激活、DNS、TCP、GET和RAU等的尝试次数和成功次数。

3、提取各业务流程的最后一次的进行时间以及是否成功的信息。

在步骤S3中，所述预设的决策树投诉原因定位算法基于用户进行数据业务的逻辑顺序和时间顺序。所述预设的决策树投诉原因定位算法的流程图如图3所示。

具体地，在步骤2中获取到所述用户号码的业务数据后，则可通过所述预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因：

S31、通过ATTACH业务流程中的用户更换终端的次数信息，明确用户在投诉前是否有更换终端的动作，若否，则进行步骤S32；

若是，则进一步判断更换终端后，业务流程是否与更换终端前一致，若否，则可确定为终端问题；若是，则进行步骤S32。

S32、筛查PDP激活和DNS模型中的用户IP字段，判断用户是否使用了欠费IP段的IP，若否，则进行步骤S33；

若是，则可确定为用户欠费。

S33、根据终端最后一次进行各业务流程的时间，确定所述终端最后进行的业务流程的类型，并根据该业务流程的类型确定所述数据业务投诉的原因：

若流程为DETACH(去附着)或PDP去激活，则表明用户投诉前未建立正常承载通道而导致无法进行正常业务。

若流程为RAU，则需进一步判断其更新类型。若RAU为周期性路由更新，则表示该终端长时间处于数据业务非激活状态。若RAU为普通路由区更新，则仅是终端的一个正常业务流程，无法单独进行问题定位，需再对其他业务流程进行逻辑分析判断。

若流程为ATTACH(附着)或PDP激活，需获知用户投诉前最后一次的该流程是否成功，若不成功则表示终端没有业务承载功能，无法开展后续的业务流程。若流程成功且用户IP为非欠费地址，则表示终端已经完成承载动作，能够进入业务流程阶段，需通过结合其余流程的分析做出最终判断。

若流程为DNS、TCP或GET，虽然意味着终端可以进入到业务流程阶段，但不一定表示终端可正常上网，需要根据数据业务流程的逻辑关系进行综合判断分析，最终得出明确的投诉原因：

若最后一次DNS失败时，不能解析出所请求的域名地址，对于此次业务的TCP三握手则无法继续，需通过该流程的原因值明确DNS失败的具体原因，从而定位引发这类用户投诉的问题；而当DNS成功后，则进入到TCP三握手环节；

TCP三握手过程中，若用户的SYN_ACK成功率低，可定位为用户访问的SP服务器无法正常响应用户的连接请求而导致。若SYN_ACK成功率正常，而ACK的成功率低，则可定位为用户所处区域存在无线环境较差或所用客户端存在异常，导致SP侧反馈的SYN_ACK信息无法得到响应；

当TCP三握手完成后，便可通过GET动作和SP侧做信息交互，进行上网。终端发生了GET，表示其整个数据业务的流程都是成功的，上网功能正常，但有可能因受无线环境或网站资源差异的影响导致GET速率不高。

进一步地，所述方法还包括：

S4、在定位所述数据业务投诉的原因后，根据数据业务问题的历史解决方案库，确定对应的问题解决方案。

其中，所述历史解决方案库基于历史处理过的投诉问题，其总结了欠费、数据功能异常、SP异常、终端异常等11大类导致用户无法进行数据业务的问题，并针对每类问题都给出相应的解决方案。

在本发明的一个实施例中，所述历史解决方案库如表2所示：

表2：历史解决方案库

在根据所述历史解决方案库确定对应的问题解决方案后，则可将所述问题解决方案反馈至客服人员，或者将所述问题解决方案通过短信/语音告知用户，以及时解决数据业务问题。

本发明实施例提供的数据业务投诉的原因定位方法，可实现数据业务投诉原因的自动分析，并给出相应的解决方案，弥补了数据业务投诉处理自动化分析的技术空白。

在传统的数据业务投诉原因定位方法中，一名经验丰富的专业人员一天可处理的投诉工单大约为50个，而本发明实施例提供的数据业务投诉的原因定位方法在实际应用中，可在30分钟内处理至少100个投诉工单，极大地提升了投诉处理的效率，显著降低了人工成本。因此，本发明实施例提供的数据业务投诉的原因定位方法具有广阔的应用前景。

图4为本发明数据业务投诉的原因定位装置实施例的结构示意图，参看图4，本发明实施例还提供一种数据业务投诉的原因定位装置，包括：获取模块1、过滤模块2以及定位模块3；

所述获取模块1用于根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；

所述过滤模块2用于根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；

所述定位模块3用于根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因。

本发明实施例提出的数据业务投诉的原因定位装置，由于可通过通用数据业务模型过滤出业务数据，并根据预设的决策树投诉原因定位算法，定位投诉的原因，因此，可快速确定投诉的原因；另外，由于使用了定位算法，因此避免了人工因素造成的投诉原因定位不准确的情况，提高了原因定位的准确性。

具体地，所述获取模块1在接到数据业务投诉后，可根据该业务投诉对应的用户号码以及该业务投诉的时间，获取所述时间前的预设时段内，例如12小时内，该用户号码的所有业务的原始信令。

可以理解的是，所述预设时段的具体时长可根据实际情况进行调整，本实施例对此不作限定。

所述过滤模块2可根据通用数据业务模型，对步骤S1中获取到的所述原始信令进行过滤，进而获取所述用户号码的业务数据。

其中，所述通用数据业务模型基于用户进行数据业务需要进行的ATTACH流程、PDP_ACTIVE流程、DNS流程、TCP流程、GET流程、RAU流程、PDP_DEACTIVE流程以及DETACH流程。

可根据通用数据业务模型，对步骤S1中获取到的所述原始信令进行过滤，以获取所述用户号码的业务数据。

具体地，所述过滤模块2具体用于：

1、通过判断ATTACH业务流程中的IMEI是否改变，获取用户更换终端的次数信息。通常，在使用数据业务过程中，若IMEI改变，则表示用户更换了终端。

2、计算在所述预设时段内，终端进行PDP激活、PDP去激活、DNS、TCP、GET和RAU等的尝试次数和成功次数。

3、提取各业务流程的最后一次的进行时间以及是否成功的信息。

所述预设的决策树投诉原因定位算法基于用户进行数据业务的逻辑顺序和时间顺序。所述预设的决策树投诉原因定位算法的流程图如图3所示。

具体地，在所述过滤模块2获取到所述用户号码的业务数据后，所述定位模块3则可通过所述预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因：

S31’、通过ATTACH业务流程中的用户更换终端的次数信息，明确用户在投诉前是否有更换终端的动作，若否，则进行步骤S32；

若是，则进一步判断更换终端后，业务流程是否与更换终端前一致，若否，则可确定为终端问题；若是，则进行步骤S32。

S32’、筛查PDP激活和DNS模型中的用户IP字段，判断用户是否使用了欠费IP段的IP，若否，则进行步骤S33；

若是，则可确定为用户欠费。

S33’、根据终端最后一次进行各业务流程的时间，确定所述终端最后进行的业务流程的类型，并根据该业务流程的类型确定所述数据业务投诉的原因：

若流程为DETACH(去附着)或PDP去激活，则表明用户投诉前未建立正常承载通道而导致无法进行正常业务。

若流程为RAU，则需进一步判断其更新类型。若RAU为周期性路由更新，则表示该终端长时间处于数据业务非激活状态。若RAU为普通路由区更新，则仅是终端的一个正常业务流程，无法单独进行问题定位，需再对其他业务流程进行逻辑分析判断。

若流程为ATTACH(附着)或PDP激活，需获知用户投诉前最后一次的该流程是否成功，若不成功则表示终端没有业务承载功能，无法开展后续的业务流程。若流程成功且用户IP为非欠费地址，则表示终端已经完成承载动作，能够进入业务流程阶段，需通过结合其余流程的分析做出最终判断。

若流程为DNS、TCP或GET，虽然意味着终端可以进入到业务流程阶段，但不一定表示终端可正常上网，需要根据数据业务流程的逻辑关系进行综合判断分析，最终得出明确的投诉原因：

若最后一次DNS失败时，不能解析出所请求的域名地址，对于此次业务的TCP三握手则无法继续，需通过该流程的原因值明确DNS失败的具体原因，从而定位引发这类用户投诉的问题；而当DNS成功后，则进入到TCP三握手环节；

TCP三握手过程中，若用户的SYN_ACK成功率低，可定位为用户访问的SP服务器无法正常响应用户的连接请求而导致。若SYN_ACK成功率正常，而ACK的成功率低，则可定位为用户所处区域存在无线环境较差或所用客户端存在异常，导致SP侧反馈的SYN_ACK信息无法得到响应；

当TCP三握手完成后，便可通过GET动作和SP侧做信息交互，进行上网。终端发生了GET，表示其整个数据业务的流程都是成功的，上网功能正常，但有可能因受无线环境或网站资源差异的影响导致GET速率不高。

进一步地，所述装置还包括解决模块，用于在所述定位模块3定位所述数据业务投诉的原因后，根据数据业务问题的历史解决方案库，确定对应的问题解决方案。

其中，所述历史解决方案库基于历史处理过的投诉问题，其总结了欠费、数据功能异常、SP异常、终端异常等11大类导致用户无法进行数据业务的问题，并针对每类问题都给出相应的解决方案。

在本发明的一个实施例中，所述历史解决方案库如表3所示：

表3：历史解决方案库

在所述解决模块根据所述历史解决方案库确定对应的问题解决方案后，则可将所述问题解决方案反馈至客服人员，或者将所述问题解决方案通过短信/语音告知用户，以及时解决数据业务问题。

本发明实施例提供的数据业务投诉的原因定位装置，可实现数据业务投诉原因的自动分析，并给出相应的解决方案，弥补了数据业务投诉处理自动化分析的技术空白。

在传统的数据业务投诉原因定位方法中，一名经验丰富的专业人员一天可处理的投诉工单大约为50个，而本发明实施例提供的数据业务投诉的原因定位装置在实际应用中，可在30分钟内处理至少100个投诉工单，极大地提升了投诉处理的效率，显著降低了人工成本。因此，本发明实施例提供的数据业务投诉的原因定位装置具有广阔的应用前景。

图5为本发明数据业务投诉的原因定位装置实施例的结构框图，参看图5，所述装置包括：处理器(processor)501、存储器(memory)502、通信接口(CommunicationsInterface)503和总线504；

其中，

所述处理器501、存储器502、通信接口503通过所述总线504完成相互间的通信；

所述通信接口503用于该装置与其他装置的通信设备之间的信息传输；

所述处理器501用于调用所述存储器502中的程序指令，以执行上述各方法实施例所提供的方法，例如包括：根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因。

进一步地，本发明实施例还公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (8)

1.一种数据业务投诉的原因定位方法，其特征在于，包括：

根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；

根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；

根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因；

其中，所述预设的决策树投诉原因定位算法基于用户进行数据业务的逻辑顺序和时间顺序。

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

在定位所述数据业务投诉的原因后，根据数据业务问题的历史解决方案库，确定对应的问题解决方案。

3.根据权利要求1所述的方法，其特征在于，所述通用数据业务模型基于用户进行数据业务需要进行的ATTACH流程、PDP_ACTIVE流程、DNS流程、TCP流程、GET流程、RAU流程、PDP_DEACTIVE流程以及DETACH流程。

4.根据权利要求1所述的方法，其特征在于，所述根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因包括：

通过ATTACH业务流程中的用户更换终端的次数信息，确定用户在投诉前是否有更换终端的动作，若否，则：

筛查PDP激活和DNS模型中的用户IP字段，判断用户是否使用了欠费IP段的IP，若否，则：

根据终端最后一次进行各业务流程的时间，确定所述终端最后进行的业务流程的类型；

根据所述终端最后进行的业务流程的类型确定所述数据业务投诉的原因。

5.一种数据业务投诉的原因定位装置，其特征在于，包括：

获取模块，用于根据数据业务投诉的用户号码以及时间，获取所述时间前的预设时段内所述用户号码对应的所有业务的原始信令；

过滤模块，用于根据通用数据业务模型，对所述原始信令进行过滤，以获取所述用户号码的业务数据；

定位模块，用于根据所述用户号码的业务数据，通过预设的决策树投诉原因定位算法，定位所述数据业务投诉的原因；

其中，所述预设的决策树投诉原因定位算法基于用户进行数据业务的逻辑顺序和时间顺序。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：

解决模块，用于在定位所述数据业务投诉的原因后，根据数据业务问题的历史解决方案库，确定对应的问题解决方案。

7.根据权利要求5所述的装置，其特征在于，所述通用数据业务模型基于用户进行数据业务需要进行的ATTACH流程、PDP_ACTIVE流程、DNS流程、TCP流程、GET流程、RAU流程、PDP_DEACTIVE流程以及DETACH流程。

8.根据权利要求5所述的装置，其特征在于，所述定位模块具体用于：

通过ATTACH业务流程中的用户更换终端的次数信息，确定用户在投诉前是否有更换终端的动作，若否，则：

筛查PDP激活和DNS模型中的用户IP字段，判断用户是否使用了欠费IP段的IP，若否，则：

根据终端最后一次进行各业务流程的时间，确定所述终端最后进行的业务流程的类型；

根据所述终端最后进行的业务流程的类型确定所述数据业务投诉的原因。