CN105610877B - 数据交互方法、平台服务器及系统 - Google Patents

Abstract

本发明涉及一种数据交互方法、平台服务器及系统，其方法包括：平台服务器曝光第三方应用的任务推送载体；在任务推送载体上，平台服务器接收用户的领任务请求，转发给第三方应用服务器；平台服务器指引用户进入应用处理领取的任务；第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；平台服务器向第三方应用服务器请求，获取任务完成情况，根据任务完成情况更新任务进度表，并进行相应计费操作。本发明通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，实现流量的合理分配，极大的提高了应用产品的分发能力，满足应用开发商的需求。

Description

数据交互方法、平台服务器及系统

技术领域

本发明涉及网络技术领域，尤其涉及一种数据交互方法、平台服务器及系统。

背景技术

目前，网页游戏等应用产品在网络上的推广方式各式各样，其中，广告推广是一种较为普遍且推广效果较好的方式。但是，现有的应用产品的广告推广方式，比较单一，而且与应用产品及应用市场没有系统结合，导致应用产品的分发能力较低，无法满足应用开发商的需求。

发明内容

本发明实施例提供一种数据交互方法、平台服务器及系统，旨在提高网页应用的分发能力。

本发明实施例提出了一种数据交互方法，包括：

平台服务器曝光第三方应用的任务推送载体；

在所述任务推送载体上，所述平台服务器接收用户的领任务请求，转发给第三方应用服务器；

所述平台服务器指引用户进入应用处理领取的任务；

所述第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；

所述平台服务器向第三方应用服务器请求，获取任务完成情况，根据所述任务完成情况更新任务进度表，并进行相应计费操作。

本发明实施例还提出一种数据交互平台服务器，包括：

推送模块，用于曝光第三方应用的任务推送载体；

接收模块，用于在所述任务推送载体上，接收用户的领任务请求，转发给第三方应用服务器；由所述第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；

引导模块，用于指引用户进入应用处理领取的任务；

操作模块，用于向第三方应用服务器请求，获取任务完成情况，根据所述任务完成情况更新任务进度表，并进行相应计费操作。

本发明实施例提出一种数据交互系统，包括：平台服务器和与所述平台服务器通信连接的第三方应用服务器，其中：

所述平台服务器为如上任一项所述的平台服务器；

所述第三方应用服务器，用于解析所述领任务请求，对应记录用户处理任务的相关数据；接收所述平台服务器的请求，进行相应处理。

本发明实施例提出的一种数据交互方法、平台服务器及系统，通过平台服务器与第三方应用服务器的交互机制，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台，具体在接收到用户的领任务请求，将此请求转发给第三方应用服务器；同时平台服务器指引用户进入应用处理领取的任务，根据任务完成情况，更新任务进度表；第三方应用服务器解析领任务请求，获取用户标识及任务ID，并对应记录用户处理任务的相关数据；后续，在用户完成任务后，根据用户请求向用户发放资源反馈(奖励)，并通知平台服务器扣费。由此，通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，从而极大的提高了应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。此外，还可以通过特定的排期审核机制，对优质应用集中导量，为应用开发商提供集中开服(以游戏为例)的能力，进一步提高了网页应用尤其是优质网页应用的分发能力，实现流量的合理分配。

附图说明

图1是本发明实施例方案涉及的系统架构示意图；

图2是本发明实施例方案涉及的系统内部结构示意图；

图3是本发明实施例方案中平台服务器与第三方应用服务器的主要交互流程示意图；

图4是本发明实施例平台服务器涉及的硬件结构示意图；

图5是本发明实施例方案中任务创建界面示意图；

图6是本发明实施例方案中广告创建界面示意图；

图7是本发明实施例方案中平台服务器的做任务界面示意图；

图8是本发明数据交互平台服务器第一实施例的功能模块示意图；

图9是本发明数据交互平台服务器第二实施例的功能模块示意图；

图10是本发明数据交互平台服务器第三实施例的功能模块示意图；

图11是本发明数据交互方法第一实施例的流程示意图；

图12是本发明数据交互方法第二实施例的流程示意图；

图13是本发明数据交互方法第三实施例的流程示意图；

图14是本发明数据交互方法第四实施例的流程示意图；

图15是本发明数据交互方法第五实施例的流程示意图。

为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例方案的主要思路是：由于现有的应用产品的广告推广方式，比较单一，而且与应用产品及开发商没有系统结合，导致应用产品的分发能力较低，无法满足应用开发商的需求。

本发明实施例架构一平台服务器，平台服务器与第三方应用服务器交互，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台，将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，极大的提高应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。此外，还可以通过特定的排期审核机制，对优质应用集中导量，为应用开发商提供集中开服(以游戏为例)的能力，进一步提高网页应用尤其是优质网页应用的分发能力，满足应用开发商的需求。

本实施例方案涉及一种任务集市应用场景，任务集市为应用开发者提供投放应用任务及任务广告的服务平台，并将开发者投放的任务、任务广告推送到应用平台进行曝光、展示，为用户提供领任务、处理任务、领奖的操作页面。

具体地，本发明实施例方案涉及的系统架构可以如图1所示。

如图1所示，该系统架构可以包括：平台服务器101和与所述平台服务器101通信连接的第三方应用服务器102；其中：

平台服务器101：提供应用接入及服务能力、提供用户流量、应用商店、活动等综合服务；同时提供任务、任务广告投放能力及计费、排序等规则，最终响应广告请求，输出一串排序后的广告队列；

第三方应用服务器102：是平台服务器101的内容提供者，接入应用平台并通过投放广告获取用户，给用户提供具体服务，比如游戏等。本实施例平台服务器101可以承载于PC端，也可以承载于手机、平板电脑等可以使用游戏等网络应用的移动终端。

平台服务器101为应用提供创建和投放应用任务和任务推送载体(本实施例以广告举例，以下称广告)的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台。

第三方应用服务器102的应用开发商可以在平台服务器101创建和投放任务以及任务广告，以使应用任务通过广告得到曝光，为应用获取用户。

在平台服务器101的交互平台上设置有用于曝光应用任务广告的广告位，第三方应用服务器102可以根据需要在平台服务器101创建任务及任务广告，经平台服务器101审核通过后，在相应的广告位中投放任务广告，以曝光相应的任务。

其中，每个应用开发商可以有多个产品(应用)，每个应用可创建多条任务(taskid)，每个任务都有一个唯一的任务id，每条任务都可以创建多条广告来投放。曝光时，曝光的是广告，每个广告只唯一关联一条任务(taskid)。

