Migrating In-App Subscriptions

How to integrate Qonversion with existing subscriber base

When you integrate Qonversion into your app with an existing subscriber base, it is important to migrate your subscribed users access management and import your historical transactions to get accurate historical analytics data.

Below you can find a simple step-by-step guide on how to migrate to Qonversion for both Analytics and Subscription management modes.

Additionally, you can book a demo call where we can discuss all the related details.

Migration process overview

There are two mutually reinforcing types of data migration: client-side and server-side. Since both have pros and cons, we recommend following both of them to get accurate data in your Qonversion dashboard.

Client-side vs Server-side migration

Client-side and Server-side are mutually reinforcing migration types, and here you can find why:

Client-side migrationServer-side migration
Historical revenue data depthTransactions for Google Play are restored with limited accuracy.Restores all the transactions.
Historical revenue data qualityAnalytics properties like country, device OS, app version, and others are added automatically.Analytics properties like country, device OS, app version, and others need to be provided from your side.
New revenue dataTracks only users who installed the app with Qonversion SDK integrated.Tracks all the subscriptions active for the moment of data migration (but not new ones).
Grant subscribers premium access for cross-platform applicationsQonversion grants users an entitlement after launching the app only on the platform where the subscription was purchased.Qonversion provides entitlements independently of the platform right after the app launches.
How to launch?As easy as it sounds, add an additional line of code to your appNeeds resources allocation from your side: prepare a file with all the historical Base64 encoded receipt data for AppStore or purchase tokens for GooglePlay

Recommended migration approach

To leverage all the pros of both migration types, we recommend the following approach:

Client-side migration

Let's start with client-side migration:

  1. Integrate Qonversion SDK to track analytics and entitlements for your new subscribers using our quick start guide.
  2. Сall the syncHistoricalData method right after Qonversion SDK initialization to synchronize all the device-related data and ensure that none of the entitlements has been missed.
  3. Launch your app update to production.
  4. After the steps above, you will process new purchases with Qonversion, while your subscribers with the previous app version will continue tracking throughout your system.

Server-side migration

Once you have the app version with Qonversion SDK up and running, it's time to proceed to the server-side migration.

  1. Prepare files with AppStore with Base64 encoded receipt data or Google Play with purchase tokens.
    1. If you do not have receipt data or purchase tokens on your side but are already running your subscription management with a third-party vendor, you should ask the vendor’s support team for the required data file.
    2. Additionally, but not necessarily, to keep your historical data granular, provide us with such user attributes as Country, IDFV, IDFA, GAID, AAID, etc..
  2. Then simply share the files with us using our support chat or book a demo call to discuss all the related details. Additionally, you can also contact us using email and provide CSV files for iOS or Android.

👍

Congratulations! After accomplishing the steps above, you will have accurate data and relevant entitlements for all of your users in Qonversion.

Migration details

Every migration step has its own vital details:

Entitlements (Premium access) migration

Ensure you have configured Entitlements and Products before you start users' entitlements migration process, so Qonversion can determine what entitlements should be granted to a user based on product ID of the purchased product.

SDK's syncHistoricalData() method

Calling the syncHistoricalData method on each app launch is safe. We have extra checks for such cases, so no additional logic is required.

Qonversion.shared().syncHistoricalData()
[[Qonversion sharedInstance] syncHistoricalData];
Qonversion.getSharedInstance().syncHistoricalData();
Qonversion.shared.syncHistoricalData()
Qonversion.getSharedInstance().syncHistoricalData();
Qonversion.getSharedInstance().syncHistoricalData();
Qonversion.GetSharedInstance().SyncHistoricalData();
Qonversion.getSharedInstance().syncHistoricalData();

App Store data migration file

There are several required fields in the file for App Store transactions import:

FieldRequiredDescription
user_idyesYour-side user identifier
receiptyesThe Base64 encoded receipt data.
product_idyesThe unique identifier of the product purchased.
original_idyesThe transaction identifier of the original purchase. See the details here: original_transaction_id
priceyesexample: 12.99
currencyyes

Google Play data migration file

There are several required fields in the file for Google Play transactions import:

FieldRequiredDescription
user_idyesYour-side user identifier
purchase_tokenyesThe Base64 encoded receipt data.
product_idyesThe unique identifier of the product purchased.
original_idyesThe original transaction ID, see the details here: orderId for Google

Additional user-related fields for analytics

For more granular analytics, we also encourage you to provide us with the following data:

FieldRequiredDescription
user_idyesYour-side user identifier
idfvnoiOS Only
idfanoiOS Only
gaidnoAndroid Only
aaidnoAndroid Only
countryno
modelno
os_versionno