Why don't Google Ads, my MMP and SKAN report the same iOS conversions?

Google Ads, your MMP and SKAN will not report the same iOS conversions, because they count different things, credit them to different moments and see different users. Use none of them as the one true number. Use Google Ads for bidding feedback, the MMP for splitting budget between channels, and your revenue source for finance, and watch whether the gap between them moves. The condition that changes the answer is region: for iOS users in the EEA, the UK and Switzerland there are no ICM claims in the MMP, so there the MMP view of Google is thinner and SKAN carries more weight.

Scope: Google App campaigns for installs on iOS, measured through an attribution partner (I use AppsFlyer’s documentation for the MMP side, and other MMPs have their own rules), all regions, with the regional exception above. Every platform fact below was checked against the primary page on 29 September 2026. For the Meta side of the same problem, read Meta vs RevenueCat vs Adjust. For the setup that produces ICM claims in the first place, read the ICM and on device measurement setup guide.

Where does each iOS number live, and what does it count?

Google publishes its own side by side comparison in Understanding iOS App campaign measurement and reporting. Read the table there. In short:

• Google Ads modeled conversions sit in the Campaigns and Ad groups tables. They include click through and engaged view conversions, not view through. Google says they can be delayed by up to five days, and they cover all users, including the EEA, the UK and Switzerland.
• ICM claims in your MMP are Google’s install claims sent to your attribution partner and shown in its interface. Google’s page says this data isn’t available in Google Ads reporting today, and adds that iOS measurement in Google Ads will change in the future to align closer with ICM for apps with ICM and on device measurement event data, without a date. About Integrated Conversion Measurement for App Campaigns describes it as event level reporting and lists on device conversion measurement using event data as the iOS requirement.
• SKAdNetwork postbacks arrive in your MMP or BI reports. In Google Ads, only SKAdNetwork installs appear, in a dedicated SKAdNetwork report. SKAN is the only one of the three that includes view through conversions, and Google recommends checking it every 30 days because of variable delays.

Inside AppsFlyer, the Google Ads (AdWords) Integration setup for advertisers page says deterministic Google claims show a match_type of srn in raw data, and ICM claims show “probabilistic”. That one column lets you split the MMP’s Google installs into the two kinds before you compare anything.

Why do the numbers differ even when everything is set up correctly?

Because the differences are built in. AppsFlyer’s Google Ads (AdWords) FAQ and discrepancies page lists the causes, and most of them are definitions, not errors.

Each side shows only its own model. AppsFlyer says Google Ads shows installs from Google’s internal modeling and does not show ICM installs, while AppsFlyer shows ICM claims and does not show Google’s internally modeled installs. Two models, two outputs, no shared total.

Click time against launch time. Google Ads records the install at click time. AppsFlyer records it at launch time. Google’s Understand your conversion tracking data page confirms the primary conversion columns are based on the time of the click, and offers a “Conversions (by conv. time)” column when you need the conversion date instead. In app events follow the same split: Google credits them to click time, and the AppsFlyer dashboard credits them to install time.

Last click against every engagement. AppsFlyer credits the last click and treats earlier engagements as assists. Google, as a self reporting network, attributes all installs following an engagement with its ads, within its own window.

Windows. For modeled conversions, Google’s comparison lists a configurable click through window with a 30 day default and a configurable engaged view window with a 2 day default. For ICM it lists a window configurable in the attribution partner’s interface, from 6 hours to 30 days, but names AppsFlyer as an exception without saying how AppsFlyer differs. AppsFlyer’s setup page has its own install click through lookback setting and recommends 30 days to match Google Ads. For SKAN, Google lists a configurable 30 day click through window, a 30 day engaged view window you cannot change and a configurable 1 day view through window.

View through rules. AppsFlyer notes that Google Ads puts view through conversions in the All conversions column, not in Conversions, unless you set it otherwise. Google’s comparison says ICM includes click through and engaged view conversions but not view through, and AppsFlyer’s setup page says Google currently claims only clicks on iOS, not impressions.