平台服务器101曝光第三方应用服务器102的任务广告后，用户可以点击任务广告安装并进入应用，进行领取任务、处理任务的操作。在接收到用户的领任务请求，平台服务器101将此请求转发给第三方应用服务器102；同时，平台服务器101指引用户进入应用处理领取的任务，根据任务完成情况，更新任务进度表；第三方应用服务器102会解析所述领任务请求，获取用户标识及任务ID，并对应记录用户处理任务的相关数据。在用户完成任务后，第三方应用服务器102根据用户请求向用户发放资源反馈(奖励)，并通知平台服务器101扣费。

具体地，如图2所示，平台服务器101可以包括客户端和数据处理服务器，第三方应用服务器102可以包括第三方应用服务器102客户端和服务器，其中：

平台服务器101客户端提供用户操作界面，供用户领取任务、处理任务(做任务)和领取奖励的平台，平台服务器101客户端主要与平台服务器101服务器及第三方应用服务器102客户端交互，接收用户的领取任务请求，并将用户的领取任务请求发送给第三方应用服务器102客户端，用户即可在第三方应用服务器102上开始处理任务。

平台服务器101数据处理服务器与第三方应用服务器102服务器交互，主要涉及相关数据处理逻辑，以及请求的回调操作等。

在用户处理任务的过程中，第三方应用服务器102服务器会对应记录用户处理任务的相关数据。平台服务器101客户端可以实时查询任务步骤是否完成，并通过平台服务器101的数据处理服务器调用回调接口从第三方应用服务器102服务器拉取数据。在用户完成任务后，平台服务器101从第三方应用服务器102的账户进行扣费操作。

此外，在用户完成任务后，第三方应用服务器102服务器根据平台服务器转发的用户请求向用户发放资源反馈(奖励)，并告知用户。

本实施例平台服务器101与第三方应用服务器102的主要交互流程可以如图3所示。

本实施例平台服务器101的硬件结构可以如图4所示。

图4示出了本发明实施例平台服务器的硬件架构。如图4所示，该平台服务器可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现该平台服务器中各组成部件之间的连接通信。用户接口1003可以包括显示屏(Display)、键盘(Keyboard)、鼠标等组件，用于接收用户输入的信息，并将接收的信息发送至处理器1005进行处理。显示屏可以为LCD显示屏、LED显示屏，也可以为触摸屏，用于显示平台服务器需要显示的数据，例如显示应用任务领取、奖励领取等操作界面。可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。如图4所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及数据交互程序。

在图4所示的平台服务器中，网络接口1004主要用于连接第三方应用服务器，与第三方应用服务器进行数据通信；用户接口1003主要用于连接客户端，与客户端进行数据通信，接收客户端输入的信息和指令；而处理器1001可以用于调用存储器1005中存储的数据交互程序，并执行以下操作：

曝光第三方应用的任务推送载体；

在所述任务推送载体上，接收用户的领任务请求，转发给第三方应用服务器；

指引用户进入应用处理领取的任务；由第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；

向第三方应用服务器请求，获取任务完成情况，根据所述任务完成情况更新任务进度表，并进行相应计费操作。

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

调用第三方应用服务器设定的回调接口，向所述第三方应用服务器发送任务完成查询请求；由第三方应用服务器根据所述任务完成查询请求，分析记录的用户处理任务的相关数据，向所述平台服务器反馈查询结果。

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

接收用户的领取资源反馈请求，调用第三方应用服务器设定的回调接口，向第三方应用服务器发送资源反馈请求；所述资源反馈请求包括用户标识、用户处理的任务ID；由第三方应用服务器根据所述资源反馈请求中的用户标识和任务ID，查询对应的任务是否完成；若完成，则向平台服务器101返回任务完成状态，由平台服务器101为用户发放资源反馈，或者，向平台服务器101返回任务完成状态，同时为用户发放资源反馈，在发放成功后，通知所述平台服务器101。

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

在用户完成任务步骤后，从第三方应用服务器的账户中扣费。

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

当调用所述设定的回调接口超过预定时间时，向用户反馈系统繁忙。

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

接收第三方应用服务器发送的应用任务创建请求；根据所述应用任务创建请求，创建应用任务；对创建的应用任务进行审核。

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

在应用任务审核通过后，接收第三方应用服务器发送的推送载体创建请求；根据所述推送载体创建请求，创建任务推送载体，并关联到指定的任务；对创建的任务推送载体进行审核；在审核通过后，投放任务和任务推送载体。

进一步地，在一个实施例中，处理器1001调用存储器1005中存储的数据交互程序可以执行以下操作：

对投放的任务推送载体进行排期审核。

本实施例通过上述方案，通过平台服务器与第三方应用服务器的交互机制，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台，具体在接收到用户的领任务请求，将此请求转发给第三方应用服务器；同时平台服务器指引用户进入应用处理领取的任务，根据任务完成情况，更新任务进度表；第三方应用服务器解析领任务请求，获取用户标识及任务ID，并对应记录用户处理任务的相关数据；后续，在用户完成任务后，根据用户请求向用户发放资源反馈(奖励)，并通知平台服务器扣费。由此，通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，从而极大的提高了应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。此外，还可以通过特定的排期审核机制，对优质应用集中导量，为应用开发商提供集中开服(以游戏为例)的能力，进一步提高了网页应用尤其是优质网页应用的分发能力，实现流量的合理分配。

下面以平台服务器对游戏的广告推广为应用场景，对本实施例方案进行详细阐述：

该方案涉及的主体包括：第三方应用服务器、平台服务器及用户(玩家)。

用户：游戏玩家。

第三方应用服务器：投放任务方，也是广告主，常见的是APP开发商，在平台中注册账户并负责玩家进入应用后的数据记录。玩家点击广告并完成任务步骤后平台服务器；

平台服务器：把任务作为商品处理，曝光任务相关的广告，并根据效果从广告主账户中扣费，主要负责任务的投放，广告的曝光，广告的点击，效果的计费，任务报表和广告报表等。平台服务器可以由自身提供广告位，也可以由第三方网站提供广告位，并与第三方网站协商广告效果收益。平台服务器将任务和任务广告进行分离，方便管理运营，同时可以减少系统开发成本，因为如果把一个任务看成一个广告，很多个性化的信息比如步骤相关信息都要强行塞进扩展字段里，而且曝光和报表统计均要做很大的改动。若将任务和任务广告分离，把任务看成一个商品，应用开发商对这个商品投很多广告，商品就被存到product表里，广告则变成普通的广告，方便投放管理。

首先，在平台服务器上，通过客户端软件，提供用户操作界面，供第三方应用服务器创建游戏任务和对应的任务广告并投放。由此设置有任务投放端和广告投放端。

