GroMore的bidding功能现已全量开放，使用前建议将GroMore SDK版本升级至2400以上，如希望体验更佳建议升级至2910以上。如需使用Mintegral的bidding功能，需更新至3010以上版本；使用Sigmob的bidding功能，需更新至3101以上版本。
安卓和iOS 双端均已支持。
如果您要使用bidding能力，需要将GroMore SDK版本更新至2400及以上；
为保障产品性能更稳定，建议更新至2910及以上。
如需使用Mintegral的bidding功能，需更新至3010以上版本。
使用Sigmob的bidding功能，需更新至3101以上版本（配合Sigmob Adapter版本 安卓≥3.4.1.4，iOS ≥3.5.0.0）。
如您想使用banner广告的bidding功能，建议更新至3100版本以上，配合开启轮播功能使收益最大化。
banner轮播功能设置请参考【瀑布流属性设置】-【banner轮播】：链接
Gromore目前支持竞价代码位与标准代码位在一个瀑布流中同时存在，因此只需在原有瀑布流上直接新增bidding代码位即可快速使用。
- 点击【GroMore】-【聚合管理】，进入对应的【应用】及【广告位】，然后点击【新建代码位】；
注：使用bidding功能需优先在瀑布流中创建穿山甲bidding代码位。
- 选择支持bidding功能的【广告网络】，【竞价类型】选择“竞价”，非穿山甲代码位需如实填写【代码位ID】，穿山甲代码位则可在【代码位ID】中直接选择代码位，点击【保存】，完成操作；
- 若【代码位ID】下拉列表中，没有合适的穿山甲代码位，则点击【新建穿山甲代码位】，跳转到新建代码位页面，按照指引填写信息，其中，【是否用于Gromore】选择“是”，【竞价类型】选择“服务端竞价”。填好后点击【提交】，然后再回到之前的页面，添加刚创建好的代码位。
添加好代码位后，回到【瀑布流管理】页面，查看广告位当前在启用中的代码位情况，包括【竞价】、【按价格】两种。其中，【竞价】即添加的bidding代码位。
我们建议开发者直接使用bidding，但如果您想要先看到一定比例的收入提升，然后再决定是否要使用bidding，可通过A/B测试来进行验证。
建议用严格A/B测试，假设要测试广告网络Y的bidding代码位，则：
对照组：任意瀑布流；
实验组：原有瀑布流+广告网络Y的bidding代码位；
其中，对照组跟实验组中，原瀑布流中的代码位 顺序及价格保持完全一致。
- 在【瀑布流管理】页面，点击右上方的【创建A/B测试】，然后按照提示填写信息。其中，【流量分配比例】建议50%：50%；为提升操作效率，选择【复制A组瀑布流配置至B组】，点击【保存】；
- 切换至【B实验组】，点击【新建代码位】，按提示添加需要测试的竞价代码位；
- - 添加完竞价代码位后，点击【开启AB测试】。
- 选择进行A/B测试的应用，尽量不要选择刚刚发布的应用，而是选择有充足数据 且 各项指标表现稳定的现有应用；
- 建议实验周期≥7天，累计活跃用户数单组＞8万（即实验周期内，对照组累计活跃用户数＞8万，实验组累计活跃用户数＞8万），以便获得稳定置信的效果数据。
# 注：GroMore平台的活跃用户数，指有广告请求的活跃用户数，可能与媒体自己统计的活跃用户数有出入。
衡量实验的效果，应该看填充率、ARPU、IPU、填充耗时；此外，由于使用bidding可以帮助释放运营人力，运营效率的提升是衡量bidding效果的另外一个重要指标。
您可能会发现，使用穿山甲bidding后，实验组的eCPM有所下降。这通常是因为，受瀑布流排序及底价的影响，之前发生展示的可能都是高价值流量；而使用bidding后，由于bidding无底价且会实时自动出价，不管用户价值高低，我们都会为您找到合适的广告去做展示。
因此，尽管eCPM可能会下降，但整体的填充率、IPU（平均每个活跃用户观看广告的次数）、ARPU（平均每个活跃用户产生的广告收入）将上升，填充耗时将下降，建议综合多个指标评估效果。
可点击【查看A/B测试数据】查看：
广告变现采用瀑布流模式，瀑布流配置粗放，人力有限，无法始终实时调控，无法实现最佳收益。
开发者的目标是希望在不增加运营人力成本的情况下，尽可能提升收入。
- 使用GroMore bidding
在广告位中直接使用穿山甲的bidding代码位，去掉穿山甲的标准瀑布流代码位；
- 进行实验验证
由于刚开始使用GroMore bidding，不明确bidding的收益，使用了GroMore平台的A/B测试功能，设置严格的对照组跟实验组，分流比例设置为50%：50%，进行效果对比。设置如下：
实验13天，获得了稳定置信的数据表现：
消耗及ARPU（平均每个活跃用户产生的广告收入）+19%，eCPM+14%；
媒体认可bidding能力，目前正在将更多的量切到bidding上。
- 广告变现采用瀑布流模式，瀑布流安排专人调优，人力成本高；
- 即使精细化调整，也无法每次展示都达到最佳收益；
- 二三十层的瀑布流经常带来超时问题，影响填充率，也影响用户体验。
开发者的目标是希望既能降低运营人力成本，又能提升收入。
- 使用GroMore bidding
在广告位中直接使用穿山甲的bidding代码位，去掉穿山甲的标准瀑布流代码位；
- 进行实验验证
由于刚开始使用GroMore bidding，不明确bidding的收益，使用了GroMore平台的A/B测试功能，设置严格的对照组跟实验组，分流比例设置为50%：50%，进行效果对比。设置如下：
- 提收入：广告收入及ARPU（平均每个活跃用户产生的广告收入）+15%，流量填充率+11%，IPU（平均每个活跃用户观看广告的次数） +5%，广告填充耗时-81%；
- 提效率：帮助媒体极大地释放了瀑布流的运营人力，获得了媒体的认可。
支持，为满足买量变现开发者测算ROI的需求，bidding目前已支持在bidding获胜时返回真实价格，调用时机需要在展示（show）之后，过早调用可能会导致没有值返回。
您可以直接调用接口获取相关内容，技术对接文档搜索platform可以看到相关字段“getShowEcpm”
安卓：
iOS：
# GroMore SDK3100及以上版本支持插全屏及 banner#
穿山甲：开屏、全屏、插屏、激励视频、信息流、banner、插全屏；
Mintegral：开屏、全屏、激励视频、横幅广告、信息流（自定义渲染、自动渲染）；
Sigmob：激励视频、全屏视频、插全屏。
目前支持的有穿山甲、Mintegral、Sigmob的bidding，MSDK 3010以上版本支持Mintegral bidding；MSDK 3101以上版本支持Sigmob bidding。
所有广告网络均支持竞价与标准代码位共存。
点击代码位【编辑】按钮，切换【竞价类型】，然后再选择要替换的竞价/标准代码位即可。
# 注：有多个穿山甲标准代码位时，需点击【⋮】删除标准代码位至只剩一个，再点击【编辑】从“标准”切换到“竞价”。
根据目前测试的case来看，使用穿山甲GroMore bidding后，收入能提升，提升的幅度在2.5%-19%不等。具体能提升多少，需要看每家开发者原来瀑布流模式的精细化运营程度。
不会。
使用GroMore bidding后，人均展示次数会提高的原因包括：①减少了因超时导致无法填充的问题，广告加载速度更快，降低了用户等待时长；②由于bidding无底价且会实时自动出价，不管用户价值高低，我们都会为您找到合适的广告去做展示。
因此，人均展示次数变高，一方面提升了广告总收益，有利于开发者；另一方面也降低了用户等待时长，有利于用户体验。
如果需要控制人均展示次数，可以使用GroMore的【展示上限】功能，控制某广告位对单一用户的展示时间间隔/单位时间内的展示次数。产品能力介绍详见：链接
GroMore里的bidding代码位会和普通代码位同时请求，只有当bidding代码位价高于普通代码位时才会胜出并填充。而我们设置的兜底代码位是无底价代码位，如果bidding代码位返回了广告，则默认bidding胜出，兜底代码位不会再请求；仅有当bidding没有填充时，兜底代码位才会请求。
联系我们
在线客服智能客服 7*24小时在线人工客服 工作日 10~12点/14~19点
