How to Choose a Mobile Measurement Partner (MMP)

A mobile measurement partner (MMP) is a third-party platform used to measure app acquisition and post-install events across multiple media sources. It can apply a consistent attribution method, deduplicate eligible claims, send conversion signals to advertising platforms and provide cohort or raw-data reporting.

An MMP is valuable, but it is not a perfect source of causal truth. Platform reports and MMP reports can differ because they use different attribution logic, windows, data availability, privacy frameworks and modelling. An install credited to a campaign is not necessarily an incremental install. Mature measurement combines operational attribution with product analytics, finance data and, where feasible, incrementality testing or marketing-mix analysis.

Choose the platform by starting with the decisions the business needs to make—not with a feature grid or vendor demo.

TL;DR

• Define channels, markets, app journeys, business events and reporting users before comparing MMPs.
• An MMP can create a consistent operational attribution view, but it cannot remove Apple or Android privacy constraints or prove incrementality by itself.
• Verify support for your exact networks and use cases: install, re-engagement, deep linking, web-to-app, subscriptions, ad revenue and offline outcomes.
• Design event names, parameters, value, currency, identity and consent rules before implementation.
• Test raw-data export, API limits, retention, data location and deletion—not only dashboards.
• Evaluate SDK and server-to-server architecture with engineering, security, legal and privacy teams.
• Model total cost at realistic future volume, including fraud, deep-linking, data export, support and overage modules.
• Plan migration as a data and campaign transition. Historical continuity can be preserved in a warehouse even when it cannot be recreated in the new interface.

What an MMP does

Operational attribution across media sources

An MMP receives eligible campaign, install, open and in-app signals, then applies configured rules to assign credit. This gives acquisition teams a common view across supported sources.

The word “common” matters more than “true”. A network may report conversions using its own models and windows, while the MMP applies another framework. Google explicitly notes that discrepancies can arise from conversion eligibility, pre-filtering, aggregation and implementation differences. Reconciliation should explain differences rather than force every tool to match.

Post-install event and revenue measurement

Installs say little about user quality. The implementation can record activation, account creation, trial, purchase, renewal, ad revenue, churn or another business milestone—subject to user choice, platform policy and applicable law.

Events can support cohort analysis and value-based optimisation. Their usefulness depends on correct semantics. An event called purchase without currency, transaction identifier, refund handling or product context can create confident but misleading ROAS.

Conversion sharing with advertising platforms

The MMP can send approved events or postbacks to media partners so campaigns optimise beyond the install. Google, for example, has an App Attribution Partner programme through which selected third-party providers can link and import app conversions.

Decide which events each network receives. Sending every event is not automatically better: data minimisation, consent, platform policy and optimisation intent all matter.

Deep linking and re-engagement

Many MMPs also manage links that route a user to relevant in-app content, including deferred deep linking after installation. Verify the exact behaviour for iOS, Android, web fallbacks, existing users and unavailable content.

Attribution and routing are related but distinct. A link can open the correct screen while attribution fails, or attribution can register while the user lands on a poor generic experience. Test both.

Fraud controls

Fraud modules can identify or reject patterns such as click flooding, install hijacking, device farms or abnormal event behaviour. Capabilities, evidence and commercial impact vary.

Ask whether a rule blocks attribution, blocks a postback, flags traffic for review or affects billing. Ensure rejected traffic is visible and disputable. Fraud prevention does not replace network governance and incrementality analysis.

Why platform reports do not form one total

Different systems answer different questions.

A user may interact with several ads before installing. Multiple platforms may claim influence under their own rules. The MMP can select credit under its rules, but that does not prove the other interactions had no effect. Avoid describing attribution as an objective reconstruction of causality.

iOS measurement: what the MMP cannot change

iOS app measurement can combine several signal paths, depending on user choice, platform eligibility and implementation.

AppTrackingTransparency

Apple states that apps must request permission through AppTrackingTransparency (ATT) to track a person across other companies' apps or websites or to access the advertising identifier on supported operating systems. An MMP cannot bypass that requirement. SDK behaviour, data sharing and App Store privacy disclosures must match the app's actual practices.

AdAttributionKit

