CN102810193B - 一种关联产品信息的显示方法及系统 - Google Patents

Abstract

本申请提供了一种关联产品的显示方法及系统，所述方法包括：接收主产品信息的显示请求；从预置的产品关系中心查找所述主产品的关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系；按照所述关联关系所表示的关联强度的大小，从所述关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息；将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。本申请公开的方法和系统，可以解决现有技术在进行关联产品信息的显示时效率低下及显示性能较低的技术问题。

Description

一种关联产品信息的显示方法及系统

技术领域

本申请涉及网络数据处理领域，特别涉及一种关联产品信息的显示方法及系统。

背景技术

电子商务是以计算机网络为基础，以电子及电子技术为手段的线上产品信息的交互过程。电子商务以网上交易平台为实现平台。在网上交易平台进行展示的产品称为在线产品，在线产品中有很多相似的产品，例如一些同类的竞争品牌产品，或者外观、用料、功能和界面体验确实很相似的产品。

当在一个网页上当前展示一个产品时，这个占据了展示界面主体内容的产品信息称为主产品信息。而在主产品信息的展示页面，有一块区域可以用来展示主产品信息的关联产品信息，这样就使得用户有可能在浏览主产品信息的时候，点击进入关联产品信息的展示页面，然后有一定的机率会去购买关联产品。

参考图1所示，为现有技术中的一种关联产品信息的显示系统101的显示示意图，在这个显示系统中，买方用户会先向关联产品信息的显示系统101提交主产品信息的显示请求，以请求显示主产品信息。图1中的买方用户的交易数据获取单元102可以获取到买方用户的历史交易行为，而定时计算交易行为单元103，则利用买方用户的历史交易行为，基于关联规则等算法挖掘所述主产品信息的关联产品信息并计算主产品和关联产品之间的关联强度，关联产品选取单元104则根据计算出的关联强度选取适合的关联产品信息，由关联产品信息显示单元将选取的关联产品信息显示在主产品信息的展示页面上。

从上述现有技术的关联产品的显示系统可以看出，现有技术的显示系统在每一次向买方用户展示关联产品信息之前，都需要依据历史交易记录进行主产品信息与关联产品的关联强度的计算，从而根据关联强度可以选取出和该主产品信息一起显示的关联产品信息。这样就使得现有技术的显示系统在显示关联产品信息的过程中由于需要挖掘关联强度而效率低下，进一步的，如果关联产品信息的显示过于缓慢，也会导致买方用户与显示系统之间会重复的发送请求及响应请求的现象，不仅浪费网络传输资源，还影响显示系统的性能。

总之，目前需要本领域技术人员迫切解决的一个技术问题就是：如何能够创新的提出一种关联产品信息的显示方法，以解决现有技术在进行关联产品信息的显示时效率低下及显示性能较低的技术问题。

发明内容

本申请所要解决的技术问题是提供一种关联产品的显示方法，用以解决现有技术在进行关联产品信息的显示时效率低下及显示性能较低的技术问题。

本申请还提供了一种关联产品的显示系统，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本申请公开了一种关联产品信息的显示方法，包括：

接收主产品信息的显示请求；

从预置的产品关系中心查找所述主产品的关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系；

按照所述关联关系所表示的关联强度的大小，从所述关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息；

将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。

优选的，所述关联强度的获取方式具体为：

在当前卖方用户发布主产品信息之后，接收其他卖方用户提交的所述主产品信息的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分；

根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品信息和主产品信息的历史交易记录。

优选的，在所述待关联产品的关联信息为当前卖方用户对所述关联请求的响应的情况下，所述根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度，包括：

按照如下公式计算其他卖方用户的关联强度：

其中，T_i表示第i个其他卖方用户的关联强度，d_i表示第i个其他卖方用户的请求参数的值，其他卖方用户共有n个。

优选的，在所述待关联产品的关联信息为所述待关联产品和主产品历史交易记录的情况下，所述根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度，包括：

获取从所述主产品信息的展示页面链接到所述关联产品信息的展示页面的前若干跳的买方用户个数，以及同时段查看所述主产品信息的总用户数；

将所述前若干跳的买方用户个数之和除以所述总用户数，以计算出所述主产品信息和所述待关联产品信息的关联强度。

优选的，还包括：

记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度；

依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品信息或关联产品信息，两两节点之间的连线表示关联强度；

将所述产品关联图保存至所述产品关系中心。

优选的，还包括：

在不同产品之间的关联强度发生变化的情况下，实时更新所述产品关系中心中保存的关联强度。

优选的，还包括：

在买方用户对所述主产品信息的关联产品信息产生了交易行为的情况下，根据所述关联产品信息的卖方用户提交的请求参数将相应的虚拟积分转发至所述主产品信息的卖方用户的注册账号。

本申请公开了一种关联产品信息的显示系统，包括：

接收请求单元，用于接收主产品信息的显示请求；

查找单元，用于从预置的产品关系中心查找所述主产品的关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系；

