Skip to main content
Cookie Gate
Category: Tracking Technologies

Google Advertising ID

Also known as: GAID, Android Advertising ID, AAID, Google Advertising Identifier
Simply put

The Google Advertising ID (GAID) is a unique identifier assigned to Android devices that advertisers and app developers can use to target ads and measure how advertising campaigns perform. It functions on Android in a way comparable to Apple's IDFA on iOS devices, and users can reset it. Although it is not a cookie, it is a device identifier that can be used to track users across apps, so it typically falls within the same privacy and consent considerations that apply to other tracking technologies.

Formal definition

The Google Advertising ID (GAID), formerly known as the Android Advertising ID (AAID), is a user-resettable, unique device identifier provided by Google Play Services on Android devices for advertising purposes within Google's ecosystem. It supports use cases including ad targeting and attribution or campaign performance measurement, serving a role broadly analogous to Apple's IDFA on iOS. As a persistent (though resettable) device identifier that can be associated with an individual's device and used to track activity across apps, the GAID generally constitutes personal data under the GDPR when it relates to an identifiable person; its use for non-essential advertising and measurement purposes typically requires a valid legal basis and, in most EU jurisdictions, prior consent under the ePrivacy rules governing access to information stored on a device, as well as any applicable GDPR obligations for the subsequent processing. Note that although the GAID is not literally a cookie, it is subject to the same categories of consent and transparency analysis applied to cookies, pixels, SDKs, and similar tracking technologies. The precise consent or opt-out requirements vary by jurisdiction (for example, opt-in approaches common in the EU and UK versus opt-out mechanisms under certain US state privacy laws), and this definition does not address platform-specific policy requirements imposed by Google or app store rules, which are out of scope.

Why it matters

The GAID is one of the primary identifiers that enables cross-app tracking on Android devices, making it central to how advertising campaigns are targeted and measured within Google's ecosystem. Because it is a persistent (though resettable) device identifier that can be linked to an individual's device and used to follow activity across multiple apps, it generally constitutes personal data under the GDPR when it relates to an identifiable person. That classification pulls the GAID into the same privacy and consent analysis that applies to cookies, pixels, SDKs, and similar tracking technologies, even though it is not literally a cookie.

Who it's relevant to

App developers and mobile product teams
Teams building Android apps that integrate advertising or analytics SDKs need to understand that reading or sharing the GAID for non-essential purposes generally triggers the same consent and transparency analysis applied to other tracking technologies. Because the GAID can be used to track users across apps, its use should be mapped to a valid legal basis and, in most EU jurisdictions, to prior consent before the identifier is accessed for advertising or measurement.
Privacy officers and data protection professionals
The GAID generally constitutes personal data under the GDPR when it relates to an identifiable person, so it should be included in records of processing, consent logging, and transparency notices where relevant. Practitioners should note that consent or opt-out requirements differ by jurisdiction and that the ePrivacy access-to-device rules and the GDPR processing obligations are distinct considerations that both may apply.
Marketing and advertising compliance teams
Teams relying on the GAID for ad targeting, attribution, or campaign performance measurement should confirm that the appropriate consent or opt-out has been captured for the applicable jurisdiction before deploying tracking. Opt-in approaches are common in the EU and UK, while certain US state privacy laws rely on opt-out mechanisms, so a single global approach may not satisfy every regime.
Legal counsel advising on cross-app tracking
Counsel assessing mobile advertising practices should treat the GAID as falling within the same categories of consent and transparency analysis applied to cookies and similar identifiers, rather than assuming that its non-cookie status removes it from scope. Interpretations and enforcement positions evolve, and platform-specific policy requirements from Google or app stores are a separate matter not addressed by the general consent analysis.

Inside GAID

Google Advertising ID (GAID)
A resettable, user-specific identifier assigned by Google Play services on Android devices, used primarily to enable advertising and analytics functionality within mobile apps and SDKs.
Resettable and user-controllable nature
Unlike hardware identifiers, the GAID can be reset by the user, and Android provides device-level controls allowing users to limit ad tracking or delete the identifier, though these controls operate separately from any in-app consent mechanism.
Role as an online identifier / personal data
Under the GDPR, the GAID is generally treated as an online identifier capable of singling out a user and therefore typically constitutes personal data when processed, even though it is not itself a cookie.
Relationship to ePrivacy rules
Accessing or storing the GAID on a user's device falls within the same category of rules as cookies and similar technologies under the ePrivacy Directive, meaning that reading it may require prior consent in most EU jurisdictions depending on the purpose.
SDK and advertising ecosystem integration
The GAID is commonly collected through advertising, analytics, and attribution SDKs embedded in apps, linking a device to profiling, measurement, and targeted advertising activities.

Common questions

Answers to the questions practitioners most commonly ask about GAID.

