1. 基础概念

1.1 什么是Head Bidding（头部竞价）

Header Bidding是一种实时的程序化广告竞价技术，允许所有需求方针对同一个广告展示同时竞价，最高出价者获得展示机会，这确保发布商的每次展示可以获得更高的收益。 Header Bidding可以让开发者获知每一次展示的价值，对后续的数据分析有重大作用。

Taku头部竞价原理:

① 每次请求广告时都会向头部竞价广告源询价，返回的价格会和创建常规广告源时填写的价格进行排序。广告请求按排序后的瀑布流优先级进行请求。

② 头部竞价与常规广告源最大的区别就是每次请求都会先去询一个价格，而不是固定为创建常规广告源时填写的价格。Header Bidding则允许各个广告平台公开竞价，确保当每一次广告曝光机会来临时，开发者能展示eCPM最高的广告。

文章图片

● 示例：

在设置头部竞价后，如下图，当常规底价广告源按排序价格逐层请求时，腾讯Bidding广告源会同时发起询价，由腾讯Bidding返回他们的出价。假如平台方的出价为160，则会用这个160的价格参与到瀑布流的排序当中，在第二优先级进行请求。

● 更多头部竞价功能介绍 >>点击查看

1.2 什么是瀑布流（Waterfall）

瀑布流，即广告分层，是广告运营优化的主要策略之一。

在进行广告变现时，若只集成一家广告平台，往往无法达到100%的广告填充，而且eCPM也不太稳定。因此一般建议集成5-8家广告平台，使用不同底价的广告源、结合Bidding的分层，设置成按照排序价格从高到低进行请求，通过广告分层的方式尽可能保证填充率和提升收益。

如下图，按照各广告平台历史eCPM从高到低配置瀑布流。当优先级最高的广告平台A没有广告返回时，则向下请求优先级第二的广告平台B。依此类推，直到某家广告平台返回了可展示的广告。这种分层方式能帮助您避免因某个平台没有广告返回而浪费当次请求，保证每次都收益都是最优的填充。

文章图片

1.3 排序价格

(1) 什么是排序价格

排序价格用于广告请求时的优先级排序：比如添加了ABCDE 5层广告源，需要对这5层广告源进行排序，这个排序会按照填写的价格从高到低排序，并不影响广告填充。建议该价格与该广告源真实eCPM（即eCPM API）数值尽可能一致，可用于预估当天实时的收益和LTV。

（注意：若多个广告源的排序价格一样，则优先级一样，每次请求时随机优先级请求。）

(2) 排序价格填写技巧

首先区分账号是否有三方广告平台的底价权限（一般三方广告平台对开放底价权限有流水要求，建议自行联系三方平台的AM确认是否有底价权限或者开通底价权限）。

① 有底价权限：按照在三方平台设置的底价填写即可。

② 没有底价权限：可以按照开发者自己的意愿进行配置，原因是Taku后台的排序价格只会影响Taku SDK在进行广告请求和展示的顺序。

举例，当穿山甲广告源A没有底价权限的时候，不论设置排序价格为1还是100，只要他的排序是所有其他广告源里面最高的，都会先请求穿山甲广告源A。这时候不论穿山甲平台返回任何价格的广告，即使平台返回价格为0.01的广告，在实际广告展示的时候都会优先展示这个穿山甲广告源A。这是因为在Taku后台设置的排序价格只影响请求和展示时候的优先顺序。如开发者希望穿山甲第一个请求展示，优量汇第二个进行请求展示，只需要设置穿山甲的排序价格大于优量汇即可，如可设置穿山甲排序价格=2，优量汇排序价格=1。

2. 为什么要精细化广告分层

由于每个广告平台都有高价和低价offer，尽可能展示高价offer才能更好地提高整体收益。如下左图示，广告平台A和B的平均eCPM分别是20、15，整体上A比B好，所以A排在前面。但这样排序会有一些不足：B虽然平均eCPM比A低，但是头部的offer（广告）往往会比A尾部的offer表现要好，但是排序是在A尾部offer之后。

所谓精细化广告分层，一般通过设置eCPM Floor（底价）的方式来尽可能优先展示高价格的offer。如下右图示，将A、B两个广告平台分别创建多个广告单元，不同广告平台交叉排序设置，依次从高到低排序，可优先展示高价格的offer，提高整体收益。

3. 如何进行设置和精细化广告分层

3.1 选择合适的三方广告平台

根据流量地区和应用品类不同，开发者可以根据实际需要选择广告平台。（以下方案仅供参考，排名不分先后。）

中国大陆：穿山甲、优量汇、快手、百度、Mintegral、Taku ADX，等。

不同广告平台的表现，可以浏览Taku年度报告了解，或者咨询您的Taku商务/运营经理。

注：Taku ADX不需要SDK单独接入，开发者后台可直接开启使用，不需要另外发版。（Taku ADX详情：请参考文档）

3.2 瀑布流设置

● 基础阶段

情况一：如果有跑过其他广告平台，参考历史广告价格。

