Identity & Device IDs

The Datafly mobile SDKs use a multi-layered identity model to track users across sessions, app reinstalls, and the transition from anonymous to known user.

Identity layers

How it works

1. App install (new user)

On first launch, the SDK:

1. Generates a new anonymous ID (UUID v4)
2. Collects the device ID (IDFV on iOS, ANDROID_ID on Android)
3. Self-generates vendor tracking IDs (GA4 client_id, Meta fbp, TikTok ttp, Pinterest _pin_unauth)
4. Starts session 1

The first event sent to the server creates a canonical identity that links all these signals:

canonical:org123:uuid-canonical-1
  ├── link:dfid:uuid-anonymous-1      (anonymous ID)
  ├── link:idfv:uuid-vendor-1         (device ID)
  └── vendor_ids: { ga_client_id, fbp, ttp, pin_unauth }

2. User logs in

When the app calls identify("user-123"):

canonical:org123:uuid-canonical-1
  ├── link:dfid:uuid-anonymous-1
  ├── link:idfv:uuid-vendor-1
  ├── link:user_id:user-123           (now linked)
  └── vendor_ids: { ga_client_id, fbp, ttp, pin_unauth }

All pre-login events are now attributed to the identified user.

3. App reinstall

When the app is reinstalled, a new anonymous ID is generated. The server recovers the identity through device recognition:

New anonymous ID: uuid-anonymous-2
Device recognition hash matches → same device
Server links: dfid:uuid-anonymous-2 → canonical:uuid-canonical-1

Result: same canonical identity, continuous user history

Device recognition

The server computes a SHA-256 hash from multiple device signals to identify returning devices:

If the hash matches a previously seen device (confidence threshold met), the server links the new anonymous ID to the existing canonical identity.

Identity correction

After processing device recognition, the server may return a corrected_anonymous_id in the batch response. The SDK automatically updates its stored anonymous ID to match:

SDK sends event with anonymousId: "uuid-anonymous-2"
Server recognises device → returns corrected_anonymous_id: "uuid-anonymous-1"
SDK updates Keychain/SharedPreferences with corrected ID
Subsequent events use the corrected ID

Platform-specific persistence

iOS

The Keychain recovery chain: Keychain → UserDefaults backup → generate new.

Android

Vendor ID generation

On first launch, the SDK self-generates tracking IDs that match the format each vendor expects:

These are sent once on the first event, then cached server-side. This means you don’t need to embed Meta SDK, GA4 SDK, etc. in your app — Datafly generates compatible IDs natively.

Advertising IDs (IDFA / AAID)

Advertising IDs require explicit user consent and must be set by the app after permission is granted:

iOS (IDFA)

import AppTrackingTransparency
import AdSupport
 
ATTrackingManager.requestTrackingAuthorization { status in
    if status == .authorized {
        let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
        Datafly.shared.setAdvertisingId(idfa, enabled: true)
    }
}

Android (AAID)

// Using Google Play Services (separate dependency)
val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
if (!adInfo.isLimitAdTrackingEnabled) {
    Datafly.setAdvertisingId(adInfo.id, enabled = true)
}

Logout / reset

Call reset() when the user logs out:

Datafly.shared.reset()

This:

1. Generates a new anonymous ID
2. Clears user ID and traits
3. Clears group ID and traits
4. Regenerates vendor IDs
5. Does not clear the event queue (pending events are still delivered)