Is a GAID a cookie, and does that mean cookie consent rules do not apply to it?
A GAID (Google Advertising ID) is not a cookie; it is a resettable, user-facing identifier assigned at the operating-system level on Android devices for advertising purposes. However, the fact that it is not literally a cookie does not place it outside the relevant legal frameworks. In most EU jurisdictions, the ePrivacy rules on storing or accessing information on a user's device can apply to identifiers accessed through SDKs and mobile apps, and the GDPR generally applies to any processing of personal data that follows, since a GAID can typically be used to single out or track a user. The legal scope of a claim should always be checked against the applicable regime, as guidance on mobile identifiers continues to evolve.
Does resetting or deleting a GAID amount to the user giving or withdrawing valid consent?
No. Resetting a GAID or enabling a device-level limitation is a technical control the user exercises, but it is not the same as the consent mechanism required under EU law. Valid consent under the GDPR must be freely given, specific, informed, and unambiguous, obtained through a clear affirmative action, typically via an in-app consent interface or CMP rather than inferred from device settings. Conversely, US state privacy frameworks such as the CCPA and CPRA generally rely on an opt-out model, so the relationship between device signals and legal obligations differs by jurisdiction. Device-level controls may support user choice but do not, on their own, satisfy or replace a compliant consent or opt-out process.
How should a GAID be handled within a consent management platform (CMP) in a mobile app?
In a mobile app context, access to and use of a GAID for advertising or analytics purposes should generally be gated behind the app's consent or preference interface. A CMP or mobile consent SDK can capture the user's choice before advertising SDKs read the GAID, and can pass that signal downstream. Because a CMP supports but does not guarantee compliance, the actual behavior of each SDK that reads the GAID should be verified against the recorded consent state. Requirements differ by jurisdiction, so the configuration should reflect whether an opt-in or opt-out model applies to the relevant users.
What records should be kept when relying on consent for GAID-based processing?
Where consent is the relied-upon basis, organizations are generally expected under the GDPR to maintain records demonstrating that valid consent was obtained, including what the user was told and the choice they made. For mobile identifiers such as a GAID, this typically means logging the consent state captured through the in-app interface and being able to show it applied before advertising SDKs accessed the identifier. The precise record-keeping expectations depend on the applicable regime and the details of the implementation, which fall outside the scope of this entry.
How should GAID handling be coordinated with the equivalent identifier on other platforms?
A GAID is specific to Android devices; other platforms use their own advertising identifiers governed by their own operating-system controls. Consent or opt-out logic should therefore be designed to handle the relevant identifier per platform consistently, so that the user's recorded choice is honored regardless of which device identifier is in use. The technical specifics of any non-Android identifier are out of scope here, but the underlying legal principles for accessing device identifiers and processing the resulting personal data generally apply across platforms.
What should teams verify before allowing advertising SDKs to read the GAID?
Teams should generally verify that the relevant legal basis or user choice is in place before an SDK accesses the GAID, that the SDK actually respects the recorded consent or opt-out state rather than reading the identifier by default, and that the geographic scope of the applicable rules has been correctly determined, since obligations differ between the EU, the UK, and individual US states. Because tools support rather than replace legal judgment, these technical checks should be paired with a review of whether the chosen approach is defensible under the applicable framework.

Common misconceptions

The GAID is not personal data because it is not tied to a name and can be reset.
Under the GDPR, the GAID is generally treated as an online identifier that can single out a user, and its resettable nature does not remove it from the scope of personal data when it is used for profiling or advertising.
Because the GAID is not a cookie, cookie consent rules do not apply to it.
The ePrivacy Directive's rules on storing and accessing information on a user's device apply to similar technologies, including identifiers accessed through SDKs, so reading the GAID may require prior consent in most EU jurisdictions in the same way as cookies.
The Android device-level 'opt out of ad personalization' setting satisfies consent obligations.
Device-level controls operate separately from app-level consent. In EU jurisdictions requiring opt-in consent, relying solely on the device setting may not meet the standard of freely given, specific, informed, and unambiguous consent, and requirements differ under opt-out frameworks such as certain US state laws.

Best practices

Treat the GAID as personal data and an online identifier when it is used for advertising, analytics, or profiling, and document the legal basis relied upon for that processing.
Assess whether accessing or storing the GAID on a device triggers ePrivacy consent obligations in the relevant jurisdiction, and obtain prior consent where required rather than assuming cookie rules do not apply to non-cookie identifiers.
Ensure that consent captured through in-app SDKs meets the applicable standard for the target jurisdiction, recognizing that EU regimes generally require opt-in while some US state laws rely on opt-out signals.
Do not treat Android device-level ad settings as a substitute for a compliant in-app consent mechanism, and clarify to users how the two interact.
Audit embedded advertising, analytics, and attribution SDKs to identify where and why the GAID is collected, and configure them so that identifiers are not read before valid consent is obtained where consent is required.
Maintain records of consent and configuration decisions relating to the GAID, and revisit them as data protection authority guidance and enforcement positions evolve, since a CMP or SDK setting supports but does not guarantee compliance.