例如，某应用A历史在Admob有单独通跑过开屏，开屏价格为5刀，则可以设置一个从高价（高价参考5刀适当提升）到低价格的开屏瀑布流。可设置从50刀到无底价层的多层瀑布流。

Tip：创建和设置广告分层时，建议Taku后台的排序价格和三方后台的实际价格设置为一致，方便后续调整。

情况二：全新的应用，没有跑过其他广告平台，也没有相应的历史广告价格。

（1）先在Taku设置一个简单的瀑布流以及对应的广告源排序价格，进行通跑至少两到三天，再进行数据调整。

通跑一段时间（约两到三天，最长一周时间，判定标准为：单层广告源累计展示大于2000）后根据三方后台广告源实际价格调整修改瀑布流。（原因是广告平台的代码位出价需要至少单代码位展示量大于2000才会有稳定的出价算法模型）
例如，TopOn后台设置①“50到无底价”多个层级，间隔为10的瀑布流（区分不同平台设置瀑布流分层即可，没有严格要求。例如Admob50，AppLovin40，Admob30，……，到Admob无底价），一段时间后根据三方后台实际价格调整。②可添加各平台Bidding。（例如Admob、Pangle、Vungle等）。
初始瀑布流建议结合上述①和②同时设置。也可以参考下述瀑布流结构参考表格进行设置。

（2）广告分层瀑布流结构参考：
基本原则：
● 广告分层的层数设置可以参考DAU或者预估日请求量级，如果DAU较多可以设置较多、较密层级，以便流量请求能够被充分利用。
● 广告层数较多的时候可以使用并行请求功能（如设置并行请求3），减少填充耗时。
● 在Taku后台配置的时候，尽量使用实际eCPM的价格作为排序价格。如果是无底价层，在前期可以设置0.01的排序价格，上线后累计展示量级较多（大于2000）以后可以打开自动价格功能。

补充

● 初次设置时，各广告平台设置层数权重，建议与该广告平台收益贡献占比保持一致。比如，历史广告收益数据中，广告平台A、B、C占比分别为50%、30%、20%，假设在瀑布流中需要设置10个广告源，广告平台A、B、C分别设置5、3、2个即可。
● 变现初期，可考虑设置无底价广告源作为兜底广告，保证整体填充率。

Tips：瀑布流结构参考表格：

瀑布流部位	配置	层数	备注
并行层-Bidding区域	广告平台A-bidding1 广告平台B-bidding2 广告平台C-bidding3 广告平台D-bidding4	2-4层	不建议设置广告平台竞价底价。原因是设置竞价底价容易导致bidding广告源填充率过低。
头部- 高底价区域	广告平台A-价格80	2-4层
中部- 中底价区域	广告平台B-价格70 广告平台C-价格60 广告平台D-价格50 广告平台A-价格40 广告平台E-价格30 广告平台F-价格20	2-8层
尾部- 低底价或者无底价区域	广告平台A-价格10 广告平台G-价格8 广告平台F-价格5 广告平台B-价格0.01（兜底层）	2-6层	兜底层：可设置由平台自主出价，不设置具体价格。在Taku后台设置较低的排序价格，例如0.5，并且打开自动出价。

● 进阶设置

(1) 最大化瀑布流基本原理

出于充分利用流量请求的考虑，我们建议确保每个广告位瀑布流整体填充率高于90%。稳定运营阶段需要根据各层广告源填充率调整底价：ecpm底价越高则对应广告源填充率越低，各层广告源填充率控制在5%以上，最低不少于1%。除开屏外，若广告源填充率在10%及以上，可尝试提高首层广告源底价。

① 高底价区：尽可能提高单价。

② 中底价区：充分利用流量。如果有较多流量流至低层时，需要在其间添加中间层。

例如：

第二层广告源￥20，展示1000；

第三层广告源￥10，展示10000。

则可以在￥10-20之间再添加一层￥15。

③ 低价区：设置低价格以及无底价广告源。充分利用流量，利用低价格兜底。

(2) 广告分层的数量限制说明

Taku的广告分层并没有数量限制，但更多的开发者选择分层在10-20层区间；结合用户网络、填充率和eCPM表现等数据可进行广告分层的适当增减。

当设置较多广告分层（例如20-40，或者大于40层时），可通过聚合管理-高级设置，设置并行数量为4-8，提高请求效率，减少整体瀑布流等待时间。

(3) 调整实践

参考上图，基于Taku后台，聚合管理页面数据调优，可以参考近期数据调整。

(4) 调优方向：

①将在Taku的排序价格调整为和eCPM API一致，或者打开自动价格（自动价格需要支持报表API并且数据量积累一定时间以后才能生效，自动价格相关参考文档），这一步的目的是数据对齐，方便后续调优瀑布流。

②评估单层广告源的收益占比和展示占比，如果展示占比和收益占比相差较大不相符，可以考虑限制该层广告源的展示频次、或者删除。
例如：有一层价格为5元的广告源展示占比为30%，收益占比为10%，此时可以考虑减少这一层的展示频次。或者增加5元以上的其他广告源的分层。这一步的目的是增加高价格的展示。