The modeled delay. Up to five days for Google Ads modeled conversions. The last few days of any Google Ads report are unfinished.

EEA, UK and Switzerland coverage. Google’s About on-device conversion measurement for iOS App campaigns says on device measurement using event data is inactive for users there, and AppsFlyer’s Bulletin: AppsFlyer and Google attribution solution (Open BETA) says ICM is not available for iOS traffic from those regions. Modeled conversions and SKAN still cover them. So expect the gap between Google Ads and the MMP to depend on how much of your Google iOS traffic comes from those three regions.

Redownloads. Google Ads applies whatever you configured as a redownload versus a new install, while ICM uses a fixed definition, per Google’s comparison. AppsFlyer adds that Google Ads shows reinstalls as a session_start conversion, while AppsFlyer puts them in its retargeting data.

Cost scope. AppsFlyer’s discrepancy page says it receives Google cost for all channels of a campaign but only attributes conversions from YouTube and Display in iOS App campaigns, so CPI looks higher in AppsFlyer. Its setup page, edited later, says any iOS App campaign for installs can be attributed through ICM. The two pages read differently, so check your own raw data for probabilistic Google installs before you decide which description fits your account.

SKAN deduplication. The same discrepancy page says AppsFlyer displays only postbacks with did_win=TRUE, while the Google Ads dashboard does not separate those from did_win=NULL, so the MMP’s SKAN install count can be lower.

How do I reconcile Google Ads, the MMP and SKAN?

With a worksheet, one row per field, filled in for all three sources before you look at the totals. The point is to name every known reason for the gap, so that what is left over is small enough to investigate.

A few cells need a source behind them. The SKAN date is an estimate: AppsFlyer’s SKAN Conversion Studio page derives install time from postback arrival time minus an average last active range and a fixed iOS postback delay. The same page says SKAN 4 sends three postbacks, after the windows that end on days 2, 7 and 35. Apple’s AdAttributionKit page Receiving postbacks in multiple conversion windows gives the same three windows, days 0 to 2, 3 to 7 and 8 to 35 from first launch, with postbacks sent after a random 24 to 48 hours for the first and 24 to 144 hours for the others, and only the first postback can carry a fine value. For revenue, Google’s Set up your SKAdNetwork conversion value schema says its conversion modeling uses only fine conversion values and does not currently support SKAN 4 coarse conversion values, so value that reaches SKAN only as a coarse value, as it does in the second and third postbacks, does not feed Google’s modeling. AppsFlyer also warns that Google Ads data imported from Firebase is structured differently and is not fully comparable with AppsFlyer data, so write the import source into the revenue row.

What does a gap that is not normal look like?

Here is one from my own work. In February and March 2026 I ran Google App campaigns for a subscription app on Android and iOS, with AppsFlyer as the MMP and ICM on for iOS. It is the same account as my bid strategy test. Over 39 days and $88,920, Google Ads reported 37.7% ROAS across all campaigns. AppsFlyer showed 29.8% lifetime ROAS and 17.0% on day 0.

The first lesson is the revenue basis row of the worksheet. Held against AppsFlyer’s day 0 figure, Google looked 21 points too high. Held against AppsFlyer’s lifetime ROAS, the gap was 8 points. Same campaigns, same spend, and the size of the “discrepancy” depended on which AppsFlyer column we picked. Most individual campaigns sat within about 10 points of AppsFlyer, in both directions, which the reasons above explain.

The second lesson is what a gap far outside that range usually means. The iOS campaign on Max Conversion Value spent $11,312 and showed 71.4% ROAS in Google Ads against 17.3% lifetime ROAS in AppsFlyer, 54 points apart. The documented reasons were the first suspects: modeled conversions, view through, different windows. The cause was simpler. The app’s revenue event, AllRevenue, passed a value of $1 to Google when there was no conversion value, instead of $0. That inflated Google’s ROAS across the board, and on iOS, where conversion volumes were lower, it swamped the real numbers. No row in the worksheet would have explained it, because nothing about it was a definition. It was a wrong value.

What is the procedure, step by step?

