Docs

Firebase StoreKit 2 & Consent Signal Tracking

Firebase's Apple SDK now supports StoreKit 2 and new TCF-aware consent signals — what to track as both roll into production purchase events.

Revenue

Firebase’s Apple SDK picked up two changes this cycle that land on the same code paths for very different reasons, and teams tend to ship them together without treating them as separate risks. The first is StoreKit 2 support, giving purchase and subscription events access to richer, more reliable transaction data than the older StoreKit 1 bridge provided. The second is an updated consent management API that adds new consent signals, a default “eu_consent_policy” state for ad-user-data and ad-personalisation consent types, and parsing of Transparency & Consent Framework (TCF) strings to read user consent preferences directly. Analytics and Swift-only APIs that used to live in the separate FirebaseAnalyticsSwift extension are also folding into the main FirebaseAnalytics module, with the extension now deprecated.

None of this breaks anything outright, which is exactly why it’s easy to under-test. A StoreKit 2 migration can silently change which purchase events fire and when — StoreKit 2’s transaction model resolves renewals and family-sharing entitlements differently than StoreKit 1 did, so a revenue dashboard built against the old event shape can start double-counting or missing renewals without any error appearing in logs. Meanwhile, the new TCF-aware consent defaults mean an app that hasn’t explicitly wired up its own consent signal is now inheriting a Google-defined default for EU users, which changes what gets sent to Firebase before anyone on the team decided it should.

Data Points to Track

  • Purchase event parity between StoreKit 1 and StoreKit 2 paths — a side-by-side count of purchase and renewal events from both integrations during migration, to catch double-fires or drops before cutting over fully
  • Consent signal state per session — which consent value (granted, denied, or the new default) is active for ad-user-data and ad-personalisation at the moment analytics events fire, not just at app launch
  • TCF string parse success rate — whether the SDK successfully parses a present TCF consent string versus falling back to the default policy, since a parse failure silently reverts to defaults
  • FirebaseAnalyticsSwift call sites still in use — an inventory of code still calling the deprecated extension APIs ahead of their removal in a future release
  • Renewal and family-sharing entitlement events by source — tagging whether a subscription event originated from a direct purchase, a renewal, or a shared-family entitlement, since StoreKit 2 distinguishes these explicitly where StoreKit 1 often didn’t

Setup Steps

  1. Run StoreKit 1 and StoreKit 2 event paths in parallel for at least one full billing cycle before removing the old integration, logging both to separate event names so revenue reconciliation is possible.
  2. Explicitly set your app’s consent signals rather than relying on the new default policy, so EU consent state reflects your actual CMP output instead of an SDK-level fallback.
  3. Add a check for TCF string presence and parse success at session start, and alert if parse failures spike, since that silently changes what data reaches Firebase.
  4. Migrate FirebaseAnalyticsSwift call sites to the merged FirebaseAnalytics module on a tracked schedule, rather than waiting for the deprecated extension’s removal to force it.
  5. Rebuild subscription and renewal dashboards against StoreKit 2’s entitlement model before fully cutting over, confirming family-sharing and renewal events map to the same downstream revenue metrics as before.

Actionable Insights

The parallel-logging period is the highest-value check here: any divergence between StoreKit 1 and StoreKit 2 purchase counts during the overlap window tells you exactly which event types need remapping before you can trust a single revenue number again. A rising share of sessions on the default consent policy, rather than an explicit signal, is a sign your CMP integration hasn’t kept pace with the SDK update — worth fixing before it affects a larger share of EU traffic than intended. If TCF parse failures are non-trivial, treat every event in that session as running on default consent, since that’s what the SDK is doing silently on your behalf, and factor it into any compliance review rather than assuming full consent-string coverage.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert