How To Integrate Mobile App Data With A CDP

Integrating mobile app data with a CDP connects the most behaviorally rich data source in consumer-facing enterprise software with the customer intelligence layer that makes that behavioral data actionable across channels.

Mobile apps generate signals no other channel captures with the same depth: screen sequences, time spent per screen, in-app search, feature engagement, notification opens and dismissals, session frequency, app version behavior, and the moment when a user moves from anonymous browsing to authenticated activity.

That last point is the defining challenge.

Mobile app data arrives in the CDP across two identity states. Before a user authenticates, the mobile SDK tracks behavior under an anonymous device-generated identifier. After the user logs in, signs up, or resumes an authenticated session, the app can associate behavior with a known user_id.

Those events belong to the same person. But the CDP will not know that unless the integration explicitly stitches the anonymous device profile to the authenticated user profile at the moment of authentication.

That is why mobile app CDP integration is not primarily an SDK installation project. Installing the SDK is the easier part. The harder design decisions are:

• When to call .identify(user_id)
• When to call .reset()
• How long to retain anonymous device events
• How to handle app reinstalls
• How to manage push tokens
• How to design for IDFA and AAID absence
• Which events must be instrumented before the first app release

If those decisions are wrong, the CDP’s mobile profile becomes permanently fragmented. Pre-login behavior stays attached to an anonymous device profile. Post-login behavior appears on the authenticated profile. Returning sessions may generate new anonymous histories that never merge. Push tokens may sit on device records instead of the unified customer profile.

A strong mobile app CDP integration prevents that fragmentation before the first SDK release ships.

Why Mobile App Data Is Different From Other CDP Sources

Most CDP source systems arrive with a known or semi-known identifier.

A CRM has a contact ID. A loyalty platform has a member ID. A marketing automation platform has an email address. A POS transaction may have a loyalty scan, phone number, or payment token. A data warehouse may already contain modeled customer IDs.

Mobile is different.

Mobile Starts Anonymous By Default

When a user first opens the app, the CDP SDK typically generates a device_id, which is a locally stored anonymous identifier for that app installation. That device_id is not a person. It is a device-level installation that may eventually belong to a person if the user authenticates.

The CDP receives valuable behavioral signals from the first app session, but those events are anonymous until the identity stitch occurs.

Authentication Changes The Identity State

When the user signs up, logs in, or restores a session from a stored authentication token, the app now knows the user_id. The mobile integration must call .identify(user_id) at that moment.

That call tells the CDP that the anonymous device_id and the authenticated user_id represent the same person. The CDP can then attach the pre-login behavior to the known customer profile.

Mobile Has Platform Governance Constraints

Mobile also has identifier and permission constraints that web, CRM, POS, and loyalty integrations do not have.

Apple’s App Tracking Transparency framework requires explicit opt-in before IDFA access. Android advertising identifiers are user-resettable and increasingly constrained. Push notification permission must be granted before a device can receive push messages. App store release cycles make tracking changes slower than web analytics changes.

That means the integration must be designed before implementation, not corrected casually after launch.

The Mobile Identifier Landscape For CDP Integration

A mobile CDP integration needs a clear identifier strategy. The CDP identity graph should know what each identifier means, when it is available, and what role it plays.

User ID

The user_id is the authenticated customer identifier from the brand’s own system. It may also be called customer_id, external_id, or account ID.

It is available only when the user is authenticated. It is not available for anonymous sessions, guest browsing, or users who never create an account.

For CDP identity resolution, the user_id should be the primary identifier. It is the most durable, privacy-stable, platform-independent identifier in the mobile stack. All other identifiers should resolve toward it when available.

The mobile SDK should call .identify(user_id) on every successful authentication event, including:

• New registration
• Returning login
• Session restore from stored token
• Account reauthentication after session expiry

Calling .identify() only on registration is one of the fastest ways to fragment mobile profiles.

Device ID