When I audit this, I check what each event sends first, then the date basis and the event filter, because each is quick to confirm and any one of them can move a comparison on its own.

1. Check the values before the models. Look at the value each revenue event actually sends to Google, including events that carry no revenue. A default of 1 where there should be 0 or nothing inflates every value based number Google shows, and no attribution model explains it away.
2. Compare mature cohorts only. Leave out at least the last five days for Google Ads, and go further when the event sits later than install. Google’s own comparison says to wait the full length of the conversion window before assessing a campaign, and Google’s Set a recommended initial Target ROAS for your App campaigns page suggests a 14 to 30 day window that excludes the most recent period. For SKAN, wait for the postbacks you rely on.
3. Pick one event and one window. In Google Ads, AppsFlyer notes that the conversion report can mix installs, purchases and subscriptions, so filter to the install conversion before you compare installs. Then set the windows in the worksheet side by side.
4. Put everything on the same date basis. Use “Conversions (by conv. time)” in Google Ads when you compare against an MMP that counts by launch date, or compare weekly totals where a day of drift washes out.
5. Split the MMP’s Google installs by match_type. The srn and probabilistic rows come from different claim methods, so compare each on its own and record their shares over time.
6. Never add SKAN to modeled totals. They measure the same campaigns through different methods. Put them next to each other, not on top of each other.
7. Treat a change in the gap as the signal, not the gap. A stable gap between Google Ads and the MMP is a property of the two methods. A gap that doubles in a week is a question: an SDK release, a consent change, a new region, a switched conversion action, a new redownload setting.

Privacy settings belong in this list only as facts to record. AppsFlyer’s setup page says that with its Aggregated Advanced Privacy toggle on, Google attributed data in raw reports shows as restricted, and that IP masking may affect ICM. Those are the app owner’s privacy decisions. I write down how they are set; I do not switch them off to make numbers match.

Which number should I use for which decision?

Bidding feedback: Google Ads. tCPA and tROAS targets are set and judged in Google Ads, against the conversions Google Ads reports. When I ask whether a target is too tight, I read Google’s own column, on matured days, over the 14 to 30 day window Google suggests. Checking a Google target against MMP numbers mixes two models and can lead you to change a target that was fine.

Budget between channels: the MMP. It applies one last click rule across every network, which Google and Meta each cannot do for the other. That makes it the fairer place to compare Google against Meta or anything else, as long as you remember that it only counts the Google installs Google claims to it, and that the EEA, UK and Swiss share of your Google iOS traffic has no ICM claims at all. Where that share is large, I use SKAN as a second read on direction.

Finance: neither ad platform. Revenue should come from where it is charged: your subscription platform or the stores, matched to paid with the checks in the Meta reconciliation piece. The MMP gives you revenue by channel, and SKAN gives an independent check on whether a channel is moving, but none of the three is a ledger.

This is part of the signal engineering work I do: deciding which event each system sees, from which source, and how the gaps between them get read. If your Google iOS numbers disagree and you do not know which gap is normal, a growth audit starts with this worksheet, and it is bookable on its own at any spend level.

Sources

All pages checked on 29 September 2026.

1. Understanding iOS App campaign measurement and reporting, Google Ads Help, no page date shown
2. About Integrated Conversion Measurement for App Campaigns, Google Ads Help
3. About on-device conversion measurement for iOS App campaigns, Google Ads Help
4. Understand your conversion tracking data, Google Ads Help
5. Set a recommended initial Target ROAS for your App campaigns, Google Ads Help
6. Set up your SKAdNetwork conversion value schema, Google Ads Help
7. Google Ads (AdWords) FAQ and discrepancies, AppsFlyer, last edited 16 March 2026
8. Google Ads (AdWords) Integration setup for advertisers, AppsFlyer, last edited 15 September 2026
9. Bulletin: AppsFlyer and Google attribution solution (Open BETA), AppsFlyer, last edited 5 August 2026
10. SKAN Conversion Studio, AppsFlyer, last edited 26 April 2026
11. Receiving postbacks in multiple conversion windows, Apple Developer, no page date shown