需先进入任务投放端(e.qq.com/task/index)投放任务，通过审核后，再进入广告投放端(http://e.qq.com/atlas/)，选择该任务并投放任务广告，任务广告通过审核后，启动任务和广告即可获得曝光。在任务投放端查看任务数据，在广告投放端查看任务广告数据。

其中，每个应用开发商可以有多个产品(应用)，每个应用可创建多条任务(taskid)，每个任务都有一个唯一的任务id，每条任务都可以创建多条广告来投放。曝光时，曝光的是广告，每个广告只唯一关联一条任务(taskid)。

具体地，应用任务及任务广告创建、投放过程如下：

第一步：第三方应用服务器登录任务投放端

第三方应用服务器通过注册账号登录平台服务器客户端，在平台服务器客户端登录任务投放端。

第二步：创建任务

①任务创建界面可以如图5所示，在任务创建界面，点击“创建任务”按钮。

②配置投放设置：手工输入要推广的应用ID(appid)；

③配置任务名称：必填，3至10个字符，本字段仅用于标记，不会对用户曝光。

④配置导入分区：必填，最多六个字符，本字段会对用户曝光，仅供展示，无法将用户导入到这个指定分区。请填写最新的推荐服务器名称，以区或服结尾。例如：双线S12区。

⑤配置任务步骤：必填，设置任务最多有四个步骤，每个步骤均有固定价格。步骤1内容固定为进入XXX应用。步骤2、步骤3由开发商自由设置，但内容中不可包含任何和连续登陆、充值等相关的条件，违规将驳回任务上线申请，且步骤2和步骤3的完成率均需超过20％(步骤完成率＝步骤N完成量/平台安装量)。步骤4可勾选，勾选后，用户完成本步骤将扣步骤4费用。具体如下表1所示：

表1

⑥配置步骤奖励：用户每完成一个步骤，均可以领取一个奖励。每个步骤奖励都需要在任务投放端配置。奖励可以自由设置为金券或道具礼包。当为道具礼包时，需填写：礼包名称(会对用户曝光)、礼包id(第三方应用服务器能识别此id)。礼包详情：该礼包的详细内容。当礼包设置为平台服务器金券：平台服务器会提供一个5金券的包，每个任务可使用一次，该5金券免费。其他情况下使用金券，每实际发出1金券，都会扣0.1元广告费。点击“保存”按钮，可保存设置。

⑦查看任务价格：配置完任务步骤和奖励后，任务的价格就定下来了。可查看到用户完成每一步后消耗多少钱。

⑧配置平台服务器接口：用于查询任务是否完成，以及控制发货。测试时可根据实际需求，填写测试环境地址或正式环境地址，但提交审核前，确保填写的接口地址是正式环境地址。

平台服务器的接口协议包括：Cgi->LogRecv接口协议、点击信息上报接口协议、点击信息入库接口协议，此外还包括其他接口协议，比如：与第三方应用服务器交互的接口协议，包括查询和发奖，其中设定有回调接口；效果计费的接口协议、任务进度更新协议、恶意行为检测接口协议等。

第三步：联调测试

①确认任务配置：确认上一步配置的任务详情，若需修改，请点击页面左下角“上一页”按钮，返回任务创建界面。若确认任务配置无误，滚动鼠标查看后续内容。

②接口测试：

步骤1：进入应用开始页面。

步骤2：点击“开始测试”按钮，程序会自动测试任务每一步骤。当某一步测试失败，测试会自动终止并返回具体错误码。

当步骤2测试通过后，联调已完成，可点击提交审核按钮，提交任务发布审核。

第四步：任务审核

提交审核后，任务处于“审核中”状态。当审核通过，状态更新为“已通过”，当审核未通过，状态更新为“已驳回”，并会附加驳回理由。

审核主要内容可以根据需要设定。

第五步：创建任务广告

①任务通过审核后，登录广告投放端，在广告投放端提供广告创建界面，广告创建界面可以如图6所示。

②创建广告。

③上传平台服务器规定的广告全部规格图片(比如180*90规格)。

④填写广告文案等信息。

广告命名时需和关联的任务实际内容相匹配。比如：畅玩大话神仙领礼包等。

⑤提交广告审核。

第六步：任务广告审核

系统会屏蔽雷同的图片。

第七步：启动投放

任务和任务广告全部通过审核后，启动任务和广告，即可将任务发布至外网。任务和任务广告审核后的状态如下表2所示。

任务状态	任务广告状态	是否产生曝光
			运行中	运行中	是
运行中	暂停	否
			已暂停|已下线|已通过	运行中	否
已暂停|已下线|已通过	暂停	否

表2

第八步：查看效果

①分规格查看任务广告图片的曝光、点击；

②分任务查看任务导量和账户消耗。

③分任务查看推广效果。

之后，还可以对任务和任务广告进行管理，在任务投放端设置有“任务管理功能”，进行任务创建、编辑、删除、查看详情的操作，在广告投放端设置有“任务广告管理”功能，用于管理任务广告。

在任务创建成功后，不可再编辑任务步骤和任务内容。

在应用任务及广告投放后，用户可以通过平台服务器的客户端界面领取任务进入应用、处理任务(做任务)和领取奖励等。

其中，用户领取任务及做任务流程如下：

平台服务器通过广告将应用任务展示给用户。用户点击任务后在新页面打开应用安装页。当用户点击任务，即认为用户任务领取成功。

任务分成多个步骤，用户每完成一个步骤，均可领取奖励。通常认为任务第一步固定为进入应用。

在用户领取任务后，平台服务器会引导用户进入应用中完成相应任务，并给完成任务的用户发放奖励(奖励由用户点击领取奖励而触发)。从而帮助广告主获取用户，并实现广告对用户的价值。平台服务器的做任务界面可以如图7所示。

当用户第一次从平台服务器进入应用时，平台服务器将向第三方应用服务器传递如下参数：

app_user_source：值为marketV3，用于标识用户源自交叉推广渠道任务集市V3版本；

app_contract_id：任务id，标识用户通过哪个任务进入应用；

app_custom：自定义参数，游戏类应用可以自由设置参数内容。

在用户点击“空间任务”icon后，调用fusion2.dialog.showTask接口，弹出“空间任务”弹窗。该弹窗里会显示该用户已领取任务的详情。用户可在弹层内领取任务奖励。

用户在应用内完成任务步骤后，第三方应用服务器不可直接给用户发货(发奖励)，需在收到第三方应用服务器发货通知后再发放奖励。

在领取奖励时，用户需返回平台服务器的广告位进行领奖或应用内领奖。当任务暂停或下线后，不会再有新用户导入，但已领取任务的用户可继续完成任务、领取奖励。

对于任务奖励，任务每个步骤都配置有奖励。奖励内容由应用开发商创建任务时自由设定，如可以包括道具礼包和平台服务器金券两种类型奖励。

当奖励为道具礼包时，第三方应用服务器需在第三方应用服务器服务器配置礼包，并在任务创建界面填写礼包id等内容。

平台服务器可以为每个任务免费配一个预定数量(比如5金券)的奖励。应用开发商可以设定将该奖励使用在任意步骤中，但一个任务仅可使用一次。

应用开发商也可自由配置平台服务器金券为步骤奖励。平台服务器将按照该步骤金券奖励的实际发放量，按照一定比例收取开发商的广告费，比如按照1金券等于0.1元收取开发商广告费。

此外，任务还设置有有效期，任务有效期为平台服务器规定的一个固定数值，比如设置领任务后七天内有效。从用户领取任务的时间开始计算，在任务有效期内，用户均可执行任务。在任务到期后，若任务尚未完成，则用户不可再继续执行或领取奖励。

此外，第三方应用服务器还设定有回调接口，应用开发者按照广告系统提供的接入协议，每创建一个任务时均提供一个具有相应逻辑的接口。由广告系统回调该接口和应用开发者通信，比如查询任务完成情况以及用户领取奖励操作。平台服务器在任务投放端创建任务界面填写本接口地址，由平台服务器回调。

作为一种调用回调接口的应用场景，第三方应用服务器答复平台服务器查询任务步骤完成状态请求：

平台服务器会主动查询用户是否完成某任务的步骤，进行步骤完成率的统计，以便进行相应的计费操作。

此时，第三方应用服务器按照之前协商的“任务完成查询和发货协议说明”来解析请求，并答复平台服务器，该用户是否完成任务步骤和用户完成步骤所在的zoneid。

作为另一种调用回调接口的应用场景，第三方应用服务器向用户发放奖励：

当用户领取任务后去应用做任务，完成任务后在平台服务器点击“领取奖励”按钮时，平台服务器将回调该接口向第三方应用服务器服务器发出“任务步骤是否完成，完成就发货(发奖励)”请求，第三方应用服务器遵循协议“任务完成查询和发货协议说明”，进行回调URL的开发，查询该用户是否完成某步骤，若完成，则给用户发货，发货成功后返回给平台服务器“发货成功”，及用户发货所在的zoneid。若该奖励由平台服务器发放，则第三方应用服务器通知平台服务器给用户发放奖励。

若平台服务器通知给某用户发放某礼包，第三方应用服务器检查已经给该用户发放过该礼包，则返回“该步骤奖励已发放过”。

如果用户在游戏多个区拥有角色，第三方应用服务器可以自行决定给哪个角色发放奖励(比如给最近登录的角色发放奖励)。

更为具体地，平台服务器在调用回调接口时，向第三方应用服务器返回如下参数：

cmd：命令字。平台服务器根据任务步骤的奖励配置和步骤完成判断逻辑，返回不同的命令字，第三方应用服务器作相应操作。

如下是cmd命令字段返回值和说明：

check:第三方应用服务器仅需要查询任务步骤是否完成，返回步骤完成状态，比如平台服务器随时可以向第三方应用服务器发送查询请求，查询任务步骤是否完成，以完成计费操作；或者，用户点击领取奖励按钮时，且该奖励为平台服务器发放(比如Q币)，平台服务器接收到用户的领取奖励请求后，调用回调接口，向第三方应用服务器返回参数check，表明需要查询任务步骤是否完成，若步骤已完成，指示第三方应用服务器返回步骤完成状态。

check_award:第三方应用服务器需要查询任务步骤是否完成，若步骤已完成，直接给用户发货(payitem)，并返回发货是否成功。比如用户点击领取奖励按钮时，且该奖励为第三方应用服务器发放，平台服务器接收到用户的领取奖励请求后，调用回调接口，向第三方应用服务器返回参数check_award，表明需要查询任务步骤是否完成，若步骤已完成，直接给用户发货(payitem)，并返回发货是否成功。

award:平台服务器通知第三方应用服务器直接给给用户发货，开发者返回发货是否成功。

向第三方应用服务器返回的参数还包括：

openid：用户的Openid。用户通过任务集市进入应用时，URL会带该参数。

appid：应用的appid。

version：协议版本号。

contractid：任务id。在系统发布任务后，系统给任务分配的的唯一ID。

payitem：道具礼包id。

providetype：发货类型。

sig：请求串的签名。

当然还可以包括其它参数，在此不再列举。

此外，回调接口的调用还可能产生延迟，当调用回调接口超过预定时间(可以设定，比如2秒)没收到第三方应用服务器的返回码时，平台服务器会记录接口超时，并向用户反馈系统繁忙。

作为一种实施方式，第三方应用服务器还可以对平台服务器发来的各种请求进行合法性校验，具体包括：

首先，第三方应用服务器对平台服务器发来的请求进行解析，得到请求源参数，并获取请求中的sig；

根据得到的请求源参数计算sig；

将计算得到的sig与请求中的sig进行比对；若两者一致，则判断该请求合法。后续，第三方应用服务器可以处理该请求并将结果返回给平台服务器。

本实施例通过上述方案，通过平台服务器与第三方应用服务器的交互机制，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台，由此，通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，实现流量的合理分配，从而极大的提高了应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。

进一步地，作为一种优选实施方式，平台服务器还可以对投放的任务广告进行排期审核。

由于不同的应用开发商具有不同的开发需求(比如游戏的开服需求)，如有些优质游戏，用户量很大，广告点击率、转化率和收益都很高，则可以采用集中导量的方式，为开发商集中开服，并在平台服务器上优先对该游戏进行曝光，以提高游戏应用的分发能力，进而实现流量对广告、平台服务器流水收益最大化。

具体实现如下：

首先获取平台服务器上，所有在线游戏的曝光广告初始排序队列。该初始排序队列是通过设定的排序算法，对在线应用进行排序而得到。

其中，设定的排序算法可以依据各种评判因素，并以一定的计算规则来实现，该评判因素可以依据广告的点击率、转化率、收益等指标来设定。

平台服务器会在收到广告拉取请求时，实时对在线应用的广告进行排序，由此得到所有在线游戏广告的初始排序队列。此外，获取需要强制加权推送的游戏白名单，以达到游戏广告排期审核的目的，对优质游戏集中导量，为游戏开发商提供集中开服的能力，从而提高优质游戏应用的分发能力，满足游戏开发商的需求。

强制加权推送的游戏的获取方式，可以通过平台服务器对所有在线游戏进行筛选，还可以通过人工推荐的方式获取。

在获取等加权推送的游戏白名单后，将这些进入白名单的游戏广告强制加权，使其位于广告曝光排序队列的前面，可以优先于其它普通的任务广告得到推广，并可以使这些游戏得到更多的曝光量。

由于网页游戏特征，需要在较短时间内完成开服，通过其他渠道无法保证获得稳定数额的用户，也无法有效进行预知。

而本实施例通过任务集市独创的“集中导量、排期审核”机制，对优质应用集中导量，可以为应用开发商提供集中开服(以游戏为例)的能力，极大的提高网页应用尤其是优质网页应用的分发能力，满足应用开发商开服需求。比如，游戏开发商可以提前一周提交下周开服计划，由系统通过算法对下周渠道资源进行排期。将优先曝光获得当日排期的应用，通过对排期算法的持续优化，渠道大多数流量集中导入优质应用，应用在可控可预知的日期内，以可控的价格，稳定获得高质用户，满足网络游戏开服需求。而且，对于优质应用，还可以自接入平台服务器后即持续获得任务集市排期。

进一步地，如图8所示，图8为本发明第一实施例提出的数据交互平台服务器的功能模块示意图。

如图8所示，该数据交互平台服务器，包括：推送模块301、接收模块302、引导模块303及操作模块304，其中：

推送模块301，用于曝光第三方应用的任务推送载体；

接收模块302，用于在所述任务推送载体上，接收用户的领任务请求，转发给第三方应用服务器；由所述第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；

引导模块303，用于指引用户进入应用处理领取的任务；

操作模块304，用于向第三方应用服务器请求，获取任务完成情况，根据所述任务完成情况更新任务进度表，并进行相应计费操作。

进一步地，所述操作模块304，还用于调用第三方应用服务器设定的回调接口，向所述第三方应用服务器发送任务完成查询请求；

所述接收模块302，还用于接收所述第三方应用服务器根据所述任务完成查询请求，分析记录的用户处理任务的相关数据反馈的查询结果。

所述接收模块302，还用于接收用户的领取资源反馈请求，调用第三方应用服务器设定的回调接口，向第三方应用服务器发送资源反馈请求；所述资源反馈请求包括用户标识、用户处理的任务ID；以及接收所述第三方应用服务器发送的资源反馈发放成功消息。

所述操作模块304，还用于在用户完成任务步骤后，从第三方应用服务器的账户中扣费。

所述操作模块304，还用于当调用所述设定的回调接口超过预定时间时，向用户反馈系统繁忙。

具体地，本实施例以推送载体为广告进行举例，以下称广告。

平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台。

应用开发商可以在平台服务器创建和投放任务以及任务广告，以使应用任务通过广告得到曝光，为应用获取用户。

在平台服务器上设置有用于曝光应用任务广告的广告位，第三方应用服务器可以根据需要在平台服务器创建任务及任务广告，经平台服务器审核通过后，在相应的广告位中投放任务广告，以曝光相应的任务。

其中，每个应用开发商可以有多个产品(应用)，每个应用可创建多条任务(taskid)，每个任务都有一个唯一的任务id，每条任务都可以创建多条广告来投放。曝光时，曝光的是广告，每个广告只唯一关联一条任务(taskid)。

平台服务器曝光第三方应用服务器的任务广告后，用户可以点击任务广告安装并进入应用，进行领取任务、处理任务的操作。

在接收到用户的领任务请求，平台服务器将此请求转发给第三方应用服务器。

平台服务器通过广告将应用任务展示给用户。用户点击任务后在新页面打开应用安装页。当用户点击任务，即认为用户任务领取成功。

同时，平台服务器指引用户进入应用处理领取的任务。

第三方应用服务器会解析所述领任务请求，获取用户标识及任务ID，并对应记录用户处理任务的相关数据。

平台服务器可以通过第三方应用服务器设定的回调接口，实时向第三方应用服务器请求查询用户的任务完成情况，第三方应用服务器根据所述任务完成查询请求，分析记录的用户处理任务的相关数据，向平台服务器反馈查询结果。

平台服务器根据第三方应用服务器反馈的任务完成情况，更新任务进度表，用于查询曝光广告的进度，以便进行相应计费操作。

用户在完成相应的任务步骤后，可以在平台服务器客户端点击“领奖励”按钮领取奖励。

任务分成多个步骤，用户每完成一个步骤，均可领取奖励。通常认为任务第一步固定为进入应用。奖励内容由应用开发商创建任务时自由设定，如可以包括道具礼包和平台服务器金券两种类型奖励。

在领取奖励时，用户需返回应用平台广告位进行领奖或应用内领奖。

如此，当用户领取任务后去应用做任务，完成任务后在平台服务器点击“领取奖励”按钮时，平台服务器将调用回调接口向第三方应用服务器服务器发出“任务步骤是否完成，完成就发货(发奖励)”请求，第三方应用服务器遵循协议“任务完成查询和发货协议说明”，进行回调URL的开发，查询该用户是否完成某步骤，若完成，则给用户发货，发货成功后返回给平台服务器“发货成功”。若该奖励由平台服务器发放，则第三方应用服务器通知平台服务器给用户发放奖励。

若奖励为平台服务器发放(比如Q币)，平台服务器接收到用户的领取奖励请求后，调用回调接口，向第三方应用服务器返回参数check，表明需要查询任务步骤是否完成。

对于应用安装的奖励，则由平台服务器直接发放奖励，无需调用回调接口。

需要说明的是，上述方案中，当调用第三方应用服务器设定的回调接口超过预定时间没收到第三方应用服务器的返回码时，平台服务器会记录接口超时，并向用户反馈系统繁忙。

在用户完成任务步骤后，平台服务器从第三方应用服务器的账户中扣费。

进一步地，在上述各实施例中，第三方应用服务器在接收到平台服务器发来的各种请求时，第三方应用服务器对请求进行合法性校验，具体过程如下：

首先，第三方应用服务器对平台服务器发来的请求进行解析，得到请求源参数，并获取请求中的sig；

根据得到的请求源参数计算sig；

将计算得到的sig与请求中的sig进行比对；若两者一致，则判断该请求合法。后续，第三方应用服务器可以处理该请求并将结果返回给平台服务器。

本实施例通过上述方案，通过平台服务器与第三方应用服务器的交互机制，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台，由此，通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，实现流量的合理分配，从而极大的提高了应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。

如图9所示，本发明第二实施例提出一种数据交互平台服务器，在上述实施例的基础上，还包括创建模块300；其中：

所述接收模块302，还用于接收所述第三方应用服务器发送的应用任务创建请求；

所述创建模块300，用于根据所述应用任务创建请求，创建应用任务；对创建的应用任务进行审核；

所述接收模块302，还用于在应用任务审核通过后，接收所述第三方应用服务器发送的推送载体创建请求；

所述创建模块300，还用于根据所述推送载体创建请求，创建任务推送载体，并关联到指定的任务；对创建的任务推送载体进行审核；在审核通过后，投放任务和任务推送载体。

应用开发商可以在平台服务器创建和投放任务以及任务广告，以使应用任务通过广告得到曝光，为应用获取用户。

在平台服务器上设置有用于曝光应用任务广告的广告位，第三方应用服务器可以根据需要在平台服务器创建任务及任务广告，经平台服务器审核通过后，在相应的广告位中投放任务广告，以曝光相应的任务。

其中，每个应用开发商可以有多个产品(应用)，每个应用可创建多条任务(taskid)，每个任务都有一个唯一的任务id，每条任务都可以创建多条广告来投放。曝光时，曝光的是广告，每个广告只唯一关联一条任务(taskid)。

本实施例创建、投放任务和任务广告的具体方案，请参照上述系统实施例，在此不再赘述。

如图10所示，本发明第三实施例提出一种数据交互平台服务器，在上述实施例的基础上，还包括：

排期审核模块305，用于对投放的任务推送载体进行排期审核。

本实施例考虑到：由于不同的应用开发商具有不同的开发需求(比如游戏的开服需求)，如有些优质游戏，用户量很大，广告点击率、转化率和收益都很高，则可以采用集中导量的方式，为开发商集中开服，并在平台服务器上优先对该游戏进行曝光，以提高游戏应用的分发能力，进而实现流量对广告、平台服务器流水收益最大化。

具体实现如下：

首先获取平台服务器上，所有在线游戏的曝光广告初始排序队列。该初始排序队列是通过设定的排序算法，对在线应用进行排序而得到。

其中，设定的排序算法可以依据各种评判因素，并以一定的计算规则来实现，该评判因素可以依据广告的点击率、转化率、收益等指标来设定。

广告平台定期在收到广告拉取请求时，实时对在线应用的广告进行排名，由此得到所有在线游戏广告的初始排序队列。

此外，获取需要强制加权推送的游戏白名单，以达到游戏广告排期审核的目的，对优质游戏集中导量，为游戏开发商提供集中开服的能力，从而提高优质游戏应用的分发能力，满足游戏开发商的需求。

强制加权推送的游戏的获取方式，可以通过平台服务器对所有在线游戏进行筛选，还可以通过人工推荐的方式获取。

在获取等加权推送的游戏白名单后，将这些进入白名单的游戏广告强制加权，使其位于广告曝光排序队列的前面，可以优先于其它普通的任务广告得到推广，并可以使这些游戏得到更多的曝光量。

由于网页游戏特征，需要在较短时间内完成开服，通过其他渠道无法保证获得稳定数额的用户，也无法有效进行预知。

而本实施例通过任务集市独创的“集中导量、排期审核”机制，对优质应用集中导量，可以为应用开发商提供集中开服(以游戏为例)的能力，极大的提高网页应用尤其是优质网页应用的分发能力，满足应用开发商开服需求。比如，游戏开发商可以提前一周提交下周开服计划，由系统通过算法对下周渠道资源进行排期。将优先曝光获得当日排期的应用，通过对排期算法的持续优化，渠道大多数流量集中导入优质应用，应用在可控可预知的日期内，以可控的价格，稳定获得高质用户，满足网络游戏开服需求。而且，对于优质应用，还可以自接入平台服务器后即持续获得任务集市排期。

基于上述系统及硬件架构，提出本发明数据交互方法实施例。

如图11所示，本发明第一实施例提出一种数据交互方法，包括：

步骤S201，平台服务器曝光第三方应用的任务推送载体；

本实施例以推送载体为广告进行举例，以下称广告。

平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台。

应用开发商可以在平台服务器创建和投放任务以及任务广告，以使应用任务通过广告得到曝光，为应用获取用户。

在平台服务器上设置有用于曝光应用任务广告的广告位，第三方应用服务器可以根据需要在平台服务器创建任务及任务广告，经平台服务器审核通过后，在相应的广告位中投放任务广告，以曝光相应的任务。

其中，每个应用开发商可以有多个产品(应用)，每个应用可创建多条任务(taskid)，每个任务都有一个唯一的任务id，每条任务都可以创建多条广告来投放。曝光时，曝光的是广告，每个广告只唯一关联一条任务(taskid)。

步骤S202，在所述任务推送载体上，接收用户的领任务请求，转发给第三方应用服务器；

平台服务器曝光第三方应用服务器的任务广告后，用户可以点击任务广告安装并进入应用，进行领取任务、处理任务的操作。

在接收到用户的领任务请求，平台服务器将此请求转发给第三方应用服务器。

平台服务器通过广告将应用任务展示给用户。用户点击任务后在新页面打开应用安装页。当用户点击任务，即认为用户任务领取成功。

步骤S203，所述平台服务器指引用户进入应用处理领取的任务；

同时，平台服务器指引用户进入应用处理领取的任务。

步骤S204，所述第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；

第三方应用服务器会解析所述领任务请求，获取用户标识及任务ID，并对应记录用户处理任务的相关数据。

步骤S205，所述平台服务器向第三方应用服务器请求，获取任务完成情况，根据所述任务完成情况更新任务进度表，并进行相应计费操作。

平台服务器可以通过第三方应用服务器设定的回调接口，实时向第三方应用服务器请求查询用户的任务完成情况，第三方应用服务器根据所述任务完成查询请求，分析记录的用户处理任务的相关数据，向平台服务器反馈查询结果。

平台服务器根据第三方应用服务器反馈的任务完成情况，更新任务进度表，用于查询曝光广告的进度，以便进行相应计费操作。

本实施例通过上述方案，通过平台服务器与第三方应用服务器的交互机制，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务等的操作平台，由此，通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，实现流量的合理分配，从而极大的提高了应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。

如图12所示，本发明第二实施例提出一种数据交互方法，在上述图11所示的实施例的基础上，还包括：

步骤S206，所述平台服务器接收用户的领取资源反馈请求，调用第三方应用服务器设定的回调接口，向第三方应用服务器发送资源反馈请求；所述资源反馈请求包括用户标识、用户处理的任务ID；

步骤S207，所述第三方应用服务器根据所述资源反馈请求中的用户标识和任务ID，查询对应的任务是否完成；若完成，则为用户发放资源反馈，在发放成功后，通知所述平台服务器。

在本实施例中，用户在完成相应的任务步骤后，可以在平台服务器客户端点击“领奖励”按钮领取奖励。

任务分成多个步骤，用户每完成一个步骤，均可领取奖励。通常认为任务第一步固定为进入应用。奖励内容由应用开发商创建任务时自由设定，如可以包括道具礼包和平台服务器金券两种类型奖励。

在领取奖励时，用户需返回平台服务器的广告位进行领奖。

如此，当用户领取任务后去应用做任务，完成任务后在平台服务器点击“领取奖励”按钮时，平台服务器将调用回调接口向第三方应用服务器服务器发出“任务步骤是否完成，完成就发货(发奖励)”请求，第三方应用服务器遵循协议“任务完成查询和发货协议说明”，进行回调URL的开发，查询该用户是否完成某步骤，若完成，则给用户发货，发货成功后返回给平台服务器“发货成功”，及用户发货所在的zoneid。若该奖励由平台服务器发放，则第三方应用服务器通知平台服务器给用户发放奖励。

若奖励为平台服务器发放(比如Q币)，平台服务器接收到用户的领取奖励请求后，调用回调接口，向第三方应用服务器返回参数check，表明需要查询任务步骤是否完成。

对于应用安装的奖励，则由平台服务器直接发放奖励，无需调用回调接口。

需要说明的是，上述方案中，当调用第三方应用服务器设定的回调接口超过预定时间没收到第三方应用服务器的返回码时，平台服务器会记录接口超时，并向用户反馈系统繁忙。

本实施例通过上述方案，通过平台服务器与第三方应用服务器的交互机制，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台，由此，通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，实现流量的合理分配，从而极大的提高了应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。

如图13所示，本发明第三实施例提出一种数据交互方法，在上述图12所示的实施例的基础上，还包括：

步骤S208，在用户完成任务步骤后，平台服务器从第三方应用服务器的账户中扣费。

在本实施例中，在用户完成任务步骤后，平台服务器从第三方应用服务器的账户中扣费。

进一步地，在上述各实施例中，第三方应用服务器在接收到平台服务器发来的各种请求时，第三方应用服务器对请求进行合法性校验，具体过程如下：

首先，第三方应用服务器对平台服务器发来的请求进行解析，得到请求源参数，并获取请求中的sig；

根据得到的请求源参数计算sig；

将计算得到的sig与请求中的sig进行比对；若两者一致，则判断该请求合法。后续，第三方应用服务器可以处理该请求并将结果返回给平台服务器。

如图14所示，本发明第四实施例提出一种数据交互方法，在上述图13所示的实施例的基础上，在上述步骤S201之前还包括：

步骤S70，所述第三方应用服务器向所述平台服务器发送应用任务创建请求；

步骤S80，所述平台服务器根据所述应用任务创建请求，创建应用任务；对创建的应用任务进行审核。

步骤S90，在应用任务审核通过后，第三方应用服务器向所述平台服务器发送广告创建请求；

步骤S200，所述平台服务器根据所述广告创建请求，创建任务广告，并关联到指定的任务；对创建的任务广告进行审核；在审核通过后，投放任务和任务广告。

应用开发商可以在平台服务器创建和投放任务以及任务广告，以使应用任务通过广告得到曝光，为应用获取用户。

在平台服务器上设置有用于曝光应用任务广告的广告位，第三方应用服务器可以根据需要在平台服务器创建任务及任务广告，经平台服务器审核通过后，在相应的广告位中投放任务广告，以曝光相应的任务。

其中，每个应用开发商可以有多个产品(应用)，每个应用可创建多条任务(taskid)，每个任务都有一个唯一的任务id，每条任务都可以创建多条广告来投放。曝光时，曝光的是广告，每个广告只唯一关联一条任务(taskid)。

本实施例创建、投放任务和任务广告的具体方案，请参照上述系统实施例，在此不再赘述。

如图15所示，本发明第五实施例提出一种数据交互方法，在上述图14所示的实施例的基础上，在上述步骤S200之后，还包括：

步骤S60，所述平台服务器对投放的任务广告进行排期审核。

本实施例考虑到：由于不同的应用开发商具有不同的开发需求(比如游戏的开服需求)，如有些优质游戏，用户量很大，广告点击率、转化率和收益都很高，则可以采用集中导量的方式，为开发商集中开服，并在平台服务器上优先对该游戏进行曝光，以提高游戏应用的分发能力，进而实现流量对广告、平台服务器流水收益最大化。

具体实现如下：

首先获取平台服务器上，所有在线游戏的曝光广告初始排序队列。该初始排序队列是通过设定的排序算法，对在线应用进行排序而得到。

其中，设定的排序算法可以依据各种评判因素，并以一定的计算规则来实现，该评判因素可以依据广告的点击率、转化率、收益等指标来设定。

广告平台定期在收到广告拉取请求时，实时对在线应用的广告进行排名，由此得到所有在线游戏广告的初始排序队列。

此外，获取需要强制加权推送的游戏白名单，以达到游戏广告排期审核的目的，对优质游戏集中导量，为游戏开发商提供集中开服的能力，从而提高优质游戏应用的分发能力，满足游戏开发商的需求。

强制加权推送的游戏的获取方式，可以通过平台服务器对所有在线游戏进行筛选，还可以通过人工推荐的方式获取。

在获取等加权推送的游戏白名单后，将这些进入白名单的游戏广告强制加权，使其位于广告曝光排序队列的前面，可以优先于其它普通的任务广告得到推广，并可以使这些游戏得到更多的曝光量。

由于网页游戏特征，需要在较短时间内完成开服，通过其他渠道无法保证获得稳定数额的用户，也无法有效进行预知。

而本实施例通过任务集市独创的“集中导量、排期审核”机制，对优质应用集中导量，可以为应用开发商提供集中开服(以游戏为例)的能力，极大的提高网页应用尤其是优质网页应用的分发能力，满足应用开发商开服需求。比如，游戏开发商可以提前一周提交下周开服计划，由系统通过算法对下周渠道资源进行排期。将优先曝光获得当日排期的应用，通过对排期算法的持续优化，渠道大多数流量集中导入优质应用，应用在可控可预知的日期内，以可控的价格，稳定获得高质用户，满足网络游戏开服需求。而且，对于优质应用，还可以自接入平台服务器后即持续获得任务集市排期。

本发明实施例数据交互方法、平台服务器及系统，通过平台服务器与第三方应用服务器的交互机制，平台服务器为应用提供创建和投放应用任务和任务广告的平台，同时也为用户提供了领取任务、处理任务及领取资源反馈(奖励)的操作平台，具体在接收到用户的领任务请求，将此请求转发给第三方应用服务器；同时平台服务器指引用户进入应用处理领取的任务，根据任务完成情况，更新任务进度表；第三方应用服务器解析领任务请求，获取用户标识及任务ID，并对应记录用户处理任务的相关数据；后续，在用户完成任务后，根据用户请求向用户发放资源反馈(奖励)，并通知平台服务器扣费。由此，通过将应用产品、应用产品的推送载体与平台服务器进行系统结合，有利于应用的曝光和用户渠道资源整合，从而极大的提高了应用产品的分发能力，满足应用开发商的需求，实现了效益的最大化。此外，还可以通过特定的排期审核机制，对优质应用集中导量，为应用开发商提供集中开服(以游戏为例)的能力，进一步提高了网页应用尤其是优质网页应用的分发能力，实现流量的合理分配。

还需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (20)

1.一种数据交互方法，其特征在于，包括：

平台服务器接收第三方应用服务器发送的应用任务创建请求；

所述平台服务器根据所述应用任务创建请求以及第三方服务器设置的任务步骤，创建应用任务，对每个任务步骤进行联调测试，测试通过后对创建的应用任务进行审核；

在应用任务审核通过后，所述平台服务器接收所述第三方应用服务器发送的推送载体创建请求；

所述平台服务器根据所述推送载体创建请求，创建任务推送载体，并关联到所述应用任务；对创建的任务推送载体进行审核；

在任务推送载体审核通过后，平台服务器投放第三方应用的所述应用任务和任务推送载体；

在所述任务推送载体上，所述平台服务器接收用户的领任务请求，转发给第三方应用服务器；其中，所述第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；

所述平台服务器指引用户进入应用处理领取的任务；

所述平台服务器向第三方应用服务器请求，获取任务完成情况，根据所述任务完成情况更新任务进度表，并进行相应计费操作。

2.根据权利要求1所述的方法，其特征在于，所述平台服务器向第三方应用服务器请求，获取任务完成情况的步骤包括：

所述平台服务器调用第三方应用服务器设定的回调接口，向所述第三方应用服务器发送任务完成查询请求；

所述平台服务器接收所述第三方应用服务器反馈的查询结果；其中，所述第三方应用服务器根据所述任务完成查询请求，分析记录的用户处理任务的相关数据，向所述平台服务器反馈所述查询结果。

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

所述平台服务器接收用户的领取资源反馈请求，调用第三方应用服务器设定的回调接口，向第三方应用服务器发送资源反馈请求；所述资源反馈请求包括用户标识、用户处理的任务ID；

所述平台服务器接收所述第三方应用服务器反馈的任务完成状态；其中，所述第三方应用服务器根据所述资源反馈请求中的用户标识和任务ID，查询对应的任务是否完成；若完成，则向平台服务器返回任务完成状态，由平台服务器为用户发放资源反馈，或者，向平台服务器返回任务完成状态，同时为用户发放资源反馈，在发放成功后，通知所述平台服务器。

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

在用户完成任务步骤后，

所述平台服务器从第三方应用服务器的账户中扣费。

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

当调用所述设定的回调接口超过预定时间时，所述平台服务器向用户反馈系统繁忙。

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

在接收到平台服务器发来的各种请求时，所述第三方应用服务器对请求进行合法性校验，具体包括：

所述第三方应用服务器对平台服务器发来的请求进行解析，得到请求源参数，并获取请求中的sig；

根据得到的请求源参数计算sig；

将计算得到的sig与请求中的sig进行比对；若两者一致，则判断该请求合法。

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

所述平台服务器对投放的任务推送载体进行排期审核。

8.一种数据交互平台服务器，其特征在于，包括：

推送模块，用于曝光第三方应用的任务推送载体；接收模块，用于接收第三方应用服务器发送的应用任务创建请求，在应用任务审核通过后，接收所述第三方应用服务器发送的推送载体创建请求；在所述任务推送载体上，接收用户的领任务请求，转发给第三方应用服务器；由所述第三方应用服务器解析所述领任务请求，对应记录用户处理任务的相关数据；

创建模块，用于根据所述应用任务创建请求以及第三方服务器设置的任务步骤，创建应用任务，对每个任务步骤进行联调测试，测试通过后对创建的应用任务进行审核；根据所述推送载体创建请求，创建任务推送载体，并关联到所述应用任务；对创建的任务推送载体进行审核；在任务推送载体审核通过后，投放所述第三方应用的所述应用任务和任务推送载体；

引导模块，用于指引用户进入应用处理领取的任务；

操作模块，用于向第三方应用服务器请求，获取任务完成情况，根据所述任务完成情况更新任务进度表，并进行相应计费操作。

9.根据权利要求8所述的平台服务器，其特征在于，

所述操作模块，还用于调用第三方应用服务器设定的回调接口，向所述第三方应用服务器发送任务完成查询请求；

所述接收模块，还用于接收所述第三方应用服务器根据所述任务完成查询请求，分析记录的用户处理任务的相关数据反馈的查询结果。

10.根据权利要求8所述的平台服务器，其特征在于，

所述接收模块，还用于接收用户的领取资源反馈请求，调用第三方应用服务器设定的回调接口，向第三方应用服务器发送资源反馈请求；所述资源反馈请求包括用户标识、用户处理的任务ID；以及接收所述第三方应用服务器返回的任务完成状态，以及发送的资源反馈发放成功消息。

11.根据权利要求9或10所述的平台服务器，其特征在于，

所述操作模块，还用于在用户完成任务步骤后，从第三方应用服务器的账户中扣费。

12.根据权利要求9或10所述的平台服务器，其特征在于，

所述操作模块，还用于当调用所述第三方应用服务器设定的回调接口超过预定时间时，向用户反馈系统繁忙。

13.根据权利要求8所述的平台服务器，其特征在于，还包括：

排期审核模块，用于对投放的任务推送载体进行排期审核。

14.一种数据交互系统，其特征在于，包括：平台服务器和与所述平台服务器通信连接的第三方应用服务器，其中：

所述平台服务器为权利要求8-13中任一项所述的平台服务器；

所述第三方应用服务器，用于解析所述领任务请求，对应记录用户处理任务的相关数据；接收所述平台服务器的请求，进行相应处理。

15.根据权利要求14所述的系统，其特征在于，

所述第三方应用服务器，还用于根据所述任务完成查询请求，分析记录的用户处理任务的相关数据，向所述平台服务器反馈查询结果。

16.根据权利要求14所述的系统，其特征在于，

所述第三方应用服务器，还用于接收资源反馈请求，根据所述资源反馈请求中的用户标识和任务ID，查询对应的任务是否完成；若完成，则向平台服务器返回任务完成状态，由平台服务器为用户发放资源反馈，或者，向平台服务器返回任务完成状态，同时为用户发放资源反馈，在发放成功后，通知所述平台服务器。

17.根据权利要求14所述的系统，其特征在于，

所述第三方应用服务器，还用于在用户完成任务步骤后，向平台服务器发送扣费通知。

18.根据权利要求14所述的系统，其特征在于，

所述第三方应用服务器，还用于在接收到平台服务器发来的各种请求时，对请求进行合法性校验；具体用于：

对平台服务器发来的请求进行解析，得到请求源参数，并获取请求中的sig；

根据得到的请求源参数计算sig；

将计算得到的sig与请求中的sig进行比对；若两者一致，则判断该请求合法。

19.根据权利要求14所述的系统，其特征在于，

所述第三方应用服务器，还用于向所述平台服务器发送应用任务创建请求，以及在应用任务审核通过后，向所述平台服务器发送推送载体创建请求。

20.一种非易失性机器可读存储介质，其特征在于，所述存储介质中存储有机器可读指令，所述机器可读指令可以由处理器执行以完成如权利要求1-7任一项所述的方法。