③评估单层广告源的填充率。
对于高级区的广告源，如果填充率较高，在10%-20%或以上，可以考虑再增加高于它的分层。
例如，价格为100的广告源填充率为5%，可以再适当增加130的广告源，这一步的目的是增加高价格的展示offer。
如果最高层或者高层区的展示率全部为1%或者低于1%，则可以考虑不用添加。转为评估整个瀑布流的填充率是否能达到90%以上，并相应调整，需要重点关注中部区及以上的瀑布流区域。

(5) 结合底价bidding进行优化

Taku 目前已支持的Bidding平台 >>点击查看

Taku 建议将Bidding和瀑布流结合使用并优化，最大程度提高变现效果。操作如下：

① 支持Bidding的平台，建议同时配置平台的竞价广告源和常规底价广告元，配合提高收益。

② 若支持Bidding设置底价，可在应用变现的稳定阶段尝试设置，设置Bidding底价之后，在每次竞价中：

如果竞胜的Bidding广告源价格高于Bidding底价，则会融入瀑布流中，进行广告请求。
如果竞胜的Bidding广告源价格低于Bidding底价，则不插入瀑布流参与进行广告请求。直到重新加载广告，拿到高于Bidding底价的广告。

3.3 流量分组优化

Taku支持多个维度对用户进行分组，不同的流量分组可以配置不同的Waterfall，以实现精细化流量变现的目的。目前Taku支持的流量分组维度具体如下：

地区，城市，日期，小时，时区，网络类型，应用版本，SDK版本，系统版本，设备ID，设备类型，设备品牌，安装时间，渠道，子渠道，和自定义规则>>点击查看

3.4 聚合管理高级设置（进阶设置）

Taku支持多项广告位维度和广告源维度的高级设置，包括串并行方式、展示上限、自动请求广告设置等。开发者可根据需要进行设置，提升瀑布流请求效率，进一步提高广告位维度和广告源维度的填充率和展示率，达到提高广告变现收益的目的。

优化瀑布流请求效率常用的高级设置介绍：

(1) 并行请求（更多并行请求介绍>>点击查看）

内容	说明
可选设置	•固定数量请求：广告源以排序价格为优先级顺序，每次对固定数量的广告源同时发起请求。最大可选并行数量为10。 •同价格并行请求（Taku SDK v5.9.20及以上）：广告源将以排序价格为优先级顺序，每次对排序价格相同的广告源同时发起请求。
实践案例	背景：同一瀑布流中包含2条价格为$9的广告源和3条价格为$7的广告源 •设定固定数量并为5时，Taku会同时请求全部5层广告源； •设定同价格并行请求时，Taku会先同时请求2条$9的广告源，在下一次同时请求3条$7的广告源。
应用场景	当广告场景展示比较频繁，即两次广告展示的间隔较短时，可以设置并行请求多条，从而进一步提高展示成功率。例如同时向A B请求，均返回成功，当A展示完后，可以立即展示B。并行请求可以提高加载效率，当广告分层较多时（如15层以上），可以考虑设置并行请求。

(2) 展示上限/间隔（更多展示限制介绍>>点击查看）

内容	说明
可选设置	聚合管理页面支持广告位维度和广告源维度2种展示频次控制功能。可填入1-1000。未勾选，则表示无限制。 •展示上限（小时）：单个用户在1小时内可以观看该广告位/广告源广告的最大次数； •展示上限（天）：单个用户在1天内可以观看该广告位/广告源广告的最大次数； •展示间隔（秒）：单个用户本次该广告位/广告源展示到下次该广告位请求之间的时间间隔。
应用场景	场景①：某些广告平台无法设置底价时，通过控制展示频次提升单用户展示质量，间接提升eCPM。场景②：若集成admob，在应用上线初期建议先设置一下展示频次上限，否则可能会因为个别极端设备导致广告平台账号封号。（路径：Taku开发者后台——聚合管理——广告源——编辑——更多设置——展示上限）

(3) 请求失败重试：广告位请求失败后，Taku会自动重试一次请求。打开请求失败重试后，流量请求、广告请求数会增加。（Taku SDK v5.9.40及以上版本支持）

(4) 自动请求广告：仅没有做预加载的开发者建议开启（更多自动请求介绍>>点击查看）

内容	说明
功能介绍	自动请求广告指在上一个广告show开始时自动请求下一条广告。注： ①自动请求广告功能已针对激励视频、插屏广告和开屏广告开放。 ②自动请求加载回来的广告不会返回AdLoaded回调，需要通过isready接口判断广告是否已经返回。
应用场景	场景①：用户停留时间较短的场景，避免因缓存不及时导致错失广告展示机会。场景②：在用户网络环境不佳时，能够改善广告请求和加载耗时长的问题。进而可以提高应用整体展示机会的利用率，缩短广告填充耗时，提升变现收益和用户体验。
自动请求广告逻辑	step1.启动游戏时就启动广告加载； step2.每一次广告播放完，接收到close的回调之后就执行加载（这里不需要判断isReady状态）； step3.每次判断广告的isReady状态是否为true，如果是false，就执行加载，true就不用执行了； step4.每一次产生广告消耗时，开始执行下一条广告加载。

数据排查及运营优化