Device ID Tracking for Mobile Apps: A Developer's Implementation Guide

iOS 14.5 changed the economics of mobile attribution overnight. The moment a user taps “Ask App Not to Track,” your IDFA access drops to zero — and with opt-out rates consistently above 60% on iOS, a majority of your paid acquisition campaigns are running without deterministic device-level signals.

Device IDs remain the most reliable foundation for mobile attribution, but as experts at Algorix note, the practice requires assigning privacy-safe resettable identifiers — not hardware serial numbers — and implementing them within a framework that survives ongoing platform restrictions. (Source: algorix.co) This guide covers the complete implementation path: how to retrieve identifiers correctly on both platforms, handle null states, stay compliant with GDPR and CCPA, and architect measurement that works even when device IDs are unavailable.

What Is a Device ID and Why It Still Matters for Attribution

A device ID in mobile advertising is a software-level, resettable identifier assigned to a device for the purpose of ad measurement. These are distinct from hardware identifiers and exist specifically to balance advertiser measurement needs with user privacy.

IDFA, GAID, IDFV, and Android ID: What Each Identifier Actually Is

IDFA (Identifier for Advertisers) is Apple's advertising identifier, user-resettable and gated behind ATT consent since iOS 14.5. GAID (Google Advertising ID) is the Android equivalent, resettable by the user and increasingly restricted on Android 12+. IDFV (Identifier for Vendor) is scoped to a single developer's apps — it persists across reinstalls on the same device but resets when all apps from that vendor are removed. Android ID is a 64-bit identifier scoped to the device and app signing key — more persistent than GAID but not intended for cross-app advertising.

How Device IDs Feed Into Attribution Modelling

Attribution modelling maps a conversion back to the ad exposure or click that drove it. What are attribution models at their core? They are rules or algorithms that assign credit to touchpoints — and device IDs are the join key that links an ad impression or click to an in-app event. Without a consistent device-level identifier, last-touch, multi-touch, and data-driven attribution models cannot close the loop between spend and outcome.

The Lifecycle of a Device ID: Creation, Reset, and Deprecation Timelines

IDFA is generated on device setup and remains stable until the user resets it in Settings or opts out via ATT. GAID follows the same pattern on Android. Both Apple and Google have signalled continued tightening: Android Privacy Sandbox is progressively replacing GAID with Topics API and Protected Audiences, with broader enforcement expected through 2026. Build your attribution pipeline to treat device IDs as a high-quality but non-guaranteed signal, not a permanent dependency.

Is a Device ID the Same as an IMEI?

No. A device ID in mobile advertising refers to a resettable, privacy-safe advertising identifier — IDFA on iOS or GAID on Android. An IMEI is a permanent hardware serial number assigned to a physical device. The two serve different purposes, and using IMEI for ad tracking violates both Apple and Google policies as well as GDPR and CCPA.

IMEI vs Device ID: Key Technical Differences

IMEI is burned into device hardware at manufacture and cannot be changed without physical intervention. Advertising identifiers are software-layer values that live in the OS and can be reset or withheld by the user at any time. IMEI identifies a specific physical unit; IDFA and GAID identify an advertising profile that a user can sever from their device. The practical implication: IMEI persists across factory resets, making it a permanent fingerprint — precisely why regulators treat it as sensitive personal data.

Why Using IMEI for Ad Attribution Is a Compliance Risk

Apple explicitly prohibits IMEI collection for advertising purposes in its App Store guidelines. Google's Play Store policies match this restriction. Under GDPR, IMEI constitutes personal data because it can uniquely identify an individual's physical device with no possibility of user reset — meaning you need a lawful basis beyond legitimate interest to process it, and consent for advertising purposes is rarely achievable at scale. Any MMP or ad network still accepting IMEI as an attribution signal is operating outside current policy norms.

iOS and Android Privacy Changes: What Broke and What Still Works

The post-ATT landscape isn't a measurement void — it's a measurement restructuring. Understanding exactly where signals are lost and where they survive is the prerequisite for building a resilient attribution architecture.

iOS ATT Framework: What Happens When Users Decline

When a user declines ATT, advertisingIdentifier returns the zeroed-out string 00000000-0000-0000-0000-000000000000. Your MMP receives no IDFA, and last-touch attribution for that install is impossible deterministically. SKAdNetwork postbacks remain available — Apple's privacy-preserving install attribution sends aggregated, delayed conversion values without exposing device-level data. The limitation is a 24–48 hour postback delay and coarse conversion value windows, which makes real-time ROAS optimization difficult.