选取单元，用于按照所述关联关系所表示的关联强度的大小，从所述关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息；

显示单元，用于将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。

优选的，还包括：

接收信息单元，用于在当前卖方用户发布主产品信息之后，接收其他卖方用户提交的所述主产品信息的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分；

获取关联强度单元，用于根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品信息和主产品信息的历史交易记录。

优选的，在所述待关联产品的关联信息为当前卖方用户对所述关联请求的响应的情况下，所述获取关联强度单元，具体配置为：

按照如下公式计算其他卖方用户的关联强度：

其中，T_i表示第i个其他卖方用户的关联强度，d_i表示第i个其他卖方用户的请求参数的值，其他卖方用户共有n个。

优选的，在所述待关联产品的关联信息为所述待关联产品和主产品历史交易记录的情况下，所述获取关联强度单元，具体配置为：

获取模块，用于获取从所述主产品信息的展示页面链接到所述关联产品信息的展示页面的前若干跳的买方用户个数，以及同时段查看所述主产品信息的总用户数；

计算模块，用于将所述前若干跳的买方用户个数之和除以所述总用户数，以计算出所述主产品信息和所述待关联产品信息的关联强度。

优选的，还包括：

记录数据单元，用于记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度；

构建产品关联图单元，依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品信息或关联产品信息，两两节点之间的连线表示关联强度；

保存单元，用于将所述产品关联图保存至所述产品关系中心。

优选的，还包括：

实时更新单元，用于在不同产品之间的关联强度发生变化的情况下，实时更新所述产品关系中心中保存的关联强度。

优选的，还包括：

转发虚拟积分单元，用于在买方用户对所述主产品信息的关联产品信息产生了交易行为的情况下，根据所述关联产品信息的卖方用户提交的请求参数将相应的虚拟积分转发至所述主产品信息的卖方用户的注册账号。

与现有技术相比，本申请包括以下优点：本申请从预置的产品关系中心查找所述主产品的关联产品信息并进行展示，无需在每一次向买方用户展示关联产品信息之前，都需要依据历史交易记录进行主产品信息与关联产品的关联强度的计算，可以节省服务器的计算资源，提高关联产品信息的显示效率；并且，由于不会导致买方用户与显示系统之间会重复的发送请求及响应请求的现象，还能节省网络传输资源，提升了显示系统的性能。同时，还可以避免仅仅依据历史交易记录的数据挖掘进行主产品与其他产品的关联所导致的显示结果不够准确的问题，可以为主产品找到更为相关的关联产品，进一步的，还能够通过产品关系中心的产品关联图来实现多个显示系统之间的共享，从而进一步节省构建显示系统的网络资源。当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中显示系统的结构示意图；

图2是本申请的一种关联产品信息的显示方法实施例1的流程图；

图3是方法实施例1中关联强度的获取流程图；

图4是方法实施例1中步骤302的一种流程图；

图5是本申请的一种关联产品信息的显示方法实施例2的流程图；

图6是产品关联图中的10条记录的关联示意图；

图7为本申请的一种关联产品信息的显示方法实施例3的流程图；

图8是本申请的一种关联产品信息的显示系统实施例1的结构框图；

图9是系统实施例1中关联强度的获取的结构框图；

图10是系统实施例1中获取关联强度单元902的一种结构框图；

图11是本申请的一种关联产品信息的显示系统实施例2的结构框图；

图12是本申请的一种关联产品信息的显示系统实施例3的结构框图。

具体实施方式

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

本申请可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本申请可以包括，通过构造一个预置的产品关系中心，可以将主产品信息与关联产品信息的关联关系预先保存，等到显示关联产品信息时，可以直接从该产品关系中心获取到数据，因此提高了关联产品信息的显示效率；并且，由于不会导致买方用户与显示系统之间会重复的发送请求及响应请求的现象，还能节省网络传输资源，提升了显示系统的性能。

同时，本申请实施例还通过接收到的主产品的卖方用户对于其他卖方用户提交的待关联产品信息以及关联请求的响应，来计算主产品与待关联产品的关联强度，并按照关联强度的大小关系来选取可以作为关联产品的待关联产品，可以避免现有技术中仅仅依据历史交易记录的数据挖掘进行主产品与其他产品的关联所导致的显示结果不够准确的问题，可以为主产品找到更为相关的关联产品，进一步的，还能够通过产品关系中心的产品关联图来实现多个显示系统之间的共享，从而进一步节省构建显示系统的网络资源。

参考图2，示出了本申请一种关联产品信息的显示方法实施例1的流程图，可以包括以下步骤：

步骤201：接收主产品信息的显示请求。

本申请实施例中所提到的主产品，指在一个当前页面上展示主体内容的产品，主产品信息指的是在该页面上展示的主产品的相关信息。在这个展示页面，有一块区域展示一些关联产品信息，从而使用户有可能在看主产品信息的时候，点击进入到关联产品信息的展示页面，然后有一定的机率会去购买关联产品。一般来说大品牌的产品更容易成为主产品，因为大品牌的产品知名度高，买家可能最初是想到买大品牌产品才来搜索其他关联产品。

