一种新型聚合广告系统的广告展示方法与流程

1.本发明涉及移动互联网领域，提出了一种新型聚合广告系统的广告展示方法。


背景技术：

2.随着移动互联网系统的高速发展，手机上安装应用越来越多，用户使用手机时长越来越多，移动互联网广告规模也日益加大，很多中小型开发者依赖广告收益作为主要营收来源。现有很多广告平台处于各自为政阶段，各家广告平台都有自己长处和短处，作为移动应用的开发者最希望的肯定是集各家之长，避各家之短。所以开发者们就开始自行对接每家广告平台，取其高价值的广告用于展示提升收入，但是：
3.由于每一家广告接口对接方式都存在差异，导致每接一家都要花费大量时间做接口适应性开发和调试，进度非常缓慢而错误率高。
4.此外，由于没有预加载机制，用户感知广告请求过长，用户无心等待直接离开，广告展示率一直处于较低水平，大量高价值广告没有展示机会，错失大量收入。
5.再次，由于缺少人群管理机制，用户偏好价值无法发挥，大量无效广告展示带来收入极低，如能通过人群管理方式针对下发不同价值广告，将大大提升每次广告展示价值，带来可观收入提升。
6.总上述原因，设计一种新型聚合广告系统的广告展示方法，能为中小开发者大幅提升现有广告收入。


技术实现要素：