GAID Restrictions on Android 12+ and the Role of Privacy Sandbox

Android 12 introduced the ability for users to opt out of ad personalization entirely, zeroing out GAID in the same way iOS ATT does. Google's Privacy Sandbox for Android is replacing GAID-based targeting with cohort-level APIs — Topics API for interest-based targeting and Attribution Reporting API for conversion measurement — though the rollout timeline continues to evolve. As one industry analysis notes, the question in 2026 is not whether device-level targeting matters, but how to use privacy-safe inputs and clear consent signals to measure outcomes without over-crediting identity-based systems. (Source: aidigital.com)

First-Party Data and Probabilistic Fallbacks: What Actually Fills the Gap

When device IDs are unavailable, three measurement approaches fill the gap. First, incrementality testing measures the causal lift driven by an ad campaign versus what would have happened organically — this is the core incrementality definition, and it operates at the aggregate level without requiring device IDs at all. To define incrementality precisely: it is the marginal conversions attributable to a specific campaign, isolated through holdout group experiments. Second, media mix modelling uses regression-based statistical analysis across channel spend and outcome data — a media mix model requires no device-level signals and is particularly useful when IDFA opt-out rates make deterministic attribution incomplete. Both approaches are complementary: incrementality testing validates individual campaign lift while media mix modelling allocates budget across channels at a portfolio level.

Step-by-Step: Implementing Device ID Tracking Correctly in Your App

A correct implementation handles the full permission state machine — consent granted, consent denied, consent not yet requested — and passes identifiers reliably downstream regardless of which state applies.

Step 1 — Request ATT Permission at the Right Moment (iOS)

The timing of the ATT prompt directly affects opt-in rates. Request permission after the user has experienced value — post-onboarding, after completing a key action — not at app launch.

// iOS Swift — ATT permission request
import AppTrackingTransparency

ATTrackingManager.requestTrackingAuthorization { status in
    switch status {
    case .authorized:
        let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
        // pass idfa to attribution layer
    case .denied, .restricted, .notDetermined:
        // trigger fallback identification flow
    }
}

Ensure NSUserTrackingUsageDescription is populated in your Info.plist with a specific, honest description of how the identifier will be used.

Step 2 — Retrieve GAID Using the Advertising ID API (Android)

On Android, GAID retrieval requires the com.google.android.gms:play-services-ads-identifier dependency and must run off the main thread.

// Android Kotlin — GAID retrieval
val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
val gaid = if (!adInfo.isLimitAdTrackingEnabled) adInfo.id else null
// if null, proceed to fallback flow

Check isLimitAdTrackingEnabled before using the value. A non-null GAID paired with limit ad tracking enabled should be treated as an opted-out state.

Step 3 — Handle the Null State: What to Do When No ID Is Available

When no advertising ID is available, apply fallbacks in this order of reliability:

1. IDFV — available on iOS regardless of ATT status; vendor-scoped but sufficient for re-engagement and owned-media attribution
2. Fingerprint hashing with consent — combine device signals (OS version, screen resolution, timezone) hashed server-side; only viable with explicit user consent and not accepted by all ad networks
3. SKAdNetwork postbacks (iOS) / Privacy Sandbox Attribution Reporting API (Android) — aggregated, delayed, but policy-compliant

Step 4 — Pass Device IDs to Your MMP via SDK or Server-to-Server API

An MMP (Mobile Measurement Partner) is the infrastructure layer that receives device IDs, matches them against click and impression logs, and resolves attribution. What is an MMP in practice? It is the system that joins your ad network data to your in-app event data using device identifiers as the key.

For server-to-server implementations, pass device IDs in the attribution postback payload alongside event name, timestamp, and campaign parameters. Never log raw device IDs in client-side analytics tools that lack a Data Processing Agreement.

Step 5 — Store and Rotate Identifiers Safely in Production

Store device IDs encrypted at rest using AES-256. Index them as foreign keys in your events table rather than denormalizing them into every event row — this makes deletion requests faster to execute. Set a TTL on stored device IDs that aligns with your attribution window (typically 30–90 days); purge values beyond that window on a scheduled job. When a user resets their advertising ID, your MMP should generate a new user record — ensure your internal systems reconcile this as a new profile, not a duplicate.

Device ID vs Alternative Identification Methods: Choosing the Right Approach

No single identification method covers all scenarios across both platforms in a post-ATT environment. The right architecture combines methods based on data availability, consent state, and measurement objective.

Deterministic vs Probabilistic Identification: When Each Is Appropriate

