本发明涉及服务评价领域,尤其涉及一种评价方法、评价装置、终端、服务器及存储介质。
背景技术:
随着互联网大潮的推进,越来越多的互联网公司都具有属于自己的行业平台。如天猫、淘宝属于电商平台,滴滴属于出行平台,美团属于外卖平台,58同城属于生活服务平台,这些平台连接着买方和卖方,买卖结束后对交易进行评价有利于其他用户判断交易风险,提高交易率。因此众多平台都大力倡导用户对交易或服务进行评价。而作为用户,用户更关心的是交易和服务本身,用户很少会积极主动去评价服务,长此以往平台的评价数据就无法为用户提供准确的判断信息。为了能够获取到足够的评价信息,出现了各种各样的评价邀请手段,如图1和图2中即为现有的评价方法示意图。
然而在现有的服务评价方法中,用户需要进入相应的app、主动寻找评价提示标志后,再点击进入评价页面进行评价,这种评价方法用户抵达评价的入口较深,操作繁琐,影响评价效率的问题。
技术实现要素:
本发明实施例提供一种评价方法、评价装置、终端、服务器及存储介质,用以解决现有技术中评价操作繁琐,影响评价效率的问题。
第一方面,本发明实施例提供一种评价方法,包括:
客户端监测会话深度,依据会话深度向服务端发送评价请求信息;
客户端接收并显示所述服务端返回的邀请评价信息;
客户端将用户的评价信息发送给服务端。
可选的,所述客户端监测会话深度具体包括:客户端检测会话条数,若会话达到预计条数,则客户端向服务端发送评价请求信息。
可选的,所述客户端将用户的评价信息发送给服务端后,还包括:存储评价信息,更新评价状态。
可选的,客户端在向服务端发送评价请求信息之前还包括:检测自身是否已发送过评价请求信息,若检测到没有发送过评价请求信息,则客户端向服务端发送评价请求信息
可选的,所述评价请求信息包含如下信息中的一个或多个:会话双方的id,帖子id,业务id;
或者,所述邀请评价信息包含如下信息中的一个或多个:消息的类型、评价提示文案、历史评价数据、可供评价数据的列表;
或者,所述评价信息包含如下信息中的一个或多个:用户点击的评价星级id、帖子id。
第二方面,本发明实施例提供一种评价方法,所述方法包括:
服务端接收客户端发送的评价请求信息;
服务端发送邀请评价信息给客户端;
服务端接收客户端发送的用户的评价信息。
可选的,所述方法还包括,服务端在接收到评价请求信息后等待预定时间,等待结束后服务端发送评价邀请信息给客户端。
可选的,所述方法还包括服务端检测在所述等待预定时间的时间内是否有过评价记录,若没有评价记录,服务端则发送邀请评价信息给客户端。
第三方面,本发明实施例提供一种评价装置,包括监测模块、第一信息发送模块、第一信息接收模块和提交模块;
所述监测模块,用于监测会话双方的会话深度;
所述第一信息发送模块,用于依据会话深度向服务端发送评价请求信息;
所述信息接收模块,用于接收并显示所述服务端返回的邀请评价信息;
所述提交模块,用于将用户的评价信息发送给所述服务端。
可选的,还包括第一检测模块,所述第一检测模块用于检测是否发送过评价请求信息,若未发送过评价请求信息,则启动第一信息发送模块发送评价请求信息。
可选的,还包括第一信息存储模块,所述第一信息存储模块用于存储评价信息,更新评价信息状态。
第四方面,本发明实施例还提供一种评价装置,包括第二信息接收模块,第二信息发送模块和第二信息存储模块;
所述第二信息接收模块,用于接收客户端发送的评价请求信息;
所述第二信息发送模块,用于发送邀请评价信息给客户端;
所述第二信息存储模块,用于接收客户端发送的用户的评价信息。
可选的,还包括计时模块,所述计时模块用于在第二信息接收模块接收到评价请求信息后计时预定时间,计时结束后启动第二信息发送模块、以发送邀请评价信息。
可选的,还包括第二检测模块,所述第二检测模块用于检测在计时的时间段内,是否有评价记录,若没有评价记录,则启动第二信息发送模块发送评价邀请信息。
第五方面,本发明实施例提供一种终端,所述终端包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述计算机程序被所述处理器执行时实现上述任意一项所述的评价方法的步骤。
第六方面,本发明实施例提供一种服务器,所述服务器包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述计算机程序被所述处理器执行时实现上述任意一项所述的评价方法的步骤。
第七方面,本发明实施例提供一种存储介质,所述存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述中任一项所述的评价方法的步骤。
本发明实施例一种评价方法、评价装置、终端、服务器及存储介质,通过实时监测会话深度,使得评价在服务过程中进行,不会脱离服务场景,且本发明实施例评价入口深度低,用户可以直接点击评价,减少了评价操作的步骤,提高了评价效率。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1为现有评价方法示意图;
图2为现有评价方法示意图;
图3为本发明第一个实施例的评价方法流程图;
图4为本发明第二个实施例的评价方法流程图;
图5为本发明第三个实施例的评价方法流程图;
图6为本发明第四个实施例的评价方法流程图;
图7为本发明第五个实施例的评价装置结构框图;
图8为本发明第六个实施例的评价装置结构框图;
图9为本发明第七个实施例的评价装置结构框图;
图10为本发明第八个实施例的评价装置结构框图;
图11为本发明第十三个实施例的评价系统结构框图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
本发明第一实施例提供一种评价方法,如图3所示,所述方法包括步骤s101-s104:
s101:客户端监测会话深度;
s102:客户端依据会话深度向服务端发送评价请求信息;
本发明实施例中,在监测会话深度时,可以是监测会话的条数,会话的条数可以根据实际需要进行设定,当监测的会话条数达到预定条数后,客户端向服务端发送评价请求信息。
s103:客户端接收并显示所述服务端返回的邀请评价信息;
s104:客户端将用户的评价信息发送给服务端。
在具体实现过程中,s104中,客户端在提交评价消息给服务器后,客户端还对评价信息进行存储,并更新评价状态,防止用户重复评价。
本发明实施例通过监测会话深度,使得评价在服务过程中进行,不会脱离服务场景,且本实施例评价入口深度低,用户可以直接点击评价,减少了评价操作的步骤。
本发明第二实施例提供一种评价方法,结合图4,包括如下步骤:
s201:客户端监测会话深度,当监测到会话条数达到预定条数后,执行步骤s202;
s202:客户端检测是否发送过评价请求信息给客服所使用的服务端,若未发送过,则执行步骤s203;
s203:客户端发送评价请求信息给服务端;
s204:客户端接收并显示所述服务端返回的邀请评价信息;
s205:客户端将用户的评价信息发送给服务端;
s206:客户端保存评价消息。
具体实现时,评价请求信息可以根据实际需要包括如下信息中的一个或多个:会话双方的id,帖子id,业务id。
邀请评价请求信息可以根据实际需要包括如下信息中的一个或多个:消息的类型、评价提示文案、历史评价数据、可供评价数据的列表。
评价信息可以根据实际需要包括如下信息中的一个或多个:用户点击的评价星级id、帖子id。
本实施例中通过检测之前是否发送过评价请求信息,防止之前发送过评价请求信息,而又再次发送评价请求信息,造成多次发送的结果;其次,本实施例在对邀请评价信息进行展示时,用户选择性的进行评价,降低了对用户的干扰,如果用户不想评价,则无需任何操作。
本发明第三个实施例提供一种评价方法,如图5所示,所述方法包括:
s301:服务端接收客户端发送的评价请求信息;
s302:服务端发送邀请评价信息给客户端;
s303:服务端接收客户端发送的用户的评价信息。
本发明服务端在接收到评价请求信息后发送邀请评价信息给客户端使得邀请评价信息的发送权掌握在服务端手中。
本发明第四个实施例提供一种评价方法,如图6所示,所述方法包括:
s401:服务端接收客户端发送的评价请求信息;
s402:服务端在接收到评价请求信息后还包括等待预定时间;
s403:服务端检测在等待预定时间的时间内是否有过评价记录,若没有评价记录,执行步骤s404。
s404:服务端发送邀请评价信息给客户端;
s405:服务端接收客户端发送的用户的评价信息并进行保存。
本实施例在具体实现时,评价请求信息可以根据实际需要包括如下信息中的一个或多个:会话双方的id,帖子id,业务id。
邀请评价请求信息可以根据实际需要包括如下信息中的一个或多个:消息的类型、评价提示文案、历史评价数据、可供评价数据的列表。
评价信息可以根据实际需要包括如下信息中的一个或多个:用户点击的评价星级id、帖子id。
本发明服务端在接收到评价请求信息后通过等待预定时间,检测在等待的时间段内是否有评价记录,防止用户通过其他途径进行评价,而造成二次评价的结果。
本发明第五个实施例提供一种评价装置,如图7所示,包括监测模块101、第一信息发送模块102、第一信息接收模块103和提交模块104;
监测模块101,用于监测会话双方的会话深度;
第一信息发送模块102,用于依据会话深度向服务端发送评价请求信息;
第一信息接收模块103,用于接收并显示服务端返回的邀请评价信息;
提交模块104,用于将用户的评价信息发送给服务端。
本发明实施例中监测模块具体用于监测会话双方的会话条数,当会话条数达到6条时,第一信息发送模块发送出评价请求信息。具体的,会话条数可以根据实际需要进行调整。
本发明实施例利用监测模块监测会话深度,使得评价在服务过程中进行,不会脱离服务场景,且本实施例评价入口深度低,用户可以直接点击评价,减少了评价操作的步骤。
本发明第六个实施例提供一种评价装置,如图8所示,包括监测模块201、第一检测模块202、第一信息发送模块203、第一信息接收模块204、提交模块104和第一信息存储模块205,
监测模块201,用于监测会话双方的会话深度;
第一检测模块202用于检测是否发送过评价请求信息,若未发送过评价请求信息。
第一信息发送模块203,用于依据会话深度和第一检测模块的检测结果发送评价请求信息;即,当会话监测模块检测会话双方的会话条数达到6条时,且第一检测模块检测之前没有发送过评价请求信息,则第一信息发送模块发送评价请求信息,
第一信息接收模块204,用于接收邀请评价信息并将接收到的邀请评价信息进行展示;
提交模块205,用于提交评价信息。
第一信息存储模块206,用于存储评价信息,更新评价信息状态。
本发明实施例中通过设置的第一检测模块能够检测之前石否发送过评价请求信息,防止之前已经发送过评价请求信息又再次发送,造成多次发送的结果。
本发明第七个实施例提供一种评价装置,如图9所示,包括第二信息接收模块301,第二信息发送模块302和第二信息存储模块303;
第二信息接收模块301,用于接收客户端发送的评价请求信息;
第二信息发送模块302,用于发送邀请评价信息给客户端;
第二信息存储模块303,用于接收客户端发送的用户的评价信息。
本发明实施例中利用设置的第二信息接收模块和第二信息发送模块,第二信息接收模块在接收到评价请求信息后,第二信息发送模块发送出评价邀请信息,使得评价邀请信息的发送权掌握在服务端的手中。
本发明第八个实施例提供一种评价装置,如图10所示,包括第二信息接收模块401、计时模块402、第二检测模块403、第二信息发送模块404和第二信息存储模块405;
第二信息接收模块401,用于接收客户端发送的评价请求信息;
计时模块402,用于在第二信息接收模块接收到评价请求信息后计时预定时间;
第二检测模块403,用于检测在计时的时间段内是否有过评价记录;
第二信息发送模块404,用于发送邀请评价信息给客户端;
第二信息存储模块405,用于接收客户端发送的评价信息并将其进行保存。
本发明实施例中利用增设的计时模块来进行计时,计时时间可以调整为5分钟或10分钟或根据实际需要调整为其他时间,使得邀请评价信息发送时机能够根据实际需要进行调整。当用户已经评价过时,利用设置的第二检测模块能够对之前评价记录进行检测,避免了用户之前已经评价过又再次发送评价邀请信息;其次,本实施例降低了对用户的干扰,如果用户不想评价,则无需任何操作。
本发明第九个实施例提供一种终端,可以作为实体装置来理解,可以是移动终端、计算机、平板电子设备,其包括处理器以及存储有所述处理器可执行指令的存储器,当所述指令被处理器执行时,执行如下步骤:
步骤1,监测会话深度,依据会话深度向服务端发送评价请求信息;
步骤2,接收并显示所述服务端返回的邀请评价信息
步骤3,将用户的评价信息发送给所述服务端。
上述方法步骤的具体实施例过程可参见第一、二实施例,本实施例在此不再重复赘述。
本发明第十个实施例提供一种服务器,可以作为实体装置来理解,包括处理器以及存储有所述处理器可执行指令的存储器,当所述指令被处理器执行时,执行如下操作:
接收客户端发送的评价请求信息;
发送邀请评价信息给客户端;
接收客户端发送的用户的评价信息。
上述方法步骤的具体实施例过程可参见第三、四实施例,本实施例在此不再重复赘述。
本发明第十一个实施例,提供一种提供存储介质,所述存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如下方法步骤:客户端监测会话深度,依据会话深度向服务端发送评价请求信息;
客户端接收并显示所述服务端返回的邀请评价信息;
客户端将用户的评价信息发送给所述服务端。
上述方法步骤的具体实施例过程可参见第一个实施例或第二个实施例,本实施例在此不再重复赘述。
本发明第十二个实施例,提供一种存储介质,所述存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如下方法步骤:
服务端接收客户端发送的评价请求信息;
服务端发送邀请评价信息给客户端;
服务端接收客户端发送的用户的评价信息。
上述方法步骤的具体实施例过程可参见第三个实施例或第四个实施例,本实施例在此不再重复赘述。
本发明第十三个实施例,提供一种评价系统,如图11所示,包括客户端和与客户端通讯连接的服务端,
所述客户端用于:
1)、监测用户会话深度。
2)、当会话条数满足6条时发送评价消息请求。
3)、接收并展示邀请评价消息。
4)、提交评价信息,将评价数据传递到服务端。
5)、更新并存储评价消息状态。
所述服务端用于:
1)、等待客户端发起评价请求。
2)、等待10分钟。
3)、检测在此10分钟内,使用用户已经通过其他途径进行了评价。
4)、如果没有评价过,则发送评价消息。
5)、存储数据。
本实施例中,监测用户会话深度具体包括:监听用户会话深度是指当用户在当前会话内有新的消息进行收发时,客户端查看当前会话的条数是否达到6条。如果达到6条,那么则再检测客户端是否已经发起过评价消息请求。如果用户发起过该请求或正在请求中,则不再发起请求。
接受并展示评价消息具体包括:客户端收到消息后,解析数据并展示评价消息。
发送评价信息具体包括:将用户点击的评价数据传递到服务端。
更新并存储评价消息状态具体包括:更新并存储评价消息状态,防止用户推出当前会话再次进入时重复点击评价消息。如果不更新不存储,那么用户会重复点击和发送评价数据。
服务端检测是否已经产生过评价具体包括:在服务端向客户端发送消息前,需要检测一次是否已经产生过评价,如果产生过评价,那么不应该发送评价消息。比如,用户通过点击评价按钮,进入到评价页面进行评价,如果再向用户发送评价消息,显然会造成二次评价,这样是不合适的。
发送评价消息具体包括:服务端向会话双方的客户方发送评价消息,引导客户对商家或经纪人进行评价。
本实施例中,数据格式a:客户端端在请求服务端发送消息时,需要将客户端此时的会话场景告诉服务端,信息包括:会话双方的id,帖子id,业务id。
数据格式b:服务端在发送消息是需要指定如下信息:消息的类型、评价提示文案、历史评价数据、可供评价数据的列表:
数据格式c:客户端在提交评价信息时,需要如下数据:用户点击的评价星级id、帖子id:
本发明实施例具有如下有益效果:
1)、降低了评价的深度,用户可以直接点击评价。
2)、降低了对用户的打扰,如果用户不想评价,则无需任何操作。
3)、实现了高效的评价引导,在会话进行过程中引导用户进行评价。
4)、评价消息的发送权在服务端手中,服务端可以调整评价消息的发送时机。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
上面结合附图对本发明的实施例进行了描述,但是本发明并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本发明的启示下,在不脱离本发明宗旨和权利要求所保护的范围情况下,还可做出很多形式,这些均属于本发明的保护之内。