Android gives you two device identifiers with very different purposes, and using the wrong one is both a privacy problem and a policy problem. The advertising ID is for advertising, is user-resettable, and now requires a permission, while the App Set ID is for non-advertising uses like analytics and fraud prevention and is scoped to your own apps. Mixing them up, using the advertising ID for analytics, or ignoring a user's reset, breaks Google Play's rules and user expectations. Here is what each identifier is for, the AD_ID permission and user controls, and how to use them respectfully.
Short answer
Android has two main app-facing identifiers: the advertising ID, a user-resettable, deletable identifier for advertising that users can opt out of, and the App Set ID, scoped to your own set of apps and intended for non-advertising uses like analytics and fraud prevention. Per Google's documentation, apps targeting Android 13 or higher that use the advertising ID must declare the AD_ID permission, or the ID is replaced with zeros, and you must respect user resets and opt-outs. Use the advertising ID only for advertising, the App Set ID for non-ad use cases, never reconnect a reset advertising ID, and declare your use in your Data safety form. The two identifiers are not interchangeable.
What you should know
- Advertising ID is for ads: user-resettable and opt-out-able.
- App Set ID is for non-ads: analytics and fraud, scoped to your apps.
- AD_ID permission is required: for advertising ID on Android 13+, or it is zeroed.
- Respect user controls: do not reconnect a reset advertising ID.
- Declare your use: in the Data safety form.
What is the difference between the advertising ID and App Set ID?
They serve different purposes and have different scopes. The table contrasts them.
| Aspect | Advertising ID | App Set ID |
|---|---|---|
| Purpose | Advertising and ad measurement | Non-advertising: analytics, fraud prevention |
| Scope | Device-wide, shared across apps | Scoped to your own set of apps |
| User control | Resettable, deletable, opt-out | Not user-facing in the same way; resets over time |
| Cross-developer tracking | Possible, governed by policy | Not for tracking across developers |
| Permission | AD_ID required on Android 13+ | No special permission |
The advertising ID is the device-wide identifier for advertising that the user controls, and is the one to use only for ad-related purposes. The App Set ID is per-developer, intended for use cases like analytics and fraud prevention that need a stable identifier without being for advertising, and is explicitly not meant to track users across different developers. Choosing the right one for the purpose is the first rule: do not reach for the advertising ID just because it is familiar if your use is analytics or fraud, where the App Set ID is appropriate.
What about the AD_ID permission and user controls?
Both reflect that the advertising ID is privacy-sensitive. Apps targeting Android 13 or higher that use the Google advertising ID must declare the AD_ID normal permission in the manifest; without it, the advertising ID your app receives is replaced with a string of zeros, breaking ad attribution. On the user side, the advertising ID is resettable and deletable: a user can reset it to break the link to past activity, opt out of personalized ads, or delete it entirely, after which the app receives zeros. You must respect these controls, which means not attempting to reconnect a reset advertising ID to its previous value or to other identifiers, sometimes called bridging, since that defeats the user's choice and violates policy. So using the advertising ID comes with both a declaration requirement and an obligation to honor the user's resets and opt-outs.
How do you use these identifiers respectfully?
Match the identifier to the purpose, declare it, and honor user choices. Use the advertising ID only for advertising and ad measurement, declare the AD_ID permission if you target Android 13 or higher, and never reconnect a reset advertising ID to past data. For non-advertising needs like analytics or fraud prevention, use the App Set ID rather than the advertising ID, since that is what it is for and it is not for cross-developer tracking. Avoid building your own persistent device identifier from device characteristics to work around these, since that is fingerprinting, which is restricted. Declare your use of these identifiers accurately in your Data safety form, since they are part of your data practices. The principle mirrors the iOS approach: identifiers the user controls, used for their intended purpose, with consent and disclosure, not covert persistent tracking.
What to watch out for
The first trap is using the advertising ID for non-advertising purposes like analytics, when the App Set ID is the right identifier; match the identifier to the use. The second is omitting the AD_ID permission on Android 13 or higher, which zeros out the advertising ID. The third is reconnecting or bridging a reset advertising ID, which violates the user's choice and policy. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces the SDKs and identifiers your app uses, which helps you see whether an SDK is using the advertising ID, so your declarations and usage match. The identifier choices you make in the app.
What to take away
- Android's advertising ID is for advertising and is user-resettable and opt-out-able, while the App Set ID is for non-advertising uses like analytics and fraud, scoped to your own apps.
- Apps targeting Android 13 or higher must declare the AD_ID permission to use the advertising ID, or it is replaced with zeros, and you must respect user resets and opt-outs.
- Use each identifier for its intended purpose, never reconnect a reset advertising ID, avoid fingerprinting as a workaround, and declare your use in the Data safety form.
- Use a pre-submission scan such as PTKD.com to see which identifiers and SDKs your app uses so your usage and disclosures align.
