接入典型的 SaaS 广告聚合 SDK 后，你的事件流——每次广告请求、每次广告展示、每个用户标识符——都会先发送到供应商的服务器。供应商对数据进行处理、补充信息，然后有时会将脱敏后的副本回传到你的数据仓库。等你看到数据时，它已经经过了一个不受你掌控的系统。
Firebase 原生 SDK 的工作方式恰好相反。事件首先写入你自己的 Firestore 和 BigQuery。供应商从你的项目中读取数据，而不是由你向供应商取回数据。这个区别听起来像是理论问题，直到你遇上第一次 GDPR 审计。
当数据归你的项目掌控，会有哪些变化
- 处理删除请求只需一次 Firestore 查询，无需向供应商提交工单，也不必等待 SLA 约定的处理时限
- BigQuery 成本可预测，因为导出数据的结构由你控制
- 数据结构迁移按你的时间表推进，不必跟着供应商的版本更新走
- 需要披露的次级数据处理者名单会缩短，而且往往大幅缩短
销售沟通中没人提的取舍
Firebase 原生架构并非没有成本。原本交由供应商承担的存储和查询，现在需要由你向 Google 付费。对于一款拥有 500 万 DAU 的应用，BigQuery 每月账单大约在 400–1,200 美元之间。这笔支出不算小，但与它所保障的广告收入相比，几乎可以忽略不计。
你还需要考虑配额。Firestore 每秒写入量、BigQuery 流式插入和 Cloud Functions 冷启动，都是实际存在的约束，只是在 SaaS SDK 模式下由供应商在幕后处理。Apps Kit SDK 内置背压控制层，通过批量写入，让大多数 DAU 低于 100 万的应用保持在免费套餐配额内。
你实际需要向 Google 支付多少费用
这套成本模型平平无奇，而这正是它的优点：每一项费用都能在你自己的结算控制台中查看。以下是我们在 2026 年实际运行的 Apps Kit SDK 部署中观察到的费用区间，已计入默认启用的背压控制层和 BigQuery 分区 90 天自动过期策略。
- 100 万 DAU：Firestore 40–90 美元，BigQuery 存储 20–50 美元，BigQuery 查询 30–80 美元，Cloud Functions 10–30 美元——合计低于 250 美元/月
- 500 万 DAU：Firestore 180–350 美元，BigQuery 存储 100–220 美元，BigQuery 查询 120–400 美元，Cloud Functions 40–110 美元——合计 400–1,200 美元/月
- 2,500 万 DAU：Firestore 700–1,400 美元，BigQuery 存储 450–900 美元，BigQuery 查询 500–1,800 美元，Cloud Functions 150–400 美元——合计 1,800–4,800 美元/月
真正影响账单的成本调优项
上述费用差异主要来自三个决策。第一，是向 BigQuery 流式插入数据，还是通过 GCS 批量导入。批量导入可将数据摄取成本降低 80% 以上，代价是报表延迟 30 分钟。第二，分区过期时间。90 天足以覆盖我们迄今遇到的所有运营查询需求，更早的原始数据应转入冷存储。第三，查询规范。一个看板如果对整年的广告展示数据执行没有范围限制的 SELECT * 查询，其费用就可能超过其他所有项目的总和。
为什么这件事在 2026 年更重要
今年的两项监管变化改变了权衡方式。DMA 的数据可携带性要求现已适用于任何处理欧盟终端用户数据的供应商，印度 DPDP 的执法过渡窗口也已于 3 月结束。这两套监管制度都以一个前提为基础：你能按要求随时完整导出与某个用户相关的所有事件。
如果权威数据源掌握在 SDK 供应商手中，你就得依赖他们的导出工具。如果权威数据源是你自己的 Firebase 项目，导出数据不过是执行一条你早就会写的查询。
GDPR / DPDP 审计实际如何开展
当监管机构或大型企业客户提出审计要求时，他们需要四项材料：所有接触终端用户数据的次级数据处理者名单、指定用户的完整数据导出、删除证明，以及数据保留计划说明。使用 SaaS SDK 时，第一项要靠查阅供应商的披露文件，接下来的两项要靠提交工单，第四项则只能靠猜。
采用 Firebase 原生架构后，这四项都能通过你自己掌控的查询和配置获取。次级数据处理者：项目中使用的 GCP 服务清单。用户数据导出：一次 Firestore 查询加一次 BigQuery 查询，SDK 已提供对应模板。删除证明：由 Cloud Functions 函数返回受影响的行数。保留计划：控制台中可查看的分区过期策略。审计工作由此从手忙脚乱的两周，变成半天就能完成的任务。
如何从 SaaS SDK 迁移，同时保持广告归因正常
让团队望而却步的，往往是他们设想中必须在一个版本内完成的迁移。我们不会这样做。Firebase 原生 SDK 会与现有 SaaS SDK 并行运行两到四周，向新的数据管道写入数据，同时旧管道继续为所有现有看板和 MMP 提供数据。
- 第 1 周：以影子模式接入 Firebase 原生 SDK，不改变用户体验，并在 BigQuery 中验证事件数据一致性
- 第 2 周：将归因回传切换至 Firebase 原生链路，广告聚合仍由旧 SDK 负责
- 第 3 周：切换广告聚合，保留 SaaS SDK 发送只读事件，在数据不一致时作为核对依据
- 第 4 周：在下一次应用更新中移除 SaaS SDK，彻底消除依赖
哪些情况下 SaaS 仍然更合适
如果你的团队尚未使用 Firebase，也没有引入计划，那么 Firebase 原生 SDK 带来的运维开销就不可忽视。对于希望接入上线后无需持续运维的工作室，以及尚未将数据所有权视为战略资产的原型项目，SaaS 广告聚合仍是合适的选择。这不是一个技术决策，而是要决定：你希望由谁掌控审计记录。
掌控事件流，不只是表明你重视隐私。它决定了下一次与供应商谈合同时，你是手握底气，还是手里只有一张截图。
本季度可以做什么
如果你已经在使用 Firebase Analytics，那么接入 Firebase 原生广告 SDK 的路，你其实已经走完了 60%，只是自己可能还没意识到。花一个迭代周期完成上面的影子模式接入，再根据数据一致性报告做决定，而不是听销售演示。大多数完成影子运行阶段的团队，都会决定在 90 天内完成切换。
