Google 的 Firebase 新产品线，从分析到实验的一体化

Google 的 Firebase 新产品线，从分析到实验的一体化

2023 年 9 月 30 号之后，如果你还赖在 Google Optimize 的后台想改一个网页 A/B 测试，看到的只会是一封关服通知。Google 把这项服务掐掉，顺手把流量实验的摊子强行并进了 Firebase A/B Testing。这一步棋看起来只是产品线收缩，实际上是把「分析—受众—配置—实验」整条链路彻底焊死在 Firebase 和 GA4 这套组合里。作为 Android 开发者，你很难再继续用独立第三方的数据后台、独立的事件系统、独立的配置下发工具来拼凑自己的增长技术栈。Google 说这叫一体化，我倾向于管这叫「温柔陷阱式的绑架」。

Google Optimize 关停：一场早有预谋的「接盘」

Google Optimize 和 Optimize 360 的死亡通知其实早几年就发了，但真正到 2023 年 9 月 30 日服务完全停止那一刻，很多团队的运营和增长同学还是懵了。过去做 Web A/B 实验用 Optimize，做 App 实验用 Firebase A/B Testing，两套系统虽然数据不互通，但至少各自安好。现在 Web 端被迫要去 Firebase 控制台里开实验，而 Firebase A/B Testing 的底层数据管道从一开始就是 GA4。这意味着如果你的网站或 App 还没把 Universal Analytics 的事件体系迁到 GA4，你连创建实验的资格都没有。

Firebase A/B Testing 本身并不神秘，它的技术骨架搭在 Remote Config 和 Cloud Messaging 之上。实验组和对照组的分配逻辑由 Remote Config 的模板条件处理，用户入组后通过 FCM 下发配置。以前这套系统还能兼容一些老旧的 Firebase Analytics 事件做指标追踪，但 Optimize 关停后，Google 把最后一根绳子也勒紧了：实验的 primary metric 和 targeting 必须来自 GA4 的 conversion 事件或受众群体。你不再能简单地抛一个自定义事件到 Firebase 然后立刻拿来做实验判停指标，而是要先在 GA4 后台把事件标记为 conversion，等数据回流，再走一遍 Firebase 的实验看板。

这个流程的摩擦成本极高。GA4 的数据延迟是出了名的，少则几个小时，多则 24 到 48 小时。以前用 Optimize 做 Web 实验，数据几乎是准实时的，运营同学上午改个按钮颜色，下午就能看转化率。现在切到 Firebase A/B Testing 接 GA4，实验跑三天，前两天数据都在「跳舞」，第三天才能勉强判断趋势。对于习惯快节奏迭代的中小团队，这种迟滞直接把实验文化憋死了。Google 美其名曰「用更强大的事件模型做更科学的统计」，实际上是拿一套为广告归因设计的延迟数据管道，硬塞给了需要快速反馈的产品实验场景。

Remote Config 的「实时化」与模板管理的暗坑

Remote Config 是 Firebase 里我最喜欢也最恨的一个组件。喜欢是因为它确实解决了客户端动态发版的问题，恨是因为早期版本的缓存机制太反人类。FirebaseRemoteConfig.getInstance().fetchAndActivate() 这个 API 很多人用错，默认的 minimumFetchIntervalInSeconds 是 12 小时，意味着你调用一次 fetch，如果本地缓存没过期，拿到的永远是旧值。大量开发者误以为配置下发了没生效，在 GitHub Issue 里骂了几年，Google 直到前两年才推了 Real-time Remote Config。

实时更新的原理倒不复杂，内部走了 FCM 的 topic 广播。Remote Config 服务端在模板变更时推一条消息到客户端，触发 onConfigUpdated 回调，开发者再去拉取最新模板。听起来很美好，实际接入时你会发现，它要求你的 App 已经集成了 Firebase Cloud Messaging SDK，并且在 Firebase Console 里正确配置了应用与 FCM 的关联。很多老项目虽然装了 FCM，但用的是旧版 topic 订阅逻辑，或者厂商通道（比如小米、华为、Oppo）的透传消息被系统杀掉，导致实时更新在 iOS 和国产 Android 机上形同虚设。

更要命的是模板版本控制。Remote Config 现在支持通过 REST API 和 Console 查看模板版本历史，也能做一键回滚。但 A/B Testing 的实验参数和 Remote Config 的基础参数是混在同一个模板命名空间里的。你在 Firebase A/B Testing 控制台里修改了一个实验变量的取值范围，Remote Config 的模板版本历史里确实会生成一个新版本，但版本注释里并不会清晰标注「这是由 A/B Testing 触发的变更」。对于多人协作的团队，运维同学在 Remote Config 后台看到一个新模板版本，很难一眼分辨是人工配置漂移还是实验系统自动生成的。所谓「一体化」在开发者体验上，到这里出现了一个明显的断层。Google 把两个产品的数据层打通了，但操作层的审计链路还是割裂的。

GA4 的「强绑定」与数据黑洞

Firebase 和 Google Analytics 的捆绑这几年越来越紧，紧到了令人不适的程度。最典型的例子是 Crashlytics。Fabric 时代的 Crashlytics 是独立运行的，崩溃堆栈、设备信息、自定义键值对，应有尽有。被 Google 收购并并入 Firebase 后，功能迭代慢了很多，但好歹还能独立用。直到 GA4 上位，Google 给 Crashlytics 加了一个「用户流」视图，号称能看到崩溃前的用户操作路径。这个功能的前提是你启用了 Google Analytics，并且把事件正确上报到 GA4。不开 GA4？那对不起，你的崩溃报告里永远少一块上下文拼图。

这不仅仅是功能阉割，而是战略胁迫。Google 需要 App 端的数据喂养它的广告模型和用户画像体系，Firebase 作为免费且好用的移动端 SDK，自然成了最完美的数据采集前端。Crashlytics 要看用户流，必须开 GA4；A/B Testing 要算指标，必须开 GA4；甚至 Firebase Predictions（虽然这个产品已经半死不活）也直接依赖 GA4 的事件流。开发者以为自己接了一个免费的崩溃监控和配置下发工具，实际上是在帮 Google 完善它的跨端用户行为图谱。

事件模型本身的迁移也是一地鸡毛。Firebase Analytics 时代的事件参数传递相对简单，你在代码里 logEvent("purchase", bundle)，参数跟着事件走。GA4 引入了更严格的 event 和 parameter 层级，自定义参数需要先注册，部分参数在报告里还可能被抽样或延迟展示。比如 screen_view 事件在 GA4 里是自动采集的，但如果你想带上额外的业务参数，必须在 GA4 后台里把这个参数注册为自定义维度，否则在 A/B Testing 的实验报告里根本选不到这个维度做分群。很多从旧版 Firebase 迁移过来的团队，代码里事件埋点没改，但后台突然看不见数了，排查半天发现是 GA4 的注册门槛挡住了数据。这种「一体化」的代价，是开发者要重新学习一整套为 Web 分析师设计的报表语言。

App Check 与 Play Integrity：免费的围墙越砌越高

Firebase 产品线里还有一个容易被忽视但战略意味极浓的组件：App Check。这个服务最早是为了