Firebase Subscription Tracking: Check SDK 6.20.0 First

October 14, 2026

Firebase Subscription Tracking: Check SDK 6.20.0 First

Firebase Subscription Tracking: Check SDK 6.20.0 First

Apptenium cover about Firebase subscription tracking

Firebase and Google Analytics will record your subscription purchases and several lifecycle events automatically, but they will not give you a complete, reconciled picture on their own. The in_app_purchase event captures the initial transaction, yet renewals and cancellations have known gaps once you move into BigQuery. For reliable long-term tracking, pair Firebase with BigQuery export or a dedicated subscription backend, which is exactly the kind of integration we help app teams surface alongside their other performance data at Apptenium.

TL;DR:

  • Automatic purchase collection requires Analytics SDK 6.20.0 or later; StoreKit 2 transactions may need verified manual logging with SDK 12.5.0 or later.
  • BigQuery omits app_store_subscription_renew and app_store_subscription_cancel, although Analytics reports show them, so churn analysis needs lifecycle records from a subscription backend.
  • Choose automatic or manual logging for each event, never both; duplicate purchase records inflate revenue, so reconcile Analytics totals monthly against store reports.
  • Link the Google Play Developer account for Android purchase reports, then verify a sandbox transaction in DebugView before release; BigQuery data may take 48 hours.
  • Enable BigQuery before cohort or finance reconciliation becomes necessary, because exports capture future events only; add a subscription backend when entitlement checks need canonical state.
Apptenium
apptenium.com
Bring App Revenue Into One View
Apptenium integrates Firebase and Google Analytics data with other performance insights, helping app teams make informed decisions about subscriptions.
Explore Apptenium

Table of Contents

How Firebase and Google Analytics collect subscription data

Firebase’s automatic collection handles the first purchase without any extra code. When a user completes a transaction, the Analytics SDK can fire an in_app_purchase event that carries the product ID, product name, currency, and quantity. This event only triggers in app versions that include the Google Analytics for Firebase SDK.

Beyond the initial purchase, Firebase automatically collects subscription lifecycle events on iOS, including:

  • app_store_subscription_renew, logged when an active subscription renews.
  • app_store_subscription_cancel, logged when a user cancels before the next billing cycle.

Automatic in-app purchase collection requires Analytics SDK 6.20.0 or later. If your app targets StoreKit 2, Apple’s newer transaction model changes how receipts are verified, and in many cases you need to call Analytics.logTransaction to log a verified StoreKit 2 transaction manually. Manual logging guidance for StoreKit 2 scenarios points to Analytics SDK 12.5.0 or later for full support, so check your SDK version before assuming full automatic coverage.

An in_app_purchase event can include a product ID, currency, and quantity. These event details help populate the In-app purchases report in Analytics.

Blind spots in Firebase reporting and how BigQuery export closes them

Firebase’s dashboards are convenient for a quick read, but they hide a structural gap: some automatically collected subscription events never make it into your raw data. Specifically, app_store_subscription_renew and app_store_subscription_cancel are not exported to BigQuery, which means any analysis built purely on BigQuery export will miss renewal and cancellation signals that Analytics reports do show on the surface. If your retention or churn modeling depends on raw event rows, this gap matters.

A second, self-inflicted risk shows up when teams mix automatic SDK events with manually logged ones for the same transaction. Logging a purchase twice, once automatically and once through custom code, inflates revenue totals in your reports. The fix is a logging discipline, not a tool:

  • Pick one source of truth per event type, either automatic collection or manual logging, never both for the same transaction.
  • Audit your codebase for duplicate logEvent calls tied to purchase completion.
  • Document which events are automatic and which are manual so new engineers do not reintroduce duplication.

Turning on BigQuery export gives you the raw material to work around the blind spots that remain. Enable it from the Firebase console under Project Settings, and expect initial propagation to take up to 48 hours, with daily syncs after that. Once the data lands, BigQuery exposes unsampled event rows you can query directly, joining user_pseudo_id to subscription lifecycle events or building renewal cohorts over time instead of relying on pre-aggregated dashboard cards.

Pro Tip: Reconcile your GA purchase revenue total against the Play Console or App Store Connect financial reports monthly; a persistent gap usually points to a double-logging bug, not a platform discrepancy.

Using RevenueCat, Stripe, or Purchasely to centralize subscription state

Firebase and BigQuery answer analytics questions well, but they are not built to be your canonical source for who currently has an active subscription. That job belongs in a backend, and three extensions make it straightforward to wire one up.

RevenueCat’s Firebase extension syncs purchase lifecycle events, including trial starts, renewals, cancellations, and billing issues, directly into Firestore, and it can update Authentication custom claims so your app’s entitlement checks stay in sync automatically. It emits named events like initial_purchase and cancellation that your app or analytics pipeline can listen for, which removes a lot of store-specific edge case handling from your own code.

For teams billing through Stripe rather than app store billing, the Stripe Firestore extension follows a similar pattern:

  1. Configure Stripe webhooks for events like customer.subscription.created and invoice.payment_succeeded.
  2. Sync product, pricing, and subscription documents into Cloud Firestore automatically.
  3. Read each user’s current subscription from a subscriptions subcollection tied to their user document.

