Skip to main content

Client SDK FAQ

Last updated 10/03/2026

What is the reporting strategy of the client SDKs?​

Data from native client SDKs (including Unity, Unreal, Flutter, and others) is first cached in a local database, and data reporting is triggered in the following cases:

  • The app goes to the background
  • Every 30 seconds (configurable in AE)
  • The cached data exceeds 30 records (configurable in AE)
  • The flush API is called explicitly

The mini program, mini game, and JavaScript SDKs report data in real time by default. If batch mode is enabled, data is cached locally first and then reported.

How is the device ID determined?​

Native client SDKs (including Unity, Unreal, Flutter, and others) determine the device ID as follows:

  • Android: Uses the Android ID

On systems earlier than Android 8.0, the Android ID is a unique device identifier. It changes only when the device is reflashed or reset to factory settings, and it is shared by all apps. On Android 8.0 and later, each combination of app signing key, user, and device has a unique ANDROID_ID value. As a result, apps that run on the same device but have different signing keys no longer see the same Android ID (even for the same user). One special case: if a user installed the app on a device running a version earlier than 8.0, uninstalled it later, upgraded to 8.0 or later, and then reinstalled the app, the Android ID differs from the previous one; if the app is not reinstalled, the Android ID does not change.

  • iOS: The IDFV is used first; if it cannot be obtained, a random UUID is used. The device ID obtained the first time is stored in the keychain and never changes, even if the IDFV changes later.

Mini program, mini game, and JavaScript APIs cannot obtain a similar device identifier, so a randomly generated ID is used as the device ID. If the user clears the cache, the device ID changes.

What are the minimum system versions supported by the client SDKs?​

The minimum versions supported by the client SDKs are Android 4.0 and iOS 8.0

How do I troubleshoot reporting issues?​

Most issues can be located quickly through client logs. Each integration guide describes how to enable client logs.

On Android, you can enable client logs by calling the enableTrackLog API. You can filter the Android SDK logs by ThinkingData.

TDAnalytics.enableTrackLog(true);

On iOS, you can enable log printing by calling the setLogLevel API, and filter the iOS SDK logs by THINKING.

[TDAnalytics setLogLevel:TDLoggingLevelDebug]

After you enable logging, you can send the logs to our technical support engineers to help locate the issue.

If you are not sure whether the reporting URL is correct, you can use the health check API to check whether the reporting URL is reachable. Visit https://YOUR_RECEIVER_URL/health-check. If the page returns ok, the receiver URL is configured correctly.

In addition, you can use the features of the Tracking Plan module to easily locate issues in data reporting.

What should I note when reporting data through the Unity SDK?​

  1. Our SDK is initialized in Awake(), so calls cannot be triggered in Awake
  2. By default, all APIs can be called only on the main thread.
  3. We use the component lifecycle of the Android system to determine whether the app enters the foreground or goes to the background. However, Unity cannot guarantee that the SDK is initialized at the very start of the program, so the first launch event may be detected only when the app goes to the background. Currently, we add a ta_app_start event the first time the app goes to the background (it is reported slightly late, but its Event Time #event_time is correct and does not affect later analysis)

What do crash events include, and how do I collect them?​

The client SDKs support collecting some crash logs. After you initialize the SDK, enable automatic collection of APP Crash events. The event name of crash events is ta_app_crash.

Crash event collection is triggered in the following cases:

  • Android: An uncaught exception occurs in the virtual machine

  • iOS:

    • Unix signal exceptions, including: SIGABRT, SIGILL, SIGSEGV, SIGFPE, SIGBUS
    • NSException exceptions

  • Collection of C# exceptions in the Unity engine

Was this page helpful?
On this page