Skip to main content
Cookie Gate
Category: Tracking Technologies

Mobile Advertising ID

Also known as: MAID, Advertising ID, IDFA, GAID
Simply put

A Mobile Advertising ID (MAID) is a unique, resettable identifier that a mobile operating system assigns to a smartphone or tablet, allowing advertisers to recognize a device and track user activity across apps to deliver targeted advertising. It is described by industry sources as anonymous, though in practice it can often be linked to other data to identify or profile a user. Users can typically reset the identifier, and mobile platforms provide controls affecting whether and how it can be accessed.

Formal definition

A Mobile Advertising ID is a device-level identifier issued by a mobile operating system to support advertising and measurement across applications; the principal implementations are Apple's Identifier for Advertisers (IDFA) on iOS and the Google Advertising ID (GAID) on Android. Although vendors commonly characterize MAIDs as anonymous, they function as persistent-until-reset pseudonymous identifiers that can enable cross-app tracking, attribution, and profiling, and they can be combined with other information to single out or re-identify a user. Because a MAID is not a cookie, cookie-specific rules do not map to it directly; however, under EU and UK law the storing of or access to such an identifier on a user's device generally falls within the ePrivacy regime, and any associated profiling typically constitutes processing of personal data under the GDPR, so consent or another lawful basis may be required. Requirements and enforcement positions vary by jurisdiction and continue to evolve, and this definition does not resolve the contested question of whether a given MAID is anonymous or personal data in a specific factual context.

Why it matters

Mobile Advertising IDs sit at the center of the mobile advertising economy, enabling cross-app tracking, attribution, and profiling in a way analogous to how cookies operate on the web. While industry sources frequently describe MAIDs as anonymous, in practice a persistent-until-reset identifier can often be combined with other data to single out, profile, or re-identify a user. This gap between the marketing characterization and the practical reality is precisely what makes MAIDs a compliance-sensitive technology for privacy officers and legal teams.

For organizations operating in the EU and UK, the significance is twofold. The storing of or access to an identifier on a user's device generally falls within the ePrivacy regime, which governs device access independently of whether the identifier is treated as personal data. Separately, any profiling or behavioral targeting built on a MAID typically constitutes processing of personal data under the GDPR, meaning consent or another lawful basis may be required. Because a MAID is not literally a cookie, teams cannot simply assume that their existing cookie consent flows extend to it; the technology requires its own analysis even though similar legal principles apply.

The treatment of MAIDs varies considerably by jurisdiction, and the underlying question of whether a specific MAID is anonymous or personal data remains contested and fact-dependent. Enforcement positions and platform-level controls continue to evolve. This makes MAIDs an area where compliance teams should avoid relying on vendor characterizations alone and should document their own assessment of how the identifier is used and combined with other data in their particular context.

Who it's relevant to

Privacy officers and data protection professionals
MAIDs require a separate assessment from web cookies because they are not stored or read the same way, yet they raise comparable questions about device access under the ePrivacy regime and personal data processing under the GDPR in the EU and UK. Privacy teams should document how MAIDs are collected, combined with other data, and shared, rather than relying on the industry description of the identifier as anonymous.
Legal counsel
The contested question of whether a given MAID is anonymous or personal data is fact-dependent and unresolved in the general case. Counsel advising on mobile data practices should evaluate whether consent or another lawful basis is required in each relevant jurisdiction, recognizing that requirements and enforcement positions vary between the EU, the UK, individual US states, and other regimes, and continue to evolve.
Mobile app developers and engineering teams
Developers integrate MAIDs through operating-system APIs on iOS (IDFA) and Android (GAID) and must account for platform-level user controls and reset functionality. Engineering teams should understand how their app requests, stores, and transmits the identifier so that these flows align with the consent and lawful-basis decisions made by legal and privacy stakeholders.
Marketing and advertising compliance teams
Because MAIDs underpin cross-app targeting and attribution, teams relying on them for campaign measurement should confirm that any profiling built on the identifier is supported by an appropriate legal basis where required. Vendor claims that a MAID is anonymous should not be treated as a substitute for the organization's own compliance judgment.

Inside MAID

Device-Level Identifier
A Mobile Advertising ID (such as Apple's IDFA or Google's GAID/AAID) is a resettable, user-facing string assigned at the device operating-system level, used to identify a device for advertising and attribution purposes without directly exposing hardware identifiers.
Cross-App Tracking Capability
Because the identifier is shared across apps on the same device, it can enable advertising networks and SDKs to link user activity across different applications, which is generally the primary privacy concern associated with it.
User Controls and Resettability
The identifier is typically resettable by the user through operating-system settings, and platforms increasingly require apps to obtain user permission before accessing it, though the exact controls depend on the platform and its current policies.
Personal Data Classification
Where a Mobile Advertising ID can be used to single out or track an individual or their device, it is generally treated as personal data under the GDPR, meaning its processing triggers GDPR obligations independently of any consent required to access it on the device.
In-App SDKs and Trackers
Advertising IDs are commonly accessed by third-party SDKs embedded in apps. These SDKs function similarly to cookies and pixels on the web and fall within the same consent and transparency considerations even though they are not literally cookies.

Common questions

Answers to the questions practitioners most commonly ask about MAID.

