Mobile Integration Overview
MageAds works in a mobile application the same way it works on the web — the same ad server, the same placements, the same reporting. The API contracts are unchanged and are documented under API Integration; this section covers only what an application does differently.
Three things change in an app:
| Web | Mobile app | |
|---|---|---|
| Who the user is | ccxuuid cookie | AAID (Android) or IDFA (iOS) read from the device |
| How events are reported | tracker <script> per event | one SDK call per event |
| Who measures viewability | the JavaScript library | your application |
Everything else — placement codes, campaign setup, product feeds, reporting — is identical.
The three building blocks
1. Identification. The app reads the platform advertising identifier. It replaces the cookie and is what links in-app behaviour to the audience profile used for targeting. No login and no server-side storage are required.
2. Tracking. Eight e-commerce events are reported through the MageAds mobile SDK. This is what feeds retargeting and audience segments. See Mobile SDK.
3. Ad serving. Sponsored products and banners are requested through your own backend and rendered with native views. See Serving Ads in an App.
The three are independent. Tracking works without ads being served, and ads can be served before tracking exists — although targeting quality depends on tracking data.
Two different credentials
An app integration uses two separate keys, and mixing them up is the single most common cause of a failed integration.
| Credential | Used for | Where it lives |
|---|---|---|
| API key | Requesting ads | Your backend only — never in the app |
| Tracker key | Reporting events from the SDK | Ships inside the app |
The API key is a Bearer token for the ads API. Putting it into the SDK configuration makes every event fail, because it is not registered as a tracker key. Ask the MageAds team for the tracker key explicitly — it is not the value your website already uses.
Anything compiled into an application binary can be extracted from it. Ad requests must go through your own backend, which holds the key and forwards the request. This is the only supported architecture for serving ads in an app.
The tracker key is different: it identifies a tracker rather than authorising a privileged call, and events are sent from the device by design.
Privacy and consent
The advertising identifier is personal data in most jurisdictions, and both platforms gate access to it. Neither gate is optional — get them wrong and tracking degrades silently rather than failing loudly.
- Android — the identifier requires the
AD_IDpermission (declared by the SDK) and respects the user's Delete advertising ID setting. Declare what you collect in Play Console Data safety. - iOS — the identifier is zeroed until the user grants App Tracking Transparency consent. You
must add
NSUserTrackingUsageDescriptionand request authorization before the first event.
Both SDKs support an anonymous mode that suppresses sensitive fields and marks the event as anonymous. Use it when consent was refused: the activity still counts towards statistics, but no profile is built.
Where to go next
| You want to | Read |
|---|---|
| Report user activity from the app | Mobile SDK |
| Show ads inside the app | Serving Ads in an App |
| Understand the tracking events themselves | Tracking & Events |
| Understand the ads API | Sponsored Products, Display Ads |
| Get credentials and placement codes | Getting Started |