[Legacy] Subscription attribution—Server-to-server events

For:
Marketers Developers
Last update:

At a glance: Implement server-to-server events to record subscriptions (new and renewed) and send subscription events to AppsFlyer as necessary. Note: This is a legacy feature. Learn more about the new, fully automatic, and improved subscription revenue mechanism.

Server-to-server subscription event

To implement server-to-server events, you need to design backend logic. The backend logic keeps track of subscriptions (new and renewed) and sends subscription events to AppsFlyer as necessary.

Sending server-to-server events to AppsFlyer for subscription notifications

AppsFlyer by default doesn't receive notifications of renewal or subscription events from the app stores. This section discusses how to set up a connection to the respective app store and pass subscription information to AppsFlyer as a server-to-server event.

Android iOS

Managing subscriptions on Android can be done on the App and Server levels. On the App level, communication is done through Google Play Billing Library. On the Server level while it is done through Google Play Developer API. The recommended way for managing subscriptions is through Google Play Developer API. This is the way that is discussed in this article.

Step 1: Set up the server endpoint to receive subscription-related notifications

Create a server endpoint that receives subscription-related notifications from Google Cloud. Then, enable real-time developer notifications:

  1. Determine a URL endpoint on your server to use for subscription status updates. For example, https://myserver/subscription-notifications.
  2. Set up Cloud Pub/Sub in your Google Cloud Platform (GCP) project.
  3. Enable real-time developer notifications for your Android app.

Step 2: Handle real-time subscription notifications

Once you set up a server endpoint to receive notifications, write the logic to handle these notifications. By default, Google sends notifications through Pub/Sub with subscriptionId and purchaseToken. The notification message doesn't contain any relevant information about the actual subscription. You need to take the purchase token and send a request to the Google Play Developer API to purchases.subscriptions. 

The subscription notification contains the following:

{
	"version": string,
	"packageName": string,
	"eventTimeMillis": 1578509686,
	"subscriptionNotification": SubscriptionNotification,
	"testNotification": AppsFlyerTest
}

In the subscription notification, there's an object called SubscriptionNotification. It contains the following.

{
	"version": 1.0,
	"notificationType": 4,
	"purchaseToken": 0f43308f-bf3f-4fa1-8aef-d515c941334b,
	"subscriptionId": 123456789
}

purchaseToken is the token that you send to Google Play Developer API to purchases.subscriptions get data about the subscription.

The subscriptionId is the value you store into your database and associate it with the AppsFlyer ID.

Step 3: Associate subscription with Appsflyer ID and GAID in your database

Once you get the data about the subscription, you need to set up a link between the subscription ID and the AppsFlyer ID and GAID. The AppsFlyer ID is mandatory for sending server-to-server events to AppsFlyer. We strongly recommend including the GAID  when sending a server-to-server event. Including it allows AppsFlyer to send event postbacks to SRNs (self-reporting networks). It also opens for you the option to use AppsFlyer Audiences. You can get the AppsFlyer ID and GAID in one of the following ways:

The complete Android subscription attribution flow

See the following flowchart for the complete subscription attribution flow:

google-play-server-notifications-flow.png

 

Sending the event to AppsFlyer

At this point, you have knowledge of a subscription status change (purchase, renewal, cancellation) and have associated it with an AppsFlyer ID. Now, make sure the following takes place:

  1. Your server gathers the necessary data for the event. Such data should include the following: revenue, subscription type, subscription ID (item_id in the data from Apple), AppsFlyer ID, time of renewal. Recommended mapping (see the code snippet below):
    • af_revenue: revenue
    • af_content_type: subscription type
    • af_content_id: subscription ID (item_id in the data from Apple)
    • renewal: true/false (based on subscription status change)
    • eventTime: the time the notification reaches your server
  2. Based on the type of event (purchase, renewal, cancellation), the server sends the event to AppsFlyer as a subscription event with all related data.

Formatting and sending the event

Subscription event request example:

HTTP POST https://api2.appsflyer.com/inappevent/<APP_ID>
HTTP/1.1
headers:
{
  authentication: '<YOUR_DEV_KEY>',
  Host: 'api2.appsflyer.com',
  Accept: 'application/json',
  'Content-Type': 'application/json'
}
body: 
{
  "appsflyer_id":"<APPS_FLYER_ID>",
  "customer_user_id":"123456",
  "eventName":"af_subscribe",
  "eventValue":"{\"af_revenue\":\"200\",\"af_content_id\":\"092\", \"af_content_type\": \"123\", \"renewal\":\"true\"}",
  "eventCurrency":"USD",
  "ip":"1.0.0.0",
  "eventTime":"2018-07-09 4:17:00.000",
  "af_events_api":"true"
}

To learn how to format and send the event to AppsFlyer, see sending server-to-server events.