Skip to main content

中介管理

中介管理是用来配置广告瀑布流、广告策略调优,可以设置中介分组、配置广告源、调整广告源优先级、设置开启A/B测试等。


1. 功能介绍#

中介组支持对不同用户群体配置不同的广告源,开发者可根据自身的流量,精细化变现。目前TradPlus支持多种流量规则,如国家/地区、应用版本、SDK版本等。

从 Android V5.4.0 和 iOS V5.1.0 开始, TradPlus 支持多种分组规则。


2. 使用指南#

2.1 使用说明#

  • 中介组的瀑布流分为手动排序、按价格排序、低优先级三个模块。

  • 三个模块之间的优先级是:手动排序模块高于按价格排序模块,按价格排序模块高于低优先级模块。

  • 即,手动排序模块里排序最低的广告源,展示优先级要高于按价格排序模块中的所有广告源。


2.2 配置中介组#

2.2.1 添加、配置中介组#

1)在 TradPlus 后台中介管理中,选择需要添加中介组的应用、广告位,点击【添加中介组】


2)填写中介组配置信息

中介组配置项配置项说明
中介组名称输入自定义的中介组名称。
国家选择中介组生效的国家。如无需区分国家,可不选择此项。
新增规则或复制已有规则选择中介组生效的规则。如无需配置规则,可不选择此项。
SDK 请求广告超时时长默认 60 秒,建议前期保持默认设置。
SDK 竞价超时时长默认 5 秒,建议前期保持默认设置。
并行请求数初始默认值 为3。
Bidding 广告源保留数● Bidding 保留数是指 Bidding 广告源竞价成功后,按价格从高到低,保留的个数。
● 默认保留 2 个,建议前期保持默认设置。
Bidding 底价● Bidding 底价即 Bidding 广告源每千次展示最低出价。
● 前期建议不配置 Bidding 底价,后续根据实际数据情况进行配置。
使用的广告源勾选需要使用的广告源。

3)中介组排序

建议按照如下规则对中介组进行排序:

  • 已添加并开启的 Bidding 广告源将自动显示在【Header Bidding】区域;

  • 已添加并开启的其余广告源,在开启“自动价格”后,将自动显示在【按价格排序】区域。TradPlus 将根据排序价格按从高到低顺序进行排序。


2.2.2 添加广告源#

您可以在【中介管理】中,为中介组添加广告源:

1)在中介管理页面,点击【添加广告源】


2)填写广告源信息,信息填写说明请参见文档:TradPlus 已聚合广告平台列表 - 配置指南

如需添加 Bidding 广告源,需要在添加广告源时选择打开 Header Bidding 模式。


2.2.3 配置广告源#

1)将鼠标悬停在需要配置的广告源上,点击更多。


2)配置频次,建议不配置展示频次。

频次控制的作用:开发者可灵活控制每个广告源的展示频次,进行广告展示量的分配。要注意:

  • 支持对所有类型的广告源配置展示频次,包括bidding广告源, 普通广告源,交叉推广等。
  • 对某广告源设置频次后,只对该中介组进行生效,不影响其他中介组下该广告源的频次设置。
  • 如果同时在广告位和广告源维度设置频次,其生效规则如下:
  • 先判断广告位维度是否已经达到频次上限,如未达到频次上限,则继续判断广告源维度是否已经达到频次上限;
  • 如广告位维度已经达到频次上限,则不再判断广告源维度的频次情况。

配置项配置项说明
展示上限(每小时)单个用户每小时的展示上限,可输入 1~1000 的整数。
展示上限(每天)单个用户每天的展示上限,可输入 1~1000 的整数。
展示间隔(分钟)单个用户展示间隔时长,可输入 1~1000 的整数。

3)关闭 / 开启自动价格,建议开启自动价格,开启后:

  • TradPlus 将优先使用该广告源过去 3 天的平均 eCPM,用于排序。

  • 如过去 3 天总展示数少于 200,则使用过去 7 天的平均 eCPM。

  • 如过去 7 天总展示数少于 200,则使用人工录入的排序价格。

平均 eCPM 计算公式:汇总收入 / 汇总展示数 * 1000


4)配置超时时长,默认为60秒,建议前期保持默认配置。


5)移至已关闭区,可将广告源关闭,系统自动将该广告源移动至已关闭区域。


2.2.4 中介组高级设置#

1)在【中介管理】页面,点击右上角【高级设置】,进入中介组高级设置页面


2)可选择开启/关闭显示手动排序区:


3)可对单个中介组的参数进行调整,参数说明见下表:

