RENEWAL_DISABLED event triggers when a user has cancelled their subscription via the Store, the subscription remains valid until the next expiration date.
On the subscription anniversary date of a RENEWAL_DISABLED 2 types of events can be triggered
- SUBSCRIPTION_EXPIRED, which is the expected follow-up to a RENEWAL_DISABLED
- RENEWAL_ENABLED which happens if the person has changed their mind in the meantime and cancelled their cancellation via the AppStore
RENEWAL_DISABLED event is very useful to inform of the user lifecycle stage and trigger re-engagement marketing actions to try to get the user back before the end of their subscription. This could be done by offering them a specific discount via a dedicated paywall for example, which you can serve to them via notification/email containing a deeplink.
app_scheme://ply/presentations/PRESENTATION_VENDOR_ID
SUBSCRIPTION_EXPIRED event triggers when the user has lost access to their subscription, and is considered the opposite of PURCHASE_VALIDATED event.
To set-up a subscription expiration date to manage user content access in your back-end, we recommend you follow one of the 2 options:
- Add 24h to `PURCHASE_VALIDATED` or `SUBSCRIPTION_RENEWED` expiration date event property.
This set-up has been selected to cover for any risk of stores server crashing which would mean any all users subscriptions affected in this timeframe would churn.
It also allows to mitigate any risk of lock sync problems between our 2 backends by a small delay in the S2S sent by the stores.
This is also a user-friendly approach, which aims at limiting the risk of frustration from the Subscribers and limiting the risk for Support tickets management
OR Use SUBSCRIPTION_EXPIRED expiration date event property