Purchasely’s Firebase extension follows a comparable webhook and shared-secret setup if you prefer its subscription management layer over building directly on StoreKit or Play Billing. Whichever path you choose, persist the full lifecycle (initial purchase, renewal, cancellation, billing issue) server-side. That record becomes your reconciliation source and keeps your Analytics imports accurate even when the app itself is offline.

Implementation checklist: linking Play, enabling exports, and testing

Treat subscription tracking as a setup you verify once, not something you assume works. Here is the order that catches the most issues:

  1. Confirm your Analytics SDK version meets the 6.20.0 minimum for automatic IAP collection, or 12.5.0+ if you need manual StoreKit 2 logging.
  2. Link your Google Play Developer account to Firebase/Analytics so the in-app purchases report populates for Android.
  3. Enable BigQuery export in Firebase project settings for raw event access.
  4. Decide on single-source logging: automatic or manual, never both, per event type.
  5. Install and configure RevenueCat, Stripe, or Purchasely if you need canonical subscription state.
  6. Secure Firestore rules so users can only read their own subscription documents.
  7. Schedule a DebugView validation pass before shipping.

Mark your core subscription events, like in_app_purchase or a custom renewal event, as key events in Analytics. Doing so lets Google Ads optimize App Campaigns toward users who actually convert to paying subscribers, rather than toward installs alone.

To verify everything end to end, use DebugView and make a sandbox purchase on a test device. Watch for in_app_purchase to appear, then any renewal or cancellation events tied to your test account. After propagation, which can take up to 48 hours for the first export, confirm the raw rows show up in your BigQuery dataset.

Pro Tip: When testing StoreKit 2 transactions, call Analytics.logTransaction only after Apple’s verification succeeds, and remove any legacy manual logging you had in place for StoreKit 1 to avoid counting the same purchase twice.

When built-in reporting is enough versus when to add more

A small app with modest subscriber counts can usually run on Firebase’s default reports and the linked Play Console data alone. The dashboards are fast to read and the in-app purchases report already gives you revenue and purchase counts without any extra engineering.

That calculation changes once recurring revenue, finance reconciliation, or cohort-level renewal analysis enter the picture. At that point, enabling BigQuery export early saves you from reconstructing historical data later, since export only captures events going forward from when you turn it on.

If your product needs canonical subscription state for entitlement checks, or if finance needs purchase records that reconcile cleanly against payment processor reports, a server-side sync through RevenueCat, Stripe, or a similar extension becomes worth the setup cost. Finance teams reconciling purchase data against bank and processor records often need a level of record keeping this payment-data reporting guide describes well, and that need is a good signal you have outgrown dashboard-only tracking. Weigh the ongoing maintenance of a backend extension against the accuracy and ownership you gain from raw, reconciled data.

When built-in reporting is enough versus when to add more — overview diagram

A pragmatic rollout plan for subscription tracking

Start by verifying automatic collection actually works: check your SDK version, link Google Play to Firebase, and confirm events in DebugView before building anything new. Only after that foundation is solid should you enable BigQuery export, and only add an extension like RevenueCat or Stripe once you have a concrete need for entitlement state or finance reconciliation.

This rollout works best as a shared effort. Engineering owns the SDK and logging discipline, analytics owns the BigQuery queries and cohort definitions, and finance should weigh in early on what reconciliation actually requires, since retrofitting their requirements after launch costs more than asking up front.

— Mike

How Apptenium brings subscription revenue into one view

Once your Firebase and BigQuery setup is solid, the next challenge is making sense of subscription revenue alongside everything else driving your app’s growth. We built Apptenium to pull downloads, subscription revenue, and ad monetization into one dashboard next to the keyword and listing data that drives those installs in the first place.

Apptenium

Instead of switching between Firebase, your ASO tools, and ad network dashboards, we bring your performance data together in one place alongside your ASO data.

Check our pricing page to compare the Free and Pro plans and see which fits your team’s reporting needs.

FAQ

What events does Firebase automatically track for subscriptions?

Firebase automatically collects the in_app_purchase event for the initial purchase, along with app_store_subscription_renew and app_store_subscription_cancel for iOS subscription lifecycle changes. These require the Analytics SDK to be present in the app version making the purchase.

Why don’t my renewal events show up in BigQuery?

Certain automatically collected events, including app_store_subscription_renew and app_store_subscription_cancel, are not exported to BigQuery even though they appear in standard Analytics reports. For complete renewal data in your raw export, you typically need a server-side integration like RevenueCat or Stripe syncing lifecycle events into Firestore.

Yes, you need to link your Google Play Developer account to your Firebase or Analytics project for the in-app purchases report to populate on Android. Without that link, purchase and subscription revenue metrics will not aggregate correctly in your reports.

How long does it take for BigQuery export data to appear?

Initial propagation after enabling BigQuery export can take up to 48 hours, after which Firebase sets up daily syncs automatically. There is no charge for the export itself, though standard BigQuery pricing applies to storage and queries.

Can a tool combine my subscription data with ASO metrics?

Our platform at Apptenium integrates Firebase and Google Analytics data to show subscription revenue alongside keyword rankings, competitor signals, and ad monetization in one dashboard. Plans are available on the pricing page, including a Free tier and a Pro plan at $9.99 per month.

Sources

← Back to Guides · Home