文档

​
​

Development

User Acquisition

Monetization

工业

Unity LevelPlay

Unity SDK

Android SDK

iOS SDK

Adobe AIR SDK

Flutter SDK

React Native SDK

Unity LevelPlay

Monetization
​
​
LevelPlay
  • LevelPlay SDK
  • LevelPlay 平台
    • 开始使用
    • 基础知识
    • 测量和报告
    • 高级设置
    • API
    • 最佳实践
      • Measure success
      • Mediation management
      • Minimizing ad latency
      • In-app bidding
      • Placements
      • A/B testing
      • Segments
      • Cross promotion
  • 法律资源
  • 帐户
  1. 实现游戏增长
  2. Unity LevelPlay
  3. LevelPlay 平台
  4. 最佳实践

A/B 测试最佳实践

通过对广告素材、放置/位置、节奏和瀑布流策略实施 A/B 测试,然后分析效果以定制广告设置,从而提高 Monetization。
阅读时间8 分钟
最后更新于 3 天前

A/B 测试是每个业务策略的关键组件。它涉及根据对照组测试您的假设,以确保您的新方法最大限度提高收入并实现业务增长。使用 Unity LevelPlay 的 A/B 测试工具,您可以质疑和尝试不同的 Monetization 变量,以了解用户如何使用广告服务并选择获胜策略。
A/B 测试需要智能规划和定义的目标才能获得最确定的结果。以下最佳实践将帮助您使用 Unity LevelPlay A/B 测试工具执行干净的测试,以便您可以根据准确的数据做出最佳决策。

设置 A/B 测试的最佳做法

测试所有可能影响 ARPDAU 的内容:**您应该不断测试任何有助于提升 ARPDAU 的变量。使用以下测试作为起点: 
  • 添加新的广告网络以查看它们是否有利润。
    • 瀑布优化测试,例如混合瀑布和传统瀑布、指定国家/地区的新瀑布、不同的实例定价、添加或删除实例、细分段和组的瀑布
    • 不同的封顶和节奏策略,在不影响参与度的情况下带来最大利润
    • 横幅刷新率,最大限度提高横幅性能
    • 不同的奖励视频奖励金额来确定哪个参与度最高 
  • 使用 AB 流量分配器。
    • 如果不想在测试开始时在对照组和测试组之间平均分配 50/50,请使用 A/B 流量拆分分配器将流量拆分为 90 /10 的拆分。这允许您分析测试组的性能,而无需向测试组提交太多流量。
    • 如果测试组表现良好,请开始一时间增加 5-10% 的流量。
  • 一时间测试一个变量。
    • 优化广告策略时,可能会发现需要测试多个变量。
    • 有效评估任何更改的重要性的唯一方法是隔离一个变量并衡量其影响。例如,这意味着您不应在激活新网络的同时更改视频放置/位置的奖励金额。
  • 批量更改测试的变量。
    • 测试 B 组中与 KPI 一致的对同一变量的多个更改。例如,如果使用实时轴心延迟报告来识别具有高延迟(可变)的实例,请删除您怀疑导致高瀑布延迟的多个网络。 
  • 避免在非常低的 DAU 应用程序上进行测试。
    • 在 app 级别上至少拥有 15K DAU 才能得出最具数据驱动性的业务结论。
  • 测试最少 3 天,最多 14 天。
    • 这将确保 B 组的足够学习,并允许快速连续测试其他变量。
  • 别管 A 组。
    • 确定要测试的变量后,保持对照组(A 组)不变。A 组中的设置已作为当前广告策略存在。
    • 仅应在 B 组中进行更改以挑战当前策略并比较结果。

A/B 测试运行时的最佳做法

  • **实时查看结果:**转到实时 A/B 控制面板轴心以验证测试是否已启动并正在运行,并实时查看结果。
  • 监控测试数据:使用 A/B 后台可以轨道您的数据,确保不会因所做的更改而发生任何太大的变化。 
  • **请勿对 50/50 拆分测试进行更改:**在 50/50 拆分测试测试期间,不要更改 B 组。如果要测试不同的假设,甚至要对当前测试进行小调整,请终止测试并启动另一个测试。如果测试开始时使用了不同的流量分配,请确保在测试开始后的 24 小时内不进行任何更改。这一点至关重要,有助于保持数据的条理和整洁以便进行分析。

分析结果的最佳做法

  • 深入数据:使用 A/B 后台作为分析结果的起点。根据在启动测试之前设置的 KPI 比较两组的数据和性能。如果需要深入了解,请查看控制面板中链接的性能和群组报告。 
  • **使用 ARPDAU 作为引导光源:**ARPDAU 是应该用于指导您继续哪个组的决策的主要指标。分析每个每日激活用户的平均收入,了解在测试组进行更改后 app 中的用户行为。虽然其他指标可能会受到新用户或用户获取的影响,但 ARPDAU 可让您更清晰地了解所有现有用户的行为和对策略的反应。
累积 ARPU 指标也是需要考虑的重要指标,尤其是在分析指定的日期的新用户时。ARPU 与累积 ARPU 指标密切相关,因此一起监控它们非常重要。 
  • **在适当的时间查看适当的数据:**只有在对组 B 进行所有更改后,才开始分析结果,以便您可以看到所有更改的影响。您还应该在分析中排除第一天的测试。如果使用 A/B 流量分配器在测试期间增加或减少五个测试组的流量,请确保至少等待 24 小时,以便获得完整的测试结果。
  • 忽略每日数据:测试假设时,您的目标是长期改进而不是每日更改。由于日常性能可能不稳定,因此应将整个测试的数据作为一个整体进行分析,而不会将其分解为几天。
  • **测试后终止跟踪 app 趋势:**在测试关闭 2 周后,返回测试 app 的 A/B 后台,分析初始 A/B 测试的持续结果。这将让您了解测试的可持续性和长期特效。 
创建 A/B 测试例程以不断提高 app 性能。小而渐进的更改可以迅速添加,从而推动收入大幅增长,并且始终有进一步优化的空间。使用先前测试分析中的见解,了解如何在后续测试中进一步改进。

Copyright © 2026 Unity Technologies
法律信息隐私政策CookiesDocumentation Terms of Use请勿出售或分享我的个人信息您的隐私选择(Cookie 设置)

“Unity”、Unity 徽标及其他 Unity 商标是 Unity Technologies 或其附属公司在美国和其他地方的商标或注册商标(此处查看更多信息)。其他名称或品牌是其各自所有者的商标。

为方便起见,一些页面是机器翻译的,可能包含不准确的内容。如有信息不一致的情况,以英文版本为准。

  • 在本页上
    • 设置 A/B 测试的最佳做法

    • A/B 测试运行时的最佳做法

    • 分析结果的最佳做法


报告此页面的问题