本步骤即是买方用户在有查看主产品信息的需求时，向服务器提交主产品信息的显示请求。

步骤202：从预置的产品关系中心查找所述主产品的关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系。

在本步骤预置的产品关系中心可以采用序列化的文件实现，也可以采用其他的永久性数据库实现，在产品关系中心保存了主产品信息、关联产品信息，以及主产品和关联产品之间的关联关系，这里的关联关系可以采用关联强度来表示。主产品与关联产品的关联强度的值接近1，则表示购买主产品的买方用户最可能购买对应的关联产品；关联强度等于1时表示主产品只有一个关联产品；关联强度如果为0表示买主产品的人一定不会买关联产品，即是主产品和关联产品之间没有关联关系。一般情况下，关联强度的值处在0到1之间，比如0.8。

本步骤预置的产品关系中心因为保存了主产品信息、关联产品信息及主产品与关联产品的关联关系，就可以在使用时快速恢复内存中已经构建好的主产品与关联产品之间的关联关系，也就知道了该关联关系所表示的关联强度。

参考图3所示，所述预置的产品关系中心保存的关联关系所表示的关联强度，在获取时可以采用如下方式：

步骤301：在当前卖方用户发布主产品之后，接收其他卖方用户提交的所述主产品的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分。

本申请实施例中，拥有主产品的卖方用户可以有权力管理申请与之相关的关联产品，因为拥有主产品的卖方用户有控制仿货与假货的需要，但也有一些拥有主产品的卖方用户愿意与一些竞争产品或仿货放在一起，这个由卖方用户自主决定。进一步的，在本申请实施例中，拥有主产品的卖方用户还有控制虚拟积分的权力。其中虚拟积分可以是佣金或者虚拟的货币等等，表示那些拥有关联产品的卖方用户在与主产品进行关联时需要付给拥有主产品的卖方用户的佣金或者积分等，因此拥有主产品的卖方用户可以按一定的比例或固定的金额接收提成。

所述虚拟积分也可以采用其他可用于交换的资源、数据等来实现。

步骤302：根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品信息和主产品信息的历史交易记录。

本步骤在实现过程中，在所述待关联产品的关联信息为当前卖方用户对所述关联请求的响应的情况下，即是在由当前卖方用户自主控制哪些待关联产品可以称为最终的关联产品的情况下，可以采用如下方式来实现步骤302：

按照公式(1)计算主产品与其他卖方用户的待关联产品之间的关联强度：

其中，T_i表示第i个其他卖方用户的待关联产品与主产品的关联强度，d_i表示第i个其他卖方用户的请求参数的值，其他卖方用户共有n个。

其中，所述当前卖方用户对所述关联请求的响应可以为同意关联，或不同意关联两种情况。如果当前卖方用户同意关联，则执行后续计算关联强度的步骤，如果当前卖方用户不同意关联，则直接放弃该待关联产品与主产品的关联过程。为方便起见，在本申请实施例一律以当前卖方用户同意关联为例进行说明。

举个例子来讲，假设关联产品的卖方用户a和b都进行主产品S的关联，且a是主产品S第一个且唯一一个请求关联的卖方用户，其请求参数的值为1元(或佣金1％)；则主产品S的卖方用户的响应为同意关联，则，a的关联产品与主产品S的关联强度值为1。

进一步的，假设在a的关联产品与主产品S关联之后，卖方用户b看到S后，认为自己的产品与S也有关联，且想建立更强的联系，因此将其请求参数设置为2元(或2％)，于是b的关联产品在主产品S的展示页面可以排在a的关联产品之前。在这种情况下，a的关联产品与主产品S的关联强度值为1/(1+2)，即0.33；而b的关联产品与主产品S的关联强度为2/3，即0.66。

通过上述方式可以将多个卖方用户的普通产品关联到主产品上，称为主产品的关联产品。而主产品的卖方用户可以针对待关联产品的卖方用户发送的请求参数进行响应，如果响应为同意关联，才能将某个待关联产品与自己的主产品进行关联，这样主产品的卖方用户就可以选择自己希望的产品与主产品相关联。

需要说明的是，如果没有其他用于普通产品的其他卖方用户提交请求，则可以通过历史交易行为计算关联强度。其中，可以周期性的进行计算，例如设定为每天晚上12点。一般情况下一天只计算有限次数，例如十次，这样计算压力不会太大。

因此，在所述待关联产品的关联信息为所述待关联产品和主产品的历史交易记录的情况下，即是采用买方用户从主产品信息的展示页面进入所述主产品信息的展示页面，并购买了主产品的历史交易记录来计算关联强度的方式，步骤302的实现参考图4所示，具体可以包括：

步骤401：获取从所述主产品信息的展示页面链接到所述关联产品信息的展示页面的前若干跳中每一跳的买方用户个数，以及同时段查看所述主产品的总用户数。

