Are we a fit?

Audiencelab supports two legitimate operating models. Keep an MMP when you need its broader channel coverage, reporting continuity, or governance. Use Audiencelab without a separate MMP when your paid acquisition and required reporting stay within Audiencelab-supported networks and data paths.

Model 1: Audiencelab with an MMP

This model is a strong fit when:

• You already use AppsFlyer, Adjust, Singular, or another MMP and want to preserve reporting continuity.
• Your media plan includes DSPs, CTV, traditional campaigns, or partner workflows outside Audiencelab's supported network paths.
• Finance, analytics, or operations require an established MMP source of record.
• You want Audiencelab to add web-to-app workflows, creative-level learning, signal design, and supported-network activation.

The MMP remains the formal attribution and governance layer. Audiencelab ingests approved MMP exports, warehouse data, SDK events, or server-to-server inputs and runs its reporting, learning, and activation workflows for the supported scope.

Model 2: Audiencelab without an MMP

A separate MMP is not required when all of the following are true:

• Your paid acquisition stays within the ad networks and campaign paths Audiencelab currently supports.
• Audiencelab's campaign and creative reporting covers the views, definitions, exports, and controls your team requires.
• An approved SDK, server-to-server, API, app, or warehouse path provides the required outcome data.
• The team has declared how attribution windows, deduplication, cohort maturity, and governance will work.

Under this model, Audiencelab covers reporting, web-to-app measurement, creative-outcome analysis, signal engineering, and supported-network activation. Add an MMP later if the media mix or reporting requirements expand beyond that scope.

What each layer can own

Read the full Audiencelab and MMP operating-model comparison.

Why aggregate coverage matters

The Audiencelab workflow is not technically dependent on IDFA or an ATT-opted-in cohort. Depending on the approved data path, it analyzes eligible aggregate outcomes beyond an IDFA-only population.

Broader eligible coverage makes reporting more complete and more accurate than a view restricted to users with an available advertising identifier. More complete outcome coverage creates more eligible purchase, ad-revenue, retention, and value signals for supported ad networks. That gives network algorithms more useful learning input and improves optimization toward valuable users.

This is a scoped capability claim, not a universal accuracy percentage or performance guarantee. Accuracy depends on source quality, definitions, deduplication, windows, cohort maturity, and the implementation. Network performance also depends on creative, product economics, audience, market, spend, and campaign setup.

What the Nanobit case supports

In the published Nanobit case study, TikTok for Business reports $1.13 CPI, 2.08 total ROAS, and 1.68 day-7 ROAS. TikTok says advanced signal engineering created a more comprehensive optimization signal by combining in-app purchase and ad-revenue data, and identifies signal engineering as one of two key performance drivers alongside creator strategy.

Read the official TikTok for Business case study.

The case is evidence for that campaign context. It does not isolate Audiencelab as the only cause and does not guarantee the same result elsewhere.

How the iOS path differs

Audiencelab's current web-first measurement and activation path does not use or depend on SKAdNetwork. That removes SKAN conversion-value and postback operations from the Audiencelab workflow. If an MMP is part of the stack, it may still use SKAdNetwork, AdAttributionKit, or other Apple-supported measurement for its reporting scope.

This is an architecture statement, not a claim that Apple attribution frameworks are unnecessary for every product or campaign. Apple documents how AdAttributionKit and SKAdNetwork can operate together.

ATT, consent, and required-reason APIs

Aggregate coverage does not mean every user or event can automatically be used. Any user- or device-level linking must follow Apple's ATT rules, applicable law, customer disclosures, data minimization, and destination-platform terms.

The Audiencelab SDK does not directly invoke Apple's UserDefaults or another required-reason API. It therefore adds no required-reason API declaration of its own. In Unity integrations, PlayerPrefs is Unity's abstraction: the underlying UserDefaults access belongs to the Unity runtime, and Unity provides the corresponding Unity Engine declaration. The privacy-control PlayerPrefs example in this documentation is host-project code, not a native required-reason API call made by the Audiencelab SDK.

Apple assigns required-reason declarations to the app or SDK code that actually uses the API. Customer code and other embedded SDKs must still provide any declarations that apply to them. See Apple's required-reason API guidance and Unity's privacy-manifest policy requirements.

Questions to answer before implementation

1. Which ad networks and campaign types are in the active media plan?
2. Does Audiencelab cover every required reporting and activation workflow, or is an MMP still needed for part of the plan?
3. What outcome, attribution window, baseline, and cohort maturity define success?
4. Which SDK, server, MMP, warehouse, or API data path is approved?
5. Which inputs are aggregate, which are user- or device-level, and which consent or disclosure rules apply?
6. Who owns event quality, deduplication, privacy review, reporting governance, and future changes?

Map the right stack

Bring your media plan, current reporting setup, data sources, and governance requirements to a stack review. We can map the supported-network scope, decide whether an MMP adds necessary coverage, and document what must be validated before launch.

Email support or book a 30-minute stack review.