Appsflyer | Documentation

About AppsFlyer

AppsFlyer is a leading mobile marketing analytics and attribution platform. It enables businesses to accurately measure campaign performance across channels, attribute user acquisitions to specific marketing efforts, and optimize strategies through AI-powered insights, all while maintaining privacy compliance.

With strengths in large-scale data processing, robust fraud protection, and a wide range of platform integrations, AppsFlyer serves as an essential tool in today's fragmented digital landscape, helping marketers transform complex data into clear, actionable decisions that drive growth and enhance customer engagement.

About the integration

Transform your mobile marketing strategy with PA Connect AppsFlyer. This integration creates a unified data ecosystem that bridges mobile attribution with comprehensive user analytics, enabling you to make data-driven decisions across the entire customer journey. By connecting Piano Analytics' advanced segmentation capabilities with AppsFlyer's attribution platform, you eliminate data silos and unlock deeper insight into user acquisition and engagement.

Track complete user journeys from initial campaign interaction through app installation and beyond. Use AppsFlyer's attribution data to understand which marketing channels drive the highest-value users, while using Piano Analytics' behavioral insights to optimize post-install engagement strategies. Access unified reporting that combines acquisition metrics with detailed user behavior analysis, so you can measure true campaign ROI and lifetime value across every touchpoint.

There are two ways to feed events into the connector, depending on how the app sends data to AppsFlyer.

Prerequisites

Before configuring either method, make sure the following are present in your Piano Analytics Data Model:

Events:
- app.install (default event)
- app.reengage (⚠️ custom event to declare)
- app.reattribute (⚠️ custom event to declare) if re-engagement and re-attribution tracking is required
Property:
- appsflyer_user_id (⚠️ custom property to declare: scope = event, data type = string, and we recommend that you add the flag “contains personal data”)

Integration methods

Method A: with the AppsFlyer SDK (client-side). The app embeds the AppsFlyer SDK. This is the standard implementation described in most AppsFlyer documentation.
Method B: without the AppsFlyer SDK (server-side, S2S). The app or backend sends events to AppsFlyer through the Server-to-Server (S2S) Events API instead of the SDK. Use this when the setup is fully server-side and the AppsFlyer SDK cannot be embedded.

In both methods, AppsFlyer produces the same Piano postback (see "The Piano postback" below). Only the way the event enters AppsFlyer differs.

Partner identification in AppsFlyer

The Piano Analytics partner ID (PID) in AppsFlyer is atinternet_int. It receives install and in-app event postback data, allowing Piano Analytics to capture user acquisition and re-engagement activity from mobile apps.

To activate the connector, locate and activate atinternet_int in the AppsFlyer partner configuration and enable the relevant postbacks. This step is required for both Method A and Method B.

Visitor ID mapping

For events sent by AppsFlyer to be associated with existing Piano Analytics sessions, the Piano visitor ID must be included in every postback as the idclient URL parameter.

Without the idclient parameter, events received from AppsFlyer cannot be matched to any visitor session in Piano Analytics. The data will appear as traffic with no connection to existing user journeys.

How the Piano visitor ID reaches AppsFlyer depends on the integration method, described below.

Implementing Method A: with the AppsFlyer SDK

Retrieve the Piano visitor ID using the Piano Analytics SDK's getVisitorId method on the mobile app. See Visitor identification for the syntax on each platform (Android, iOS, Flutter).
Push this value to AppsFlyer using the setAdditionalData SDK method, under the key pianoVisitorId. AppsFlyer automatically injects this value into the postback URL via the {pianoVisitorId} placeholder.

Example: if the Piano visitor ID is abc-123-def, the app must call:

AppsFlyer.setAdditionalData({"pianoVisitorId": "abc-123-def"})

AppsFlyer then sends the postback to:

https://<domain>/event?s=<site_id>&idclient=abc-123-def

(Optional) Set the Customer User ID via the AppsFlyer SDK if cross-platform tracking with appsflyer_user_id is needed.
In the AppsFlyer UI, locate the partner atinternet_int and enable the install postback.
Enable the event postback as well if re-engagement and re-attribution tracking is required.

With the SDK in place, AppsFlyer automatically fires the postback whenever an install or in-app event occurs, transforming it into the corresponding Piano event.

Implementing Method B: without the AppsFlyer SDK (server-side, S2S)

Before sending the S2S payload, make sure your backend has the Piano visitor ID for this user.

When there is no AppsFlyer SDK, the Piano visitor ID is passed inside the custom_data field of the S2S payload, as a JSON-encoded string under the key pianoVisitorId. AppsFlyer uses this value to populate the {pianoVisitorId} placeholder (the idclient parameter) in the Piano postback.

S2S API endpoint

POST https://api2.appsflyer.com/inappevent/{app-id}

Payload

For the Piano postback to fire correctly with all required fields populated, the S2S payload must include:

JSON

{
  "appsflyer_id": "<appsflyer_device_id>",
  "customer_user_id": "<user_id>",
  "eventName": "app.install",
  "eventTime": "2024-01-15 10:30:00.000",
  "eventValue": "{}",
  "custom_data": "{\"pianoVisitorId\": \"<piano_visitor_id>\", \"appUserId\": \"<app_user_id>\"}"
}

Field mapping and notes