参数说明
并行请求数并行请求数为1表示串行请求,若条数为n(n>1),TradPlus同时向前n个广告源发起请求。如果未填充,会继续向后续广告源发起请求,直到填充n条广告或瀑布流请求结束为止。
Bidding底价Bidding底价仅对支持Bidding的广告平台和TradPlus Exchange生效。当某个Bidding广告源出价低于Bidding底价时,TradPlus将自动过滤此出价结果。设置bidding底价会降低Bidding广告源的填充和收益,请谨慎设置。底价最小值为0.01。
Bidding广告源保留数如配置保留数为n,当竞价结束后,最多只会保留n个价格最高的Bidding广告源的出价结果,其他会自动过滤掉。设置Bidding广告源保留数会降低Bidding广告源的填充和收益,请谨慎设置。
服务端竞价超时时长TradPlus SDK 向TradPlus服务器发起竞价请求到收到响应的最长等待时长。
广告源请求广告超时时长TradPlus SDK向三方广告SDK发起一次请求后的最长等待时长
广告填充回调模式从TradPlus Android SDK v8.0 和iOS SDK v7.7开始支持。

TradPlus支持2种填充回调模式,不同模式下TradPlus通知应用“广告已填充”的时机会不同。应用可根据自身场景选择使用:
1.速度优先:应用需要频繁展示广告,用户不会等待广告。
2.eCPM优先:应用不需要频繁展示广告,用户可以等待广告。

如不确定哪种模式最优,可通过A/B测试对比验证。

4)当有多个中介组需要调整,且每个中介组的需要配置的参数相同时,可通过批量操作功能提高配置效率:勾选全部中介组,点击【批量操作】,选择需要调整的参数即可。


2.3 配置流量分组#

2.3.1 功能介绍#

流量分组是指开发者根据一定的规则对用户群体进行分组,包括用户属性、用户行为、地理位置等,同时支持开发者自定义属性和规则。开发者可对不同分组配置不同的瀑布流,实现精细化运营。


2.3.2 使用指南#

i. 使用说明#
  • TradPlus 上报数据

以下数据由 TradPlus SDK 上报,开发者不需要处理。

类别参数类型条件规则数量描述
app应用版本version包括、不包括1安卓填写version name,ios填写version。包括和不包括时,可填多个版本号,用英文逗号分隔。
app应用安装时间int范围、>、<1从第一次初始化TradPlus SDK开始算起。
appSDK版本version包括、不包括 、范围、>、<1TradPlus SDK版本,包括和不包括时,可填多个版本号,用英文逗号分隔。>和<时,只能填写一个。
deviceIDFAstring包括1针对iOS14无法获取时,我们可以通过用户是否授权IDFA来创建一个流量分组归类这些设备。(仅 iOS 产品有该指标)
device设备 IDstring包括1web端可填多个设备ID ,用英文逗号分隔,设备ID可以是 IDFA, IDFV, GAID, OAID。
device系统版本version包括、不包括 、>、<1手机系统版本,包括和不包括时,可填多个系统版本号,用英文逗号分隔。>和<时,只能填写一个。
device设备类型string(ignoreCase)包括、不包括1可选择iPhone或iPad,可多选。
device设备制造商string(ignoreCase)包括、不包括1举例Huawei ,可多选。
device网络连接类型string包括1web端可多选,可取值为:WiFi, 2G, 3G, 4G, 5G。

  • 应用上报数据

以下数据由开发者根据需要,通过sdk接口上报。如果不上报,如下规则将无法在中介组中使用。

参数Key类型条件规则数量描述
自定义用户IDuser_idstring包括1Web端可输入多个ID,英文逗号分隔。另外,TradPlus 可基于此user id提供设备层级的变现数据(API)。
年龄user_ageint范围 、>、<, =多个输入数字(0-99), 单位 岁。
性别user_genderstring=1web端只能单选,可取值为:male、female;sdk端可传值:unknown、male、female。
游戏中等级user_levelint范围 、>、<, =1
应用内付费金额user_iap_amountfloat范围 、>、<, =1
应用内付费币种user_iap_currencystring=1目前支持USD, CNY, EUR。 单选
应用内付费次数user_iap_countint>、<, =1
渠道channelstring包括、不包括1Web端支持填入多个渠道号,用英文逗号分隔,渠道号需要开发者在SDK中传入。
子渠道sub_channelstring包括、不包括1Web端支持填入多个子渠道号,用英文逗号分隔,子渠道号需要开发者在SDK中传入。
自定义用户属性custom_xxxstring/int整数:范围,>、<, = ;字符串:包括,不包括最多5个应用通过Key-Value形式(key以’custom_’+字段名),传入自定义用户属性,如custom_username。最多支持5个。
segment tagsegment_tagstring包括1如SDK上报segment_tag,会使用指定segment的waterfall配置。此参数匹配时,会无视其他参数。最多支持1个。

ii. 使用方法#
  • 设置方法

需要在初始化SDK之后,初始化广告位ID之前调用接口。