7.为了解决上述现有技术中存在的问题，本发明通过虚拟广告位提升广告互用性；通过广告预加载配置减少用户等待时间；通过人群管理根据用户各种属性进行人群分离，每种人群定制化展示不同广告内容；每个人群下面还可以制定多个策略同时做抽样的ab测试，不同策略可以配置不同广告源和广告串并行加载广告方案，测试不同广告配置方案价值，择优保留，二次深度测试。
8.本发明解决其技术问题所采用的技术方案是：
9.一种新型聚合广告系统的广告展示方法，包括有以下步骤：
10.步骤1：客户端调用mustang
‑
sdk请求加载指定广告位id的广告，服务器根据sdk请求广告所带的用户特征属性和平台大数据，经过算法得出标签属性定向所属的用户人群，根据用户人群找出所预定的广告策略配置，再从广告策略配置里面随机提取一套广告策略下发给sdk；
11.步骤2：sdk收到任意一组策略后，根据策略配置串并行请求广告、预加载和缓存配置，逻辑系统开始实际广告平台请求流程请求广告；
12.如果策略配置是有启动预加载，那么sdk自行马上开始请求广告，无需客户端发起；
13.如果策略配置缓存机制，那么并行请求下得到多于1个广告返回，sdk把多出来广
告放到暂存区，下次客户端发起广告请求时，马上从暂存区拿出广告返回给客户端用于广告展示。
14.本发明还具有以下附加技术特征：
15.作为本发明技术方案进一步具体优化的：步骤1中，客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果有，马上把广告返回给客户端；如果不存在广告，sdk开始一次从服务器拿广告策略配置到请求广告平台的流程。
16.作为本发明技术方案进一步具体优化的：步骤1中，所述广告策略配置是一个请求广告串并行结构，sdk首先查看服务器是否有下发bid并行请求分组；
17.如果有则bid和非bid同时开始请求广告，非bid请求会以串行的方式提取编号排序好的组配置，接着根据组内是一个代码位配置还是多个代码位配置决定是否需要并行请求多个广告；
18.如果出现多个代码位在规定时间内都拿到广告，则按组内排序优先级决定出哪个广告优先展示，不展示广告放到缓存暂存区。
19.作为本发明技术方案进一步具体优化的：步骤2中，实现过程如下：
20.(4)客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果有，马上把广告返回给客户端。
21.(5)客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果没有，sdk发起一次请求到mustang服务器，服务器根据sdk请求广告所带用户特征属性和平台大数据这个用户标签属性定向所属的用户人群；根据用户人群找出所预定的广告策略配置，再从广告策略配置里面随机提取一套广告策略下发给sdk；
22.(6)sdk收到任意一组策略后，根据策略配置串并行请求广告、预加载和缓存配置，逻辑系统开始实际广告平台请求流程请求广告。如果策略配置是有启动预加载，那么sdk自行马上开始请求广告，无需客户端发起；如果策略配置缓存机制，那么并行请求下得到多于1个广告返回，sdk把多出来广告放到暂存区，下次客户端发起广告请求时，马上从暂存区拿出广告返回给客户端用于广告展示。
23.作为本发明技术方案进一步具体优化的：平台大数据的用户标标签属性通过算法和历史数据按不同维度汇总得出；
24.历史数据方面例如用户每天观看广告次数、每个广告大致价值、喜欢看哪方面的广告等等；算法方面会根据用户经常出入地理位置，使用什么手机应用、应用使用时长，外部第三方数据等计算出用户性别，年龄，应用使用偏好，生活习惯等维度用户标签，储存在云端。
25.本发明和现有技术相比，其优点在于：
26.本发明通过虚拟广告位提升广告互用性；通过广告预加载配置减少用户等待时间；通过人群管理根据用户各种属性进行人群分离，每种人群定制化展示不同广告内容；每个人群下面还可以制定多个策略同时做抽样的ab测试，不同策略可以配置不同广告源和广告串并行加载广告方案，测试不同广告配置方案价值，择优保留，二次深度测试。
27.本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变
得明显，或通过本发明的实践了解到。
附图说明
28.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
29.图1
‑
图2为本发明的sdk的工作原理示意图；
30.图3
‑
图6为本发明的服务器的工作原理示意图。
具体实施方式
31.下面将参照附图更详细地描述本发明公开的示例性实施例，这些实施例是为了能够更透彻地理解本发明，并且能够将本发明公开的范围完整的传达给本领域的技术人员。虽然附图中显示了本发明公开的示例性实施例，然而应当理解，本发明而不应被这里阐述的实施例所限制。
32.一种新型聚合广告系统的广告展示方法，包括有以下步骤：
33.步骤1：客户端调用mustang
‑
sdk请求加载指定广告位id的广告，服务器根据sdk请求广告所带的用户特征属性和平台大数据，经过算法得出标签属性定向所属的用户人群，根据用户人群找出所预定的广告策略配置，再从广告策略配置里面随机提取一套广告策略下发给sdk；
34.步骤2：sdk收到任意一组策略后，根据策略配置串并行请求广告、预加载和缓存配置，逻辑系统开始实际广告平台请求流程请求广告；
35.如果策略配置是有启动预加载，那么sdk自行马上开始请求广告，无需客户端发起；
36.如果策略配置缓存机制，那么并行请求下得到多于1个广告返回，sdk把多出来广告放到暂存区，下次客户端发起广告请求时，马上从暂存区拿出广告返回给客户端用于广告展示。
37.用户人群：mustang广告可以根据用户各种属性进行人群分离，从而制定各个特定人群进行广告和内容变现优化，提升用户价值。
38.聚合广告：即新型聚合广告系统里面包含多个第三方的广告源，每个广告源来源于不同广告公司，每个公司独立一个广告系统。
39.物理广告位：即软件产品中，一个真实存在广告的场景。
40.虚拟广告位：这是多个物理广告位的集合，主要用于提升广告的预加载使用范围和广告在每个物理广告位的互用性。
41.客户端：这是ios手机和android手机的统称。
42.优化的：步骤1中，客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果有，马上把广告返回给客户端；如果不存在广告，sdk开始一次从服务器拿广告策略配置到请求广告平台的流程。
43.优化的：步骤1中，所述广告策略配置是一个请求广告串并行结构，sdk首先查看服
务器是否有下发bid并行请求分组；
44.如果有则bid和非bid同时开始请求广告，非bid请求会以串行的方式提取编号排序好的组配置，接着根据组内是一个代码位配置还是多个代码位配置决定是否需要并行请求多个广告；
45.如果出现多个代码位在规定时间内都拿到广告，则按组内排序优先级决定出哪个广告优先展示，不展示广告放到缓存暂存区。
46.优化的：步骤2中，实现过程如下：
47.客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果有，马上把广告返回给客户端。
48.客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果没有，sdk发起一次请求到mustang服务器，服务器根据sdk请求广告所带用户特征属性和平台大数据这个用户标签属性定向所属的用户人群；根据用户人群找出所预定的广告策略配置，再从广告策略配置里面随机提取一套广告策略下发给sdk；
49.sdk收到任意一组策略后，根据策略配置串并行请求广告、预加载和缓存配置，逻辑系统开始实际广告平台请求流程请求广告。如果策略配置是有启动预加载，那么sdk自行马上开始请求广告，无需客户端发起；如果策略配置缓存机制，那么并行请求下得到多于1个广告返回，sdk把多出来广告放到暂存区，下次客户端发起广告请求时，马上从暂存区拿出广告返回给客户端用于广告展示。
50.优化的：平台大数据的用户标标签属性通过算法和历史数据按不同维度汇总得出；历史数据方面例如用户每天观看广告次数、每个广告大致价值、喜欢看哪方面的广告等等；算法方面会根据用户经常出入地理位置，使用什么手机应用、应用使用时长，外部第三方数据等计算出用户性别，年龄，应用使用偏好，生活习惯等维度用户标签，储存在云端。
51.实施例1
52.客户端调用mustang
‑
sdk请求加载指定广告位id的广告，服务器根据sdk请求广告所带用户特征属性和平台大数据这个用户经过算法得出标签属性定向所属的用户人群，根据用户人群找出所预定的广告策略配置，再从广告策略配置里面随机提取一套广告策略下发给sdk，
53.sdk收到任意一组策略后，根据策略配置串并行请求广告、预加载和缓存配置，逻辑系统开始实际广告平台请求流程请求广告。如果策略配置是有启动预加载，那么sdk自行马上开始请求广告，无需客户端发起；如果策略配置缓存机制，那么并行请求下得到多于1个广告返回，sdk把多出来广告放到暂存区，下次客户端发起广告请求时，马上从暂存区拿出广告返回给客户端用于广告展示。
54.sdk的工作原理：
55.如下图1和图2，客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果有，马上把广告返回给客户端；如果不存在广告，sdk开始一次从服务器拿广告策略配置到请求广告平台的流程。
56.广告策略配置是一个请求广告串并行结构，sdk首先查看服务器是否有下发bid并行请求分组，如果有则bid和非bid同时开始请求广告，非bid请求会以串行的方式提取编号
排序好的组配置，接着根据组内是一个代码位配置还是多个代码位配置决定是否需要并行请求多个广告，如果出现多个代码位在规定时间内都拿到广告，则按组内排序优先级决定出哪个广告优先展示，不展示广告放到缓存暂存区。
57.服务器的工作原理：
58.具体流程如图3
‑
图6，实现过程如下：
59.客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果有，马上把广告返回给客户端。
60.客户端调用mustang
‑
sdk请求加载指定广告位id的广告，sdk内部先查看暂存区里面是否存在“未失效广告”，如果没有，sdk发起一次请求到mustang服务器，服务器根据sdk请求广告所带用户特征属性和平台大数据这个用户标签属性定向所属的用户人群，(补充:平台大数据的用户标标签属性通过算法和历史数据按不同维度汇总得出。历史数据方面例如用户每天观看广告次数、每个广告大致价值、喜欢看哪方面的广告等等；算法方面会根据用户经常出入地理位置，使用什么手机应用、应用使用时长，外部第三方数据等计算出用户性别，年龄，应用使用偏好，生活习惯等维度用户标签，储存在云端)根据用户人群找出所预定的广告策略配置，再从广告策略配置里面随机提取一套广告策略下发给sdk。
61.sdk收到任意一组策略后，根据策略配置串并行请求广告、预加载和缓存配置，逻辑系统开始实际广告平台请求流程请求广告。如果策略配置是有启动预加载，那么sdk自行马上开始请求广告，无需客户端发起；如果策略配置缓存机制，那么并行请求下得到多于1个广告返回，sdk把多出来广告放到暂存区，下次客户端发起广告请求时，马上从暂存区拿出广告返回给客户端用于广告展示。
62.为使本发明实施例的目的、技术方案和优点更加清楚，上面结合本发明实施例中的附图，对本发明实施例中的技术方案进行了清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
63.因此，以上对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
64.在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
65.在本发明的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。