The device_id is the anonymous SDK-generated identifier for a specific app installation on a specific device.

It is created on first app launch and stored locally. It can survive app restarts and background sessions, but it is usually cleared on uninstall and reinstall.

The device_id is the bridge from anonymous behavior to the known user profile. Before authentication, events attach to device_id. After authentication, .identify(user_id) creates the mapping from device_id to user_id.

The identity strategy must also specify what happens on logout. Calling .reset() on logout generates a new anonymous device identity for the next session. Without .reset(), a different user on the same device could have their anonymous events merged into the prior user’s profile.

Push Token

The push_token is the device notification token issued through Apple Push Notification Service on iOS or Firebase Cloud Messaging on Android.

It identifies a device that can receive push notifications from a specific app. It is available only after the user grants push permission and the app registers with the notification service.

In the CDP, the push token should be stored as a device-level attribute on the unified user profile. One user_id may have multiple push tokens if the customer has the app on more than one device.

The push token is not the primary identity key. It is an activation identifier. The CDP-MAP integration guide covering push notification delivery depends on this identifier being correctly stored, updated, and associated with the authenticated profile.

IDFA

The IDFA is the iOS Identifier for Advertisers. It is a device-level advertising identifier used for attribution and paid media matching.

Since iOS 14.5, IDFA access requires Apple’s ATT permission prompt. Users who decline the prompt do not make IDFA available to the app or SDK.

That means IDFA should never be the foundation of CDP profile resolution. It may support attribution or paid media use cases when available, but the CDP’s mobile profile quality must not depend on it.

The fallback logic should be simple: use user_id when authenticated and device_id when anonymous.

AAID

The AAID, or Android Advertising ID, is the Android equivalent of the IDFA. It is user-resettable and subject to evolving privacy constraints.

Its role is similar to IDFA: useful as a supplementary attribution or audience matching signal, but not reliable enough to serve as the primary identity resolver.

The Key Rule

Design for advertising identifier absence, not presence.

A strong mobile CDP integration should achieve full profile quality using only user_id and device_id. IDFA and AAID are optional supplementary signals. They are not the foundation of the mobile customer profile.

The Anonymous-To-Authenticated Identity Stitch

The anonymous-to-authenticated identity stitch is the most important design decision in mobile app CDP integration.

How The Identity Stitch Works

When a user first opens the app, the SDK generates a device_id. The CDP receives events such as app_opened, screen_viewed, product_viewed, or feature_used under that anonymous identifier.

Those events represent real behavior, but they do not belong to a known profile yet.

When the user authenticates, the mobile app calls .identify(user_id). That call tells the CDP that the current device_id belongs to the known user_id. The CDP creates a mapping and retroactively attributes the anonymous event history to the authenticated profile.

The authenticated customer profile now includes the behavior that happened before login.

That matters for retail apps, QSR apps, financial services apps, subscription apps, and marketplaces where users commonly browse before logging in or creating an account.

Three Identity Stitch Failures To Prevent

• The first failure is calling .identify() too late. Some implementations call .identify() only when a user creates an account. That misses returning logins and restored sessions. The fix is to call .identify(user_id) on every successful authentication event.
• The second failure is not calling .reset() on logout. If a user logs out and another user opens the same app installation, the CDP may incorrectly attach the second user’s anonymous behavior to the first user’s profile. The fix is to call .reset() on every logout, session expiry, forced reauthentication, or account switch.
• The third failure is ignoring reinstall behavior. When a user uninstalls and reinstalls the app, a new device_id is usually generated. If the user authenticates, the new device identity can stitch to the same user_id, but the integration strategy should define whether pre-reinstall history should remain separate or merge with the known profile.

Users Who Never Authenticate

Some users will use the app without ever logging in.

Those sessions still matter. The CDP should retain anonymous device_id profiles for a defined period, commonly 30 to 90 days, so the data can be stitched later if the user eventually authenticates.