如需使用流量分组功能,则开发者技术侧务必进行此步骤。


  • APP全局自定义规则设置
平台方法
AndroidSegmentUtils.initCustomMap(customMap);
iOS[TradPlus sharedInstance].dicCustomValue = dicXXX
UnityTradPlus.initCustomMap(map);

  • Placement 自定义规则设置
平台方法
AndroidSegmentUtils.initPlacementCustomMap("placementId", customMap);
iOS_rewardedVideoAd.dicCustomValue = dicXXX
UnityTradPlus.initPlacementCustomMap("placementId", map);

● 示例

  • Android SDK代码示例
HashMap&lt;String, String&gt; customMap = new HashMap&lt;&gt;();
customMap.put(&quot;user_gender&quot;, &quot;male&quot;);//男性
customMap.put(&quot;user_level&quot;, &quot;10&quot;);//游戏等级10
SegmentUtils.initCustomMap(customMap);//设置APP维度的规则,对全部placement有效
SegmentUtils.initPlacementCustomMap(&quot;placementId&quot;, customMap);//仅对该广告位有效,会覆盖APP维度设置的规则
  • iOS SDK代码示例
//应用纬度的自定义信息
[TradPlus sharedInstance].dicCustomValue = @{@&quot;user_id&quot;:@&quot;test user id&quot;};
//广告位纬度的自定义信息,以激励视频为例
self.rewardedVideoAd = [[MsRewardedVideoAd alloc] init];
self.rewardedVideoAd.segmentTag = @&quot;test segmentTag&quot;;
self.rewardedVideoAd.dicCustomValue = @{@&quot;user_id&quot;:@&quot;test user id2&quot;};
[self.rewardedVideoAd setAdUnitID:_placementId isAutoLoad:YES];
...
  • Unity SDK代码示例
Dictionary&lt;string, string&gt; map = new Dictionary&lt;string, string&gt;();
map.Add(&quot;user_age&quot;, &quot;18&quot;);//年龄18岁
map.Add(&quot;user_gender&quot;, &quot;male&quot;);//男性
map.Add(&quot;user_level&quot;, &quot;10&quot;);//游戏等级10
TradPlus.initCustomMap(map);//设置APP维度的规则,对全部placement有效
TradPlus.initPlacementCustomMap(&quot;placementId&quot;, map);//仅对该广告位有效,会覆盖APP维度设置的规则

  • 后台配置

1)新建中介组


2)设置流量规则


3)调整优先级

当一个用户满足多个流量组规则时,可以通过拖拽的方式设置流量组优先,决定优先匹配哪个广告策略。


2.4 中介组数据报表#

2.4.1 数据指标#

中介组数据报表可查看每个广告源的广告数据,具体指标如下:

指标含义
竞价请求APITradPlus通过广告平台的报表API拉取到的竞价请求数。
竞价响应APITradPlus通过广告平台的报表API拉取到的竞价响应数。
竞价响应率API竞价响应数API / 竞价请求数API。
竞价胜出率API广告请求数API / 竞价响应数API。
请求APITradPlus通过广告平台的报表API拉取到的请求数。
填充APITradPlus通过广告平台的报表API拉取到的填充数。
填充率API填充API / 请求API 。
展示APITradPlus通过广告平台的报表API拉取到的展示数。
展示率API展示数API / 填充数API。
点击APITradPlus通过广告平台报表API拉取到的点击数。注意:部分广告平台API不返回点击数。
点击率API点击数API / 展示数API。
填充时长从发起请求到成功填充广告的平均时长。
请求时长每次请求广告的平均时长,会统计填充、未填充、超时等所有情况的请求数据。
eCPM API千次展示带来的广告收入。
eCPC API平均每次点击获得的广告变现收入。
收入 APITradPlus通过广告平台报表API拉取到的估算收入。
请求占比该广告源请求数 / 合计请求数 * 100%
填充占比该广告源填充数 / 合计填充数 * 100%
展示占比该广告源展示数 / 合计展示数 * 100%
收入占比该广告源收入 / 合计收入 * 100%

2.4.2 操作指南#

1)中介组数据报表提供三方数据和Tradplus

  • 可点击右上角【三方API】、【Tradplus】进行切换。


2)点击右上角图标按钮,选择【自定义指标】,勾选需要查看的数据维度。


3)导出报表

点击右上角图标按钮,选择【导出】,可导出报表。


2.5 设置 A/B 测试#

可通过中介组页面跳转至A/B测试功能,关于A/B测试详细使用指南请见:高级功能 - A/B测试


3. 常见问题#

Q:为什么部分数据有下划线?#

A:部分三方平台不分享广告请求、填充等数据,TradPlus后台使用自己的埋点数据来补足该部分数据,并用下划线来区分。


