Mobile App Conversion Tracking: iOS, Android & Cross-Platform

Apple's App Tracking Transparency framework, launched in April 2021, didn't just change iOS attribution. It split mobile measurement into two eras: before and after. Five years on, most guides still treat iOS ATT as a discrete problem to patch rather than a fundamental restructuring of how mobile conversion data works across every platform. This piece covers the full picture: iOS, Android, and web-to-app together, including where your data is leaking, which attribution approaches actually work in 2026, and an honest comparison of the platforms that handle this best.

Tested across more than 20 mobile attribution setups, including apps with mixed Shopify/web funnels, pure app businesses, and hybrid SaaS products that acquire via web and convert inside apps. This includes scenarios where DataCops is the wrong call and where the traditional attribution vendors are the only answer.

Quick Answers

How do I track conversions in a mobile app?

You need three things working together: an SDK inside the app to capture in-app events, a server-side or CAPI layer to send those events to ad platforms, and an attribution method that ties ad clicks to installs and post-install actions. For iOS, Apple's SKAdNetwork (SKAN) provides privacy-preserving attribution that doesn't require user consent. For Android, Google Advertising ID (GAID) still works but is increasingly restricted under Google's Privacy Sandbox rollout. For web-to-app journeys, you also need deferred deep linking and cross-device matching logic.

What is the best mobile app attribution platform?

