1. Play's baseline is local law, not a global template. The User Data policy states that developers "must at all times comply with privacy and data protection laws applicable in the jurisdictions in which you offer your products or services", and its Do/Don't table is blunter still: "Adhere to all applicable privacy, data security, and data protection laws (e.g., GDPR)... failing to comply with applicable laws is a policy violation." The same policy already requires that you "disclose what data you collect, how you use it, and who it's shared with", provide "a valid privacy policy", obtain consent where required, and offer account deletion. A US-only policy shipped to EU or Brazilian users is therefore not a documentation gap; it is a Play policy violation with legal exposure stacked on top. (§https://support.google.com/googleplay/android-developer/answer/10144311)
2. The Data safety declaration must match what the app actually does, region by region. Data safety is a declaration about real runtime behaviour - data types collected, whether they are shared, encryption in transit, deletion requests - and Google reviews it against the app and the SDKs bundled inside it. A policy page promising "no sharing with third parties" while an ad SDK transmits the advertising ID is the classic mismatch. The form, the policy and the SDK inventory have to tell one story, and regional differences (for example a consent-gated ad stack in the EEA) belong in that same story rather than in an annex nobody reads. (§https://support.google.com/googleplay/android-developer/answer/10787469)
3. EEA, UK and Switzerland: collecting consent is only half the duty - it has to be withdrawable. Google's GDPR guidance says it directly: "GDPR mandates consent revocation, requiring you to provide users with a way to withdraw their consent choices at any time", and "To avoid impact on monetization for users in the EEA and UK, you must implement a Google-certified CMP by January 16, 2024." The UMP SDK satisfies this with a consent message plus a "Privacy options" entry point that stays reachable inside the app after first run; a one-time interstitial the user can never reopen fails the revocation test. Watch the scope: Google's EU User Consent Policy covers the EEA, the UK and Switzerland, and teams routinely ship EEA-only flows and forget Switzerland. Under-age handling is separate - setTagForUnderAgeOfConsent suppresses the consent request, but ageRestrictedTreatment must also be set on ad requests or the tag has no effect downstream. (§https://developers.google.com/admob/android/privacy/gdpr / §https://support.google.com/admob/answer/10113207)
4. California: under the CPRA the opt-out is a visible link, not a buried toggle. The California Attorney General's own explainer states that businesses selling personal information "are subject to the CCPA's requirement to provide a clear and conspicuous 'Do Not Sell or Share My Personal Information' link on their website that allows you to submit an opt-out request", that they "cannot require you to create an account in order to submit your request", that identity verification "should not" be required, and that a user-enabled global privacy control such as GPC must be honoured. The in-app equivalent is an opt-out path reachable from settings and the privacy policy, using the same wording, with ad-tech sharing for cross-context behavioural advertising treated as "sharing". A policy that recites CCPA obligations but offers no way to exercise them is the single most common failure we see in review. (§https://oag.ca.gov/privacy/ccpa)
5. Brazil (LGPD): one legal basis per purpose, an encarregado, and a real transfer mechanism. LGPD requires a documented legal basis for each processing purpose (Art. 7) - consent is only one of ten - grants data subjects confirmation, access, correction, anonymisation, portability and deletion rights (Art. 18), requires a published data protection officer/encarregado (Art. 41), and allows international transfers only to adequate jurisdictions or under the mechanisms recognised by the ANPD (Arts. 33-36). In practice the three things Brazilian users and the ANPD look for are a Portuguese-language policy, an in-app channel for rights requests, and the encarregado's contact inside the policy. (§https://www.gov.br/anpd/pt-br)
6. Korea (PIPA): consent is itemised, and collection consent is not third-party consent. PIPA requires separate consent to collect and use personal information (Art. 15) and a second, distinct consent to provide it to third parties (Art. 17) - a single "I agree to the privacy policy" checkbox satisfies neither - plus access, correction and deletion rights under Arts. 35-37 and a domestic representative obligation (Art. 31-2) for overseas operators above the statutory thresholds. The policy must name the items collected, the purpose and the retention period per item, in Korean for Korean users. (§https://law.go.kr/LSW/lsInfoP.do?lsiSeq=251020)
7. Cross-border transfer has to be disclosed, not implied. The three regimes converge on the same disclosure set: recipient or recipient category, country, items transferred, purpose, method and retention - GDPR Chapter V with its adequacy and SCC routes, LGPD Arts. 33-36, and PIPA Art. 28-8. If your analytics and ad SDKs sit in the United States, that is a cross-border transfer and the policy has to say so at data-type level; "we may share data with service providers" meets the standard in none of the three.
8. Operate it as one canonical policy with regional annexes. Keep a master text, then per-region annexes covering jurisdiction, legal basis, rights, transfer, regulator contact, language, effective date and version. Localise the language, not just the date. Version the document and keep the changelog, because reviewers and regulators ask what the user actually agreed to on a given day. Log consent state with a timestamp and the CMP consent-string identifier so you can prove it later, re-prompt on material changes instead of silently editing the policy, and test with region-spoofed devices: an EEA build with no reachable privacy-options entry point, or a California build with no opt-out, is a one-line finding for any auditor.