Q:在中介组中新建了瀑布流或修改了配置后,多久会生效?#

A:后台完成配置后2分钟即可生效,在手机上本地拉到配置需要2分钟到1个小时不等。如需立即生效,可在手机上将APP清除缓存或卸载重装。


Q:在中介组给某些设备建了一个中介组,为什么该中介组没有生效?#

A:

  • 如果是国内安卓手机,在规则处填写OAID,中介组不会生效,这是由于TradPlus SDK不主动获取国内手机的OAID信息导致的。有以下三种解决方法:

    • 使用GAID来测试,确保测试手机有安装谷歌服务框架Google setting,在谷歌广告设置里可查看广告ID(GAID)

    • 使用OAID,确保应用在初始化TradPlus SDK之前调TradPlusSdk.setAuthUID(Context, true)

    • 使用海外手机

  • 如果是ios手机,中介组配置了设备的IDFA,需要该手机授权此应用的IDFA权限,中介组才会生效

在应用启动后,会弹出IDFA权限申请,这个弹框只会出现一次,后续如果要变更IDFA权限,需要在手机的系统设置【隐私】-【跟踪】里调整。


Q:在中介组中采用“年龄”、“等级”等分组,如果应用不把年龄、等级等用户信息传给TradPlus,TradPlus能获取到用户信息吗?#

A:不能。聚合SDK不会违规获取用户信息。因此要注意,如果开发者希望在中介组对年龄、用户等级等维度做瀑布流优化,需要先把相关信息传给TradPlus。


Q:TradPlus 如何判断用户来自哪个国家?#

A:用户从客户端发起广告请求的时候,TradPlus 会根据用户的IP信息来判断。


Q:中介组 Bidding 是采用服务端 Bidding 还是客户端 Bidding,是否需要开发者做技术联调?#

A:部分广告平台采用服务端 Bidding,部分广告平台采用客户端 Bidding,详细信息可见:TradPlus 已聚合广告平台列表

不需要开发者做技术联调,应用端只需要集成对应版本的 TP SDK,然后填写 Bidding 广告位即可。


Q:什么是SDK请求广告超时时长?#

A:TradPlus SDK 按照中介管理瀑布流配置进行请求,在请求某个广告源时,如果达到默认超时时长后三方还未响应,TradPlus SDK 将自动请求下一个广告源。


Q:各个广告类型默认的SDK请求广告超时时长是多少?#

A:

  • 激励视频和插屏:60秒

  • 横幅和原生:10秒

  • 开屏:10秒


Q:什么是竞价超时时长?#

A:TradPlus SDK 同时向已配置的三方bidding广告平台发起竞价请求,若某个三方平台在5s内不响应,则TradPlus SDK不再等待,继续向其他有响应的广告平台发起广告请求。


Q:各个广告类型默认的竞价超时时长是多少?#

A:所有广告类型的竞价超时时长均默认为5s。


Q:Bidding+ 传统瀑布流的广告请求逻辑是什么?#

A:

  • 用户打开应用,应用初始化 TradPlus SDK;

  • TradPlus SDK 向三方平台发送竞价请求,三方广告平台返回eCPM信息;

  • TradPlus SDK 根据竞价的eCPM高低,将竞价 ID merge 到瀑布流里,结合生成新的瀑布流;

  • TradPlus SDK 根据新的瀑布流策略进行广告请求和展示。


Q:中介组中,为什么会出现低层比高层广告源的请求数还多的情况?#

广告源的请求数除了跟排序位置有关,也受到填充率和广告过期时间的影响。并非排序位置越靠前,请求数就一定越多。

1. 填充率的影响

填充率越小的广告源,获得请求的可能性也越大。

比如一个中介组的waterfall共配置4个广告源,缓存数为3,共请求2轮waterfall:

  • 请求第一轮waterfall后,并行请求到3条广告:as1,as2,as4

  • 然后as1被展示,触发第二轮waterfall请求,因as2已有缓存,在第二轮中不会被请求

  • 两轮加载后,ad3的累计请求数多于as2

可以看到,对两个相邻广告源(as2和as3),如果较低层广告源(as3)的填充率较小,就可能会出现低层广告源(as3)的请求数多于较高层广告源(as2)的情况。


2. 广告过期时间的影响

各广告平台的广告过期时间不同,也会影响广告请求次数。

仍以上面的waterfall配置为例:

  • 请求第一轮waterfall后,缓存到3条广告:as1,as2,as4。其中as4的广告过期时间为0.5h,小于as1和as2的3h。

  • 0.5h后,as4因广告过期被清除,触发第二轮waterfall请求。因as1和as2已有缓存,在第二轮中不会被请求。as3和as4因无缓存,会被再次请求。

  • 两轮加载后,ad3和as4的累计请求数多于as1和as2。