AdMob and Apple App Privacy labels: what to select in App Store Connect
If your iOS app serves ads through Google AdMob, your App Privacy answers in App Store Connect need to account for identifier collection under Identifiers, and you have to answer three separate questions about it: whether the data is collected, whether it is linked to the user's identity, and whether it is used for tracking. The table above shows the data types the AdMob Service Profile implies; the three answers are yours to confirm.
What Google AdMob implies for your Apple App Store answers
In-app advertising. Personalized vs non-personalized ads, consent, and advertising identifier use are configuration-dependent.
| App Fact | Apple App Store | Google Play | Collection |
|---|---|---|---|
| Advertising identifier | Device ID (advertising identifier)Identifiers | Advertising IDDevice or other IDs | Likely |
| Device ID | Device IDIdentifiers | Device or other IDsDevice or other IDs | Likely |
- Advertising identifier and Device ID
Advertising identifiers may be used depending on platform, consent, and ad personalization settings
Device or other identifiers may be processed for ad serving and measurement
Advertising-related data; personalization and tracking need confirmation.
Device identifiers may be used for ads.
You confirm: Shows personalized ads · Tracks users across other apps/websites · Device identifier processed · Advertising identifier processed
What this profile does not cover
- AdMob does not prove personalized advertising is enabled.
- Tracking under Apple’s definition depends on linkage and purposes — confirm with ATT and your ad setup.
The three questions Apple asks, and why they differ
Apple's App Privacy form is not a single checkbox per data type. For every data type you declare, you answer:
- Is it collected? Does the data leave the device.
- Is it linked to the user? Can it be tied to the user's identity, directly or via an account.
- Is it used for tracking? This has Apple's specific meaning, not the everyday one.
Developers get the first one right and then guess at the other two. That is where AdMob integrations go wrong, because the correct answers depend on how you configured ad personalization and consent — not on the fact that the SDK is present.
What "tracking" means to Apple
Apple defines tracking narrowly: linking user or device data collected in your app with third-party data for targeted advertising or advertising measurement, or sharing it with a data broker. The important consequence is that an advertising SDK is not automatically "tracking". A non-personalized ad configuration with no cross-app linkage can be a legitimate "no".
Equally, if your ads are personalized using the advertising identifier and data is linked with third-party data for targeting or measurement, that is tracking, and it brings obligations with it: the App Tracking Transparency permission request, and a declaration that matches. Claiming no tracking while requesting ATT authorisation is a visible contradiction.
This is why the AdMob Service Profile marks its tracking potential as configuration-dependent rather than assuming either answer, and why an App Passport asks whether you display personalized ads, whether you implemented consent controls, whether the advertising identifier is in use, and whether ads track users across apps and sites owned by other companies. Four questions, because four different things are true or false independently.
Identifiers, and why one Apple category covers two facts
Apple's Identifiers section has a single "Device ID" data type, but two distinct facts can land there: a general device identifier and the advertising identifier specifically. The table above lists both, because both are things you may need to confirm, and collapsing them loses the distinction that matters for your tracking answer.
Advertising identifier availability on iOS depends on ATT authorisation. If the user declines, the identifier is not available to you — but your App Privacy declaration describes what your app does when permitted, not the best case where every user declines.
Linkage is about your app, not about AdMob
"Linked to the user" asks whether the data can be associated with the user's identity. AdMob does not know whether your app has accounts. If your app signs users in and ad-related identifiers can be associated with those accounts, linkage may apply even though the SDK documentation says nothing about your account system.
This is the single most common source of a wrong AdMob label: copying another app's answers, which encode that app's account model rather than yours.
Common mistake
The most common mistake is declaring "Data Not Collected" because the ads are served by Google rather than by your own servers. Apple's form covers data collected by third-party SDKs in your app. If AdMob is in your build and processing identifiers for ad serving or measurement, that is collection you declare.
The second common mistake is a mismatched pair: presenting the ATT prompt while declaring no tracking, or declaring tracking while never requesting ATT authorisation. Both directions are inconsistent, and both are easy for a reviewer to observe by running your app.
A third is treating consent tooling as the whole answer. Implementing a consent messaging platform is good practice for regions that require it, but it does not change what your App Privacy label must say about the data your app collects when consent is given.
Why apps get rejected
Rejections in this area cluster around Guideline 5.1.1 and the accuracy of what you declared. The recurring patterns:
- App Privacy answers that omit identifier collection while an ads SDK is clearly present.
- An ATT prompt with no corresponding tracking declaration, or the reverse.
- A privacy policy that never mentions advertising or third-party ad partners while the label declares advertising use.
- Personalized ads shipped to an audience that includes children, without the handling those audiences require.
Apple reviewers do run the app. An advertising integration is one of the most visible things in a build, which makes an inaccurate advertising label one of the easier inconsistencies to catch.
Getting to an answer you can defend
Work in this order:
- Establish what your integration actually does. Personalized or non-personalized. Advertising identifier in use or not. Consent controls present or not.
- Answer collection first, using the data types in the table above as the starting set.
- Answer linkage against your own account model, not the SDK's documentation.
- Answer tracking against Apple's definition, and make ATT behaviour match.
- Make your privacy policy say the same thing. Advertising, third-party partners, and identifier use all belong there if they are in your label.
Step five is where most inconsistency lives, and it is what Declora's Consistency Check compares: your Apple answers, your Google Play answers, and your generated Public Pages, all derived from one set of confirmed App Facts. A change to a fact regenerates every output rather than leaving one of them stale.
FAQ
Does using AdMob automatically mean my app does tracking under Apple's definition?
No. Apple's definition turns on linking your app's user or device data with third-party data for targeted advertising or advertising measurement, or sharing with a data broker. A non-personalized configuration without cross-app linkage can be a legitimate "no" — but it has to be true of your setup, and your ATT behaviour has to match.
Can I declare "Data Not Collected" if Google serves the ads?
No. Apple's App Privacy answers cover data collected by third-party SDKs included in your app, not only data your own backend receives.
Do I need the ATT prompt for AdMob?
You need it if you engage in tracking as Apple defines it, which for an ads integration usually means personalized advertising using the advertising identifier. If you do not track, you do not need the prompt — and you should not declare tracking either.
Should the advertising identifier be marked as linked to the user?
It depends on your app. If identifiers can be associated with a signed-in account, linkage may apply. The SDK cannot answer this because it does not know your account model.
Does Declora decide these answers for me?
No. The Service Profile suggests App Facts with a reason and a confidence level, and asks the configuration-dependent questions. You confirm them. Declora then generates consistent Apple and Google answers and Public Pages from what you confirmed. It is not a law firm, does not provide legal advice, and cannot guarantee approval by Apple, Google, or any regulatory authority.
Sources
- App privacy details on the App Store — Apple, checked 2026-07-22
- App Review Guideline 5.1.1 — Data Collection and Storage — Apple, checked 2026-07-22
- App Tracking Transparency — Apple, checked 2026-07-22
- AdMob — Google Play data disclosure — Google AdMob, checked 2026-07-22
- Google Play Ads policy — Google, checked 2026-07-22
- Provide information for Google Play's Data safety section — Google, checked 2026-07-22
- Guide updated
- 2026-07-29
- Profile last reviewed
- 2026-07-22
- Catalog version
- 2026.07.2 · profile 1.0.0