S2S field	Role
`custom_data`	Must include `pianoVisitorId` as a JSON-encoded string. This is what populates the `idclient` parameter in the Piano postback URL.
`customer_user_id`	Maps to `appsflyer_user_id` in the Piano postback body.
`eventName`	Controls the event name sent to Piano.
`appsflyer_id`	The AppsFlyer device ID.
`eventTime` / `eventValue`	Standard S2S fields (event timestamp and value).

Important:

Re-attribution and re-engagement (app.reattribute, app.reengage) are set automatically by AppsFlyer based on its attribution logic. You don’t need to send them explicitly.
src_creation and src_campaign are populated by AppsFlyer from the attribution record, you don’t need to send them.
The atinternet_int integration must be active and the postbacks enabled in the AppsFlyer UI, exactly as in Method A.

Reference: AppsFlyer Server-to-server events API for mobile (S2S).

The Piano postback

AppsFlyer sends data to Piano Analytics through HTTP postbacks. There are two postback types, install and event, each consisting of a URL and a JSON body.

Since atinternet_int is an Analytics Partner account, the postback templates are managed on the AppsFlyer side. This output is identical whether the event was collected via the SDK (Method A) or via the S2S API (Method B).

First install

Triggered when a user installs the app and launches it for the first time.

URL:

https://$$dashboard(domain)/event?s=$$dashboard(site_property_id)&idclient={pianoVisitorId}

Body:

JSON

{
  "events": [
    {
      "name": "app.install",
      "data": {
        "appsflyer_user_id": "$$sdk(af_customer_user_id)",
        "src_creation": "$$sdk(promoter-id)",
        "src_campaign": "$$sdk(af_c_id)",
        "src_medium": "appsflyer",
        "src_force": true
      }
    }
  ]
}

Re-engagement and re-attribution

URL:

https://$$dashboard(domain)/event?s=$$dashboard(site_property_id)&idclient={pianoVisitorId}

Body for re-engagement (triggered when the user returns to the app via a marketing touchpoint, after the first install):

JSON

{
  "events": [
    {
      "name": "app.reengage",
      "data": {
        "appsflyer_user_id": "$$sdk(af_customer_user_id)",
        "src_creation": "$$sdk(promoter-id)",
        "src_campaign": "$$sdk(af_c_id)",
        "src_medium": "appsflyer",
        "src_force": true
      }
    }
  ]
}

Body for re-attribution (triggered when the user reinstalls the app after uninstalling it):

JSON

{
  "events": [
    {
      "name": "app.reattribute",
      "data": {
        "appsflyer_user_id": "$$sdk(af_customer_user_id)",
        "src_creation": "$$sdk(promoter-id)",
        "src_campaign": "$$sdk(af_c_id)",
        "src_medium": "appsflyer",
        "src_force": true
      }
    }
  ]
}

Postback properties

Each postback body includes source attribution properties prefixed with src_, plus appsflyer_user_id for cross-platform reconciliation:

Property	Value	Description
`src_creation`	`$$sdk(promoter-id)`	The publisher or ad network that drove the install.
`src_campaign`	`$$sdk(af_c_id)`	The campaign ID from AppsFlyer.
`src_medium`	`appsflyer`	Fixed value identifying AppsFlyer as the attribution source.
`src_force`	`true`	Forces Piano Analytics to override any existing source attribution.
`appsflyer_user_id`	`$$sdk(af_customer_user_id)` (Method A) / `customer_user_id` (Method B)	The AppsFlyer Customer User ID (CUID), set by the advertiser. Useful for cross-platform reconciliation between AppsFlyer and Piano Analytics. Optional.

src_force means the most recent AppsFlyer source overrides the current session source: the whole visit inherits the acquisition source. If several touchpoints occur within the same visit, the last one wins on the Piano side (raw data in AppsFlyer keeps all touchpoints).

Reporting in Piano Analytics

Once the connector is active, your AppsFlyer data is available in Piano Analytics alongside the rest of your app data. You can link the marketing sources that drive your installs to what users do in the app afterwards.

Build your own analyses

You can use the events and properties sent by AppsFlyer in Data Query and in your boards like any other data:

Events: app.install, app.reengage, and app.reattribute, to count installs, re-engagements, and reinstalls.
Source properties: src_creation (the publisher or ad network), src_campaign (the AppsFlyer campaign ID), and src_medium.

For example, split app.install by src_campaign to see which campaigns bring the most installs. Then compare how users from each campaign engage with the app afterwards, to find the campaigns that bring users who stay active rather than those who only install.

Out-of-the-box board

If you'd rather not build your analyses from scratch, Piano can provide a ready-to-use board for your AppsFlyer data. To get it, contact the support center.

Troubleshooting

Once configured, trigger a test event and confirm that it appears in Piano Analytics with the correct visitor ID and source attribution. If something looks wrong, check the following common issues.

Events appear but are not linked to any visitor session

The idclient parameter is missing or empty.

Method A: verify that the Piano visitor ID is correctly retrieved and pushed to AppsFlyer via setAdditionalData.
Method B: verify that pianoVisitorId is present in custom_data as a JSON-encoded string.

No events received at all

Confirm that the install postback is enabled in the AppsFlyer UI for the atinternet_int partner.
Verify that the Piano Analytics site ID ($$dashboard(site_property_id)) and collection domain ($$dashboard(domain)) are correctly configured in the AppsFlyer dashboard.
Method B: confirm that events are being accepted by the S2S endpoint for the correct {app-id}.

Last updated: October 08, 2026