It depends on your platform mix, team size, and how much you rely on paid UA. AppsFlyer is the market leader for apps spending heavily across multiple networks (Meta, Google UAC, TikTok, AppsFlyer's own network). Adjust is a strong second for mid-market apps wanting clean SDK + server integration. Branch dominates when deep linking and web-to-app journeys are the primary use case. Singular is worth evaluating for cost-efficiency at scale. For web-first businesses with an app component, server-side CAPI tools like DataCops can handle the web side while you layer a lighter attribution SDK for the app portion.

How does iOS App Tracking Transparency affect mobile measurement?

iOS ATT requires apps to ask users for explicit permission before accessing the IDFA (Identifier for Advertisers) for cross-app tracking. Opt-in rates average 15-25% globally (AppsFlyer 2026 data), meaning 75-85% of iOS users are invisible to cross-app attribution. When a user doesn't opt in, IDFA is zeroed out and unavailable. Ad networks fall back to Apple's SKAdNetwork for attribution, which is privacy-preserving but introduces a 24-72 hour reporting delay and carries significant signal limitations compared to deterministic IDFA matching.

What is SKAdNetwork and how does it work?

SKAdNetwork (SKAN) is Apple's privacy-preserving attribution framework. When a user sees an ad on iOS and installs an app, SKAN sends an attribution postback directly from the device to Apple and then to the ad network, without exposing any user-level data. SKAN 4.0 (supported from iOS 16.1+) introduced multiple postbacks (up to three per install), crowd anonymity thresholds, and coarse/fine conversion values. The limitation is that conversion values must be configured in advance using a schema, you get no user-level data at all, and the system applies crowd anonymity delays that can stretch reporting windows significantly.

How do I track cross-platform conversions between web and mobile app?

This requires deferred deep linking combined with a server-side identity resolution layer. When a user clicks a web ad, you capture a click ID (GCLID, fbclid, etc.) and set a first-party cookie. If they later install your app, a deferred deep link carries the attribution context into the app on first open. The challenge is matching the web session to the app session without IDFA on iOS. Branch, AppsFlyer, and Adjust all have probabilistic matching fallbacks for this scenario, though match accuracy drops significantly without device identifiers.

What percentage of iOS users allow app tracking?

Global ATT opt-in rates average 15-25%, meaning roughly 3 in 4 iOS users decline cross-app tracking when prompted. Rates vary significantly by vertical: gaming apps see 10-18% opt-in, utility apps 25-35%, finance apps 20-28%. The framing of the permission prompt matters. Apps that show a pre-permission screen explaining the value exchange before the system prompt see opt-in rates 8-12 percentage points higher than apps that show the system prompt cold (AppsFlyer benchmark data).

How do I set up Google Ads conversion tracking for mobile apps?

Google Ads app conversion tracking uses the Firebase SDK integrated with Google Analytics for Firebase. Once integrated, you import Firebase events as Google Ads conversions. For Android, GAID-based attribution works deterministically when users haven't opted out of ad personalization. For iOS, Google uses SKAN alongside its own probabilistic modeling. You can also use Google Tag Manager for Apps to manage event firing without requiring app updates, though this adds complexity. Server-side import via the Google Ads API (Offline Conversion Import) works for in-app purchase events where you have server-confirmed purchase data.

The Measurement Gap by Platform

Before choosing a tool, you need to know how much data you're actually missing. The numbers differ significantly between iOS and Android, and between app-only and web-to-app journeys.

On iOS, the gap is structural. With 75-85% of users opting out of tracking, SKAN becomes your primary signal for paid acquisition attribution. SKAN is accurate for install attribution on participating networks but provides no user-level post-install data beyond what you encode in conversion values. If you're running campaigns optimizing for purchase events, you can encode purchase value tiers into SKAN conversion values, but you lose the granularity needed for LTV-based bidding. The practical impact: iOS campaign optimization at the user level is significantly degraded compared to pre-ATT.

On Android, the situation is better but changing. GAID still works for the majority of users, giving you deterministic install and in-app event attribution. However, Google's Privacy Sandbox for Android is rolling out the Protected Audience API and Attribution Reporting API as GAID replacements, following a similar direction to Apple. As of 2026, GAID is still dominant but the trajectory is clear. Budget for the eventual transition now.

For web-to-app journeys, the gap compounds. A user clicking a Facebook ad, visiting your web landing page, then installing your app represents three attribution handoffs: web click to session, session to app install, install to in-app conversion. Each handoff loses signal. On iOS, you lose the user-level identifier between web and app. Probabilistic matching using device fingerprinting (screen resolution, OS version, IP) has accuracy rates of 60-75% under ideal conditions, dropping further when users have VPNs or privacy browsers.

Bot contamination adds another layer. Fraudlogix 2026 data puts global invalid traffic at 20.64%, with finance and legal verticals at 42%. For mobile app installs specifically, install fraud (incentivized installs, emulator farms, SDK spoofing) is a persistent problem. AppsFlyer's Mobile Fraud Index estimates that 24-31% of app install attributions show signs of fraud on networks with weaker traffic quality controls. This doesn't mean 24-31% of your conversions are fake, but it means your attribution platform's fraud protection tier matters.

Attribution Stack Decision Framework

Not all apps need the same attribution approach. The right stack depends on your platform mix, acquisition channels, and measurement priorities.

Pure iOS app, single ad network (e.g., Meta only)

SKAN is mandatory for the non-consenting 75-85% of users. Configure a SKAN 4.0 conversion value schema that maps your most important post-install events to fine and coarse values. Use Meta's SKAN support alongside Meta's Conversions API (app events) for the 15-25% who have opted in. You don't need a third-party MMP for this scenario if you're single-network. AppsFlyer or Adjust add value when you're running multiple networks and need unified reporting.

iOS + Android app, multi-network acquisition

This is where a full mobile measurement partner (MMP) becomes necessary. AppsFlyer, Adjust, Branch, or Singular each provide unified SKAN management, GAID attribution for Android, fraud protection, and cross-network reporting dashboards. AppsFlyer has the deepest network integrations (3,000+ partners) and the most mature SKAN management tooling. Adjust is strong for teams wanting more direct SDK control and transparent pricing. Singular offers the best cost-to-feature ratio for apps spending under $500K/month on UA.

Web + app hybrid (web acquisition, in-app conversion)

This is the hardest to instrument correctly and where most teams underinvest. You need: first-party click ID capture on the web side, server-side CAPI for web events to ad platforms, deferred deep linking into the app, a matching layer to resolve web sessions to app installs, and SDK-based in-app event tracking. Branch is purpose-built for this and handles the deep linking and attribution matching well. For the web-side CAPI component, server-side tools including DataCops handle web event forwarding to Meta and Google with bot filtering applied before events reach the platform.

B2B SaaS with mobile app

Trial signups typically happen on web, trials are conducted partially in-app, and purchases convert back on web or via sales. Attribution here is less about install attribution and more about cross-device journey stitching. Focus on your CRM as the identity spine, use server-side event import to connect CRM stage changes to ad platform conversion data, and don't over-engineer the mobile attribution layer if app usage isn't the primary conversion driver.

Platform-by-Platform Attribution: SKAdNetwork vs Probabilistic vs Server-Side

There are three fundamental attribution methods available for mobile in 2026. Understanding the tradeoffs is more useful than choosing a vendor before choosing an approach.

SKAdNetwork (SKAN 4.0)

SKAN is Apple's mandated privacy-preserving framework. It works at the campaign level, not the user level. You get an install postback with a campaign ID and conversion value, but no IDFA, no user-level journey data. SKAN 4.0 improved on previous versions by adding multiple postbacks (for measuring post-install engagement), crowd anonymity thresholds that trigger tiered delays, and fine conversion values with a higher bit count. The practical limitation is configuration complexity: you must define your conversion value schema before running campaigns, and changing it mid-flight resets your optimization window.

SKAN is appropriate when: you're running on iOS and most of your users don't opt in (which is most apps), you're optimizing for install volume rather than LTV-based events, and you're running campaigns on networks with strong SKAN support (Meta, Google, TikTok all support SKAN 4.0 as of 2026).

Probabilistic attribution

Probabilistic matching uses non-unique device signals (IP address, device type, OS version, screen resolution, timestamp proximity) to probabilistically match a click to an install without using an identifier. Accuracy is typically 60-80% under ideal conditions. It degrades in the presence of VPNs, shared IPs (corporate networks, university campuses), and privacy browsers. In markets with high VPN adoption (Southeast Asia, some EU countries), probabilistic matching accuracy can fall below 50%.

Most MMPs use probabilistic matching as a fallback when IDFA is unavailable and SKAN doesn't apply (some edge cases, web-to-app journeys). It's useful as a signal alongside SKAN but shouldn't be treated as deterministic. Apple's App Store review guidelines restrict fingerprinting for attribution purposes, which means some probabilistic approaches that rely on more granular device data may conflict with policy.

Server-side attribution

For the events you can confirm on your server (purchases, subscription activations, trial starts that go through your backend), server-side attribution is the most reliable method regardless of device. You capture the event on your server, attach whatever user identifiers you have (hashed email, phone, customer ID), and send to ad platforms via CAPI. This is how you get credit for conversions that happen in-app when you have server confirmation.

Server-side works for both iOS and Android without dependence on ATT consent or GAID availability. The limitation is that it only works for events your server knows about. Pure client-side in-app events (screen views, feature interactions) that don't touch your backend can't use server-side attribution directly.

Tool Reviews

Mobile Measurement Partners (MMP Tier)

AppsFlyer

AppsFlyer is the market leader in mobile attribution for a reason. Its network partner count (3,000+), fraud protection (Protect360), and SKAN management tooling are best-in-class. The attribution SDK is stable and well-documented. Protect360 actively filters install fraud including emulator farms, SDK spoofing, and click flooding.

What works: comprehensive network integrations, robust SKAN 4.0 support with conversion value management UI, strong fraud protection, deep analytics including cohort LTV modeling, good customer support at enterprise tier.

What doesn't: pricing escalates quickly, entry point is around $500/month and scales with MAU and attributed installs. Teams have complained on G2 about the complexity of the dashboard for smaller teams, and the fraud protection tier (Protect360) is priced separately. SDK size is meaningful for apps where binary size matters. Not a fit for web-first businesses where mobile is a secondary channel.

Who should use it: apps spending $50K+/month on paid UA across multiple networks where accurate cross-network attribution and fraud filtering are worth the platform cost.

Value for money: 7/10 at mid-market, 8/10 at enterprise.

Pricing: custom quote, typically starting $500-2,000/month for mid-market, scaling by attributed installs.

Adjust

Adjust positions as the clean, developer-friendly alternative to AppsFlyer. The SDK is well-maintained, the API documentation is thorough, and the platform has strong server-to-server integration support for teams that want to manage event forwarding themselves. Fraud prevention (Adjust Fraud Prevention Suite) catches click injection, SDK spoofing, and install hijacking.

What works: clean SDK, strong S2S integration, good SKAN support, transparent pricing model, reliable data export, strong EU data residency options for GDPR compliance.

What doesn't: smaller network partner count than AppsFlyer, less mature self-serve tooling for campaign managers (more engineering-oriented), dashboard is functional but not as polished as AppsFlyer's.

Who should use it: mid-market apps with an engineering team comfortable with API integration, teams that want clean data pipelines over a feature-rich UI, EU-based businesses that prioritize data residency.

Value for money: 8/10.

Pricing: custom quote, typically lower entry point than AppsFlyer for comparable MAU ranges.

Branch

Branch's primary strength is deep linking and web-to-app attribution. If your acquisition funnel moves users from web to app (landing page to app install, email to in-app screen, social link to specific in-app content), Branch handles this better than any other platform. Attribution accuracy for web-initiated journeys is meaningfully higher than competitors because deep link data carries attribution context directly.

What works: best-in-class deferred deep linking, strong web-to-app attribution matching, good cross-device journey tracking, solid analytics for measuring the web-to-app funnel.

What doesn't: install fraud protection is weaker than AppsFlyer or Adjust, not the right choice if pure paid UA attribution accuracy is the primary need, pricing can get complex for large-volume deep link use.

Who should use it: hybrid web+app products where users frequently move between web and app contexts, email-driven re-engagement campaigns, content-heavy apps where linking into specific in-app content matters.

Value for money: 8/10 for web-to-app use cases, 6/10 for pure app attribution.

Pricing: free tier available, paid from $59/month, scaling by MAU.

Singular

Singular combines attribution with marketing analytics in one platform, including spend aggregation from ad networks alongside attribution data. For teams running complex multi-channel attribution and wanting unified ROAS reporting in one tool rather than paying for an MMP plus a BI layer separately, Singular is worth evaluating.

What works: unified attribution plus spend data in one platform, good SKAN support, ETL pipeline for data warehouse export, competitive pricing.

What doesn't: smaller engineering team than AppsFlyer/Adjust means slower feature releases, fraud protection is less mature, some niche network integrations are missing.

Who should use it: growth teams managing paid UA across 5+ networks that want attribution and spend reporting unified without building a separate analytics layer.

Value for money: 8/10.

Pricing: from around $599/month, custom above that.

Server-Side CAPI for Web Events

The tools above handle in-app attribution. For the web side of hybrid funnels, server-side CAPI is the relevant layer, specifically for sending web-originated events to Meta, Google, and other platforms.

DataCops

DataCops handles server-side event forwarding from your web properties to Meta CAPI, Google Conversions API, TikTok Events API, and LinkedIn Insight CAPI. The differentiator is its 361B+ IP database that filters bot and invalid traffic before events reach ad platforms, which prevents polluting your algorithm's training data with fake conversions.

For hybrid web+app businesses, DataCops is relevant for the web portion of the funnel: capturing web events (page views, add-to-cart, initiate checkout) server-side and sending them to ad platforms with first-party data. It runs on your subdomain so events survive ad blockers and iOS Safari ITP. The bundled TCF 2.2 CMP handles consent across both web and the consent layer for web-originated events.

What works: bot filtering at the server level before CAPI, first-party subdomain deployment, bundled CMP (saves Cookiebot/OneTrust at $11-10K/month), covers Meta + Google + TikTok + LinkedIn in one stack, simple setup (one script tag + one CNAME).

What doesn't: DataCops is a web-side CAPI tool, not a mobile MMP. It doesn't provide in-app SDK attribution, SKAN management, or install attribution. If your primary conversion tracking need is inside a native iOS or Android app with no web component, DataCops isn't the right tool. SOC 2 Type II is in progress, not complete. Pinterest and Snapchat CAPI are not supported.

For mobile app businesses with a meaningful web acquisition component, DataCops handles the web CAPI layer while an MMP like Adjust or AppsFlyer handles in-app attribution. They're not competitive; they cover different parts of the stack.

Who should use it: web-first businesses with an app component, hybrid SaaS products acquiring via web content, ecommerce brands running web campaigns that drive app installs.

Value for money: 9/10 for the use case it solves.

Pricing: Free (no CAPI), Growth $7.99/month (no CAPI), Business $49/month (CAPI starts here), Organization $299/month, Enterprise custom.

Feature Comparison Table

DataCops is the only tool in this comparison with both bot filtering and a bundled TCF 2.2 CMP. AppsFlyer has the strongest fraud protection for in-app install fraud but it's a separate paid tier. None of the MMPs include a CMP; that's a separate budget line.

Setting Up iOS Conversion Tracking: The Practical Steps

iOS setup has two parallel tracks: the SKAN track for non-consenting users and the CAPI track for consenting users and server-confirmed events.

For SKAN, you need to configure your conversion value schema before launching campaigns. SKAN 4.0 gives you up to 63 coarse conversion values plus fine values (0-63 range). Map your highest-value post-install events to fine values: trial start, first purchase, subscription activation. Map engagement milestones to coarse values. The schema should reflect what you'll actually optimize campaigns against. AppsFlyer, Adjust, and Singular all have schema management UIs that simplify this, but the underlying logic is the same regardless of which MMP you use.

For consenting users (15-25% of your iOS audience), instrument Meta's app events SDK or App Events API to send purchase and registration events. These reach Meta with full IDFA matching and result in higher Event Match Quality scores. Combined SKAN + consented app events gives Meta's algorithm a richer training signal than SKAN alone.

For server-confirmed events (purchases, subscriptions), server-to-server event import bypasses both ATT consent and SKAN entirely for the purpose of ad platform CAPI reporting. You send the event from your server with hashed customer data. This is the most reliable track for purchase attribution and should be prioritized for any event that touches your backend.

Setting Up Android Conversion Tracking

Android attribution is currently more straightforward because GAID works without an equivalent ATT prompt. Users can opt out of ad personalization in their device settings, but the default is opted in, giving you deterministic attribution for most users.

For Google Ads specifically, Firebase SDK integration is the standard approach. Import Firebase events as Google Ads conversion actions in your Google Ads account. For campaigns running on Android, Google's UAC optimization uses the full Firebase event data to optimize installs toward users likely to complete your target in-app event.

Google Tag Manager for Apps (Firebase-based) lets you add or modify event tracking without app store updates, which matters for teams iterating on conversion event definitions. Be aware that GTM for Apps has limitations compared to direct Firebase instrumentation, particularly for events that require server-side confirmation.

Watch Privacy Sandbox for Android. Google's GAID replacement is rolling out through 2026 and 2027. The Attribution Reporting API for Android follows a similar privacy-preserving design to SKAN, with aggregated reports rather than user-level attribution data. Start testing now if you're an Android-first app with significant UA budgets; the transition will require SKAN-style conversion schema thinking applied to Android.

Web-to-App Conversion Tracking

This is where most teams have the largest unaddressed gap. The journey from web ad click to in-app conversion involves three distinct measurement contexts: the web session, the app install, and post-install in-app events.

Step one is capturing click IDs at the web session level. When a user clicks a Google or Meta ad and lands on your web page, capture the GCLID or fbclid in a first-party cookie. If your setup doesn't survive ITP (Safari's 7-day cap on third-party scripts), you lose this ID for a meaningful portion of your traffic. First-party CAPI tools running on your own subdomain preserve this data. The first-party analytics layer at this stage prevents the web session from going dark.