Apple recommends AdAttributionKit for app advertising campaigns. It is a privacy-preserving framework in which devices produce signed postbacks for eligible downloads and re-engagements. Data detail depends on Apple's privacy protections and may include fine or coarse conversion values when conditions are met.

Apple documents a minimum 24–48 hour interval between an eligible conversion and receipt of a production postback. It also supports multiple conversion windows and distinguishes winning from certain non-winning postbacks. Re-engagement support has its own rules and limits.

The MMP can help configure, collect, validate and interpret these postbacks, but cannot turn them into unrestricted user-level histories. During evaluation, ask:

• which AdAttributionKit and SKAdNetwork capabilities are supported;
• how interoperability and transition are handled;
• how conversion schemas are versioned;
• how winning, non-winning, coarse, fine and null data are displayed;
• how delayed postbacks are blended—or deliberately not blended—with other attribution;
• how re-engagement is reported;
• which fields are observed, inferred or modelled.

Apple's SKAdNetwork documentation now directs developers to use AdAttributionKit for relevant campaigns, so a selection process based only on old “SKAN 4 support” checklists is incomplete.

Android measurement is also evolving

Google Play's Install Referrer API can securely provide referral information such as the referrer URL and click/install timestamps for eligible Google Play installs. MMPs commonly use it as one Android input.

Android is not a permanently unconstrained alternative to iOS. Google's Privacy Sandbox Attribution Reporting API is designed to support app and web attribution without reliance on cross-party identifiers. Its current documentation describes event-level and aggregatable reports, with limits, delays and noise; Google also labels parts of the design as subject to change.

Ask vendors which Android capabilities are production-ready, beta or roadmap. Avoid buying on a slide that treats a proposal as a generally available feature.

Start with a measurement requirements document

Before demonstrations, define the decisions the system must support.

Acquisition decisions

• Which networks, agencies and owned channels need attribution?
• Do you buy web-to-app, app-to-app, QR, influencer, connected TV or offline media?
• Which markets and app stores matter?
• Are install, re-engagement and cross-device journeys in scope?

Product and value decisions

• What defines activation?
• Which purchase, subscription, renewal, ad-revenue or retention outcomes matter?
• Is gross revenue sufficient, or is contribution/margin needed?
• How are refunds, cancellations and free trials treated?
• How quickly does enough value emerge to guide optimisation?

Data users

• Which decisions happen in the MMP interface?
• What must go to a warehouse, BI tool, product analytics or finance model?
• Which data must return to each advertising platform?
• Who needs row-level access, aggregated reports or scheduled alerts?

Governance

• Which legal entities are controller, processor or independent controller for each data flow?
• What consent and deletion mechanisms are required?
• Where may data be stored and transferred?
• How long should data be retained?
• Who approves SDK releases and taxonomy changes?

This document prevents a common error: selecting a platform that demos well but does not support the organisation's actual data flows.

MMP evaluation scorecard

Weight the criteria for the business rather than counting features.

Create pass/fail requirements for critical integrations, privacy and raw-data access. A high total score should not compensate for a missing requirement that makes the system unusable.

Event taxonomy before SDK implementation

The taxonomy is a data contract across product, engineering, marketing and analytics. It should define:

• canonical event name and business meaning;
• exact trigger and excluded cases;
• required and optional parameters;
• value, currency, tax, refund and transaction-ID logic;
• user/account identifiers and when they are permitted;
• consent requirements and destinations;
• deduplication key;
• owner, version and validation query;
• retention and deletion implications.

Prefer a small set of decision-relevant events over hundreds of undocumented signals. Reuse consistent product analytics events where appropriate, but do not assume every internal event should be sent to advertising partners.

Example purchase contract

Server-side revenue or subscription data may be more reliable than trusting only a client event. The correct design depends on the product architecture and vendor capabilities.

SDK, server-to-server and technical due diligence

An SDK is not a one-time checkbox. It is third-party code that affects app releases, privacy disclosures, security review, startup performance and maintenance.

Engineering should assess:

• supported OS and framework versions;
• binary size and runtime impact;
• initialization and consent sequencing;
• offline event queueing and retry behaviour;
• duplicate and out-of-order handling;
• SDK signing, privacy manifest and release cadence;
• crash and incident history;
• server-to-server support and authentication;
• test environments and debug tooling;
• kill switch or remote-disable options;
• compatibility with existing analytics and consent architecture.