Is a Mobile Advertising ID anonymous because it isn't tied to my name?
No. Although a Mobile Advertising ID (such as Apple's IDFA or Android's AAID) does not directly contain a name, it is generally treated as personal data under the GDPR because it is a persistent identifier that can single out a device and, by extension, an individual, and can be combined with other data to build a profile. In the EU and UK it is typically regarded as identifying rather than anonymous. Treatment under US state privacy laws such as the CCPA/CPRA may differ, but these identifiers are also commonly considered personal information there. Whether it constitutes personal data in a specific case depends on facts not covered by this definition.
Since a Mobile Advertising ID is not a cookie, do cookie consent rules apply to it?
The label matters less than the function. In most EU jurisdictions, the ePrivacy rules on storing or accessing information on a user's device can extend to technologies beyond literal cookies, including SDKs and device identifiers accessed on a phone, while any subsequent processing of personal data is governed by the GDPR. So consent obligations may apply even though a Mobile Advertising ID is not technically a cookie. The precise application to a given SDK or platform can be contested and depends on how the identifier is accessed and used.
When do we need consent before accessing a Mobile Advertising ID in a mobile app?
Where the identifier is used for advertising, analytics, or profiling, consent is generally required in most EU jurisdictions before accessing or processing it, because such uses are typically not strictly necessary. Consent under the GDPR must be freely given, specific, informed, and unambiguous through a clear affirmative action. Requirements differ under US state frameworks, which often rely on an opt-out model rather than prior opt-in. Note that platform-level controls (discussed below) operate alongside, not instead of, these legal obligations.
How do platform-level controls like an app-tracking permission prompt relate to our consent obligations?
Platform controls that ask users to allow or limit tracking operate at the operating-system level and govern access to the identifier on the device. They can support, but do not by themselves satisfy, legal consent requirements. A user granting a platform permission does not necessarily provide the specific, informed consent that may be required under EU or UK law, and platform mechanics may not map cleanly onto legal opt-out obligations under US state laws. Legal judgment is needed to align the two; the tooling does not replace it. The exact interaction depends on facts and evolving guidance not covered here.
How should we record consent or preferences relating to a Mobile Advertising ID?
Where consent is the basis for using the identifier, you should generally maintain records demonstrating that valid consent was obtained, consistent with accountability and record-keeping expectations under the GDPR in the EU and UK. This typically includes what the user was told, when, and the choice made. Where a jurisdiction relies on opt-out, you should retain evidence of honoring opt-out requests instead. A consent management platform can help capture these records, but it supports rather than guarantees compliance, and the adequacy of any logging approach depends on the specific facts.
What happens to advertising and measurement that depend on a Mobile Advertising ID when a user declines?
If a user withholds or withdraws permission, you generally cannot lawfully use the identifier for advertising, analytics, or profiling in jurisdictions where consent is required, and you should stop the associated processing. This may limit targeted advertising and cross-app or cross-session measurement tied to that identifier. Some strictly necessary functions may continue where they do not rely on the identifier for excluded purposes. Which specific functions remain permissible depends on the use case and applicable law and is not resolved by this definition alone.

Common misconceptions

Mobile Advertising IDs are not covered by cookie or ePrivacy rules because they are not cookies.
In most EU jurisdictions, the ePrivacy rules on storing and accessing information on a user's device are technology-neutral and can extend to identifiers and information accessed through apps and SDKs, not just browser cookies. The subsequent processing of any personal data derived from the identifier is separately governed by the GDPR. The precise application to mobile identifiers can depend on national implementation and evolving regulatory guidance.
An operating-system-level permission prompt to access the advertising ID is the same as valid consent for all downstream processing.
A platform permission may address access to the identifier on the device, but under EU law it does not automatically satisfy the separate GDPR requirement for valid consent (freely given, specific, informed, and unambiguous) for the further processing of that data for advertising. These are distinct obligations that should not be conflated.
Because the advertising ID is resettable and pseudonymous, it is not personal data.
Resettability and pseudonymity do not remove an identifier from the scope of personal data where it can still be used to single out, link, or track an individual or device. Under the GDPR such identifiers are generally treated as personal data.

Best practices

Treat access to a Mobile Advertising ID and the subsequent processing of associated personal data as two distinct legal questions, addressing device-access rules (ePrivacy-derived, in EU jurisdictions) and GDPR processing obligations separately.
Where required in the EU, obtain valid consent that meets the GDPR standard (freely given, specific, informed, and unambiguous through a clear affirmative action) before advertising or tracking SDKs access or use the identifier, rather than relying solely on a platform permission prompt.
Map and document the third-party SDKs in your app that access the advertising ID, and maintain records of what is accessed, for what purposes, and under what legal basis, to support accountability and consent record-keeping.
Account for differing jurisdictional requirements, recognizing that EU and UK approaches generally center on prior consent while several US state frameworks may rely on opt-out mechanisms, and confirm the specific scope applicable to your user base.
Respect and correctly propagate user controls, including operating-system-level tracking permissions and identifier resets, and ensure that a withdrawal or absence of permission stops the corresponding processing.
Use consent management tooling to support and document compliance for in-app tracking, while treating such tools as an aid rather than a guarantee of lawful processing, and obtain legal review for contested or fact-specific questions.