著录项信息
专利名称 | 一种网络用户识别的方法及其应用服务器 |
申请号 | CN201110300817.7 | 申请日期 | 2011-09-30 |
法律状态 | 权利终止 | 申报国家 | 中国 |
公开/公告日 | 2012-01-25 | 公开/公告号 | CN102333092A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04L29/06 | IPC分类号 | H;0;4;L;2;9;/;0;6;;;H;0;4;L;2;9;/;0;8查看分类表>
|
申请人 | 北京亿赞普网络技术有限公司 | 申请人地址 | 北京市海淀区中关村南大街甲18号院2号楼1607
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 亿赞普(北京)科技有限公司,亿赞普(中国)网络技术有限公司 | 当前权利人 | 亿赞普(北京)科技有限公司,亿赞普(中国)网络技术有限公司 |
发明人 | 郑芳只;罗峰;黄苏支;李娜 |
代理机构 | 北京润泽恒知识产权代理有限公司 | 代理人 | 苏培华 |
摘要
本申请提供了一种网络用户识别的方法及其应用服务器,其中的方法具体包括:当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明;依据所述用户身份证明恢复相应的cookie;依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息。本申请能够在cookie被删除的情况下,提高用户识别的准确度。
1.一种网络用户识别的方法,其特征在于包括如下步骤:
当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明;其中,所述用户标识包括:ADSL的账号网络用户名,和/或,专线用户的用户IP地址;
依据所述用户身份证明恢复相应的cookie;
依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息;
其中,所述依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明的步骤,具体包括:
依据用户标识和用户代理,在应用服务器的本地缓存中查询是否存在相应的客户端用户;
在缓存命中成功时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;
在缓存命中失败时,依据所述用户标识和用户代理在远程服务器中查询是否存在相应的客户端用户;
在远程服务器中存在相应的客户端用户时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;
在远程服务器中不存在相应的客户端用户时,在远程服务器中依据所述用户标识和用户代理产生一个新客户端用户的用户身份证明。
2.如权利要求1所述的方法,其特征在于,在所述当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明的步骤之前,所述方法还包括:
当cookie在所述用户上网行为信息中存在时,依据cookie中的用户身份证明获取最新的用户代理。
3.如权利要求2所述的方法,其特征在于,所述依据cookie中的用户身份证明获取最新的用户代理的步骤,包括:
依据cookie中的用户身份证明在应用服务器的本地缓存中查询是否存在相应的客户端用户;
在缓存命中成功时,依据应用服务器的本地缓存查询结果获取应用服务器的本地缓存用户信息,所述应用服务器的本地缓存用户信息中包括有用户代理;
将应用服务器的本地缓存用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述应用服务器的本地缓存用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述应用服务器的本地缓存用户信息中的用户代理进行更新;
在缓存命中失败时,依据cookie中的用户身份证明在远程服务器中查询相应的客户端用户的识别信息,并依据查询结果获取远程存储用户信息,所述远程存储用户信息中包括有用户代理;
将所述远程存储用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述远程存储用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述远程存储用户信息中的用户代理进行更新。
4.如权利要求1至3中任一项所述的方法,其特征在于,还包括:
在用户身份证明存在的情况下,在应用服务器端和/或远程服务器端对所述用户身份证明、用户标识和当前用户代理进行关联存储。
5.一种应用服务器,其特征在于,包括:
第一查询装置,用于当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明;其中,所述用户标识包括:ADSL的账号网络用户名,和/或,专线用户的用户IP地址;
恢复装置,用于依据所述用户身份证明恢复相应的cookie;
识别装置,用于依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息
其中,所述第一查询装置,包括:
第一缓存查找模块,用于依据用户标识和用户代理在应用服务器的本地缓存中查询是否存在相应的客户端用户;
第一获取模块,用于在缓存命中成功时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;
第一查询请求模块,用于在缓存命中失败时,向远程服务器发送第一查询请求;
所述远程服务器包括:
第一远程查询装置,用于依据所述第一查询请求,通过所述用户标识和用户代理在远程服务器中查询是否存在相应的客户端用户;
证明获取装置,用于在远程服务器中存在相应的客户端用户时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;
证明产生装置,用于在远程服务器中不存在相应的客户端用户时,在远程服务器中依据所述用户标识和用户代理产生一个新客户端用户的用户身份证明;
第一返回装置,用于将所述证明获取装置或证明产生装置输出的用户身份证明,返回给所述应用服务器。
6.如权利要求5所述的应用服务器,其特征在于,还包括:
用户代理获取装置,用于在第一查询装置执行查询操作前,当cookie在所述用户上网行为信息中存在时,依据cookie中的用户身份证明获取最新的用户代理。
7.如权利要求6所述的应用服务器,其特征在于,所述用户代理获取装置,包括:
第二缓存查找模块,用于依据cookie中的用户身份证明在应用服务器的本地缓存中查询是否存在相应的客户端用户;
第二获取模块,用于在缓存命中成功时,依据应用服务器的本地缓存查询结果获取应用服务器的本地缓存用户信息,所述应用服务器的本地缓存用户信息中包括有用户代理;
本地匹配模块,用于将应用服务器的本地缓存用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述应用服务器的本地缓存用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述应用服务器的本地缓存用户信息中的用户代理进行更新;
第二查询请求模块,用于在缓存命中失败时,向远程服务器发送第二查询请求;
所述远程服务器包括:
第二远程查找装置,用于在缓存命中失败时,依据cookie中的用户身份证明在远程服务器中查询相应的客户端用户的识别信息,并依据查询结果获取远程存储用户信息,所述远程存储用户信息中包括有用户代理;
远程匹配装置,用于将所述远程存储用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述远程存储用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述远程存储用户信息中的用户代理进行更新;
第二返回装置,用于将所述远程匹配装置输出的最新的用户代理,返回给所述应用服务器。
8.如权利要求5至7中任一项所述的应用服务器,其特征在于,还包括:
关联存储装置,用于在用户身份证明存在的情况下,在应用服务器端对所述用户身份证明、用户标识和当前用户代理进行关联存储。
一种网络用户识别的方法及其应用服务器\n技术领域\n[0001] 本申请涉及网络通信技术领域,特别是涉及一种网络用户识别的方法及其应用服务器。\n背景技术\n[0002] 目前,互联网规模和覆盖面的迅速增长带来了信息超载问题:过量信息的同时呈现使得用户无法快速从中获取对自己有用的部分,信息使用效率反而降低。为了降低用户享用信息的成本,需要向用户推荐所需要的信息。其中,向用户推荐信息的第一步就是识别用户,因为只有识别了每个用户,才能进一步根据用户以往行为,进行挖掘、计算和推荐信息。\n[0003] 以网站为例,在识别了每个用户后,不但能够更加清晰地了解到底有多少用户访问了网站,分辨他们是谁(用户ID、邮箱、性别年龄等);同时也能够更好地跟踪这些用户,发现他们的行为特征、兴趣爱好及个性化的设置等,以便于更好地把握用户需求,提升用户体验。\n[0004] 现有技术一种典型的用户识别方法是基于cookie(用于存储用户私有信息的小文本文件)的用户识别。当通过自定义Apache日志格式或者JavaScript的方法获得用户cookie时,其实已经找到了一个非常有效的用户识别的手段。cookie在未被清除的前提下可以认为是跟某个访问客户端电脑绑定的,所以基于cookie的用户识别的准确度比较高。\n[0005] 但是,基于cookie的用户识别当然也存在缺陷,由于浏览器会自动把cookie保存到客户端本地对应的某个目录下,所以最常见的缺陷就是cookie被客户端用户删除而导致客户端用户无法与原先记录实现对应;同时由于客户端电脑会被共用,或者客户端用户会在不同的电脑上访问网站,这个时候cookie就无法直接对应到该客户端用户。\n[0006] 总之,需要本领域技术人员迫切解决的一个技术问题就是:如何能够在cookie被删除的情况下,实现较高精度的用户识别。\n发明内容\n[0007] 本申请所要解决的技术问题是提供一种网络用户识别的方法、一种应用服务器,能够在cookie被删除的情况下,提高用户识别的准确度。\n[0008] 为了解决上述问题,本申请公开了一种网络用户识别的方法,包括如下步骤:\n[0009] 当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明;其中,所述用户标识包括:\nADSL的账号网络用户名,和/或,专线用户的用户IP地址;\n[0010] 依据所述用户身份证明恢复相应的cookie;\n[0011] 依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息,[0012] 其中,所述依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明的步骤,具体包括:\n[0013] 依据用户标识和用户代理,在应用服务器的本地缓存中查询是否存在相应的客户端用户;\n[0014] 在缓存命中成功时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;\n[0015] 在缓存命中失败时,依据所述用户标识和用户代理在远程服务器中查询是否存在相应的客户端用户;\n[0016] 在远程服务器中存在相应的客户端用户时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;\n[0017] 在远程服务器中不存在相应的客户端用户时,在远程服务器中依据所述用户标识和用户代理产生一个新客户端用户的用户身份证明。\n[0018] 优选的,在所述当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明的步骤之前,所述方法还包括:\n[0019] 当cookie在所述用户上网行为信息中存在时,依据cookie中的用户身份证明获取最新的用户代理。\n[0020] 优选的,所述依据cookie中的用户身份证明获取最新的用户代理的步骤,包括:\n[0021] 依据cookie中的用户身份证明在应用服务器的本地缓存中查询是否存在相应的客户端用户;\n[0022] 在缓存命中成功时,依据应用服务器的本地缓存查询结果获取应用服务器的本地缓存用户信息,所述应用服务器的本地缓存用户信息中包括有用户代理;\n[0023] 将应用服务器的本地缓存用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述应用服务器的本地缓存用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述应用服务器的本地缓存用户信息中的用户代理进行更新;\n[0024] 在缓存命中失败时,依据cookie中的用户身份证明在远程服务器中查询相应的客户端用户的识别信息,并依据查询结果获取远程存储用户信息,所述远程存储用户信息中包括有用户代理;\n[0025] 将所述远程存储用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述远程存储用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述远程存储用户信息中的用户代理进行更新。\n[0026] 优选的,所述方法还包括:\n[0027] 在用户身份证明存在的情况下,在应用服务器端和/或远程服务器端对所述用户身份证明、用户标识和当前用户代理进行关联存储。\n[0028] 另一方面,本申请还公开了一种应用服务器,包括:\n[0029] 第一查询装置,用于当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明;其中,所述用户标识包括:ADSL的账号网络用户名,和/或,专线用户的用户IP地址;\n[0030] 恢复装置,用于依据所述用户身份证明恢复相应的cookie;\n[0031] 识别装置,用于依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息;\n[0032] 其中,所述第一查询装置,包括:\n[0033] 第一缓存查找模块,用于依据用户标识和用户代理在应用服务器的本地缓存中查询是否存在相应的客户端用户;\n[0034] 第一获取模块,用于在缓存命中成功时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;\n[0035] 第一查询请求模块,用于在缓存命中失败时,向远程服务器发送第一查询请求;\n[0036] 所述远程服务器包括:\n[0037] 第一远程查询装置,用于依据所述第一查询请求,通过所述用户标识和用户代理在远程服务器中查询是否存在相应的客户端用户;\n[0038] 证明获取装置,用于在远程服务器中存在相应的客户端用户时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;\n[0039] 证明产生装置,用于在远程服务器中不存在相应的客户端用户时,在远程服务器中依据所述用户标识和用户代理产生一个新客户端用户的用户身份证明;\n[0040] 第一返回装置,用于将所述证明获取装置或证明产生装置输出的用户身份证明,返回给所述应用服务器。\n[0041] 优选的,所述应用服务器还包括:\n[0042] 用户代理获取装置,用于在第一查询装置执行查询操作前,当cookie在所述用户上网行为信息中存在时,依据cookie中的用户身份证明获取最新的用户代理。\n[0043] 优选的,所述用户代理获取装置,包括:\n[0044] 第二缓存查找模块,用于依据cookie中的用户身份证明在应用服务器的本地缓存中查询是否存在相应的客户端用户;\n[0045] 第二获取模块,用于在缓存命中成功时,依据应用服务器的本地缓存查询结果获取应用服务器的本地缓存用户信息,所述应用服务器的本地缓存用户信息中包括有用户代理;\n[0046] 本地匹配模块,用于将应用服务器的本地缓存用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述应用服务器的本地缓存用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述应用服务器的本地缓存用户信息中的用户代理进行更新;\n[0047] 第二查询请求模块,用于在缓存命中失败时,向远程服务器发送第二查询请求;\n[0048] 所述远程服务器包括:\n[0049] 第二远程查找装置,用于在缓存命中失败时,依据cookie中的用户身份证明在远程服务器中查询相应的客户端用户的识别信息,并依据查询结果获取远程存储用户信息,所述远程存储用户信息中包括有用户代理;\n[0050] 远程匹配装置,用于将所述远程存储用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述远程存储用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述远程存储用户信息中的用户代理进行更新;\n[0051] 第二返回装置,用于将所述远程匹配装置输出的最新的用户代理,返回给所述应用服务器。\n[0052] 优选的,所述应用服务器还包括:\n[0053] 关联存储装置,用于在用户身份证明存在的情况下,在应用服务器端对所述用户身份证明、用户标识和当前用户代理进行关联存储。\n[0054] 与现有技术相比,本申请具有以下优点:\n[0055] 本申请在cookie被删除的情况下,首先依据用户标识和用户代理恢复被删除的cookie,然后依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息。由于基于cookie的用户识别的准确度高于基于IP+用户代理的用户识别的准确度,故本申请能够在cookie被删除的情况下,提高用户识别的准确度;\n[0056] 其次,由于本申请能够克服现有技术中cookie删除问题带来的用户识别准确度欠高的问题,精准定位和跟踪基于客户端的用户;这样,能够进一步依据识别结果,为用户推荐最有效和价值信息,从而能够解决用户信息过载问题,降低用户享用信息成本;\n[0057] 再者,本申请还能依据cookie中的用户身份证明获取最新的用户代理,并依据相应客户端用户的用户标识和最新的用户代理查询得到相应的用户身份证明,以避免用户代理发生变化对cookie恢复的影响,从而能够进一步提高用户识别的准确度。\n附图说明\n[0058] 图1是本申请一种网络用户识别的方法实施例1的流程图;\n[0059] 图2是本申请一种远程服务器基于用户标识和用户代理进行查询的流程图;\n[0060] 图3是本申请一种网络用户识别的方法实施例2的流程图;\n[0061] 图4是本申请一种远程服务器基于cookie中用户身份证明进行查询的流程图;\n[0062] 图5是本申请一种用户识别时序图示例;\n[0063] 图6是本申请一种客户端6A和应用服务器6B的交互示意图;\n[0064] 图7是本申请一种应用服务器实施例的结构图。\n具体实施方式\n[0065] 为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。\n[0066] 本申请实施例的核心构思之一在于,在客户端用户cookie被删除的情况下,在应用服务器端依据用户标识和用户代理恢复被删除的cookie;具体而言,当cookie在相应客户端用户的用户上网行为信息中不存在时,首先依据相应客户端用户的用户标识和用户代理,在应用服务器端查询得到相应的用户身份证明(UID,User Identification),然后依据所述用户身份证明恢复相应的cookie,最后依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息。这样,本申请能够在cookie被删除的情况下,提高用户识别的准确度。\n[0067] 首先,关于cookie的起源进行一个简单的介绍。某些网站为了辨别用户身份、进行session(会话)跟踪,故利用cookie在客户端上储存用户私有信息(通常经过加密);\n其中,cookie中最重要的用户私有信息就是作为用户唯一标识的用户身份证明。\n[0068] 在实际中,在客户端用户首次访问网站的应用服务器时,应用服务器会针对该客户端用户分配一个独一无二的用户身份证明,并依据该用户身份证明生成cookie,然后在响应消息中将cookie传递给客户端用户。浏览器会自动把cookie保存到本地对应的某个目录下。这样,只需在后续的每次访问请求中把cookie传递给应用服务器,应用服务器就能够依据cookie中的用户身份证明知道这次访问请求是哪个客户端用户发送的。\n[0069] 下面通过较优实施例具体介绍本申请的技术方案,需要说明的是,较优实施例并不应理解为对本发明的限制。另外,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。\n[0070] 参照图1,示出了本申请一种网络用户识别的方法实施例1的流程图,具体可以包括:\n[0071] 步骤101、当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明。\n[0072] 具体地,应用服务器在接收到客户端用户的访问请求时,可以依据用户访问请求中的报文数据,解析得到相应的用户上网行为信息,其中,所述用户上网行为信息通常可以包括用户IP(user_ip)、用户代理(UA,UserAgent)、cookie、访问网站域名(host)、访问网站页面信息(统一资源定位符)和/或用户上次来源(referer)。\n[0073] 其中,用户代理是指能够帮助服务器识别其客户端用户的操作系统及版本、CPU类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等的信息。\n[0074] 如果应用服务器解析的用户上网行为信息中不存在cookie,则认为报文数据中没有携带cookie,此时,一种可能性是用户的cookie被客户端用户删除,还有一种可能性是该客户端用户的身份是新用户或者首次访问该网站。此时,可以应用本申请对该客户端用户的身份进行识别,进一步恢复用户和产生新用户。\n[0075] 对于一个上网用户而言,其用户标识是唯一的,且不发生变化的。具体地,在实际中,对于专线用户的用户标识而言,由于其用户IP地址是固定的,不发生变化的,能够标识唯一的用户,故此时用户IP地址可以作为客户端用户的用户标识。对于ADSL(非对称数字用户环路,Asymmetric Digital Subscriber Line)等非专线用户而言,由于IP是动态的,无法进行唯一标示,而ADSL的账号网络用户名(user_name)固定不变,且能够标识唯一的用户,故此时,ADSL的账号网络用户名可以作为客户端用户的用户标识。\n[0076] 在实际中,在接收到客户端用户的上网请求时,AAA(验证、授权和记账,Authentication、Authorization、Accounting)服务器会生成相应的计费报文;而应用服务器在接收到所述计费报文后,可以根据所述计费报文,解析得到相应的用户基本信息,所述用户基本信息具体可以包括网络用户名(即ADSL的账号网络用户名)和/或用户IP地址。\n[0077] 在某些情况下,应用服务器可以针对客户端用户,直接从所述用户基本信息中获取网络用户名或用户IP作为用户标识,以及从所述用户上网行为信息中获取用户代理,然后,依据相应的用户标识和用户代理,在应用服务器端查询得到相应的用户身份证明即可。\n[0078] 此种情况下,为了便于在线查询,在本申请的一种优选实施例中,可以在离线情况下,对所述用户身份证明、用户标识和当前用户代理进行关联存储,相应地,所述方法还可以包括:\n[0079] 在用户身份证明存在的情况下,在应用服务器和/或远程服务器端对所述用户身份证明、用户标识和当前用户代理进行关联存储。\n[0080] 这样,只需以用户标识与当前用户代理的组合关键字,在应用服务器和/或远程服务器端的数据库中进行查询匹配即可查询到用户身份证明。\n[0081] 在某些特殊情况下,应用服务器可能无法直接获取网络用户名和用户代理,则需要依据用户IP关联,查找到网络用户名和用户代理,然后,依据相应的用户标识和用户代理查询得到相应的用户身份证明即可。\n[0082] 此种情况下,为了便于在线查询,在本申请的一种优选实施例中,还可以在离线情况下,对所述用户身份证明、用户标识和当前用户代理进行关联存储,所述方法还可以包括:\n[0083] 在用户身份证明存在的情况下,在应用服务器和/或远程服务器端对所述用户IP、用户身份证明、用户标识和当前用户代理进行关联存储。\n[0084] 如下示出了此种情况下一种存储结构的示例:\n[0085] \n[0086] 在本申请一种优选实施例中,所述步骤101可以进一步包括:\n[0087] 当cookie在相应客户端用户的用户上网行为信息中不存在时,依据用户标识和用户代理,在应用服务器的本地缓存中查询是否存在相应的客户端用户,若缓存命中成功,则依据所述用户标识和用户代理获取该客户端用户的用户身份证明。需要说明的是,应用服务器的本地缓存仅保留近期的数据,例如仅保留1天或2天的数据,也可以仅保留当前正在上网的,在线的用户数据;而其余历史数据均保存在远程服务器中,例如当前已断网离线的用户。\n[0088] 本优选实施例在应用服务器的本地缓存进行查找基于用户标识和用户代理的客户端用户,如果能查找到,则表明该客户端用户近期出现在应用服务器中,于是,可以获取作为用户唯一标志的用户身份证明(用户身份证明在cookie信息中,作为cookie内容一部分信息),同时也证明该客户端用户删除了cookie信息,需要进一步恢复cookie。\n[0089] 在本申请的另一种优选实施例中,所述依据相应客户端用户的用户标识和用户代理查询得到相应的用户身份证明的步骤,还可以包括:\n[0090] 在缓存命中失败时,依据所述用户标识和用户代理在远程服务器中查询是否存在相应的客户端用户;需要说明的是,在缓存命中失败,也即当应用服务器的本地缓存中查找不到时,表示客户端用户近期没有出现该应用服务器中,因此需要去远程服务器的历史数据中查询。\n[0091] 在远程服务器中存在相应的客户端用户时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;\n[0092] 在远程服务器中不存在相应的客户端用户时,在远程服务器中依据所述用户标识和用户代理产生一个新客户端用户的用户身份证明。在实际应用中,还会依据该用户身份证明生成cookie,然后在响应消息中将cookie传递给应用服务器。\n[0093] 在具体实现中,所述远程服务器可以包括UDC(用户数据中心,user data center)。例如,可以在UDC的数据库中基于网络用户名和用户代理查找相应的客户端用户,如果查找到,则获取用户信息【网络用户名、用户代理、user_ip和用户身份证明】,并将用户身份证明反馈给应用服务器,同时也说明该客户端用户删除了cookie信息,需要进一步恢复用户cookie;如果没有查找到,则说明该客户端用户是新用户,第一次访问应用服务器,于是,会分配一个全局唯一标识一个用户的用户身份证明,并初始化用户信息【网络用户名、用户代理、user_ip和用户身份证明】,同时将用户身份证明反馈给应用服务器。\n[0094] 参照图2,示出了本申请一种远程服务器基于用户标识和用户代理进行查询的流程图,具体可以包括:\n[0095] 步骤201、接收来自应用服务器的适配消息,所述适配消息中包括有网络用户名和用户代理;\n[0096] 步骤202、基于网络用户名和用户代理在数据库中查询是否存在相应的客户端用户,若是,则执行步骤203;否则,执行步骤204;\n[0097] 步骤203、获取用户信息:网络用户名、用户代理、cookie,并转向步骤206;\n[0098] 客户端用户存在时,说明该客户端用户已经进入到应用服务器内部,用户cookie被删除,于是可以通过网络用户名和用户代理来恢复cookie。\n[0099] 步骤204、根据网络用户名和用户代理,在数据库中产生用户唯一标识用户身份证明;\n[0100] 步骤205、在数据库的用户表项中填充网络用户名、用户代理、cookie,并转向步骤\n206;\n[0101] 步骤206、将cookie中的用户身份证明返回给应用服务器。\n[0102] 步骤102、依据所述用户身份证明恢复相应的cookie;\n[0103] 在具体实现中,所述依据所述用户身份证明恢复相应的cookie的步骤可以为,应用服务器依据用户身份证明生成相应的cookie,并种植到客户端。这样,当客户端用户当用户再次访问应用服务器时,会携带cookie信息,使得应用服务器知道这次访问请求是哪个客户端用户发送的。其中,所述种植过程可以为,通过P3P协议(隐私偏好平台,Platform for Privacy Preferences)将cookie存储在客户端的固定文本,这里,P3P是允许网络站点来宣告它们收集的关于浏览用户他们的意向使用的信息的一个协议。\n[0104] 步骤103、依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息。\n[0105] 在实际中,作为识别结果的客户端用户的信息通常可以包括如下信息中的一者或多者:\n[0106] (1)用户识别信息:\n[0107] 具体可以包括网络用户名、用户IP、用户代理、cookie等。\n[0108] (2)基础信息静态属性:\n[0109] 具体可以包括:年龄、教育程度、薪资情况、学校和职业等。\n[0110] (3)动态信息:\n[0111] 具体可以包括兴趣组、投送广告状态等。\n[0112] 在实际应用中,对于一个需要用户ID注册登录的网站来说,用户唯一标识符的选择可以遵从以下顺序:当用户注册登录时以用户ID为准,当用户在未登录状态浏览时以用户的cookie为准,当用户未登录且cookie被删除的情况下使用本方法,以提高用户识别的准确度。\n[0113] 虽然现有技术在cookie被删除的情况下,可以基于IP+用户代理进行用户识别,但是由于IP和用户代理均是不断变化的,所以不能精准定位和识别出用户,导致识别的准确度欠高。而本申请在cookie被删除的情况下,首先依据用户标识和用户代理恢复被删除的cookie,然后依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息。由于基于cookie的用户识别的准确度高于基于IP+用户代理的用户识别的准确度,故本申请能够在cookie被删除的情况下,提高用户识别的准确度。\n[0114] 进一步,由于本申请能够克服现有技术中cookie删除问题带来的用户识别准确度欠高的问题,精准定位和跟踪基于客户端的用户;这样,能够进一步依据识别结果,为用户推荐最有效和价值信息,从而能够解决用户信息过载问题,降低用户享用信息成本。\n[0115] 参照图3,示出了本申请一种网络用户识别的方法实施例2的流程图,具体可以包括:\n[0116] 步骤301、当cookie在所述用户上网行为信息中存在时,依据cookie中的用户身份证明获取最新的用户代理;\n[0117] 步骤302、当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和最新的用户代理,查询得到相应的用户身份证明;\n[0118] 步骤303、依据所述用户身份证明恢复相应的cookie;\n[0119] 步骤304、依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息。\n[0120] 由于用户代理表示浏览器信息、插件信息、操作系统信息等,这样,当其中任何信息发生变化时,用户代理内容都会发生变化,比如版本升级,安装插件、或插件升级等行为都会导致用户代理内容发生变化。\n[0121] 为了避免用户代理内容发生变化对cookie恢复的影响,本实施例依据cookie中的用户身份证明获取最新的用户代理,实时更新所述用户代理,以保证所述用户代理总是为最新的状态,以便于依据相应客户端用户的用户标识和最新的用户代理查询得到相应的用户身份证明,以避免用户代理发生变化,对cookie恢复产生影响,从而能够进一步提高用户识别的准确度。\n[0122] 在本申请的一种优选实施例中,所述依据cookie中的用户身份证明获取最新的用户代理的步骤,可以进一步包括:\n[0123] 依据cookie中的用户身份证明在应用服务器的本地缓存中查询是否存在相应的客户端用户;\n[0124] 在缓存命中成功时,依据应用服务器的本地缓存查询结果获取应用服务器的本地缓存用户信息,所述应用服务器的本地缓存用户信息中可以包括有用户代理;\n[0125] 将应用服务器的本地缓存用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述应用服务器的本地缓存用户信息中的用户代理作为最新的用户代理;需要说明的是,匹配成功可以说明用户代理没有发生变化,使用应用服务器的本地缓存用户信息中用户代理就可以;\n[0126] 若匹配失败,则依据所述用户上网行为信息中的用户代理对所述应用服务器的本地缓存用户信息中的用户代理进行更新;需要说明的是,匹配失败说明用户代理发生了变化,故需要进行更新;\n[0127] 在缓存命中失败时,依据cookie中的用户身份证明在远程服务器中查询相应的客户端用户的识别信息,并依据查询结果获取远程存储用户信息,所述远程存储用户信息中可以包括有用户代理;\n[0128] 将所述远程存储用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述远程存储用户信息中的用户代理作为最新的用户代理;这里,匹配成功说明用户代理没有发生变化,故使用远程存储用户信息中用户代理即可;\n[0129] 若匹配失败,则依据所述用户上网行为信息中的用户代理对所述远程存储用户信息中的用户代理进行更新。这里,匹配识别说明用户代理发生了变化,故需要进行更新。\n[0130] 在具体实现中,所述远程服务器可以包括UDC(用户数据中心,user data center)。例如,可以在UDC的数据库中基于cookie查找相应的客户端用户。\n[0131] 参照图4,示出了本申请一种远程服务器基于cookie中用户身份证明进行查询的流程图,具体可以包括:\n[0132] 步骤401、接收来自应用服务器的适配消息,所述适配消息中包括有cookie;\n[0133] 步骤402、基于cookie中用户身份证明在数据库中查询相应的客户端用户的识别信息;\n[0134] cookie存在则表示相应的客户端用户已经访问过应用服务器。\n[0135] 步骤403、依据查询结果,获取用户信息;\n[0136] 步骤404、将所述用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配失败,则执行步骤405;若匹配成功,则执行步骤407;\n[0137] 步骤405、将所述用户上网行为信息中的用户代理作为最新用户代理,更新到相应的用户表项中;\n[0138] 这里,用户表项用于在数据库中存储用户信息;\n[0139] 步骤406、将最新用户代理返回给应用服务器;\n[0140] 步骤407、将所述用户信息中的用户代理作为最新用户代理,返回给应用服务器。\n[0141] 需要说明的是,在应用服务器接收到最新用户代理后,可以对所述用户身份证明、用户标识和最新用户代理进行关联存储。这样,在用户代理发生变化时,应用服务器和UDC均对客户端用户的用户信息进行了更新和关联存储,以提高接下来用户识别的准确性和实时性。\n[0142] 所以,本申请中对所述用户身份证明、用户标识和当前用户代理进行关联存储,所述关联存储的执行主体可以包括应用服务器和UDC中的一者或多者,另外,在所述用户身份证明、用户标识和当前用户代理中任一者发生变化时,所述执行主体都会进行相应的更新和关联处理。\n[0143] 为使本领域技术人员更好地理解本申请,以下通过图5所示用户识别时序图说明本申请在实际中的应用,所述用户识别时序图具体可以包括:\n[0144] 步骤(1)、AAA Server接收来自客户端用户的计费请求,根据该计费请求中的网络用户名来获取用户账户的费用或余额,并判断是否允许该客户端用户的进一步上网,如果允许,则执行步骤(2)和(3),否则,由于费用不足拒绝该客户端用户上网;\n[0145] 步骤(2)允许该客户端用户上网;\n[0146] 步骤(3)当用户的费用和余额允许用户上网时,AAA Server将用户基本信息同步到Web Server(即本实施例中的应用服务器),由Web Server解析出用户基本信息,即网络用户名、用户IP和上下线状态,并把所述用户基本信息缓存在本地服务器上;其中,网络用户名是标志用户的唯一标识,是不会发生变化的;\n[0147] 步骤(4)当客户端用户上网浏览时,Web Server依据相应的访问请求解析出用户上网行为信息,其中,所述用户上网行为信息具体可以包括:用户IP、用户代理、cookie、访问网站域名、访问网站页面信息、访问referer信息等;\n[0148] 同时,Web Server判断cookie信息,如果cookie存在,则Web Server通过cookie中用户身份证明查询用户信息,查询该客户端用户是否存在,如果存在,则匹配用户上网行为中携带用户代理和通过用户身份证明查询用户身份信息中用户代理进行匹配,如果匹配成功,说明用户代理没有发生变化;如果匹配不成功,则把用户上网中携带用户代理更新查询结果中用户代理信息,执行步骤(7);如果不存在,则执行步骤(5);\n[0149] 如果cookie不存在,则Web Server通过IP关联,首先获取得到网络用户名和用户代理,然后通过网络用户名和用户代理查询该客户端用户是否存在,如果存在,则获取用户身份证明信息,即通过网络用户名和用户代理把用户关联起来,并执行步骤(7);如果不存在,则执行步骤(5);\n[0150] 步骤(5)UDC(用户数据中心,user data center)根据消息类型,区分是基于网络用户名+用户代理的查询,还是基于用户身份证明(user_id)的查询;\n[0151] 基于用户身份证明的查询具体可以包括:通过用户身份证明进行查询该客户端用户【说明该客户端用户曾经进入系统中】,获取到用户信息中网络用户名和用户代理,和用户本次携带网络用户名和用户代理进行匹配,若匹配成功,则执行步骤(6);若匹配不成功,则将网络用户名和最新用户代理更新到用户信息中【user-agent变化,关联处理】,并执行步骤(6);\n[0152] 基于网络用户名+用户代理的查询具体可以包括:通过网络用户名和用户代理来查询,如果数据库中不存在,则表示该客户端用户为新用户,即第一次进入系统,需要为该客户端用户新生产一个新用户身份证明;如果存在,则表示该客户端用户把已经将种植cookie删除,故可以通过网络用户名和用户代理关联起来,获取用户的原有用户身份证明,转(6);\n[0153] 步骤(6)UDC把关联结果同步到Web Server,便于业务处理;\n[0154] 步骤(7)Web Server依据识别得到的用户信息,进行用户行为识别、用户兴趣分析和积累,并从用户积累信息、网站内容、时间等多个维度,分析出用户所需要信息和感兴趣的信息,投送给用户;\n[0155] 步骤(8)和(9)当客户端用户非第一次上网时,由于Web Server已经将用户信息存储到应用服务器的本地缓存,故基于应用服务器的本地缓存的关联存储结构,就可以进行业务处理;\n[0156] 步骤(10)当该客户端用户下线时,AAA Server会把相应的下线消息同步到Web Server;\n[0157] 步骤(11)当Web Server接收到下线消息时,解析出相应的用户信息:网络用户名、用户IP和下线状态;并且,为了信息持久化的需求,会把该用户信息同步到UDC,;\n[0158] (12)为了信息持久化的需求,Web Server把该客户端的用户信息同步到UDC上,以便于把用户最新信息存储在UDC的数据库中的用户表项中,以避免发生用户信息丢失的情况。\n[0159] 需要说明的是,前述用户识别方法实施例中的任何一个方法步骤均可作为存储在计算机可读介质上的可执行软件指令,其中,所述计算机可读介质也可以包括传输型介质。\n[0160] 为了说明前述用户识别方法实施例的应用环境,参照图6,示出了本申请一种客户端6A和应用服务器6B的交互示意图,其中,应用服务器6B在接收到客户端6A的访问请求时,可以依据所述访问请求中的报文数据,解析得到相应的用户上网行为信息,当cookie在相应客户端用户的用户上网行为信息中存在时,应用服务器6B可以直接依据cookie向客户端6A返回响应信息;当cookie在相应客户端用户的用户上网行为信息中不存在时,应用服务器6B则会首先依据用户标识和用户代理恢复被删除的cookie,然后依据恢复后cookie中的用户身份证明,向客户端6A返回响应信息。\n[0161] 与前述方法实施例相应,本申请还公开了一种应用服务器实施例,参照图7,具体可以包括:\n[0162] 第一查询装置701,用于当cookie在相应客户端用户的用户上网行为信息中不存在时,依据相应客户端用户的用户标识和用户代理,查询得到相应的用户身份证明;\n[0163] 恢复装置702,用于依据所述用户身份证明恢复相应的cookie;\n[0164] 识别装置703,用于依据所述恢复后cookie中的用户身份证明,识别得到相应客户端用户的信息。\n[0165] 在本申请实施例中,优选的是,所述用户标识可以包括:网络用户名,和/或,专线用户的用户IP。\n[0166] 在本申请的一种优选实施例中,所述第一查询装置701,可以进一步包括:\n[0167] 第一缓存查找模块,用于依据用户标识和用户代理在应用服务器的本地缓存中查询是否存在相应的客户端用户;\n[0168] 获取模块,用于在缓存命中成功时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明。\n[0169] 在本申请的另一种优选实施例中,所述第一查询装置701还可以包括:\n[0170] 第一查询请求模块,用于在缓存命中失败时,向远程服务器发送第一查询请求;\n[0171] 此时,所述远程服务器具体可以包括:\n[0172] 第一远程查询装置,用于依据所述第一查询请求,通过所述用户标识和用户代理在远程服务器中查询是否存在相应的客户端用户;\n[0173] 证明获取装置,用于在远程服务器中存在相应的客户端用户时,依据所述用户标识和用户代理获取该客户端用户的用户身份证明;\n[0174] 证明产生装置,用于在远程服务器中不存在相应的客户端用户时,在远程服务器中依据所述用户标识和用户代理产生一个新客户端用户的用户身份证明;\n[0175] 第一返回装置,用于将所述证明获取装置或证明产生装置输出的用户身份证明,返回给所述应用服务器。\n[0176] 在本申请的另一种优选实施例中,所述应用服务器还可以包括:\n[0177] 用户代理获取装置,用于在第一查询装置执行查询操作前,当cookie在所述用户上网行为信息中存在时,依据cookie中的用户身份证明获取最新的用户代理。\n[0178] 在本申请的再一种优选实施例中,所述用户代理获取装置,可以进一步包括:\n[0179] 第二缓存查找模块,用于依据cookie中的用户身份证明在应用服务器的本地缓存中查询是否存在相应的客户端用户;\n[0180] 第二获取模块,用于在缓存命中成功时,依据应用服务器的本地缓存查询结果获取应用服务器的本地缓存用户信息,所述应用服务器的本地缓存用户信息中包括有用户代理;\n[0181] 本地匹配模块,用于将应用服务器的本地缓存用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述应用服务器的本地缓存用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述应用服务器的本地缓存用户信息中的用户代理进行更新;\n[0182] 第二查询请求模块,用于在缓存命中失败时,向远程服务器发送第二查询请求;\n[0183] 所述远程服务器包括:\n[0184] 第二远程查找装置,用于在缓存命中失败时,依据cookie中的用户身份证明在远程服务器中查询相应的客户端用户的识别信息,并依据查询结果获取远程存储用户信息,所述远程存储用户信息中包括有用户代理;\n[0185] 远程匹配装置,用于将所述远程存储用户信息中的用户代理与所述用户上网行为信息中的用户代理进行匹配,若匹配成功,则以所述远程存储用户信息中的用户代理作为最新的用户代理;若匹配失败,则依据所述用户上网行为信息中的用户代理对所述远程存储用户信息中的用户代理进行更新;\n[0186] 第二返回装置,用于将所述远程匹配装置输出的最新的用户代理,返回给所述应用服务器。\n[0187] 在本申请实施例中,优选的是,所述应用服务器还可以包括:\n[0188] 关联存储装置,用于在用户身份证明存在的情况下,在应用服务器端对所述用户身份证明、用户标识和当前用户代理进行关联存储。\n[0189] 对于应用服务器实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。\n[0190] 本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。\n[0191] 以上对本申请所提供的一种网络用户识别的方法及其应用服务器,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
法律信息
- 2018-09-21
未缴年费专利权终止
IPC(主分类): H04L 29/06
专利号: ZL 201110300817.7
申请日: 2011.09.30
授权公告日: 2014.05.28
- 2016-01-13
专利权的转移
登记生效日: 2015.12.25
专利权人由亿赞普(中国)网络技术有限公司变更为亿赞普(北京)科技有限公司
地址由100081 北京市海淀区中关村南大街甲18号院2号楼1607变更为100190 北京市海淀区南大街东北旺北京中关村软件园孵化器1号楼C座三层1322-D
- 2016-01-13
专利权人的姓名或者名称、地址的变更
专利权人由北京亿赞普网络技术有限公司变更为亿赞普(中国)网络技术有限公司
地址由100081 北京市海淀区中关村南大街甲18号院2号楼1607变更为100081 北京市海淀区中关村南大街甲18号院2号楼1607
- 2014-05-28
- 2012-03-14
实质审查的生效
IPC(主分类): H04L 29/06
专利申请号: 201110300817.7
申请日: 2011.09.30
- 2012-01-25
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2009-03-18
|
2007-09-12
| | |
2
| |
2008-04-09
|
2005-11-30
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |