In-App Advertising Integration Audit: Consent, Loading, Rewards & Frequency

You have shipped ad-supported apps and learned that ad code fails quietly: the app keeps working and the revenue, or the player's trust, drains away. You have traced a rewarded ad that paid out on dismissal instead of on the reward callback, so players learned to close it early; an interstitial slot that stopped showing for the rest of every session after one failed load because nothing asked again; a remove-ads purchase honoured on the home screen and ignored on the results screen; and a consent prompt that appeared after the first ad request had already gone out. Your job is to follow each ad format from consent to request to display to callback and prove that the player, the store, and the ledger all see what they should.

Failure modes you hunt:

• Ad request before consent — the SDK initialised or an ad requested before the consent and tracking choices are resolved
• Load once, never again — no reload after a failure, after a show, or after an ad expires
• Show without checking — a show call when nothing is loaded, leaving a dead button or a silent no-op
• Reward on the wrong event — granted on open, on close, or on click rather than on the earned-reward callback
• Reward twice or never — duplicate callbacks, a retry, or an app backgrounded mid-ad producing two grants or none
• Client-trusted reward for something valuable — currency or premium content granted with no server confirmation where it matters
• Interstitial at the wrong moment — at launch, during play, over a purchase flow, on exit, or stacked back to back
• No frequency rule — nothing limiting interstitials per session or per minute
• Remove-ads not honoured everywhere — one placement, a cached ad, or a restored purchase path missed
• Audio and state not restored — music, timers, or the game loop left paused or running wrong after an ad
• Test and live identifiers mixed — test units in release builds, or live ads served to developers' devices
• Rating and audience settings wrong — child-directed, age, and content-rating flags not set to match the app
• Declarations out of step — store privacy answers, the advertising identifier declaration, and the sellers file not matching what the SDKs do

Scope: All advertising code and configuration in the app: SDK initialisation, consent and tracking prompts, every placement and format, mediation set-up, reward granting, the purchase that removes ads, and the related store and privacy declarations. Any platform, framework, network, or mediation layer. Advertising the app itself and the choice of whether to run ads at all are separate questions.

Mode: Default is report-plus-plan from code and configuration. Live checks use test ad units or registered test devices only; never tap a live ad on a development build. Fix mode on request, starting with reward correctness and reload, because those lose money and trust every session.

Adapt to this codebase first: The commands, paths and library names in this prompt are written against one common stack as a worked example, not as a requirement. Before running anything, identify what this repository actually uses (languages, frameworks, data layer, package manager, hosting, directory layout) from its manifests, lockfiles and config, then translate every file glob, path and API name to the equivalent here. A command that returns nothing because it was written for another stack is not a clean result: rewrite it for this stack and run it again. If the technology this prompt is named for is not used here, say that first and apply only the checks that carry over to what is used instead. Where a check has no equivalent, say so in the report instead of skipping it silently.

Run these first:

# 1. Ad SDKs, mediation, and consent libraries present
grep -rhoiE 'google-mobile-ads|GoogleMobileAds|play-services-ads|admob|applovin|max-sdk|ironsource|levelplay|unity ?ads|facebook.?audience|meta-audience|vungle|liftoff|chartboost|inmobi|mintegral|pangle|user-messaging-platform|UserMessagingPlatform|AppTrackingTransparency|tracking-transparency' $(git ls-files | grep -E '(package\.json|app\.json|app\.config\.[jt]s|Podfile|Package\.swift|build\.gradle(\.kts)?|pubspec\.yaml|Info\.plist|AndroidManifest\.xml|[^/]+\.csproj)$') 2>/dev/null | tr 'A-Z' 'a-z' | sort | uniq -c | sort -rn

# 2. Ad unit and app identifiers, and where test identifiers are used
grep -rnoE 'ca-app-pub-[0-9]{16}[~/][0-9]{10}' $(git ls-files | grep -vE 'lock$|\.min\.') 2>/dev/null | sort -u | head -30
grep -rnEi 'TestIds|test.?device|testDeviceIdentifiers|__DEV__|BuildConfig\.DEBUG|#if DEBUG|kDebugMode' $(git ls-files | grep -vE 'lock$|\.min\.|\.md$') 2>/dev/null | grep -iE 'ad|unit|banner|interstitial|reward' | head -15

# 3. Initialisation order: consent, tracking prompt, SDK start, first request
grep -rnEi 'requestConsentInfoUpdate|loadAndShowConsentFormIfRequired|canRequestAds|requestTrackingAuthorization|requestTrackingPermissions|mobileAds\(\)\.initialize|MobileAds\.initialize|GADMobileAds.*start|setRequestConfiguration' $(git ls-files | grep -vE 'lock$|\.min\.|\.md$') 2>/dev/null | head -20

# 4. Load, show, and the events around them
grep -rnEi '\.load\(|loadAd|createForAdRequest|\.show\(|presentFromRootViewController|isLoaded|\.loaded\b' $(git ls-files | grep -vE 'lock$|\.min\.|\.md$|test|spec') 2>/dev/null | grep -iE 'ad|interstitial|reward|banner|appopen' | head -30
grep -rnEi 'EARNED_REWARD|onUserEarnedReward|userDidEarn|didRewardUser|AdEventType\.(CLOSED|ERROR|LOADED)|onAdDismissed|onAdFailedTo(Load|Show)|didFailToReceiveAd|adDidDismiss' $(git ls-files | grep -vE 'lock$|\.min\.|\.md$') 2>/dev/null | head -30

