一、使用说明

1、GroMore SDK版本要求

如果您要使用bidding能力，需要将GroMore SDK版本更新至2400及以上；为保障产品性能更稳定，建议更新至2910及以上。

如需使用Mintegral的bidding功能，需更新至3010以上版本。

使用Sigmob的bidding功能，需更新至3101以上版本（配合Sigmob Adapter版本 安卓≥3.4.1.4，iOS ≥3.5.0）。

自定义ADN的bidding功能，需更新至3210以上版本（白名单功能）。

2、Bidding支持的代码位样式有哪些？

注：各家广告网络广告类型对应关系，可点击查看，具体样式支持的MSDK版本可参考接入文档。

3、自定义adn支持的是哪种类型bidding？

支持的是客户端bidding。

4、banner轮播支持bidding

如您想使用banner广告的bidding功能，建议更新至3100版本以上，配合开启轮播功能使收益最大化。

banner轮播功能设置请参考【瀑布流属性设置】-【banner轮播】：链接

二、GroMore bidding操作指引

1、使用流程

Gromore目前支持竞价代码位与标准代码位在一个瀑布流中同时存在，因此只需在原有瀑布流上直接新增bidding代码位即可快速使用。

添加bidding代码位

- 点击【GroMore】-【聚合管理】，进入对应的【应用】及【广告位】，然后点击【新建代码位】；

注：使用bidding功能需优先在瀑布流中创建穿山甲bidding代码位。

- 选择支持bidding功能的【广告网络】，【竞价类型】选择“竞价”，非穿山甲代码位需如实填写【代码位ID】，穿山甲代码位则可在【代码位ID】中直接选择代码位，点击【保存】，完成操作；

- 若【代码位ID】下拉列表中，没有合适的穿山甲代码位，则点击【新建穿山甲代码位】，跳转到新建代码位页面，按照指引填写信息，其中，【是否用于Gromore】选择“是”，【竞价类型】选择“服务端竞价”。填好后点击【提交】，然后再回到之前的页面，添加刚创建好的代码位。

查看bidding代码位

添加好代码位后，回到【瀑布流管理】页面，查看广告位当前在启用中的代码位情况，包括【竞价】、【按价格】两种。其中，【竞价】即添加的bidding代码位。

2、效果验证

我们建议开发者直接使用bidding，但如果您想要先看到一定比例的收入提升，然后再决定是否要使用bidding，可通过A/B测试来进行验证。

如何使用A/B测试

建议用严格A/B测试，假设要测试广告网络Y的bidding代码位，则：

对照组：任意瀑布流；

实验组：原有瀑布流+广告网络Y的bidding代码位；

其中，对照组跟实验组中，原瀑布流中的代码位 顺序及价格保持完全一致。

     ① 操作流程

- 在【瀑布流管理】页面，点击右上方的【创建A/B测试】，然后按照提示填写信息。其中，【流量分配比例】建议50%：50%；为提升操作效率，选择【复制A组瀑布流配置至B组】，点击【保存】；

- 切换至【B实验组】，点击【新建代码位】，按提示添加需要测试的竞价代码位；

- - 添加完竞价代码位后，点击【开启AB测试】。

附：A/B测试功能官网介绍

    ② 注意事项

- 选择进行A/B测试的应用，尽量不要选择刚刚发布的应用，而是选择有充足数据 且 各项指标表现稳定的现有应用；

- 建议实验周期≥7天，累计活跃用户数单组＞8万（即实验周期内，对照组累计活跃用户数＞8万，实验组累计活跃用户数＞8万），以便获得稳定置信的效果数据。

# 注：GroMore平台的活跃用户数，指有广告请求的活跃用户数，可能与媒体自己统计的活跃用户数有出入。

需关注的核心指标

    ①判断指标

衡量实验的效果，应该看填充率、ARPU、IPU、填充耗时；此外，由于使用bidding可以帮助释放运营人力，运营效率的提升是衡量bidding效果的另外一个重要指标。

您可能会发现，使用穿山甲bidding后，实验组的eCPM有所下降。这通常是因为，受瀑布流排序及底价的影响，之前发生展示的可能都是高价值流量；而使用bidding后，由于bidding无底价且会实时自动出价，不管用户价值高低，我们都会为您找到合适的广告去做展示。

因此，尽管eCPM可能会下降，但整体的填充率、IPU（平均每个活跃用户观看广告的次数）、ARPU（平均每个活跃用户产生的广告收入）将上升，填充耗时将下降，建议综合多个指标评估效果。

   ②数据查看路径

可点击【查看A/B测试数据】查看：

三、数据指标分析指南

1、效果指标

