App SDK FAQ

The Published Apps section and the App Scanner accept the Bundle ID value for iOS and the Package ID value for Android.

A typical ID for both stores looks as follows: com.mycompany.myiosapp.

This is how you can quickly locate these values:

• Android: The Google Play Store posts the Package ID in the Store link to your app. For example, https://play.google.com/store/apps/details?id=com.google.android.apps.docs.editors.sheets&hl=en&gl=US

• iOS: Locate the Bundle ID through the Apple Store Connect interface, as Apple's App Store does not disclose the Bundle ID. The Bundle ID can be found under General > App Information.
  

  

  
  

There are several different types of services that Usercentrics differentiates between.

• TCF Vendors are vendors that are registered with IAB. The complete current vendor list can be found on IAB’s website.

• Google Ad Technology Providers are vendors who work with Google alongside the TCF framework, but are themselves not yet part of TCF framework.

• Data Processing Services are any services that may require end user consent, but are not categorized as either of the above.

Reviewing the services your application or game is using and identifying which category the services or vendors you are working with is crucial to the correct implementation.

If you don’t already use the App Scanner to identify the SDKs that are currently installed in your app or game, ensure to review the scan results and categorize the service suggestions according to your requirements.

What is a DAU?

A Daily Active User (DAU) represents one unique device that interacts with your app at least once during a calendar day.

Usercentrics counts a DAU when the Usercentrics SDK initializes on a device. This can happen when the app is opened or when the operating system wakes the app in the background.

How Usercentrics Counts DAU

• One count per device per day:
  Usercentrics counts a DAU the moment the SDK initializes on a device.
  Initialization can happen when the app is:

  • Opened (user launches it)

  • Resumed (the app was in the background and the user comes back to it)

  • Woken by the system (the operating system briefly starts the app to handle things like notifications or background tasks).

• Daily window (UTC)
  DAU is calculated based on calendar days, meaning UTC time 00:00:00 to 23:59:59 UTC. If the SDK initializes before and after this window boundary (e.g., 23:58 and 00:02 UTC), the device is counted once for each day.

• Deduplication mechanism
  To avoid multiple counts, the SDK stores the last day the device was counted. If another initialization happens on the same day, Usercentrics ignores it.

What is ADAU?

ADAU (Average Daily Active Users) represents the average number of DAUs your app has during a month.

Formula:

ADAU = (DAU Day 1 + DAU Day 2 + … + DAU Day n) / number of days in the month

Usercentrics uses monthly ADAU as the basis for pricing.

Why use an average?

Daily usage naturally fluctuates depending on the nature of the app.
Using an average ensures pricing reflects real usage patterns without penalizing spikes.

Examples:

• A football app may see high activity only on match days.

• A shopping app may peak during sales or holiday periods.

ADAU smooths these variations to give a fair and stable view of app activity.

When a device might be counted twice

There is one valid exception where a device may be counted more than once on the same day:

• User manually clears app data
  Clearing data removes the stored timestamp used for deduplication. The next initialization is treated as a new device state and results in another DAU count on the same day.

• Session restore
  A session is restored when the app automatically deletes or rebuilds its local storage.
  This can happen if the user reinstalls the app, the app restores a backup, or the app resets its own data. In these cases, the SDK timestamp is removed, and the next initialization may be counted as another DAU on the same day.

This behavior is expected, as the SDK cannot identify the device once its data has been erased.

Why DAU can differ between iOS and Android

The two platforms behave differently when handling background events. This affects how often the SDK initializes, and therefore how often a device can be counted (with deduplication still preventing overcounting within a day).

Conclusion

• On iOS, SDK initialization usually reflects real user activity.

• On Android, SDK initialization can also happen due to system-triggered background events.

• Deduplication ensures only one DAU per day, but these differences affect when the first initialization happens.

SDK Initialization best practices

• Android
  We recommend to initialize the SDK in Application.onCreate() to ensure consent is ready before any background processing. These initializations come from a technical compliance standpoint (consent must be ready if background data processed). Background triggers may still cause initialization, but deduplication prevents multiple counts per day.

• iOS
  We recommend to initialize the SDK in AppDelegate. iOS limits background starts, so SDK initialization usually aligns with actual user activity.

Certain types of user interaction with the banner are not considered a user interaction and will generate a NO_INTERACTION or Ignore-type event.

• Android:

  • Pressing the system back button (if enabled) *

  • Pressing X in second layer (if enabled) *

  • Closing the app without interacting with the banner

• iOS:

  • Pressing X in second layer (if enabled) *

  • Closing the app without interacting with the banner

* Programmatic customization only

Daily Active Users (DAU) is the measurement of the number of users who are active on an app each day. DAU is calculated based on the number of unique mobile users who had at least one active session in a 24-hour time frame.

Average Daily Active Users per month (ADAU per month)  is (DAU Day 1 + DAU Day 2 + … DAU Day n.) / number of days in the month)

Pricing is based on monthly Average Daily Active Users (ADAU)

Why use an average?

This formula enables to take into account variations in DAU for each app. This protects a non-linear usage of an app due to the nature of its business.

Example: Football results that get checked by customers only on match days, or shopping apps that experience an increased usage during sales.

What is a session?

Apps uses the same session definition as Usercentrics Web CMP, with a difference in how often a session is called:

• Web: every 30 min

• Apps: every 24 hours

To comply with the TCF policies, the first layer of the CMP banner must be transparent about which purposes, special purposes, features and special features. These values are populated automatically based on the TCF vendors that are selected in the Global Vendor List.

Working with Stacks is a TCF-compliant way to consolidate certain purposes on the first layer into one selector with pre-defined text approved by the TCF policies.

This feature can be configured in the Admin Interface under Services > Global Vendor List.

The latest version of the TCF policies, and the overview of all available stacks can be reviewed here.

The App SDK does not display the language icon on the first layer on mobile. Instead, it relies on the Language Hierarchy.

You can set the default initialization to a specific language if the language specified exists, is supported, and has been added as a visible language in the Admin Interface.

The capability of restoring user sessions depends on the following:

• It’s a Premium-only feature.

• It is not enabled by default for new configurations.

If you are interested in using this feature, get in touch with your CSM, as it needs to be enabled.

Please note, that this feature is not supported for US frameworks.