What an MMP SDK Collects from a Device

What does an MMP SDK send?

An MMP SDK sends the signals the MMP needs to match an app install or event to a click or impression, plus the events you choose to measure.

The exact list differs by vendor and by settings. The groups below are what the vendor docs and SDK manifests on this site typically describe. Treat them as a checklist for reading a specific vendor's privacy documentation, not as a statement about any one SDK.

Device and app details

Sent with almost every request so the MMP can tell devices and app versions apart:

• device model, OS name and version, language and time zone
• app version and build, and the SDK version
• the IP address the request comes from, which the server sees whatever the SDK does
• timestamps for first open, sessions and events

Several vendors use IP address and user agent only as a fallback for probabilistic matching, where privacy rules and the platform allow it. Linkrunner, for example, describes its matching as deterministic first, with IP and user-agent matching only as a fallback when no deterministic signal exists. Check each vendor's documentation for how it uses them.

Platform identifiers

These carry the most privacy weight, and each platform controls them:

• IDFA (iOS): only available after the user allows tracking in Apple's App Tracking Transparency prompt. Without consent it reads as zeros.
• IDFV (iOS): a per-vendor identifier that doesn't need ATT consent, commonly used to count devices across your own apps.
• Google Advertising ID (Android): apps targeting Android 13 (API 33) or later must declare com.google.android.gms.permission.AD_ID to read it. Several SDKs declare it for you; child-directed apps usually remove it.
• App Set ID (Android): a per-developer identifier that some SDKs read alongside the advertising ID. Tenjin's Flutter plugin, for example, bundles the App Set ID library.

On each vendor datasheet, the Android permissions line shows what that SDK declares, from its docs or its published manifest.

Attribution-specific signals

These exist mainly for attribution:

• Play Install Referrer (Android): the referrer string Google Play passes to the app after install, which carries the click's tracking parameters. It is the main Android signal for Play Store installs. Some SDKs bundle the library; others ask you to add it.
• Click identifiers in deep links: when a user opens the app from a tracking link, the URL can carry a click ID that the MMP matches on its servers.
• SKAN and AdAttributionKit (iOS): the SDK may update conversion values on the device. The postback itself goes from Apple's frameworks to the ad network (and a copy to the MMP if you set it up), without user-level data.

Deep Link Doctor's page on Play Store referrer encoding shows how campaign tags reach the referrer from a store link, and why bad encoding loses them.

Events and revenue you choose to send

The SDK sends the in-app events you log: sign-ups, purchases, levels completed. That part is entirely in your hands:

• Send only the events you use for measurement or ad network optimisation.
• Avoid personal data in event names and values. If you pass an email or phone number for ad network matching, check whether the SDK can hash it on the device first.
• Revenue events usually carry an amount and currency.

Linkrunner, for example, documents opt-in SHA-256 hashing of personal data in its SDK, off by default, and a setConsent call for consent signals. Other vendors offer their own hashing and consent controls, so check each one's privacy docs.

How to check what a specific SDK collects

Don't rely on a summary, this one included. For the SDK you are adding:

1. Read the vendor's data collection or privacy page for the SDK, and the platform-specific docs linked from its datasheet.
2. Check the merged Android manifest after a build. It lists every permission the SDK and its dependencies declare.
3. Check the SDK's iOS privacy manifest (PrivacyInfo.xcprivacy) if it ships one, and use it in your App Store privacy answers.
4. Watch the network calls from a debug build with a proxy, and compare them with the vendor's documentation.
5. Use the SDK's consent and opt-out APIs where your consent setup requires them.

Questions to ask a vendor

• Which identifiers does the SDK read, and on which OS versions?
• Does it read the advertising ID when the user or app has opted out?
• Is personal data hashed on the device, and is that on by default?
• Which permissions does the SDK declare on Android, and can they be removed?
• Where is the data processed and stored?

An SDK is the part of an MMP that lives inside your app, so it deserves the same review as any other dependency. Linkrunner's glossary entry on what an SDK is covers the basics for teammates who are new to the term.