Best practices for troubleshooting user conversion failures in third-party callbacks

Last updated 10/05/2026

1. Background

When customers connect and use third-party data callback solutions, they often run into user ID conversion failures. These issues make up a large share of day-to-day support cases and affect both data accuracy and the effectiveness of business decisions. To help internal colleagues and external customers troubleshoot and resolve these issues, we wrote this best practices document, which provides a systematic troubleshooting guide and solutions.

tip

Adjust: Adjust Push API configuration documentation

AppsFlyer: AppsFlyer Push API configuration documentation

SolarEngine: SolarEngine Push API configuration documentation

2. SDK initialization order (important)

warning

The ThinkingData SDK and the third-party SDK must be initialized and their APIs called strictly in the following order. Continue reading only after you've confirmed that your initialization code follows this order

1. Initialize the ThinkingData client SDK
2. Call the automatic or manual integration API to set distinct_id in third-party events (for the code, see the official documentation; it isn't repeated here)
3. Initialize the third-party SDK

3. Problem scenarios

tip

• App version: app_version in the pre-conversion data is the app version. If the pre-conversion data doesn't contain the app_version field, configure the third-party platform to send it back.

• Event name:

  • AppsFlyer: uses event_name in the pre-conversion data as the event name
  • Adjust: the event name is taken in this order of priority: activity_kind (when its value isn't "event") > event_token > event_name
  • SolarEngine: uses event_name in the pre-conversion data as the event name

• Scenario 1:

  • In the same app version, the install event doesn't carry distinct_id, while other events do.

    • How third-party install events are collected:
      • When you use a third-party SDK to track app installs, the install event is the first event the SDK reports automatically after it's initialized. If the user identifier (distinct_id) is set only after the SDK is initialized, the install event can't include that distinct_id, because the install event is triggered before distinct_id is set
    • Cause: the ThinkingData client SDK is initialized after the third-party SDK
    • Solution: initialize the ThinkingData client SDK and call the API that sets did before you initialize the third-party SDK

• Scenario 2:

  • Across app versions, some versions carry distinct_id and others don't.
    • Check whether some

• Scenario 3:

  • The SDK initialization order has been verified as correct, but all the events sent back show user conversion failures.
    • If you use automatic integration with the Android or iOS SDK, you also need to integrate the plugin. Make sure the plugin is integrated: Android plugin integration documentation, iOS plugin integration documentation

• Scenario 4:

  • If all of the above scenarios check out, confirm whether the third-party backend is set up to send the user identification fields back to AE

    • AppsFlyer: make sure that both the Custom Data and Customer User ID fields are selected

    • Adjust: check whether the callback link you configured carries the publisher_parameters={publisher_parameters} parameter. If it doesn't, add it

    • SolarEngine: check whether the callback URL carries the event_custom_params parameter