Bidding对比传统的瀑布流方式，每次请求仅返回一次结果，填充效率更高、多bidder环境下每次请求的结果也会更优。因此，在数据表现上也会表现出与传统瀑布流差异的地方。主要有以下几点：

1. 代码位填充率：Bidding代码位填充率一般在80%以上，主要因其填充效率更高，填充价格区间也会更广；
2. 填充耗时：Bidding代码位的填充耗时一般在2s内，主要是因为Bidding只需要一次请求，在没有网络问题的情况下一般返回时长都较短；
3. 竞胜率：=GroMore聚合收到填充后，比价胜出的占比，代表的是bidding的竞争能力。竞胜率越高说明bidding在该广告位上竞争能力越强。
4. ECPM：Bidding的价格是实时请求模型计算的最优价格，区间范围没有控制，高低均有可能。但由于Bidding填充效率更高，传统瀑布流因为低价格区间等待时长较长没有填上的部分更容易被Bidding填上，因此在最终数据呈现上可能会表现的在低区间填充更多，所以Bidding代码位的ECPM可能看起来偏低（相对瀑布流来说），但对开发者的整体收益则是正向的。

【展示ECPM vs 询价ECPM】需要注意的是后台显示的ECPM为，展示ECPM，即最终实际展示的填充算出来的ECPM。Bidding请求时获得的价格为询价ECPM，询价ECPM如果在竞胜中失败则不会披露。

5. ARPU：ARPU的表现和填充率相关，在DAU不变的情况下，填充率更高自然也会带动ARPU提升，历史测试中在瀑布流上增配Bidding代码位，广告位整体ARPU可提升3%-20%。

2、竞价链路指标

点击下图所示“竞价链路”，可查看服务端竞价代码位询价、物料请求、竞胜等核心链路数据。以下将说明各指标含义、预期表现（可结合流程图进行理解）。

服务端竞价代码位竞价链路流程图

四、常见问题

1、是否支持展示时返回bidding价格？

支持，为满足买量变现开发者测算ROI的需求，bidding目前已支持在bidding获胜时返回真实价格，调用时机需要在展示（show）之后，过早调用可能会导致没有值返回。

您可以直接调用接口获取相关内容，技术对接文档搜索platform可以看到相关字段“getShowEcpm”

安卓：

iOS：

2、在同一个瀑布流中，能否同时使用竞价和标准代码位？

所有广告网络均支持竞价与标准代码位共存。

3、为什么Bidding代码位的填充率很高，但展示率看起来会偏低？

GroMore后台展示率的公式为 展示率=展示量/填充量。

当Bidding填充后，还会与普通代码位进行比价，如果是多bidding的环境还会与各家bidding进行比价，价高者才会胜出展示。因为Bidding的填充率较高，因此展示率的分母填充量相对较大，但分子展示量只有获胜者才会展示，所以展示率看起来会偏低。也可以参考竞胜率验证。

4、使用穿山甲GroMore bidding后，广告收入能提升多少？

根据目前测试的case来看，使用穿山甲GroMore bidding后，收入能提升，提升的幅度在2.5%-19%不等。具体能提升多少，需要看每家开发者原来瀑布流模式的精细化运营程度。

5、使用穿山甲GroMore bidding后，人均展示次数变高了，会不会影响用户体验？

不会。

使用GroMore bidding后，人均展示次数会提高的原因包括：①减少了因超时导致无法填充的问题，广告加载速度更快，降低了用户等待时长；②由于bidding无底价且会实时自动出价，不管用户价值高低，我们都会为您找到合适的广告去做展示。

因此，人均展示次数变高，一方面提升了广告总收益，有利于开发者；另一方面也降低了用户等待时长，有利于用户体验。如果需要控制人均展示次数，可以使用GroMore的【展示上限】功能，控制某广告位对单一用户的展示时间间隔/单位时间内的展示次数。产品能力介绍详见：链接

6、Bidding代码位和普通代码位、兜底代码位是如何比价的？

GroMore里的bidding代码位会和普通代码位同时请求，只有当bidding代码位价高于普通代码位时才会胜出并填充。而我们设置的兜底代码位是无底价代码位，如果bidding代码位返回了广告，则默认bidding胜出，兜底代码位不会再请求；仅有当bidding没有填充时，兜底代码位才会请求。

7、添加Bidding代码位后，瀑布流整体的ECPM为什么看起来比原来低？

由于Bidding填充效率较高，增加Bidding代码位之后传统瀑布流低价格区间因为等待时长较长没有填上的部分更容易被填上，因此有可能整体瀑布流的ECPM看起来会比配置Bidding前低。

这个时候建议观察整体瀑布流的收益和ARPU，而非单代码位的ECPM，填充率提升之后整体收益预期是正向提升的。