On this page
Integrating an advertising SDK adds a data-processing path to your application. The engineering task is to identify that path, determine the applicable platform and provider requirements, and prevent requests until the current state permits them. A dialog shown once is not a complete consent implementation.
This is an integration design guide, not a jurisdiction-wide legal conclusion. Requirements depend on audience, location, data use, platform and partner contracts. Use qualified review where needed and verify the documentation for every SDK actually included in the release.
Inventory what the release contains
Start with the dependency lock and built artifact, not a marketing list. Record direct SDKs, adapters, mediated partners and transitive packages. For each, document version, supported runtime, initialization effects, identifiers accessed, network destinations and available configuration controls.
Separate code availability from verified distribution and device behavior. An SDK repository can exist without a verified public package or a successful build on your target device. The ADX availability register explicitly separates these states and marks its SDKs experimental. Assess the exact integration rather than describing every listed runtime as production-ready.
Create a data-flow record for app-to-SDK, SDK-to-partner and any server relay. Include event reporting and diagnostics. An ad request can carry contextual data even when a personalized identifier is absent. Avoid putting prompts, private document titles or generated sensitive content into advertising metadata.
Model request eligibility as explicit state
The following is a design model, not executable SDK code. Adapt it to the selected platform's documented API:
| State | Allowed behavior | Transition evidence |
|---|---|---|
| Unknown or updating | Load the permitted configuration/consent flow; withhold ad requests | Current provider state obtained |
| User interaction required | Show the required supported interaction | Provider reports a resolved state |
| Requests permitted | Initialize/request only as documented for that state | Fresh eligibility and placement conditions |
| Restricted or refused | Respect the documented restriction; provide core app behavior | A later valid state change |
| Configuration failure | Fail safely under a documented policy | Recovery or a reviewed fallback |
Do not collapse all these states into consent=true. Separate authorization to request ads, permission for a tracking operation and the application's own placement eligibility. A paid tier or age-related product rule may prohibit an ad even when a provider permits a request.
Follow the current provider gate
Google's Android UMP guide describes updating consent information and checking canRequestAds() before requesting ads. It also warns about duplicate requests when several completion paths can permit loading. Follow the current guide and guard your application's initialization/request path against duplication. Official UMP integration guidance.
This is a provider-specific mechanism, not a universal substitute for reviewing all mediated partners. Record which configuration and message choices the release uses. Avoid inventing a single boolean that supposedly covers every SDK or jurisdiction.
Keep consent-flow callbacks separate from screen lifecycle events. Navigation, backgrounding or a repeated initialization should not cause duplicate request loops. Use one owner for the ad-request gate and make transitions observable through safe state identifiers rather than personal data.
Distinguish iOS tracking permission from general disclosure
Apple's privacy guidance describes App Tracking Transparency requirements for tracking and access to the advertising identifier, with scope defined by Apple's rules. App privacy disclosures and SDK-related declarations are additional responsibilities; an advertising feature does not automatically justify a tracking operation. Apple privacy and data-use guidance.
Audit what the selected SDK actually does, how it is configured and whether the app's declared practices match the artifact. Do not claim that merely adding a privacy manifest proves that no tracking occurs, or that every ad request always requires the same permission prompt.
Keep explanations accurate and avoid coercive interaction design. A user should understand the relevant choice and still receive the core behavior your product and applicable requirements promise.
Handle refusal and later changes
Refusal is a normal state to test. Verify that the app does not repeatedly prompt, silently enable a prohibited path or break a completed user task. If a documented non-personalized or restricted mode is available, validate its actual requirements rather than assuming it is exempt from every obligation.
Users can change choices. Provide the required re-entry path and refresh eligibility appropriately. Stop or reconfigure future requests when a state changes. Determine what queued requests and cached creatives may do under the selected SDK's documented lifecycle.
Deleting an application account and changing an advertising preference are different operations. Map retention and deletion separately across application storage, analytics and advertising partners. Do not claim a preference update automatically deletes all historical data.
Keep initialization and rendering honest
Some SDKs may perform work during initialization; verify this in documentation and a controlled network inspection. Defer initialization when required and configure settings before the first request. Don't assume that delaying a visible ad delays every SDK network call.
For server-mediated integrations, distinguish the server's response from the client's rendering. A server cannot infer a valid visible impression from its own HTTP success. Follow documented event semantics and do not synthesize reward eligibility from a response payload alone.
Maintain a remote disable mechanism for problematic placements or SDK versions. Disabling the visual component may not disable all background traffic, so test the whole data path.
Test the state matrix on the actual runtime
At minimum cover fresh installation, returning user, required interaction, refusal, permitted requests, later preference changes, offline startup, configuration errors and repeated callbacks. Include background/foreground transitions and navigation during the flow. Use provider test modes or documented test devices; do not generate fraudulent live traffic.
Record OS, device, app build, SDK/adapters, configuration and observed destinations. Redact identifiers from captured artifacts. Our article presents this test plan; it does not claim that any particular mobile SDK was device-tested here.
Add negative assertions: no ad request before the permitted state, no duplicate request from two callbacks, no prompt data in event payloads and no secret in client logs. A successful happy-path screenshot is insufficient evidence for these boundaries.
Release with an evidence packet
Keep the dependency inventory, configuration export, state-transition design, test results and current disclosures together. Assign an owner and review trigger for SDK updates, new partners or changed data use. A partner addition is a privacy and performance change, not merely another revenue source.
Connect the integration to monetization economics and auditable revenue metrics. Release only the runtime and format for which the evidence is adequate. Where package publication, lifecycle behavior or data handling is unverified, record the gap and withhold production claims until it is resolved.