漏斗分析
1. 功能介绍#
漏斗分析报表是 TradPlus 基于漏斗模型设计的数据报表，完整记录了聚合广告变现各事件的数据和核心漏斗转化率。
2. 使用场景#
通过此报表，您可以快速找到广告展示流失的环节。
3. 使用指南#
3.1 数据筛选项#
3.1.1 使用说明#
TradPlus 漏斗分析提供 9 个数据筛选项：
| 筛选项 | 说明 |
|---|---|
| 应用 | 开发者在 TradPlus 后台已创建的应用。 |
| 广告位 | 开发者在 TradPlus 后台已创建的广告位。 |
| 国家 / 地区 | TradPlus SDK 检测到的您的应用发布的国家/地区。如：中国、美国、英国。 |
| 广告类型 | 开发者已使用的广告类型，如激励视频、开屏等。 |
| A / B 测试分组 | 在 TradPlus 后台配置的A/B测试分组。 |
| SDK 版本 | TradPlus SDK 版本号。 |
| 广告场景 | 开发者在 TradPlus 后台已创建广告场景，并在到达广告场景、展示和点击时上报广告场景 ID。 |
| 应用版本 | 开发者定义的应用版本号。 |
| 渠道 | 通过 TradPlus SDK 上报的渠道信息。 |
3.1.2 操作指南#
1）点击筛选项，在弹出的下拉菜单中选择需要的筛选项。
3.2 漏斗模型报表#
3.2.1 事件说明#
以下事件均统计次数、用户数和人均次数。
- 其中用户数可以切换为“参与用户数”或“DAU”，“参与用户数”即实际参与该事件的用户数。以“应用请求”事件为例，参与用户数为“应用请求”的用户数。
| 事件 | 含义 |
|---|---|
| 启动应用 | 应用初始化 TradPlus SDK。 |
| 应用请求 | 应用向 TradPlus SDK 成功发起的请求。 |
| 应用填充 | 应用向 TradPlus SDK 发起请求后，广告成功返回。 |
| 应用填充时长 | 从应用发起请求到成功填充广告的平均时长。 |
| 到达广告场景 | 应用调用 TradPlus 的进入广告场景接口。 |
| 查询 isReady | 应用调用 TradPlus SDK 的 isReady 接口。 |
| 触发展示 | 应用调用 TradPlus 的 show 接口（横幅、原生横幅为触发 TradPlus 展示逻辑）。 |
| 触发展示成功 | 成功触发三方的展示，注意：成功触发展示后，需要等展示时长和面积等满足三方广告平台规范，才算有效展示。 |
| 展示 | TradPlus SDK 收到三方广告 SDK 的展示回调。（部分三方广告 SDK 不返回 Banner 或 Native 的展示回调）。 |
| 展示API | TradPlus通过广告平台报表API拉取到的点击数。注意：部分广告平台（如Unity Ads）不返回点击数。 |
3.2.2 核心指标数据#
统计核心漏斗转化率，用于分析广告展示的流失。
| 漏斗事件 | 关键转化率 | 含义/计算公式 | 使用说明 |
|---|---|---|---|
| 应用请求广告 | 应用填充率 | 聚合层级的广告填充率，即应用向聚合SDK发起请求后，成功返回广告的比率。 | 反映 Waterfall 配置是否合理，影响因素有使用广告平台的个数、广告源底价配置等。 |
| 用户到达广告场景 | 广告场景到达率 | 到达广告场景的用户数 / 启动应用的用户数。 | 反映广告场景设计是否合理，如果想提高此转化率，可把广告场景入口设计得更加明显。 |
| 触发广告展示 | 广告触发率 | 用户到达广告场景时，触发广告的比率。计算公式：触发展示的次数 / 到达广告场景的次数。 | 对激励视频，广告触发率体现了奖励对用户的吸引程度；对其他广告类型，因为是应用主动触发，广告触发率应当是100%，否则是应用本身做了限制。 |
| 展示广告 | 触发成功率 | 应用触发展示后，能够成功触发广告展示的比例。注意：成功触发展示后，需要满足广告平台对展示面积和时长等的要求，才能被认可为一次展示。 | 如果触发成功率较低，通常是广告频次限制或接入问题导致。TradPlus 后台会统计所有失败原因和相应次数。 |
| 展示广告 | 展示成功率 | 展示次数 / 触发展示成功的次数 | 能够反映广告展示质量和广告场景设计是否合理。注意：部分广告平台的 Banner 和 Native 不会回调展示。 |
3.2.3 操作指南#
点击报表左上方【分天】、【汇总】、【趋势】选项卡，可切换查看对应的报表。
【分天】报表：
按日期维度统计各漏斗事件数据和转化率
默认展示 19 个数据指标，您可以根据需求选择需要的指标，点击右侧“自定义指标”按钮- 勾选需要的数据指标即可。
【汇总】报表：
统计在筛选日期范围内的汇总数据，按漏斗顺序展示。
“次数”列后面的“转化率”为基于事件次数计算的转化率，比如应用填充率是应用请求次数 / 应用填充次数。
“DAU”列后面的“转化率”为基于用户数的转化率，比如广告场景到达率是到达广告场景用户数 / 启动应用用户数。
【趋势】报表：
直观展示各漏斗事件和转化率的数据趋势，次数和用户数为折线图展示，人均用柱状图展示。
1）可选择需要监测的数据指标。
4. 最佳实践#
TradPlus漏斗分析报表用于分析聚合广告变现的广告展示是否最大化。进行数据分析时，可先按漏斗模型顺序查看漏斗转化率，然后再分析广告填充是否及时。
4.1 关注漏斗转化率#
应用内广告流程通常是：应用提前请求广告，当用户到达广告场景时，触发并展示广告。
基于此流程，我们梳理出“应用请求广告->用户到达广告场景->触发广告展示->展示广告”这四个漏斗步骤。通过统计每个步骤的关键转化率，我们就可以知道收益流失在哪一步。
4.2 分析广告填充是否及时#
即使应用填充率达到100%，也无法保证应用需要广告时一定有广告可供展示，原因是用户到达广告场景时，广告可能还没有准备好。可能的影响因素有：
应用发起广告请求的时机较晚，用户快看广告时才开始请求；
广告场景设计较浅，用户打开应用后很快就需要观看广告；
Waterfall配置层级过多或底价过高，导致填充时长过长。
为监控广告填充是否及时，TradPlus提供了多种数据指标供开发者使用，如下：
| 数据指标 | 含义/计算公式 | 使用说明 |
|---|---|---|
| 到达广告场景时的ready率 | 用户到达广告场景时，至少有一条广告已经ready的比率。 | 可以反应广告填充是否足够及时，如果过低，可以增加并行请求数、减少waterfall层数或调整广告场景位置。 |
| 查询ready率 | 应用询问TradPlus是否有广告ready时，广告已经ready的比率。 | 因为询问的接口（即isReady方法）是由应用灵活调用，所以开发者需要结合具体使用方式来分析。需要注意的是，应用在发现广告没有ready时，有时会频繁调用isReady方法，从而导致“查询ready率”比真实情况偏低。 |
| 应用填充时长 | 从应用发起请求到成功填充广告的平均时长，是聚合层级的广告填充速度。 | 此指标反映了waterfall的加载速度，当上述两个ready率比较低时，我们可以通过减少waterfall层数来降低应用填充时长。但同时要注意对eCPM的影响，因为我们最终是要得到最优的Arpu值。 |
4.3 到达广告场景事件的上报时机#
应用需要主动上报到达广告场景事件给TradPlus，上报时机是：
激励视频
如果广告观看按钮始终显示，不会在无广告时置灰或隐藏，可在用户点击按钮时上报此事件，如图1；
如果广告按钮只有在广告时才会显示，可以在用户进入广告位时上报。
插屏
- 在满足广告触发条件时上报用户到达广告场景的事件，比如广告场景是清理结束后弹出插屏，则在清理结束时进行上报。
4.4 两种ready率的区别#
“到达广告场景时的广告ready率”是在应用上报广告场景这一时机的广告ready率；
“查询ready率”的触发时机和场景是不确定的，取决于开发者的使用方式。
5. 常见问题#
Q：广告源的填充率很低，是否说明广告位的填充不足？#
A：
三方广告源的填充率与广告位的填充情况无必然联系。
因为聚合包含了多个三方广告源，应用向聚合发起请求后，只要有一个填充即可。所以我们应当看应用填充率，这个才是聚合层级的广告填充率。只有当应用填充率异常时，才需要关注三方广告源的填充率。
Q：广告源的展示率很低，是否说明展示流失很多？#
A：
三方广告源的展示率低与展示流失无必然联系。
如果配置多个广告缓存，当应用向聚合SDK发起一次请求后，聚合会向多个三方广告源请求广告，在展示广告时只会展示价格较高的广告，剩余的广告会缓存下来备用。
如果后续没有被展示，就会降低广告源的展示率。而如果要知道展示流失情况，需要看漏斗模型的每一步转化率。如果某一项有异常，再针对性排查原因。