If the user never authenticates within the retention window, the anonymous events can expire according to governance policy. They may still support aggregate analytics, but they should not be used for named customer activation.

The Mobile Event Taxonomy For CDP Ingestion

Mobile app events should be defined before SDK installation. Changes after launch often require an app update and app store review, which makes mobile event planning more consequential than web event planning.

Category 1: Lifecycle Events

Lifecycle events capture installation, launch, and app version state. Many modern CDP SDKs capture some of these automatically.

The core lifecycle events include:

• app_installed: The app_installed event should include device_id, platform, app version, SDK version, install source, and install timestamp. This event establishes when the app installation began and can support attribution analysis.
• app_opened: The app_opened event should include device_id, user_id if authenticated, platform, app version, session ID, launch type, and timestamp. It is one of the most important inputs for engagement, recency, and churn risk.
• app_updated: The app_updated event should include previous app version, new app version, device_id, and timestamp. It helps teams evaluate whether app version changes affect engagement or event capture.

Category 2: Screen Events

Screen events track which screens or views a user visits inside the app.

The canonical event is screen_viewed. It should include device_id, user_id if authenticated, screen name, screen path, previous screen name, session ID, and timestamp.

Screen sequences are valuable because they show how users move through the app. They can reveal onboarding friction, conversion paths, product discovery behavior, subscription cancellation paths, and high drop-off screens.

Category 3: Action Events

Action events track specific user interactions that have business meaning.

For retail and ecommerce apps, action events may include:

• product_viewed
• product_added_to_cart
• checkout_started
• purchase_completed

For QSR and restaurant apps, action events may include:

• menu_item_viewed
• order_customization_started
• order_placed
• favorite_location_selected

For financial services apps, action events may include:

• account_balance_viewed
• transfer_initiated
• statement_opened
• card_locked

Each action event should include event_name, device_id, user_id if authenticated, session ID, event properties, and timestamp.

The CDP program manager and mobile engineering team should agree on action events before implementation begins. Adding a missed event later may require another mobile release.

Category 4: Identity Events

Identity events are not behavioral events, but they are the most important events in the integration.

• The .identify(user_id) call should include every identifier and profile attribute available at authentication time, such as user_id, email, phone, loyalty ID, device_id, push token, and timestamp.
• The .reset() call should clear local device identity and generate a new anonymous device_id.

The CDP data contracts guide covering ODCS data contracts at the ingestion boundary is the right model for enforcing this taxonomy. The mobile source contract should validate non-null device_id, session ID consistency, allowed event names, required properties, and duplicate app_installed events.

Three Mobile SDK Integration Patterns

There are three common mobile CDP integration patterns. The right choice depends on the app architecture, privacy requirements, mobile team structure, and platform-specific feature needs.

Pattern 1: Native SDK Per Platform

A native SDK pattern installs the CDP vendor’s iOS SDK and Android SDK separately.

This gives the engineering team the deepest access to platform-specific features, including iOS notification service extensions, Android notification channel handling, platform-native lifecycle hooks, and more precise device behavior.

The tradeoff is engineering cost. Two codebases must be maintained. SDK versions may differ. Platform-specific bugs must be tested and resolved separately.

This pattern is best for enterprise apps already maintained as separate iOS and Android codebases with dedicated native engineering teams.

Pattern 2: Cross-Platform SDK

A cross-platform SDK pattern uses React Native, Flutter, Expo, or a similar framework to instrument both platforms from a shared codebase.

This pattern is often the most practical choice for modern enterprise consumer apps. Engineering cost is lower because the team maintains one implementation. Standard event categories such as lifecycle, screen, action, and identity events can usually achieve equivalent data quality.

The main limitation is platform-specific feature depth. For example, advanced iOS push notification tracking may still require a native module even in a cross-platform app.

This pattern is best for teams that already maintain a React Native or Flutter app and want consistent event behavior across iOS and Android.

Pattern 3: Server-Side Event Tracking