从历史交易行为中获得主产品与其他关联产品的关系，即是如果查看主产品A的买方用户后来购买了关联产品B，则B与A之间建立关系。B与A之间的关系强度按预置的关联规则计算。例如，步骤301中的前若干跳一共为三跳，则假设某一时间段内查看过A产品后，第二跳就进入B的页面的买方用户数为X2，第三跳进入产品B页面的买方用户数为X3，第三跳为X4。该同时段内，查看A产品的总买方用户数为Y。

这里的“跳”指的是从一个产品信息的页面进入另一个产品信息的展示页面的一次链接。

步骤402：将所述前若干跳的买方用户个数之和除以所述总用户数，以计算出所述主产品和所述待关联产品的关联强度。

则B与A之间的关系强度就为：(X2+X3*50％+X4*40％)/Y。例如，X2＝30，X3＝20，X4＝10，Y为100，则B与A之间的关系强度为0.44。其中涉及到的50％和40％是代表二跳页面与三跳页面的去掉跳离率，即去除掉进入某一个页面就马上离开，不再产生后续访问的比例。其中，去掉跳离率为经验值。需要说明的是，在上述计算方式中，为了方便起见，只取了前三跳的用户个数，也可以根据实际需求适应性的调整。

从步骤301和302中可以看出，关联强度是可以提升的，例如当买方用户从某一个主产品到一个关联产品的历史交易记录增多时，通过买方用户的历史交易行为的数据挖掘就可以提升关联强度。也可以通过关联产品的卖方用户向主产品的卖方用户的请求，但是拥有关联产品的卖方用户需要提高其请求参数的值，例如付出更高的佣金或费用给主产品的卖方用户。

需要说明的是，在实际应用中，前述的两种情况经常会同时存在，因此上述两种计算关联强度的算法可以结合使用。具体的，即是同时采用当前卖方用户对所述关联请求的响应情况和所述待关联产品和主产品历史交易记录来计算关联强度。例如，由历史交易记录得到待关联产品B与主产品A的关联强度为0.5，即是买主产品A的用户中，有50％也买了待关联产品B(每天定时计算得到)；但由于B的卖家又发送了关联请求，且按照B的卖家发送的关联请求计算出的关联强度为，：Ti＝1/(1+2+3+4)＝0.1；则B产品的Ti最终的值是0.5+0.1＝0.6。

步骤203：按照所述关联关系所表示的关联强度的大小，从所述所有关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息。

在从产品关系中心获取到主产品信息的关联产品信息，以及主产品与关联产品之间的关联关系之后，就可以依据该关联关系所表示的关联强度的大小，从该主产品的所有关联产品信息中选取若干个较大的关联强度对应的关联产品信息作为待显示的关联产品信息。

步骤204：将所述待显示的关联产品信息与所述主产品信息发送至用户所在的客户端进行显示。

最后将选取出的待显示的关联产品信息显示在主产品信息的展示页面上。其中，关联产品信息的显示区域可以灵活设置，并且上述待显示的关联产品信息的排序方式也可以灵活设置。例如，假设关联产品A与主产品X的关联强度是0.9，而关联产品B与主产品X的关联强度是0.5，则在主产品X的展示页面，可以将关联产品A排在关联产品B前面。在本申请实施例中，因为采用了预置的产品关系中心来保存主产品信息、关联产品信息以及主产品与关联产品的关联关系，因此可以在接收到买方用户发送的显示主产品信息的请求时，直接从该预置的产品关系中心中获取到该主产品信息的关联产品信息及关联强度，并从中选取出可以显示的关联产品信息。因为不需要再计算关联强度，所以显示效率有了较大提高；并且，如果关联产品信息的显示过程很快，就不会导致买方用户与显示系统之间会重复的发送请求及响应请求的现象，这样就节省了网络传输资源，提升了显示系统的性能。

需要说明的是，当采用图3所示的流程来获取需要存储至产品关系中心的关联关系时，因为其他卖方用户会提交其希望与主产品关联的待关联产品信息及关联请求，就使得主产品的卖方用户有权力管理申请与主产品关联的待关联产品，就能够实现卖方用户自主选择展示在其所拥有的主产品的展示页面的关联产品，也能决定某些待关联产品是否展示在主产品的展示页面上。因此本申请实施例进一步的通过将卖方用户对所述关联请求的响应与交易历史记录进行结合，可以使展示在主产品页面的关联产品不再机械化，主产品上显示的关联产品也与该主产品更为相关，从而还解决了主产品的展示页面上的关联产品的显示结果不够准确的问题。

参考图5，示出了本申请一种关联产品信息的显示方法实施例2的流程图，可以包括以下步骤：

步骤501：在当前卖方用户发布主产品之后，接收其他卖方用户提交的所述主产品的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分。

步骤502：根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品和主产品信息的历史交易记录。

步骤501和502与实施例1相同，在此不再赘述。