Step two is the app install. If the user installs your app after the web session, deferred deep linking carries attribution context into the app on first open. Branch handles this most reliably for web-initiated journeys. AppsFlyer and Adjust have deferred deep linking built in but Branch's web-to-app matching accuracy is generally superior.

Step three is matching the web session to the app install. On iOS without IDFA, this relies on probabilistic matching (IP + device signals) with the accuracy caveats mentioned above. On Android, GAID provides a more reliable match if the user is signed into their Google account across web and app. For logged-in users with an account that spans web and app, server-side identity resolution using hashed email is the most accurate method regardless of platform.

For the actual in-app conversion events (first purchase, subscription start), server-to-server import to ad platforms is the most reliable signal path. Your backend confirms the purchase, fires a CAPI event to Meta or Google with the customer's hashed email and any available device data. This bypasses both ATT and SKAN for the conversion credit step, giving ad platforms a clean, server-confirmed signal. This is covered in more detail in API-to-API Conversion Tracking Setup.

AppsFlyer vs Adjust vs Branch vs Singular: Direct Comparison

For teams evaluating MMPs, the decision usually comes down to use case fit rather than a clear best-in-class winner.

Choose AppsFlyer if: you're spending $100K+/month across multiple UA channels, install fraud is a material concern, and you need the broadest network partner coverage. The Protect360 fraud suite is genuinely stronger than competitors and worth the additional cost for high-volume UA. The complexity and cost are drawbacks for smaller teams.

Choose Adjust if: you have an engineering team comfortable with API integration, you want transparent pricing, you're building a custom analytics stack that will consume Adjust data via API, or you're in the EU and want strong data residency guarantees. Adjust's documentation is better than AppsFlyer's for technical teams.

Choose Branch if: web-to-app journeys are central to your product, you're running email or SMS campaigns that need to deep link into specific in-app content, or you're a content app where linking to specific screens matters for engagement. For pure paid UA attribution, Branch is a secondary choice.

Choose Singular if: you want attribution plus spend aggregation in one platform, you're managing 5+ ad networks, and you want to avoid building a separate BI layer for marketing performance reporting. Singular's cost per feature is competitive for mid-market budgets.

None of these choices are permanent. SDK migration is real work (typically 2-8 weeks for a production app), but teams do switch. Start with the tool that fits your current primary use case rather than trying to optimize for all scenarios simultaneously.

Consent Management for Mobile Apps

GDPR, TCF 2.2, and the June 15, 2026 Google Consent Mode deadline apply to web properties, but mobile apps in the EEA have their own consent requirements under GDPR Article 6 and the ePrivacy Directive. If your app collects personal data for advertising purposes, you need a valid legal basis, which typically means explicit consent for behavioral advertising.

On the web side, DataCops bundles a TCF 2.2 certified first-party consent manager that handles Consent Mode v2 for Google and consent signaling for Meta. For the web portion of a hybrid web+app funnel, this handles compliance without a separate Cookiebot or OneTrust subscription.

For in-app consent on iOS, the ATT prompt itself serves as the consent mechanism for cross-app tracking. But if your app also shows a web view or uses analytics SDKs that collect data for advertising, you need an in-app CMP. Most MMPs don't include this; it's a separate integration using IAB TCF-compliant mobile CMPs.

For Android apps, GDPR consent for analytics and advertising SDKs requires a similar CMP integration. Google's User Messaging Platform (UMP) SDK handles consent for Google's ad services and integrates with Consent Mode for Android.

The CNIL fined Google 325M EUR in September 2025 for consent violations, which illustrates that enforcement has moved beyond warnings. If you're running an app in the EEA, consent infrastructure is not optional. The June 2026 deadline for Consent Mode v2 adds pressure on the web side, and the same compliance posture should be applied to your app.

In-App Purchase Conversion Tracking for Meta Ads

Meta's in-app purchase tracking has two layers: client-side app events (via Facebook SDK) and server-side events via Conversions API.

Client-side app events send purchase data directly from the device to Meta. This works for opted-in iOS users and Android users and gives real-time event reporting. The limitation is that iOS users who declined ATT don't send IDFA, reducing match quality.

Server-side via Meta's Conversions API for App Events sends events from your backend to Meta with hashed customer data (email, phone, name, location) attached. This improves Event Match Quality (EMQ) for purchase events and can recover attribution for some non-consenting iOS users through hashed data matching rather than IDFA matching.