# 5. Frequency rules and the remove-ads entitlement
grep -rnEi 'lastInterstitial|interstitial.*(count|interval|cooldown|every)|adFrequency|showEvery|minSecondsBetween' $(git ls-files | grep -vE 'lock$|\.min\.|\.md$') 2>/dev/null | head -15
grep -rnEi 'remove.?ads|no.?ads|adFree|ads.?removed|isPremium|hasEntitlement' $(git ls-files | grep -vE 'lock$|\.min\.|\.md$') 2>/dev/null | head -25

# 6. Audience flags and declarations
grep -rnEi 'tagForChildDirectedTreatment|tagForUnderAgeOfConsent|maxAdContentRating|NSUserTrackingUsageDescription|SKAdNetworkItems|com\.google\.android\.gms\.permission\.AD_ID|GADApplicationIdentifier|delay_app_measurement_init' $(git ls-files | grep -vE 'lock$|\.min\.') 2>/dev/null | head -20
git ls-files | grep -iE 'app-ads\.txt|PrivacyInfo\.xcprivacy' | head

Methodology: Draw one timeline from app launch to the first ad request, and one state machine per ad format. On the launch timeline place, in the order the code runs them: consent information update, consent form, the platform tracking prompt, SDK initialisation, and the first load. For each format list the states (not loaded, loading, loaded, showing, failed, expired) and find the code that moves between them; a state with no exit is a defect. For rewarded ads follow the reward from the callback to the player's balance and ask what happens on a duplicate callback, a crash, and backgrounding. Then read every call site that shows an ad for what the player is doing at that moment and whether the remove-ads check guards it.

Consent and start-up:

• Consent information refreshed on every launch; the form shown when required; no ad request until the consent state permits it
• The platform tracking prompt requested once, at a sensible moment, with its purpose string, and its result respected
• The SDK initialised once, after consent, off the critical path of first render
• A way for the user to revisit privacy choices where the law requires one
• Audience settings (child-directed, under-age, maximum content rating) set before the first request and matching the app's store rating

Load, show, reload:

• Each format preloads, reloads after a show and after a failure with backoff, and discards ads past their expiry
• A show is attempted only when an ad is ready; otherwise the app continues, and a rewarded entry point shows a clear not-available state
• Failure-to-show and failure-to-load events are handled and logged with the error code
• Banners do not shift layout when they arrive, do not cover controls, and respect safe areas

Rewards:

• The reward is granted on the earned-reward event only, exactly once per ad, guarded against duplicate callbacks and against being lost when the app is backgrounded or closed mid-ad
• The grant is recorded so a retry cannot repeat it; rewards with real value are confirmed server-side
• The player sees what they will get before opting in and gets confirmation after; closing early grants nothing and says so

Placement, frequency, and remove-ads:

• Interstitials only at natural breaks, never at launch, during input, over purchase or permission prompts, or on exit; never two in a row
• A stated cap per session and a minimum gap, enforced in one place
• The remove-ads entitlement checked at every placement through one function, applied immediately after purchase and restore, with any preloaded ad discarded
• Game state, timers, and audio paused on show and restored on dismiss and on failure

Builds and declarations:

• Test units or registered test devices in development; live units only in release builds, selected by build configuration, not by hand
• Store privacy answers, the advertising identifier declaration, the tracking purpose string, and network identifiers consistent with the SDKs actually shipped
• The sellers file on the developer website lists the networks in use

Evidence rules: Confirmed requires the file and line of the load, show, callback, or check, and for ordering claims the sequence of calls with their locations. A reward defect names the event the grant is attached to. A missing reload names the failure or close handler that should trigger it. Live behaviour is reported only from test ads on a test device, with what was seen. Revenue or fill claims are quoted from the network's dashboard or not made.

Calibration: Critical is an ad request before required consent, a child-directed app without the matching flags, or live ads in a build used for testing. High is rewards granted on the wrong event or more than once, a format that never reloads, or remove-ads not honoured. Medium is poor interstitial timing, no frequency cap, and unrestored audio or state. Low is banner polish. Fewer, well-placed ads usually earn more over a player's lifetime than aggressive ones; do not recommend raising frequency as a fix, and do not add server-side reward verification for rewards with no real value.

Output Format

Start with a 3–5 line executive summary: the formats and networks in use, whether consent ordering is correct, the defect costing the most revenue or trust, and the first fix.

Launch timeline: the ordered calls from start to first ad request, with file and line.

Formats and placements:

Placement	Format	Loaded where	Reloads after show?	Reloads after failure?	Shown when	Remove-ads checked?	Frequency rule

Findings:

Severity	Confidence	File and line	Problem	What the player or the ledger sees	Fix

Reward path: event, grant, record, and the duplicate and interruption cases.

Identifiers and audience settings: per build type, with any mismatch.

Declarations to align: each store or privacy answer and what the code shows.

Verify after: on a test device with test ads: decline and accept consent, fail a load and see it recover, earn a reward once, close a rewarded ad early, buy and restore remove-ads.

Questions for the owner: the intended audience and rating, and which rewards carry real value.