步骤503：记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度。

本实施例与实施例1的不同之处在于，本实施例还需要根据关联强度建立产品关联图。具体的，首先接收电子商务网站提交的数据结构，其中，电子商务网站提交的数据结构可以为：

thirdparty_siteid，Main_product_id-＞[Related_product_id_list]；

其中，thirdparty_siteid表示网站标识，Main_product_id表示主产品标识，Related_product_id_list表示关联产品列表，其中包括关联产品标识及关联强度。

步骤504：依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品信息或关联产品信息，两两节点之间的连线表示关联强度。

其中，在记录数据结构之后，就可以周期性的构建产品关联图，例如，每一小时读取一次记录。具体的构建过程即是读取记录并连接节点的过程，读取的某条数据结构的记录后，首先根据主产品标识和关联产品标识增加相应的图节点，然后再根据是否存在关联强度以及关联强度的大小进行节点连线。

在实际应用中，可以设定节点的边为50，表示一个主产品信息最多可以存在50个关联产品信息，这个值一般受网页上展示的关联产品信息区间大小所限制。当然也可以适应性调整该数值。

步骤505：将所述产品关联图保存至产品关系中心。

在建立了产品关联图之后，可以保存当前的产品关联图到一个预置的产品关系中心中。保存这个产品关联图结构之后，可以快速获取某个主产品信息的节点对应的关联产品信息及对应的关联强度。

可见，产品关系中心可以维护线上所有的产品关系。产品关系中心可以预先设置一个空的产品关联图，在后续周期性的读取数据记录的时候，进行不断地更新。例如，国产MP3的卖方用户，希望国产MP3作为关联产品出现在主产品“APPLE的IPOD”的展示页面下方，则国产MP3的卖方用户提交相应的请求参数，如果没有其他卖方用户提交关联产品标识及请求参数，且主产品“APPLE的IPOD”的响应标识同意关联，则可以计算出国产MP3与“APPLE的IPOD”的关联强度，并保存到产品关系中心。

参考图6所示，图6为产品关联图中的10条记录的关联示意图。其中，节点10代表产品关系中心中第10条的记录，它被4个产品引用，也就是说，节点10为主产品，而引用节点10的四个产品则是关联产品。在图6中，箭头指向的节点表示主产品信息，而与箭头指向相反的节点表示该主产品信息的关联产品信息。其中，连线上的数值代表该连线涉及的主产品与关联产品的关联强度的值。

步骤506：接收主产品信息的显示请求。

步骤507：从所述产品关系中心查找所述主产品的所有关联产品信息。

步骤508：按照所述关联关系所表示的关联强度的大小，从所述所有关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息。

步骤509：将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。

本实施例通过实现一个统一的产品关系中心，来维护线上所有的在线产品，这样就使得虽然各个显示系统的组成单元不同，但是都使用该产品关系中心，所以主产品和关联产品的关联关系就可以在各个显示系统之间共享，即实现了各个显示系统之间的产品资源共享，节省了构建显示系统的网络资源。

参考图7，示出了本申请一种关联产品信息的显示方法实施例3的流程图，在本实施例中，可以包括以下步骤：

步骤701：在当前卖方用户发布主产品信息之后，接收其他卖方用户提交的主产品的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品信息的展示页面进入所述待关联产品信息的展示页面并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分。

步骤702：根据所述待关联产品的关联信息和请求参数，获取所述主产品和所述待关联产品的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品和主产品历史交易记录。

步骤703：记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度。

步骤704：依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品信息或关联产品信息，两两节点之间的连线表示关联强度。

步骤705：将所述产品关联图保存至产品关系中心。

在本实施例中，再将产品关联图保存至产品关系中心时，具体可以采用如下表所示的存储数据结构：

在该表中保存了产品关系中心的数据主要结果，可以采用内存级别的缓存，用来存放指定(thirdparty_sited，Main_product_id)对应的Related_product_id_list和S_main_id等信息。其中，字段thirdparty_siteid是记录第三方网站的代号，为表示方便，这里用域名直接代表，而在实际实现时可以用数字代号；字段Related_product_id_list则按产品关联强度保存，其格式为：{关联产品的pk_id1，关联产品的卖方用户id1，关联强度1；关联产品的pk_id2，关联产品的卖方用户id2，关联强度2；}，一般来说，考虑节省存储资源且关联强度很小的关联产品可以不予考虑，这个列表长度控制在50个关联产品之内。这个表可以记录在内存缓存中，以提升性能。

步骤706：在不同产品之间的关联强度发生变化的情况下，实时更新所述产品关系中心中保存的关联强度。

因为在实际应用中，各个卖方用户都可能随时提交待关联产品信息及请求参数，因此，即便是相同的主产品与关联产品之间的关联强度，也会在不同时刻产生不同的变化。例如，某个关联产品的卖方用户不再希望自己的关联产品与主产品产生关联关系，或者某个关联产品与主产品的关联强度因为买方用户的交易行为而使得关联强度更小，等等。因此，在本步骤中，则在主产品与关联产品的关联强度产生了变化的情况下，实时更新产品关系中心保存的关联强度，即是实时更新产品关联图中的连线关系以及连线上的关联强度的值。

