Mobile App Attribution Setup That Actually Works

Mobile App Attribution Setup That Actually Works

Most eCommerce brands launch a mobile app and immediately plug into the same attribution logic they use for web. Platform-reported installs from Apple and Google. Maybe a UTM tacked onto a deep link. Then they wonder why their install campaigns show a 3x ROAS in the dashboard while actual revenue from app customers barely moves.

The problem isn't your campaigns. The problem is that your attribution setup is lying to you about which campaigns produced which installs, and you're scaling spend based on fiction.

The Privacy Blindspot Eating 40% of Your Install Data

When Apple rolled out App Tracking Transparency with iOS 14.5, it didn't just make attribution harder. It made platform-native attribution functionally broken for most eCommerce apps. Branch mobile attribution guide research shows that SKAdNetwork hides 30-40% of install data, forcing app marketers to operate blind on a massive chunk of their traffic.

That's not a rounding error. That's nearly half your install volume disappearing into a black box.

Here's what actually happens when a customer sees your Instagram ad, taps through, and installs your app on an iPhone running iOS 16+. Apple's ATT prompt fires. If the user taps "Ask App Not to Track" (and roughly 75% of users do), your app loses access to the IDFA. Without the IDFA, Meta can't tell you that this install came from Campaign X, Ad Set Y, Creative Z. Instead, you get a SKAdNetwork postback 24-48 hours later with a conversion value that maps to... something. Maybe revenue. Maybe just "opened the app." The granularity is gone.

Google's situation is slightly better on Android with the Google Advertising ID (GAID), but Google has already announced its own privacy sandbox for Android. The window is closing there too.

So what do most brands do? They look at their Meta Ads Manager, see "842 app installs this week," compare it to their app store analytics showing 1,400 new installs, and shrug at the gap. That gap is where your highest-value installs are hiding. Those 558 unattributed installs might be your best customers. You'll never know, because your attribution setup can't see them.

The real cost isn't just bad data. It's bad decisions. When 40% of your installs are invisible, you're making budget allocation calls with 60% of the picture. You're killing campaigns that actually work and scaling campaigns that don't, because the signal is buried under platform-level noise.

**The App Install Truth Protocol**: Recovering What the Platforms Lost

The App Install Truth Protocol: Recovering What the Platforms Lost

I call this the App Install Truth Protocol. It's a three-layer attribution architecture that combines deterministic tracking (what you can prove), probabilistic modeling (what you can infer with high confidence), and server-side stitching (what you can reconstruct from your own data). I've deployed variations of this across eCommerce apps doing $2M-$8M in annual app revenue, and the consistent finding is a 25-35% reduction in apparent CAC once you can actually see which campaigns drive profitable installs.

The protocol works on a simple principle: don't rely on any single attribution signal. Stack three independent signals and triangulate.

Layer 1: Deterministic Attribution. This is your foundation. When a user opts into tracking (about 25% on iOS, higher on Android), you get a clean, device-level match between ad click and app install. A third-party mobile measurement partner (MMP) like AppsFlyer or Adjust captures this deterministic match via their SDK. This is your ground truth. It's small but accurate.

Layer 2: Probabilistic Attribution. For the 75% of iOS users who opt out, your MMP uses device fingerprinting: IP address, user agent string, device model, OS version, and timing. This isn't as precise as IDFA matching, but when a user clicks an ad from a specific IP on a specific device model and then installs the app from that same IP on that same device model within 24 hours, the confidence is north of 90%. Cometly's attribution tracking guide breaks down how probabilistic matching works at scale.

Layer 3: Server-Side Stitching. This is where most brands stop short, and it's where the real value lives. Your app collects a user ID at registration or first purchase. Your server matches that user ID to any existing customer record from web, email, or previous purchases. Now you've stitched the install back to the original acquisition source, even if the install itself was unattributed. You can see that the customer who installed your app last Tuesday originally came from a Google Shopping campaign six months ago.

The App Install Truth Protocol doesn't pick one signal. It layers all three and uses the strongest available signal for each install. Deterministic when you have it. Probabilistic when you don't. Server-side stitching to fill the remaining gaps.

Phase 1: Build the Foundation (Days 1-14)

