Firebase AB Testing 关键疑点解释

实验启动 - Firebase A/B Testing 的用户分组机制1实验启动后流程创建试验后点击启动实验等于正式发布了一个实验规则规则运行期间如果用户启动应用并获取Remote Config时Firebase会自动进行条件判断国家是美国版本号26条件不满足不参与实验如果条件满足就会将其随机分配到某个组中并将结果持久化已经分配的用户会永远保持在同一组直到实验结束。2如果实验只是创建了没有启动等于实验规则没有发布那么它也不会生效所有用户打开app也均不会被进行分组客户端请求Remote Config时永远拿到的是默认值。Firebase如何保证随机分组的公平性Firebase使用用户唯一标识进行实验分组针对同一个用户的分组它不是今天随机一次明天又重新随机一次而是通过用户id和实验id结合哈希算法将用户固定到一个组中所以如果一个用户一旦被分配到了某个组中那这个用户之后就永远属于这个组。客户端如何主动知道当前用户属于哪个实验以及属于此实验下的哪个分组客户端通常不需要、也不应该主动查询“我属于哪个实验、哪个分组”。Firebase A/B Testing 的设计理念是客户端只读取 Remote Config 参数通过参数值间接知道自己拿到了哪个分组。更合理的方式专门增加一个Remote Config 参数作为分组标识在每个分组中赋予一个固定不变的值例如字母AB客户端拿到这个参数值直接就作为组标识。为什么不建议在第一次获取到分组信息时再持久化到客户端本地先说结论Firebase 已经做了“持久化用户实验分组”客户端再自己持久化一份分组信息通常不是一个好设计原因不是性能而是一致性和实验生命周期管理。通过前面的Firebase分组机制我们知道用户一旦被分到某个组下之后之后就永远固定在这个分组下了不会变因此即使每次启动都动态反推属于哪个组结果也都是固定且一致的如下App启动1 Remote Config -B App启动2 Remote Config -B....App启动100 Remote Config -B如果在第一次获取到分组B之后客户端持久化保存到本地之后每次启动都从本地直接读取这样看起来更快也更方便但是却存在如下几个问题1Remote Config 不只是“分组系统”还是“配置系统”分组信息本身就是根据属性值反推的如果中间修改了属性值本来值3对应的是B组修改之后变成值2对应的是B组了以及实验结束后全部用户都会恢复到默认值此时如果客户端一直只从本地缓存读就会存在B组明明已经结束了但是客户端还依然判定自己属于B组。2实验不是永久存在的这个是最大的问题实验结束之后客户端持久化保存的分组数据会变得没有任何意义之后再开启新的实验这个分组应该要动态更新才对。3Remote Config 本身已经有本地缓存机制实际上 Firebase Remote Config SDK 已经帮你做了一层缓存客户端再做持久化保存本身也是在重复实现 Firebase 已经做的事情。提示如果非要使用客户端持久化必须还得搭配动态获取Remote Config等获取到结果之后实时更新本地缓存下一次是用的就是更新后的本地缓存绝不推荐单纯客户端本地化写死。如果实验中途修改分组比例修改之前已经进入实验的用户通常不会被重新洗牌否则会污染实验数据只会影响修改之后再次进入实验的用户分配。是否可以借助实验来完成国家判断场景我的实验是面向100%的美国用户创建的刚好我的业务逻辑中需要判断当前用户所处的国家是否是在美国我是不是可以不用自己写判断逻辑直接依赖实验来进行国际判断结论不建议这么做原因你的想法看起来很合理但是忽略了一个问题实验条件 ≠ 用户属性并且实验条件只存在当前实验中如果之后试验结束那么你的国家判断逻辑也会跟着一起消失。而且当实验一多的时候这种依赖实验判断的逻辑会越来越混乱所有激活事件到底是什么谁才算真正参加实验官方解释意思是实验开始后所有被分配进入实验的用户都将受到实验变体中变量的影响但是只有触发激活事件的用户才会被纳入最终的实验效果衡量中。为什么需要激活事件原因因为在很多实验中并不是所有进入实验的用户都有意义。举例假设你实验的目的是为了看广告策略是否影响收入以及留存实验变体A启动广告展示5秒实验变体B启动页广告展示3秒如果被分配到该实验下的用户打开app因为网络原因导致根本就没有看到启动广告那么这个用户其实不应该影响实验结果所以我们可以将激活事件设置为 splash_ad_show只让真正看到启动广告的人才进入实验分析。如果不设置激活事件会怎么样如果不设置这个激活事件Firebase就会认为所有被分配到实验的用户从分组那一刻开始就是最终实验效果衡量的参与者如果每天有1万人打开app这1万人全部都会进入实验统计有可能其中只有1000人看到了广告其他用户都是无效实验对象不设置激活事件他们的行为会导致实验结果被严重稀释设置了激活事件就等于对参与实验的用户又做了一层关键行为过滤在实验中且触发了激活事件的用户才会被纳入最终实现效果衡量的数据样本中。实验相关的信息是如何关联到Firebase Analytics自定义事件上的须知实验信息归属的是用户级别而不是事件级别也就是说在实验启动期间当用户启动app参与了实验并被随机分配到某个分组下之后实验信息就会被同步写入用户属性User Property中之后该用户在应用中触发的所有自定义事件就会自动共享被写入到该用户属性中的实验信息从而实现的将某个自定义事件和实验信息绑定这也是为什么Firebase 能知道这些事件属于哪个实验组的原因。注意一个前提只有在实验启动之后实验用户在应用中产生的行为才会有因为这个时候产生该行为的用户才会有实验属性未启动实验之前的历史数据不会被关联。提示在Firebase Console的A/B Testing 页面我们会自动看到主要指标的统计数据示例如下Variant A: Revenue$10000Variant B: Revenue$12000这是因为firebase自动帮我们把用户事件和用户的实验属性进行了join关联但是如果你导出BigQuery执行如下的SQL命令查询select* from events whereevent_namepurchase你不会直接看到类似这样的数据你需要再将user_properties展开在里面去找实验数据即你需要自己手动去join解析。Remote Config 的默认值在什么时候会被用到0分组下没有为字段设置新值会使用默认值。1用户不满足实验条件会直接返回默认值。2实验没有覆盖到这个用户例如实验流量设置的是20%那么其余80%没有参与实验的用户也会直接拿到默认值。3如果启动时因为网络原因导致拉取Remote Config参数值失败则会返回SDK的本地默认值。3实验结束取默认值分有条件和无条件结束实验后的处理例如Remote Config参数默认值为0对照组参数值为1实验组1参数值为2现在实验组1胜出接下来我们要关闭实验在Firebase后台关闭实验时选择发布获胜变体firebase会将该变体对应的参数值设置为Remote Config的正式配置这里分两种情况1没有 Remote Config 条件时发布获胜变体后其实就是用该变体的值直接修改了默认值之后所有用户都拿到的是默认值2。2存在 Remote Config 条件时更接近真实项目发布获胜变体后不是直接修改默认值而是更改对应条件下的默认值等于Remote Config中配置了两个默认值如下图建议发布后去Config Remote配置中去检查一下值对不对。注意客户端没法知道实验结束正常Firebase的事件参与实验统计由Firebase自动维护实验结束后会自动停止统计但是本地AdFlow事件上报依赖手动添加实验信息所以必须通过一个专门的字段值来判断实验是否关闭如果关闭AdFlow事件也不应该再携带实验信息数据。