步骤707：接收主产品信息的显示请求。

步骤708：从所述产品关系中心查找所述主产品的所有关联产品信息。

步骤709：按照所述关联关系所表示的更新后的关联强度的大小，从所述所有关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息。

在本实施例中，当步骤706中关联强度进行更新之后，从产品关系中心中获取更新后的关联强度。

步骤710：将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。

步骤711：在买方用户对所述主产品的关联产品产生了交易行为的情况下，根据所述关联产品的卖方用户提交的请求参数将相应的虚拟积分转发至所述主产品的卖方用户的注册账号。

在本实施例中，如果在主产品的展示页面上显示所述主产品信息的关联产品信息之后，有买方用户从所述主产品信息的展示页面上进入所述关联产品信息的页面进行查看并且产生了交易行为，即是购买了关联产品，则根据该关联产品的卖方用户提交的请求参数将相应的虚拟积分转发至所述主产品的卖方用户的注册账号。

例如，关联产品B已经与主产品A关联，关联产品B的卖方用户愿意提供每次交易2块钱的佣金给主产品A的卖方用户，A审核同意之后，可以在每个月底，根据本月内从主产品A连接到关联产品B且购买了B的用户个数，计算A可以拿到多少来自B的佣金，并将佣金打入A卖方用户的注册账户。假设卖方用户a给主产品的卖方用户的佣金为每次交易1元，最终a付给主产品的卖方用户的费用为1*成交次数；假设卖方用户b给主产品的卖方用户的佣金为每次交易21元，最终b付给主产品的卖方用户的费用为2*成交次数。

本申请实施例通过一个产品关系中心，可以实现各个显示系统的交互以及资源共享，同时根据主产品的卖方用户的响应，以及待关联产品的卖方用户提供的请求参数，可以计算出主产品与待关联产品的关联强度，从而选取关联强度较大的待关联产品作为最终的关联产品并显示在主产品的展示页面上。这样不仅使得关联产品的显示准确性更高，还能够使得产品关系中心的数据能够被多个显示系统共享。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

与上述本申请一种关联产品的显示方法实施例1所提供的方法相对应，参见图8，本申请还提供了一种关联产品信息的显示系统实施例1，在本实施例中，该系统可以包括：

接收请求单元801，用于接收主产品信息的显示请求；

查找单元802，用于从预置的产品关系中心查找所述主产品的关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系；

其中，所述关联关系表示主产品和关联产品之间的关联强度大小，在实际应用中可以采用图9所示的模块获取：

接收信息单元901，用于在当前卖方用户发布主产品之后，接收其他卖方用户提交的所述主产品的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分。

获取关联强度单元902，用于根据所述待关联产品的关联信息和请求参数，获取所述主产品和所述待关联产品的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品和主产品历史交易记录。

在所述待关联产品的关联信息为当前卖方用户对所述关联请求的响应的情况下，所述获取关联强度单元902，具体可以配置为：

按照如下公式计算其他卖方用户的关联强度：

其中，T_i表示第i个其他卖方用户的关联强度，d_i表示第i个其他卖方用户的请求参数的值，其他卖方用户共有n个。

在所述待关联产品的关联信息为所述待关联产品和主产品历史交易记录的情况下，所述获取关联强度单元902，参考图10所示，具体可以配置为：

获取模块1001，用于获取所有查看所述主产品信息之后对所述关联产品产生交易的买方用户的关联强度参数，所述关联强度参数包括：从所述主产品信息的展示页面链接到所述关联产品信息的展示页面的前若干跳的买方用户个数，以及同时段查看所述主产品信息的总用户数。

计算模块1002，用于将所述前若干跳的买方用户个数之和除以所述总用户数，以计算出所述主产品和所述待关联产品的关联强度。

选取单元803，用于按照所述关联关系所表示的关联强度的大小，从所述关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息；

显示单元804，用于将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。

在本申请实施例中，因为采用了预置的产品关系中心来保存主产品信息、关联产品信息以及主产品与关联产品的关联关系，因此可以在接收到买方用户发送的显示主产品信息的请求时，直接从该预置的产品关系中心中获取到该主产品信息的关联产品信息及关联强度，并从中选取出可以显示的关联产品信息。因为不需要再计算关联强度，所以显示效率有了较大提高；并且，如果关联产品信息的显示过程很快，就不会导致买方用户与显示系统之间会重复的发送请求及响应请求的现象，这样就节省了网络传输资源，提升了显示系统的性能。

