如果您要使用bidding能力,需要将GroMore SDK版本更新至2400及以上;为保障产品性能更稳定,建议更新至2910及以上。
如需使用Mintegral的bidding功能,需更新至3010以上版本。
使用Sigmob的bidding功能,需更新至3101以上版本(配合Sigmob Adapter版本 安卓≥3.4.1.4,iOS ≥3.5.0)。
自定义ADN的bidding功能,需更新至3210以上版本(白名单功能)。
注:各家广告网络广告类型对应关系,可点击查看,具体样式支持的MSDK版本可参考接入文档。
广告网络 | 开屏 | 插全屏 | 激励视频 | 信息流 | banner | draw信息流 | 插屏 | 全屏 |
穿山甲 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Mintegral | ✅ | ✅ | ✅ | ✅ | ||||
Sigmob | ✅ | ✅ | ✅ | ✅ | ✅ | |||
自定义ADN | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
支持的是客户端bidding。
如您想使用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测试数据】查看:
Bidding对比传统的瀑布流方式,每次请求仅返回一次结果,填充效率更高、多bidder环境下每次请求的结果也会更优。因此,在数据表现上也会表现出与传统瀑布流差异的地方。主要有以下几点:
【展示ECPM vs 询价ECPM】需要注意的是后台显示的ECPM为,展示ECPM,即最终实际展示的填充算出来的ECPM。Bidding请求时获得的价格为询价ECPM,询价ECPM如果在竞胜中失败则不会披露。
点击下图所示“竞价链路”,可查看服务端竞价代码位询价、物料请求、竞胜等核心链路数据。以下将说明各指标含义、预期表现(可结合流程图进行理解)。
指标 | 含义 | 指标解读/预期表现 |
询价 | GroMore聚合向ADN发出获取服务端竞价代码位价格的请求。 | 接近流量请求量,如少15%建议进行排查。 |
询价响应 | ADN收到GroMore聚合请求,并向GroMore返回服务端竞价代码位价格。 | - |
询价响应率 | ADN向GroMore返回服务端竞价价格的次数 / GroMore聚合向ADN发出获取服务端竞价代码位价格请求的次数。 | 一般在80%以上,如少于60%建议通过错误码诊断、人工排查。 |
竞胜次数 | GroMore中,该代码位比价胜出其他代码位的次数。 | - |
竞胜率 | GroMore聚合收到填充后,比价胜出的占比,代表的是竞价代码位的竞争能力。 | 竞胜率越高说明竞价代码位在该广告位上竞争能力越强 |
物料请求 | GroMore向ADN发起服务端竞价广告物料加载的请求。 | - |
物料填充 | ADN向GroMore返回服务端竞价代码位广告物料。 | - |
物料填充率 | ADN向GroMore返回服务端竞价代码位广告物料的次数 / GroMore向ADN发起服务端竞价代码位广告物料加载请求的次数。 | 一般近满填,除网络问题等原因导致物料加载失败 |
服务端竞价代码位竞价链路流程图
支持,为满足买量变现开发者测算ROI的需求,bidding目前已支持在bidding获胜时返回真实价格,调用时机需要在展示(show)之后,过早调用可能会导致没有值返回。
您可以直接调用接口获取相关内容,技术对接文档搜索platform可以看到相关字段“getShowEcpm”
安卓:
iOS:
所有广告网络均支持竞价与标准代码位共存。
GroMore后台展示率的公式为 展示率=展示量/填充量。
当Bidding填充后,还会与普通代码位进行比价,如果是多bidding的环境还会与各家bidding进行比价,价高者才会胜出展示。因为Bidding的填充率较高,因此展示率的分母填充量相对较大,但分子展示量只有获胜者才会展示,所以展示率看起来会偏低。也可以参考竞胜率验证。
根据目前测试的case来看,使用穿山甲GroMore bidding后,收入能提升,提升的幅度在2.5%-19%不等。具体能提升多少,需要看每家开发者原来瀑布流模式的精细化运营程度。
不会。
使用GroMore bidding后,人均展示次数会提高的原因包括:①减少了因超时导致无法填充的问题,广告加载速度更快,降低了用户等待时长;②由于bidding无底价且会实时自动出价,不管用户价值高低,我们都会为您找到合适的广告去做展示。
因此,人均展示次数变高,一方面提升了广告总收益,有利于开发者;另一方面也降低了用户等待时长,有利于用户体验。如果需要控制人均展示次数,可以使用GroMore的【展示上限】功能,控制某广告位对单一用户的展示时间间隔/单位时间内的展示次数。产品能力介绍详见:链接
GroMore里的bidding代码位会和普通代码位同时请求,只有当bidding代码位价高于普通代码位时才会胜出并填充。而我们设置的兜底代码位是无底价代码位,如果bidding代码位返回了广告,则默认bidding胜出,兜底代码位不会再请求;仅有当bidding没有填充时,兜底代码位才会请求。
由于Bidding填充效率较高,增加Bidding代码位之后传统瀑布流低价格区间因为等待时长较长没有填上的部分更容易被填上,因此有可能整体瀑布流的ECPM看起来会比配置Bidding前低。
这个时候建议观察整体瀑布流的收益和ARPU,而非单代码位的ECPM,填充率提升之后整体收益预期是正向提升的。
在线客服智能客服 7*24小时在线人工客服 工作日 10~12点/14~19点