In a server-side pattern, the mobile app sends events to the brand’s backend, and the backend forwards events to the CDP through server-to-server APIs.

This is often attractive in regulated industries or apps with strict SDK performance requirements. It keeps data flow under brand-owned infrastructure before data reaches a third-party CDP.

The tradeoff is that the brand must rebuild much of what the SDK would otherwise provide automatically. The backend must manage anonymous identifiers, session tracking, lifecycle equivalents, event routing, and the identity stitch.

This pattern is the most flexible and privacy-controlled, but it requires the most custom engineering.

Five Steps To Design The Mobile App CDP Integration

A successful mobile app CDP integration should be designed before SDK code is written.

Step 1: Audit The Identifier Landscape

Document the identifiers available in both iOS and Android builds.

This audit should answer:

• What user_id format does the authentication system use?
• Does the app request ATT permission on iOS?
• What is the observed ATT opt-in rate?
• Does the app request push notification permission?
• What is the observed push opt-in rate?
• Does the app currently track anonymous users?
• What device or session identifier already exists, if any?

The identifier audit becomes input to the identity strategy.

Step 2: Define Identity Resolution Rules

The identity strategy should define four mobile-specific rules before SDK installation.

• First, define the .identify() trigger. It should fire on new registration, every login, and every valid session restore.
• Second, define the .reset() trigger. It should fire on logout, session expiry, forced reauthentication, and account switching.
• Third, define anonymous event retention. Most programs use a 30 to 90 day window, depending on the app’s path from install to first authentication.
• Fourth, define reinstall handling. Most programs should not merge across reinstall unless a specific use case requires it.

The CDP integration plan guide should capture these identity decisions formally before Phase 3 build begins.

Step 3: Define The Mobile Event Tracking Plan

Create the mobile tracking plan before SDK installation.

The plan should include:

• Lifecycle events automatically captured by the SDK
• Screen tracking approach
• Action events required for the first use cases
• Identity call payload
• Push token update logic
• Data contract validation rules
• Event naming convention
• Required and optional properties

This tracking plan is the contract between the CDP program and the mobile engineering team.

Step 4: Install The SDK And Validate The Identity Stitch

After SDK installation, validate identity behavior before testing downstream activation.

Run four tests:

1. Launch the app anonymously and confirm app_opened includes device_id but no user_id.
2. Authenticate and confirm the CDP receives both device_id and user_id.
3. Confirm pre-login events are attributed to the authenticated profile.
4. Log out and confirm .reset() generates a new device_id.

Then grant push permission and confirm the push token appears as a device-level attribute on the authenticated profile.

These should be acceptance criteria, not optional QA notes. The CDP SOW guide covering integration acceptance criteria is the right place to make those tests binding.

Step 5: Design Permission Prompting

Push notification permission and ATT permission should be designed intentionally.

Push permission should be requested at a high-engagement moment, such as after a purchase, after loyalty enrollment, or after the user engages with a feature that benefits from notifications. Asking on first launch often creates lower intent opt-in behavior.

ATT prompting is different. It is required only if the CDP or attribution program needs IDFA for advertising tracking. If the CDP integration relies on user_id and device_id, ATT is not required for core CDP profile quality.

How Stable Kernel Designs Mobile CDP Integrations

Stable Kernel designs mobile CDP integrations at the intersection of CDP architecture and mobile app engineering.

Identity Strategy Before SDK Installation

Stable Kernel treats the identity strategy document as a required Phase 2 deliverable before the Phase 3 SDK sprint begins.

That document defines the .identify() trigger, .reset() trigger, anonymous retention policy, and reinstall handling rule. It also defines which identifiers are included in the identify payload, including email, phone, loyalty ID, push token, and the canonical user_id.

The most common issue Stable Kernel sees in post-implementation mobile CDP programs is simple but costly: .identify() was called only on new user registration, not on returning login. The fix requires an app update and retroactive profile cleanup. The prevention is one line of code in the right authentication path.