Server-to-server collection can strengthen certain business events but does not automatically solve attribution. The design still needs a lawful and technically valid way to associate eligible campaign signals with backend outcomes.

Raw data and portability

Do not accept “API available” as proof of portability. Run a proof of concept.

Check:

• whether event-level fields needed by the warehouse are included;
• export latency and backfill capability;
• API rate limits and pagination;
• retention and re-download window;
• time zones and timestamp semantics;
• identity and consent fields;
• rejected, organic and unattributed records;
• costs for raw data, connectors and extra destinations;
• what can be exported after termination.

Where possible, continuously export canonical acquisition and event data to a company-controlled warehouse. This does not make future MMP outputs directly comparable, but it preserves the old methodology and enables a documented bridge during migration.

Privacy and security are selection criteria

An MMP can process advertising identifiers, IP addresses, device data, purchase events or customer identifiers depending on the setup. Involve privacy, legal and security teams before the SDK ships.

Review:

• purpose and lawful basis or consent by market;
• ATT and other platform permissions;
• data minimisation and partner postbacks;
• controller/processor roles and contract terms;
• data location, transfers and subprocessors;
• user access, SSO and audit logs;
• retention, deletion and data-subject request support;
• security certifications and incident notification;
• children's data, health, finance or other sensitive contexts;
• App Store and Google Play disclosure obligations.

This article is a measurement framework, not legal advice. The implementation must be reviewed for the app, jurisdictions and audiences involved.

Pricing: model total cost at scale

MMP pricing varies by vendor and agreement. It may be based on attributed conversions, installs, monthly active users, events, data volume or a negotiated package. Features such as fraud, deep linking, advanced analytics, incrementality, audiences and premium support may be separate.

Build three scenarios:

Add implementation, privacy/security review, data engineering, maintenance, app releases, training and migration to the licence fee. Negotiate how volume is measured, how overages are approved and how prices change at renewal.

When an MMP may not be necessary

A third-party MMP is not compulsory for every app. A smaller advertiser using a narrow Google ecosystem may use Google Analytics for Firebase, Google Play conversion sources and Google Ads integrations. Firebase can also export raw, unsampled Analytics events to BigQuery, subject to product limits and configuration.

An MMP becomes more compelling when the business needs:

• comparable operational reporting across multiple paid networks;
• certified third-party network integrations;
• deep linking and re-engagement infrastructure;
• consistent post-install event sharing;
• fraud controls for a broader supply mix;
• acquisition cohorts and raw attribution exports;
• one governed process across agencies and markets.

The decision should compare the incremental control and labour saved with the total implementation and licence cost.

Migration without losing the measurement record

Switching MMPs can affect SDKs, links, network connections, attribution rules, dashboards, postbacks, audiences and campaign learning. It does not mean all historical evidence must disappear.

Use a migration plan:

1. Inventory the current system. Events, parameters, links, partners, exports, audiences, attribution settings and owners.
2. Export and document history. Preserve raw data, reports, schemas and methodology under the existing contract.
3. Map old to new. Record semantic and attribution differences; do not silently rename incompatible metrics.
4. Build and test. Validate app and server events, privacy states, deep links, revenue and partner postbacks.
5. Plan coexistence carefully. A limited overlap may aid comparison, but duplicate SDKs/postbacks can create privacy, performance and optimisation risks. Agree the method with both providers and networks.
6. Choose the cutover. Consider app release adoption, campaign learning, reporting cycles and seasonality.
7. Annotate the break. Dashboards must show that methodology changed; year-on-year differences are not automatically performance changes.
8. Decommission deliberately. Remove obsolete SDK/configuration, revoke access and confirm data retention or deletion.

Historical dashboards may not transfer into the new interface. A company-controlled warehouse and clear methodology preserve more continuity than relying solely on either vendor UI.

Implementation and acceptance plan

Phase 1: design

• approve requirements, event taxonomy and data-flow map;
• select attribution and consent rules;
• define validation queries and acceptance criteria;
• establish account ownership and environments.

Phase 2: technical implementation