另外，因为在本申请实施例中，其他卖方用户还会提交其希望与主产品关联的待关联产品信息及关联请求，就使得主产品的卖方用户有权力管理申请与主产品关联的待关联产品，就能够实现卖方用户自主选择展示在其所拥有的主产品的展示页面的关联产品，也能决定某些待关联产品是否展示在主产品的展示页面上。因此本申请实施例进一步的通过将卖方用户对所述关联请求的响应与交易历史记录进行结合，可以使展示在主产品页面的关联产品不再机械化，主产品上显示的关联产品也与该主产品更为相关，从而还解决了主产品的展示页面上的关联产品的显示结果不够准确的问题。

与上述本申请一种关联产品的显示方法实施例2所提供的方法相对应，参见图11，本申请还提供了一种关联产品信息的显示系统实施例2，在本实施例中，该系统可以包括：

接收信息单元901，用于在当前卖方用户发布主产品信息之后，接收其他卖方用户提交的所述主产品的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品信息的展示页面进入所述待关联产品信息的展示页面并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分。

获取关联强度单元902，用于根据所述待关联产品的关联信息和请求参数，获取所述主产品和所述待关联产品的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品和主产品历史交易记录。

与系统实施例1相比，本实施例的系统还可以包括：

记录数据单元1101，用于记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度；

构建产品关联图单元1102，依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品或关联产品，两两节点之间的连线表示关联强度。

保存单元1103，用于将所述产品关联图保存至产品关系中心。

接收请求单元801，用于接收主产品信息的显示请求。

查找单元802，用于从预置的产品关系中心查找所述主产品的所有关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系。

选取单元803，用于按照所述关联关系所表示的关联强度的大小，从所述所有关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息；

显示单元804，用于将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。

本实施例通过实现一个统一的产品关系中心，来维护线上所有的在线产品，这样就使得虽然各个显示系统的组成单元不同，但是都使用该产品关系中心，所以主产品和关联产品的关联关系就可以在各个显示系统之间共享，即实现了各个显示系统之间的产品资源共享，节省了构建显示系统的网络资源。

与上述本申请一种关联产品的显示方法实施例3所提供的方法相对应，参见图12，本申请还提供了一种关联产品信息的显示系统实施例3，在本实施例中，该系统可以包括：

接收信息单元901，用于在当前卖方用户发布主产品信息之后，接收其他卖方用户提交的所述主产品的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分。

获取关联强度单元902，用于根据所述待关联产品的关联信息和请求参数，获取所述主产品和所述待关联产品的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和/或所述待关联产品和主产品历史交易记录。

记录数据单元1101，用于记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度；

构建产品关联图单元1102，依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品或关联产品，两两节点之间的连线表示关联强度。

保存单元1103，用于将所述产品关联图保存至产品关系中心。

实时更新单元1201，用于在不同产品之间的关联强度发生变化的情况下，实时更新所述产品关系中心中保存的关联强度。

接收请求单元801，用于接收主产品信息的显示请求。

查找单元802，用于从预置的产品关系中心查找所述主产品的所有关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系。

选取单元803，用于按照所述关联关系所表示的关联强度的大小，从所述所有关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息。

显示单元804，用于将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示。

转发虚拟积分单元1202，用于在买方用户对所述主产品的关联产品产生了交易行为的情况下，根据所述关联产品的卖方用户提交的请求参数将相应的虚拟积分转发至所述主产品的卖方用户的注册账号。

本申请实施例通过一个产品关系中心，可以实现各个显示系统的交互以及资源共享，同时根据主产品的卖方用户的响应，以及待关联产品的卖方用户提供的请求参数，可以计算出主产品与待关联产品的关联强度，从而选取关联强度较大的待关联产品作为最终的关联产品并显示在主产品的展示页面上。这样不仅使得关联产品的显示准确性更高，还能够使得产品关系中心的数据能够被多个显示系统共享。

本实施例所述的系统可以集成到第三方交易平台的服务器上，也可以单独作为一个实体与第三方交易平台的服务器相连，另外，需要说明的是，当本申请所述的方法采用软件实现时，可以作为第三方交易平台的服务器新增的一个功能，也可以单独编写相应的程序，本申请不限定所述方法或系统的实现方式。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于系统类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种关联产品信息的显示方法、系统及服务器进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (12)

1.一种关联产品信息的显示方法，其特征在于，该方法包括：

接收主产品信息的显示请求；

从预置的产品关系中心查找所述主产品的关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系；

按照所述关联关系所表示的关联强度的大小，从所述关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息；

将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示；

其中，所述关联强度的获取方式具体为：

在当前卖方用户发布主产品信息之后，接收其他卖方用户提交的所述主产品信息的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分；

根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和所述待关联产品信息和主产品信息的历史交易记录；

其中，当所述当前卖方用户对所述关联请求的响应为所述当前卖方用户同意关联时，根据所述请求参数与所述待关联产品信息和主产品信息的历史交易记录计算所述待关联产品信息的关联强度；当所述当前卖方用户对所述关联请求的响应为所述当前卖方用户不同意关联时，所述待关联产品与所述主产品之间没有关联关系。

