App store subscription events
When a Firebase/GA4 app project is linked to the Apple App Store or Google Play, the stores can report subscription lifecycle events — purchases, renewals, cancellations, refunds — into analytics. These app-store subscription events let you analyse recurring revenue alongside in-app behaviour. They originate from the store, not your client SDK, so their availability and naming depend on the platform's own documentation.
Where these events come from
Apple and Google can surface subscription lifecycle data into a linked analytics project rather than requiring you to instrument every renewal in the app. That means events for initial purchase, renewal, cancellation, grace period, and refund may appear from the store integration. Because the data model is the store's, consult Apple's App Store and Google Play developer documentation for exactly which states are reported.
Why analyse them in context
Subscription revenue is recurring, so understanding it means joining store-reported lifecycle events with in-app engagement: which features retained subscribers, where churn clusters, how trials convert. Keep the analysis aggregate and posture-neutral — this is about modelling recurring revenue, not ranking platforms. The exact event availability differs by store, so verify against the platform's own docs rather than assuming parity.
- Events originate from the store link, not the client SDK
- Cover purchase, renewal, cancellation, refund states
- Availability and naming follow each store's docs
How it appears in analytics and logs
Subscription events present in analytics but absent from your client logs are expected — they come from the store link, not the app SDK, so check the linkage if they are missing.
Diagnostic use case
Analyse subscription renewals, cancellations, and refunds against in-app engagement by relying on store-reported subscription events linked into your GA4 app property.
What WebmasterID can help detect
WebmasterID focuses on first-party web signals; app-store subscription events are a mobile/store-side concept covered here for completeness and comparison.
Common mistakes
- Expecting store subscription events to appear in client SDK logs.
- Assuming identical event coverage across Apple and Google.
- Treating linked data as if it carried user identity in analytics.
Privacy and accuracy notes
Store-reported subscription events carry transaction context, not personal identity in analytics. Keep linked data aggregate and follow each store's own data-use rules; this is educational, not legal advice.
Related pages
- The in_app_purchase event
in_app_purchase is an automatically collected GA4 event on mobile apps that fires when a user completes a purchase through the App Store or Google Play. It captures the product id, price, currency, and quantity from the store, giving app monetization reporting without manual instrumentation. It is the app-store analogue of the web purchase event, and like it, records the transaction, not the buyer.
- In-app message events
In-app message events record how users interact with messages shown inside an app — impressions, dismissals, and action clicks from an in-app messaging campaign. In the Firebase/GA4 model these arrive as automatically collected events when in-app messaging is in use. They let you measure whether on-device prompts drive the action you intended, distinct from push notifications delivered outside the app.
- The purchase event and e-commerce
The purchase event records a completed transaction and anchors all e-commerce reporting: revenue, items, and conversion value. It carries a transaction id, a value and currency, and an items array describing what was bought. The discipline is to record the order, not the customer — product and revenue data belong in the event, personal identity does not.
- Event Explorer
Explore lifecycle events, web or app.
Sources and verification notes
- Google Analytics Help — Subscription events (Play/App Store linking)Automatically collected and store-linked app events.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.