中介管理
中介管理是用来配置广告瀑布流、广告策略调优，可以设置中介分组、配置广告源、调整广告源优先级、设置开启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开始算起。 |
| app | SDK版本 | version | 包括、不包括 、范围、>、< | 1 | TradPlus SDK版本，包括和不包括时，可填多个版本号，用英文逗号分隔。>和<时，只能填写一个。 |
| device | IDFA | string | 包括 | 1 | 针对iOS14无法获取时，我们可以通过用户是否授权IDFA来创建一个流量分组归类这些设备。（仅 iOS 产品有该指标） |
| device | 设备 ID | string | 包括 | 1 | web端可填多个设备ID ，用英文逗号分隔，设备ID可以是 IDFA, IDFV, GAID, OAID。 |
| device | 系统版本 | version | 包括、不包括 、>、< | 1 | 手机系统版本，包括和不包括时，可填多个系统版本号，用英文逗号分隔。>和<时，只能填写一个。 |
| device | 设备类型 | string(ignoreCase) | 包括、不包括 | 1 | 可选择iPhone或iPad，可多选。 |
| device | 设备制造商 | string(ignoreCase) | 包括、不包括 | 1 | 举例Huawei ，可多选。 |
| device | 网络连接类型 | string | 包括 | 1 | web端可多选，可取值为：WiFi, 2G, 3G, 4G, 5G。 |
- 应用上报数据
以下数据由开发者根据需要，通过sdk接口上报。如果不上报，如下规则将无法在中介组中使用。
| 参数 | Key | 类型 | 条件 | 规则数量 | 描述 |
|---|---|---|---|---|---|
| 自定义用户ID | user_id | string | 包括 | 1 | Web端可输入多个ID,英文逗号分隔。另外，TradPlus 可基于此user id提供设备层级的变现数据（API）。 |
| 年龄 | user_age | int | 范围 、>、<, = | 多个 | 输入数字（0-99）， 单位 岁。 |
| 性别 | user_gender | string | = | 1 | web端只能单选，可取值为：male、female；sdk端可传值：unknown、male、female。 |
| 游戏中等级 | user_level | int | 范围 、>、<, = | 1 | |
| 应用内付费金额 | user_iap_amount | float | 范围 、>、<, = | 1 | |
| 应用内付费币种 | user_iap_currency | string | = | 1 | 目前支持USD, CNY, EUR。 单选 |
| 应用内付费次数 | user_iap_count | int | >、<, = | 1 | |
| 渠道 | channel | string | 包括、不包括 | 1 | Web端支持填入多个渠道号，用英文逗号分隔，渠道号需要开发者在SDK中传入。 |
| 子渠道 | sub_channel | string | 包括、不包括 | 1 | Web端支持填入多个子渠道号，用英文逗号分隔，子渠道号需要开发者在SDK中传入。 |
| 自定义用户属性 | custom_xxx | string/int | 整数：范围，>、<, = ；字符串:包括，不包括 | 最多5个 | 应用通过Key-Value形式（key以’custom_’+字段名），传入自定义用户属性，如custom_username。最多支持5个。 |
| segment tag | segment_tag | string | 包括 | 1 | 如SDK上报segment_tag，会使用指定segment的waterfall配置。此参数匹配时，会无视其他参数。最多支持1个。 |
ii. 使用方法#
- 设置方法
需要在初始化SDK之后，初始化广告位ID之前调用接口。
如需使用流量分组功能，则开发者技术侧务必进行此步骤。
- APP全局自定义规则设置
| 平台 | 方法 |
|---|---|
| Android | SegmentUtils.initCustomMap(customMap); |
| iOS | [TradPlus sharedInstance].dicCustomValue = dicXXX |
| Unity | TradPlus.initCustomMap(map); |
- Placement 自定义规则设置
| 平台 | 方法 |
|---|---|
| Android | SegmentUtils.initPlacementCustomMap("placementId", customMap); |
| iOS | _rewardedVideoAd.dicCustomValue = dicXXX |
| Unity | TradPlus.initPlacementCustomMap("placementId", map); |
● 示例
- Android SDK代码示例
- iOS SDK代码示例
- Unity SDK代码示例
- 后台配置
1）新建中介组
2）设置流量规则
3）调整优先级
当一个用户满足多个流量组规则时，可以通过拖拽的方式设置流量组优先，决定优先匹配哪个广告策略。
2.4 中介组数据报表#
2.4.1 数据指标#
中介组数据报表可查看每个广告源的广告数据，具体指标如下：
| 指标 | 含义 |
|---|---|
| 竞价请求API | TradPlus通过广告平台的报表API拉取到的竞价请求数。 |
| 竞价响应API | TradPlus通过广告平台的报表API拉取到的竞价响应数。 |
| 竞价响应率API | 竞价响应数API / 竞价请求数API。 |
| 竞价胜出率API | 广告请求数API / 竞价响应数API。 |
| 请求API | TradPlus通过广告平台的报表API拉取到的请求数。 |
| 填充API | TradPlus通过广告平台的报表API拉取到的填充数。 |
| 填充率API | 填充API / 请求API 。 |
| 展示API | TradPlus通过广告平台的报表API拉取到的展示数。 |
| 展示率API | 展示数API / 填充数API。 |
| 点击API | TradPlus通过广告平台报表API拉取到的点击数。注意：部分广告平台API不返回点击数。 |
| 点击率API | 点击数API / 展示数API。 |
| 填充时长 | 从发起请求到成功填充广告的平均时长。 |
| 请求时长 | 每次请求广告的平均时长，会统计填充、未填充、超时等所有情况的请求数据。 |
| eCPM API | 千次展示带来的广告收入。 |
| eCPC API | 平均每次点击获得的广告变现收入。 |
| 收入 API | TradPlus通过广告平台报表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。