• integrate supported SDK and server events;
• configure platform credentials, partner links and deep links;
• implement privacy states and disclosures;
• connect raw-data export and business systems.

Phase 3: QA

• test clean install, reinstall and re-engagement;
• test click, view and organic paths where supported;
• validate currency, revenue, transaction deduplication and refunds;
• confirm partner postbacks under each consent state;
• inspect delayed and aggregated framework outputs;
• compare backend, analytics, MMP and network records with expected differences.

Phase 4: controlled launch

• release to a limited population if the app architecture allows;
• monitor event loss, duplicates, crashes and reporting latency;
• document the baseline discrepancy by source;
• only then use downstream events for bid optimisation.

Acceptance should mean that the defined journeys work and reconcile within explained tolerances—not that every dashboard has the same total.

Space Ads approach to MMP selection

We begin with acquisition and business decisions, then map the event, value, consent and postback architecture needed to support them. Vendor selection follows the requirements document and a hands-on proof of concept rather than a generic feature comparison.

The measurement plan distinguishes operational attribution from incrementality and reconciles MMP, network, product and finance views. Implementation is validated before downstream events influence bidding, and the business retains access to its taxonomy, accounts, exports and methodology.

FAQ

What is a mobile measurement partner?

An MMP is a third-party app measurement platform that connects eligible campaign interactions with installs and in-app events across supported sources. It can provide consistent attribution rules, postbacks, deep linking, cohorts, raw data and fraud controls depending on the product.

Is an MMP a single source of truth?

It can be the agreed operational source for cross-network attribution, but it is not causal truth. Platform models, privacy postbacks, product analytics and finance data answer different questions. Incrementality needs additional methods.

Does an MMP solve iOS attribution?

It helps implement and interpret available signal paths, including AdAttributionKit, but cannot bypass ATT or Apple's privacy protections. Expect delayed, aggregated or limited data in relevant contexts and ask the vendor to label observed and modelled outputs clearly.

What is the most important MMP selection criterion?

There is no universal winner. Critical requirements are usually exact media integrations, privacy-framework support, event and raw-data flexibility, deep-linking needs, security/privacy fit and sustainable total cost. A missing must-have should outweigh a long feature list.

How much does an MMP cost?

Pricing is vendor-specific and may depend on conversions, installs, MAU, events, data or negotiated tiers. Model licence, modules, overages, implementation, engineering, privacy review and maintenance at current, growth and peak volume.

Can I use Firebase instead of an MMP?

For some businesses, yes. Firebase/Google Analytics can measure app events, integrate with Google products and export Analytics data to BigQuery. A third-party MMP is more useful when comparable attribution, deep links and partner connections are required across a broader media mix.

How difficult is it to migrate MMPs?

Migration can be substantial because it affects code, links, partner integrations, schemas, data exports and optimisation signals. Preserve historical raw data and methodology, test a controlled cutover and explicitly annotate the measurement break.

Should the app send every event to ad networks?

No. Send the minimum events needed for a defined reporting or optimisation purpose, consistent with user choice, law and platform terms. Internal product analytics can retain a richer taxonomy than partner postbacks.

Key takeaways

• Choose an MMP against a written measurement and governance specification.
• Treat attribution as an operational decision model, not proof of causality.
• Verify current AdAttributionKit, Android, ATT and partner capabilities with live documentation and tests.
• Make event semantics, value, consent and deduplication part of one data contract.
• Prove raw-data portability and security/privacy fit before signing.
• Calculate total cost at growth and peak scale.
• Preserve history in company-controlled storage and plan migration methodically.
• Validate downstream outcomes before using them for campaign optimisation.

See how Space Ads approaches web and app analytics, and continue with our guide to SKAdNetwork and AdAttributionKit.

Sources and further reading

• AdAttributionKit — Apple Developer
• Receiving AdAttributionKit postbacks — Apple Developer
• User privacy and data use — Apple Developer
• Google Play Install Referrer — Android Developers
• Attribution Reporting for mobile — Privacy Sandbox
• Google Ads App Attribution Partners — Google Ads Help
• Comparing app conversions in Google Ads — Google Ads Help
• Google Analytics for Firebase reports and BigQuery export