Day 1-3: Select your MMP. You need a third-party mobile measurement partner. The two serious options for eCommerce are AppsFlyer and Adjust. Statsig's comparative analysis breaks down the differences, but here's the short version: AppsFlyer has deeper eCommerce integrations and better raw data exports. Adjust has a cleaner UI and slightly lower pricing at the entry tier. For brands doing under $5M in app revenue, either works. For brands above $5M, AppsFlyer's data granularity pays for itself.

Pick one. Do not try to run both. Do not try to build your own. The SDK installation, partner integrations, and fraud detection are not things you want to maintain in-house.

Day 4-7: Integrate the SDK. Your developer (or Shopify app partner, if you're running a Shopify-native app) installs the MMP SDK into your iOS and Android builds. This is a 2-4 hour development task for a competent mobile developer. The SDK needs to fire on three events minimum: app install, app open, and first purchase. If you're running a subscription model, add subscription start as a fourth event.

Configure your ATT prompt. This is the iOS permission dialog that asks users to allow tracking. The timing and copy of this prompt matter enormously. Don't fire it on first app open. Fire it after the user has experienced value, ideally after they've browsed at least two product pages or added something to their wishlist. Brands that delay the ATT prompt by one session see opt-in rates 15-20% higher than those who fire it immediately.

Day 8-10: Set up event naming conventions. This is where most setups go wrong quietly. Your MMP needs consistent event names that match across platforms. If Meta calls it "Purchase" and your MMP calls it "order_complete" and your backend calls it "transaction_confirmed," you'll spend weeks debugging discrepancy reports. Standardise before you launch. Use a naming document that maps every event across every system.

Day 11-14: Validate. Run a test campaign with $500-$1,000 on a single channel (Meta works best for testing). Compare three numbers: platform-reported installs (Meta Ads Manager), MMP-reported installs (AppsFlyer/Adjust dashboard), and app store installs (App Store Connect / Google Play Console). Your MMP number should be higher than the platform number but lower than the app store number. If the MMP number is lower than the platform number, your SDK integration has a problem. If the MMP number equals the app store number, something is miscounting organic installs as paid.

Don't skip validation. I've seen brands run their MMP for three months before realising the SDK was only firing on Android, missing every iOS install entirely. Another common mistake: the SDK fires on app update events, not just fresh installs, inflating your numbers by 20-30% with existing users who simply updated the app. Check your MMP's "reinstall" and "reattribution" settings. Make sure you're counting net new installs, not every app store interaction.

Create a simple reconciliation spreadsheet with four columns: date, platform installs, MMP installs, and app store installs. Run it daily during the validation window. The ratios should stabilise within 5-7 days. If they don't, your event mapping has a gap that needs debugging before you move to Phase 2.

Phase 2: Layer in Probabilistic and Server-Side Tracking (Month 2-3)

With deterministic tracking live, you now have a baseline. Phase two recovers the installs that deterministic tracking can't reach.

Week 5-6: Enable probabilistic attribution in your MMP. Both AppsFlyer and Adjust offer probabilistic modeling as a configuration option. Turn it on, but set the attribution window to 24 hours for click-through and 1 hour for view-through. Wider windows inflate your numbers and create false positives. AppsFlyer's technical documentation explains the mechanics of their probabilistic model, and understanding it helps you calibrate trust in the data.

Probabilistic attribution will immediately surface installs that were invisible before. Expect your attributed install count to jump 15-25% in the first week after enabling it. This isn't fake data. These are real installs that were happening all along but showing up as "organic" because deterministic matching couldn't reach them.

Week 7-8: Build server-side stitching. This requires a backend developer and a customer data platform (CDP) or, at minimum, a well-structured database. The logic is straightforward: when a user creates an account or makes a first purchase in your app, match their email address (or phone number) against your existing customer database. If they exist, tag the app install with their original acquisition source.

For Shopify-based apps, this is easier than it sounds. Shopify's customer API gives you the original UTM parameters and referring site for every customer record. When App User #4,721 registers with sarah@email.com and your Shopify customer record for sarah@email.com shows original_source = "google / cpc," you've just attributed an app install that no MMP could see.

The key to making stitching work at scale is matching logic that handles edge cases. Customers don't always use the same email. They might register on web with a work email and on the app with a personal Gmail. Build your matching hierarchy: first try exact email match, then phone number match, then name + postcode combination as a fallback. Each layer of matching captures installs the previous layer missed. In practice, email matching alone catches about 65% of stitchable installs. Adding phone number matching pushes that to 80%. The name + postcode fallback picks up another 5-8%, mostly from customers who used different email addresses across channels.

One critical detail: time-stamp your stitching. When you match an app install to a web acquisition source, record both the original web acquisition date and the app install date. This matters because a customer acquired via Google Shopping 14 months ago who installs your app today isn't a Google Shopping app install. They're an organic app install from an existing customer. Your attribution should reflect the most recent meaningful touchpoint, not the earliest one in the database.

Week 9-12: Build your attribution dashboard. Pull data from three sources into a single view: MMP data (deterministic + probabilistic), server-side stitched data, and platform-reported data. For each campaign, show three columns: platform-reported installs, MMP-attributed installs, and stitched installs. The gap between column one and column three is your recovered attribution. That gap is where your budget decisions change.

AttributionApp's mobile tracking guide walks through the end-to-end setup for connecting these data sources into a unified view.

Phase 3: Campaign-Level Profit Tracking (Month 4-6)

Attribution is pointless if it doesn't change decisions. The final phase connects install attribution to revenue and profit at the campaign level.

Build a cost-per-install (CPI) report that includes all three attribution layers. Most brands calculate CPI as ad spend divided by platform-reported installs. That's wrong. Your CPI should be ad spend divided by total attributed installs (deterministic + probabilistic + stitched). For a brand spending $50,000/month on app install campaigns, recovering 30% more attributed installs drops your apparent CPI from $8.33 to $5.83. That changes which campaigns look profitable and which don't.

Track 30-day and 90-day revenue per install by campaign. Not all installs are equal. A customer who installs via a Meta retargeting campaign and makes a purchase within 48 hours is worth dramatically more than an organic install who opens the app once and never returns. Your MMP can track post-install events (purchase, subscription start, repeat purchase) and tie them back to the original campaign. This gives you revenue-per-install at the campaign level, which is the only metric that matters for budget allocation.

Run monthly attribution audits. Every 30 days, compare your three data sources. If the gap between platform-reported and MMP-attributed is growing, your probabilistic model might need recalibration. If stitched installs are declining as a percentage, check whether your app registration flow changed or your email matching logic broke. Attribution infrastructure isn't a set-and-forget system. It degrades the moment you stop watching it.

Set up fraud detection rules. Mobile install fraud is a billion-dollar problem, and poor attribution setups are particularly vulnerable. Your MMP includes fraud detection features: device farm identification, click flooding detection, and install time anomaly checks. Enable all of them. A common pattern is a network reporting hundreds of installs from the same IP range within minutes. Without fraud filters, those show up as attributed installs and inflate the ROI of whatever campaign they're attached to. One brand I worked with discovered that 18% of their attributed installs from a specific ad network were fraudulent. They were paying $6,200/month for installs that never resulted in a single app open.

I've seen brands discover that their TikTok app install campaigns, which looked expensive on a platform-reported basis, were actually their highest-ROI channel once probabilistic and stitched attribution revealed the true install count. One Australian DTC brand running about $4M in annual revenue found that TikTok's reported CPI of $12.40 dropped to $7.80 after implementing the full protocol, making it cheaper per install than their Meta campaigns. They shifted $15,000/month from Meta to TikTok and saw app revenue grow 22% over the following quarter.

The Metric That Replaces Vanity Installs: Revenue Per Attributed Install

Stop measuring total installs. Stop measuring platform-reported CPI. Both numbers are contaminated by the privacy gap.

Your new north star is Revenue Per Attributed Install (RPAI), segmented by campaign and channel. RPAI takes total revenue generated by customers attributed to a specific campaign (across all three layers) and divides it by the total attributed installs from that campaign.

A campaign with 1,000 attributed installs and $45,000 in 90-day revenue has an RPAI of $45. A campaign with 2,000 attributed installs and $30,000 in 90-day revenue has an RPAI of $15. The second campaign looks better in your install dashboard. The first campaign is three times more valuable.

The App Install Truth Protocol doesn't just fix your attribution. It gives you a decision-making framework that separates the campaigns generating customers from the campaigns generating downloads. In a post-ATT world where 40% of your data is hidden by default, the brands that build this infrastructure will make better decisions with the same budget. The brands that don't will keep guessing, keep scaling the wrong campaigns, and keep wondering why app revenue doesn't match what the dashboard promised.

Your competitors are looking at the same broken platform data you are. The difference is whether you build the system that sees what they can't.