2.根据权利要求1所述的方法，其特征在于，在所述待关联产品的关联信息为当前卖方用户对所述关联请求的响应的情况下，所述根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度，包括：

按照如下公式计算其他卖方用户的关联强度：

$T_i=\frac{d_i}{d_1+...+d_n}$

其中，T_i表示第i个其他卖方用户的关联强度，d_i表示第i个其他卖方用户的请求参数的值，其他卖方用户共有n个。

3.根据权利要求1所述的方法，其特征在于，在所述待关联产品的关联信息为所述待关联产品和主产品历史交易记录的情况下，所述根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度，包括：

获取从所述主产品信息的展示页面链接到所述关联产品信息的展示页面的前若干跳的买方用户个数，以及同时段查看所述主产品信息的总用户数；

将所述前若干跳的买方用户个数之和除以所述总用户数，以计算出所述主产品信息和所述待关联产品信息的关联强度。

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

记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度；

依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品信息或关联产品信息，两两节点之间的连线表示关联强度；

将所述产品关联图保存至所述产品关系中心。

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

在不同产品之间的关联强度发生变化的情况下，实时更新所述产品关系中心中保存的关联强度。

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

在买方用户对所述主产品信息的关联产品信息产生了交易行为的情况下，根据所述关联产品信息的卖方用户提交的请求参数将相应的虚拟积分转发至所述主产品信息的卖方用户的注册账号。

7.一种关联产品信息的显示系统，其特征在于，该系统包括：

接收请求单元，用于接收主产品信息的显示请求；

查找单元，用于从预置的产品关系中心查找所述主产品的关联产品信息；所述产品关系中心用于存储主产品信息、关联产品信息及主产品与关联产品的关联关系；

选取单元，用于按照所述关联关系所表示的关联强度的大小，从所述关联产品信息中选取预置个数的关联产品信息作为待显示的关联产品信息；

显示单元，用于将所述待显示的关联产品信息与所述主产品信息发送至用户客户端进行显示；

接收信息单元，用于在当前卖方用户发布主产品信息之后，接收其他卖方用户提交的所述主产品信息的待关联产品信息以及关联请求；所述待关联产品信息包括待关联产品标识及请求参数，所述请求参数表示在买方用户通过主产品的展示页面进入所述待关联产品并产生交易行为之后，需要提交给所述当前卖方用户的虚拟积分；

获取关联强度单元，用于根据所述待关联产品的关联信息和请求参数，获取所述主产品信息和所述待关联产品信息的关联强度；所述待关联产品的关联信息包括：当前卖方用户对所述关联请求的响应和所述待关联产品信息和主产品信息的历史交易记录；

其中，当所述当前卖方用户对所述关联请求的响应为所述当前卖方用户同意关联时，根据所述请求参数与所述待关联产品信息和主产品信息的历史交易记录计算所述待关联产品信息的关联强度；当所述当前卖方用户对所述关联请求的响应为所述当前卖方用户不同意关联时，所述待关联产品与所述主产品之间没有关联关系。

8.根据权利要求7所述的系统，其特征在于，在所述待关联产品的关联信息为当前卖方用户对所述关联请求的响应的情况下，所述获取关联强度单元，具体配置为：

按照如下公式计算其他卖方用户的关联强度：

$T_i=\frac{d_i}{d_1+...+d_n}$

其中，T_i表示第i个其他卖方用户的关联强度，d_i表示第i个其他卖方用户的请求参数的值，其他卖方用户共有n个。

9.根据权利要求7所述的系统，其特征在于，在所述待关联产品的关联信息为所述待关联产品和主产品历史交易记录的情况下，所述获取关联强度单元，具体配置为：

获取模块，用于获取从所述主产品信息的展示页面链接到所述关联产品信息的展示页面的前若干跳的买方用户个数，以及同时段查看所述主产品信息的总用户数；

计算模块，用于将所述前若干跳的买方用户个数之和除以所述总用户数，以计算出所述主产品信息和所述待关联产品信息的关联强度。

10.根据权利要求7所述的系统，其特征在于，还包括：

记录数据单元，用于记录电子商务网站提交的数据结构，所述数据结构包括：主产品标识、关联产品标识和关联强度；

构建产品关联图单元，依据所述主产品标识、关联产品标识和关联强度构建产品关联图，其中，所述产品关联图中的节点为主产品信息或关联产品信息，两两节点之间的连线表示关联强度；

保存单元，用于将所述产品关联图保存至所述产品关系中心。

11.根据权利要求10所述的系统，其特征在于，还包括：

实时更新单元，用于在不同产品之间的关联强度发生变化的情况下，实时更新所述产品关系中心中保存的关联强度。

12.根据权利要求7所述的系统，其特征在于，还包括：

转发虚拟积分单元，用于在买方用户对所述主产品信息的关联产品信息产生了交易行为的情况下，根据所述关联产品信息的卖方用户提交的请求参数将相应的虚拟积分转发至所述主产品信息的卖方用户的注册账号。