The practical recommendation: use both. Client-side for real-time reporting, server-side for match quality improvement. Use deduplication keys to prevent double-counting the same event. Meta's Event Deduplication uses the eventID field to collapse duplicate client-side and server-side events. This is covered in more detail in Testing and Debugging Conversion API Events.

For the web side of an ecommerce funnel that drives app installs, the Meta CAPI integration on web should be running alongside the in-app purchase tracking, not instead of it. The two track different parts of the funnel.

Buyer Decision Matrix

App-only business, sub-$50K/month UA spend

Start with Firebase/GA4 for free attribution on Android and SKAN via the Ad Network's own tools for iOS. If you're only on one network (Google UAC or Meta only), you don't need a paid MMP yet. Move to Adjust or Singular when you hit two or more networks and need unified cross-network reporting.

For web conversion events feeding the app funnel: out of scope until you have web landing pages running paid traffic. When you do, treat web and in-app attribution as separate stacks.

App-only business, $50K-500K/month UA spend

Adjust or Singular at this range. AppsFlyer is justifiable if install fraud has been a material problem or you're running campaigns on 10+ networks. Budget separately for Protect360 if fraud is the driver.

Hybrid web+app, $50K-500K/month

Branch for the web-to-app attribution layer plus deferred deep linking. One of the MMPs (Adjust recommended for cost-efficiency) for in-app attribution. For web CAPI, a server-side tool for web events to Meta and Google. These three layers address different parts of the measurement stack and can coexist without conflict.

Enterprise app (500K+ MAU, $500K+/month UA)

AppsFlyer with Protect360 is the standard at this scale. The fraud filtering ROI justifies the cost. Add a dedicated MMP implementation for SKAN schema management as iOS UA scales. Dedicated engineering resources for CAPI integration at the server level.

B2B SaaS with mobile app component

Attribution focus should be on the web funnel, not in-app. Use server-side CAPI for web events, CRM integration to tie ad touches to pipeline stages, and a lightweight MMP (Branch or Adjust) for basic app install attribution. Don't over-engineer the mobile layer if app usage isn't driving revenue directly.

EU-based app with strict GDPR requirements