Mobile Engineering And CDP Engineering Together

Stable Kernel’s mobile app development practice includes iOS, Android, React Native, and Flutter engineering. That matters because mobile CDP integration requires coordination between the CDP program team and the mobile codebase owners.

Stable Kernel can help define the tracking plan, select the SDK pattern, implement or refactor SDK calls, configure identity validation tests, and ensure the app’s event taxonomy aligns with the CDP’s data contract.

Stable Kernel helps enterprise mobile teams design CDP integrations that include the identifier audit, identity strategy document, mobile event tracking plan, SDK pattern selection, ODCS data contract, and pre-production validation tests before launch.

FAQ

How Do You Integrate Mobile App Data With A CDP?

Integrating mobile app data with a CDP requires five steps: audit the mobile identifier landscape, define identity resolution rules, create the mobile event tracking plan, install the SDK and validate the identity stitch, and design push and ATT permission prompting. The integration is complete when anonymous tracking, identity stitching, logout reset behavior, and push token registration all pass validation.

What Is The Anonymous-To-Authenticated Identity Stitch?

The anonymous-to-authenticated identity stitch is the process of merging pre-login mobile behavior tracked under device_id with the authenticated customer profile tracked under user_id. The stitch occurs when the app calls .identify(user_id) at login, registration, or session restore. Without that call, pre-login behavior remains fragmented from the known profile.

What Are The Differences Between Native, Cross-Platform, And Server-Side Mobile CDP Integration?

Native SDK integration uses separate iOS and Android SDKs and provides the deepest platform-specific capabilities. Cross-platform SDK integration uses React Native, Flutter, or Expo to instrument both platforms from one codebase, usually with lower engineering cost. Server-side integration sends app events to the brand’s backend first, then routes them to the CDP, which provides more control but requires custom session, device, and identity logic.

What Is IDFA And How Does ATT Affect Mobile CDP Integration?

IDFA is Apple’s Identifier for Advertisers. ATT requires explicit user permission before the app can access IDFA. Because many users do not grant ATT permission, CDP mobile identity should not rely on IDFA. The CDP should use user_id for authenticated users and device_id for anonymous users. IDFA should be treated as a supplementary attribution signal.

What Happens When A Mobile User Never Authenticates?

If a mobile user never authenticates, the CDP retains their behavior under an anonymous device_id for a defined retention period, often 30 to 90 days. If the user logs in before that period expires, the CDP can stitch the anonymous behavior to the known profile. If the user never authenticates, the anonymous events can expire or support aggregate analytics.

What Is A Push Token In Mobile CDP Integration?

A push token is the device notification token issued by APNs on iOS or FCM on Android. It allows the brand to send push notifications to a specific device. In the CDP, the push token should be stored as a device-level attribute on the authenticated user_id profile and updated whenever the token rotates.

What Events Should A Mobile App Send To A CDP?

A mobile app should send lifecycle events, screen events, action events, and identity events. Lifecycle events include app_installed, app_opened, and app_updated. Screen events include screen_viewed. Action events depend on the business use case, such as product_viewed, order_placed, or transfer_initiated. Identity events include .identify(user_id) and .reset().

How Does Mobile App CDP Integration Differ From Web CDP Integration?

Mobile app CDP integration uses a device-based SDK identifier rather than a browser cookie, requires mobile permission design for push notifications and potentially ATT, and often requires app store review for event tracking changes. Web events can usually be changed with a deployment. Mobile event changes may require an app release, which makes the initial tracking plan more important.

Can Stable Kernel Help Design And Build A Mobile App CDP Integration?

Yes. Stable Kernel helps enterprise teams design and build mobile app CDP integrations, including identifier audits, identity strategy documents, SDK pattern selection, mobile event tracking plans, data contracts, push token handling, and identity validation tests. Stable Kernel’s mobile app development team can also support iOS, Android, React Native, and Flutter implementation work when engineering capacity is needed.