When you integrate a typical SaaS mediation SDK, your event stream — every ad request, every impression, every user identifier — is sent first to the vendor's servers. They process it, enrich it, and (sometimes) ship a redacted copy back to your warehouse. By the time you see the data, it has been through a system you do not control.
A Firebase-native SDK works the other way around. Events are written first to your own Firestore and BigQuery. The vendor reads from your project, not the reverse. The difference sounds academic until the first GDPR audit.
What changes when your project owns the data
- Deletion requests are a single Firestore query — no vendor ticket, no SLA
- BigQuery costs are predictable, because you control the export schema
- Schema migrations happen on your timeline, not the vendor's release notes
- Sub-processor disclosures shrink, often dramatically
The trade-offs nobody mentions in the sales call
Firebase-native is not free of cost. You pay Google for the storage and the queries you would otherwise have offloaded to the vendor. For a 5M-DAU app the BigQuery bill lands somewhere between $400 and $1,200 a month — meaningful, but a rounding error against the ad revenue it protects.
You also have to think about quotas. Firestore writes per second, BigQuery streaming inserts, and Cloud Function cold starts are real constraints that a SaaS SDK absorbs invisibly. Apps Kit SDK ships with a backpressure layer that batches writes to stay inside free-tier quotas for most apps under 1M DAU.
What you actually pay Google
The cost model is boring, which is the point — every line is observable in your own billing console. These are the ranges we see across active Apps Kit SDK deployments in 2026, after the backpressure layer and 90-day BigQuery partition expiration that we ship by default.
- 1M DAU: Firestore $40–90, BigQuery storage $20–50, BigQuery queries $30–80, Cloud Functions $10–30 — total under $250/month
- 5M DAU: Firestore $180–350, BigQuery storage $100–220, BigQuery queries $120–400, Cloud Functions $40–110 — total $400–1,200/month
- 25M DAU: Firestore $700–1,400, BigQuery storage $450–900, BigQuery queries $500–1,800, Cloud Functions $150–400 — total $1,800–4,800/month
Cost knobs that actually move the bill
Most of the spread above comes from three decisions. First, whether you stream-insert to BigQuery or batch through GCS — batching cuts ingestion cost by 80%+ at the cost of a 30-minute reporting delay. Second, partition expiration — 90 days covers every operational query we have ever needed; raw data older than that belongs in cold storage. Third, query hygiene — one dashboard with an unbounded SELECT * over a year of impressions can outspend everything else combined.
Why this matters more in 2026
Two regulatory shifts changed the math this year. The DMA's data-portability requirements now apply to any vendor processing EU end-user data, and the Indian DPDP enforcement window closed in March. Both regimes assume you can produce, on demand, a complete export of every event tied to a user.
If your SDK vendor is the system of record, you are dependent on their export tooling. If your Firebase project is the system of record, the export is a query you already know how to write.
How a GDPR / DPDP audit actually plays out
When a regulator or large enterprise customer asks for an audit, they want four artefacts: a list of every sub-processor that touches end-user data, a complete export for a named user, proof of deletion, and a description of your retention schedule. With a SaaS SDK you produce the first by reading their disclosure, the next two by filing tickets, the fourth by guessing.
With a Firebase-native setup all four are queries you own. Sub-processors: list of GCP services in your project. User export: one Firestore query and one BigQuery query, both shipped as templates in the SDK. Deletion proof: a Cloud Function that returns the affected row counts. Retention: your partition expiration policy, visible in console. The audit goes from a two-week scramble to a half-day exercise.
Migrating from a SaaS SDK without breaking attribution
The migration that scares teams is the one they imagine doing in a single release. We do not run it that way. The Firebase-native SDK ships alongside the existing SaaS SDK for two to four weeks, writing to the new pipeline while the old one continues to feed every existing dashboard and MMP.
- Week 1: integrate Firebase-native SDK in shadow mode, no user-facing change, validate event parity in BigQuery
- Week 2: cut attribution postbacks over to the Firebase-native path, hold mediation on the old SDK
- Week 3: switch mediation, keep SaaS SDK firing read-only events as a tiebreaker
- Week 4: remove the SaaS SDK in the next app update, leaving zero dependency
When SaaS still wins
If your team has no Firebase footprint and no plans to build one, the operational overhead of a Firebase-native SDK is real. SaaS mediation is the right answer for studios that want to ship and forget, and for prototypes where data ownership is not yet a strategic asset. The decision is not technical — it is about who you want to own the audit trail.
Owning the event stream is not a privacy posture. It is the difference between negotiating your next vendor contract from strength and from a screenshot.
What to do this quarter
If you already use Firebase Analytics, you are 60% of the way to a Firebase-native ad SDK and probably do not realise it. Spend a sprint shipping the shadow-mode integration above, and decide based on the data parity report — not the sales deck. Most teams that complete the shadow phase decide to cut over inside ninety days.