Adjust for data residency guarantees. A TCF 2.2 compliant in-app CMP for consent collection. For the web layer, a bundled consent manager and CAPI to handle Consent Mode v2. The June 15, 2026 deadline makes the consent infrastructure the immediate priority.

When NOT to Use DataCops

DataCops solves the web-side server-side CAPI problem with bot filtering and bundled consent. It does not solve the following:

1. Pure mobile app attribution with no web component. If your entire funnel lives inside a native app and you need SDK-based install attribution, SKAN management, and in-app event tracking, you need an MMP. DataCops doesn't have an app SDK and doesn't manage SKAN conversion schemas.

2. Deep linking and web-to-app session matching. Branch is purpose-built for this. DataCops handles web event forwarding to CAPI but doesn't provide the deferred deep link infrastructure or probabilistic matching layer needed to connect web sessions to app installs.

3. Pinterest or Snapchat Conversions API. DataCops covers Meta, Google, TikTok, and LinkedIn. If your paid channels include Pinterest or Snapchat, DataCops doesn't forward events to those platforms.

4. Enterprise compliance requirements requiring SOC 2 Type II certification today. DataCops has SOC 2 Type II in progress. If your procurement requires a current SOC 2 Type II certificate as a vendor requirement, you'll need to wait for completion or use a vendor that already holds the certification.

5. Businesses where the primary conversion happens inside a third-party marketplace app (e.g., Amazon, App Store purchases). Server-side CAPI is relevant for events on your own web properties. If your conversion funnel lives entirely inside a platform you don't control, the CAPI layer isn't applicable.

The Bot Contamination Problem in Mobile Attribution

Mobile attribution fraud is underreported relative to display ad fraud, but the data is significant. Fraudlogix 2026 puts global IVT at 20.64% across digital advertising. For mobile specifically, AppsFlyer's fraud research estimates 24-31% of install attributions on lower-quality networks show indicators of fraud, including install hijacking, click flooding, and emulator farms.

The mechanism matters. Install fraud inflates your install count, which distorts your optimization. If Meta's algorithm trains on attributions that include fraudulent installs, it optimizes for the signals correlated with fraud (specific device types, IP ranges, behavioral patterns). Lookalike audiences built on contaminated conversion data underperform for legitimate customer acquisition.

For web-originated events feeding into app campaigns, bot filtering at the CAPI layer (before events reach the ad platform) prevents this contamination on the web side. The fraud traffic validation layer checks events against a 361B+ IP database that includes datacenter ranges, residential proxies, VPN endpoints, and known fraud traffic patterns. Events from known bot sources are filtered before they reach Meta or Google's servers.

In-app fraud filtering (SDK spoofing, emulator detection) requires the MMP's own fraud suite, which is a separate layer from web CAPI bot filtering. They address different parts of the funnel.

What Your Attribution Data Is Actually Telling You

The useful framing here isn't which tool is best. It's understanding what each layer of your attribution stack is measuring, where the gaps are, and what decisions you can and can't make reliably with the data you have.

SKAN data tells you which iOS campaigns drive installs, with a 24-72 hour delay and campaign-level (not user-level) granularity. It's useful for budget allocation between campaigns, not for optimizing individual user acquisition.

MMP attribution data tells you which channels and campaigns drive installs across Android and opted-in iOS users. For Android and opted-in iOS, this is close to accurate. For opted-out iOS users, it's a model estimate.

Server-confirmed conversion data (purchase, subscription start reported by your backend) is the most reliable signal in the stack. It doesn't depend on ATT consent or SKAN. Prioritize getting this data into your ad platforms via server-side API import.

Web session data, properly captured with a first-party server-side layer, tells you about pre-install web behavior for users who went through a web acquisition funnel. This connects to in-app conversions only through the deep linking and identity resolution layers described above.

The shadow in your data is the iOS user who declined ATT, arrived via a web-to-app path without deep link data, converted inside the app, and whose purchase was confirmed server-side but whose ad click attribution is unknown. This gap is structural, not a tooling failure. Knowing which part of your conversion volume sits in this gap helps you calibrate how much to trust your reported ROAS on iOS campaigns. For more on the structural measurement gaps in cross-channel attribution, The Shadow Analytics covers the systemic version of this problem.

The conversions your iOS campaigns reported last month: how many came from users you can deterministically attribute, and how many are modeled estimates you've accepted as accurate because the dashboard showed a green number?