Deterministic identification uses a known, explicit identifier — a logged-in user's hashed email, a device ID — to match an event to a user with high confidence. Probabilistic identification uses statistical inference from device signals to estimate a match. Deterministic is appropriate when you have consent and an available identifier. Probabilistic is a fallback for opted-out users, but accuracy degrades as privacy restrictions tighten and should not be reported alongside deterministic data without clearly labelling the difference.

First-Party Data Strategies That Complement Device ID Tracking

First-party login IDs — hashed email, phone number, or internal user ID passed through a clean room or direct API integration — provide deterministic matching that survives device ID loss entirely. Implement user login early in onboarding and pass a hashed identifier to your attribution layer alongside any available device ID. This dual-key approach maximises match rates across consented and non-consented user populations.

When to Use Media Mix Modelling Alongside Device-Level Attribution

A media mix model is a regression-based approach that attributes conversions to channels using aggregate spend and outcome data — no device-level signals required. It is most useful when device ID coverage falls below 40–50% of installs, making campaign-level deterministic attribution statistically unreliable. Tie this back to the incrementality definition: MMM shows budget efficiency across channels at a portfolio level, while incrementality testing isolates the causal lift of a specific campaign or creative. Use both in parallel for a complete measurement picture.

GDPR, CCPA, and Device ID Compliance: What Developers Must Implement

GDPR classifies device IDs as personal data when they can be linked to an individual — this shifts the legal basis required from legitimate interest to explicit consent before collection for advertising purposes.

Consent Requirements Before Reading IDFA or GAID

You must obtain informed, specific consent before reading an advertising identifier. On iOS, ATT provides this mechanism natively. On Android, you are responsible for building consent UI before calling the Advertising ID API. Consent must be logged with a timestamp server-side, tied to the user session, and retrievable for audit purposes.

Data Minimisation: Only Collect What Attribution Actually Needs

Collect device IDs only for the specific attribution purposes declared in your privacy policy. As LinkedIn's privacy guidance notes, sharing device IDs with unknown or untrusted third-party sources is a significant data security risk — limit transmission to partners with signed Data Processing Agreements. (Source: linkedin.com)

Implementation checklist:

• Obtain explicit consent before reading IDFA or GAID
• Log consent timestamp server-side with user session reference
• Transmit device IDs only to partners with a current DPA in place
• Implement a deletion endpoint that purges device IDs from your MMP and internal databases within 30 days of a user deletion request
• Never pass raw device IDs to client-side analytics, logging tools, or crash reporters without confirming those services are DPA-covered

User Deletion Requests and Device ID Purging Workflows

Under GDPR Article 17 and CCPA deletion rights, a user deletion request must cascade to all systems holding their device ID. Build a deletion endpoint that accepts a user ID, resolves it to all associated device IDs in your database, fires deletion calls to your MMP's API, and confirms purge completion. Test this workflow quarterly — it is a compliance requirement, not a nice-to-have.

Troubleshooting Common Device ID Issues in Production

Why Your MMP Is Receiving Null Device IDs

Problem: Attribution events arrive at your MMP with no device ID populated.

Likely causes:

• ATT permission not requested before SDK initialisation
• GAID retrieved on the main thread and silently failing
• SDK initialised before consent flow completes

Fix: Delay MMP SDK initialisation until after consent status is confirmed. On Android, wrap GAID retrieval in a background coroutine with proper error handling for GooglePlayServicesNotAvailableException.

Duplicate Attribution from ID Resets and Reinstalls

Problem: Single users appear as multiple new users in your MMP after resetting their advertising ID.

Likely causes:

• No IDFV or first-party ID passed alongside advertising ID
• No reinstall detection logic in SDK configuration
• Attribution window set too short to catch re-engagement

Fix: Pass IDFV (iOS) or Android ID (Android) as a secondary identifier alongside GAID/IDFA. Your MMP can use secondary identifiers to stitch reset events to existing user profiles where policy permits.

Mismatched Device IDs Across SDK and Server-to-Server Calls

Problem: Device IDs in server-to-server postbacks do not match IDs sent by the client SDK, causing attribution failures.

Likely causes:

• Client SDK sending IDFV while S2S integration sends IDFA
• ID collected before ATT consent resolved (returning zeroed IDFA)
• Encoding mismatch — uppercase vs lowercase UUID strings

Fix: Standardise on a single identifier type per integration path and enforce UUID string normalisation (lowercase) at the collection layer before transmission to your MMP.

Frequently Asked Questions