How to Measure iOS Campaign Performance on Google Ads

Five years after App Tracking Transparency landed, iOS user acquisition still runs on a different set of rules than Android. Consent rates now average around 35%, but the spread by category is enormous, mid-teens for education apps, close to 50% for top gaming subcategories. Which means for the majority of your iOS users there is no IDFA, no deterministic click-to-install chain, and no clean row in a spreadsheet that says “this ad produced this purchase.”

What has changed is that the workarounds have matured. Google Ads now offers three distinct ways to measure iOS App campaigns, each with different data granularity, latency, and attribution logic. Used well, together they give you enough signal to optimise confidently. Used carelessly, they give you three numbers that disagree and an afternoon lost to reconciling them.

This guide covers what each method actually measures, how to set them up properly, and how to read the numbers when they conflict.

Why iOS measurement is structurally different

Before the mechanics, the constraint. On Android you can generally observe a click, an install, and a downstream event, and tie them together at the user level. On iOS, for non-consented users, Apple deliberately breaks that chain and replaces it with two things:

Aggregation. SKAdNetwork (SKAN) reports installs and post-install activity in aggregate, not per user. There is no user ID to join on, no cohort you can slice by hand afterwards.

Deliberate information loss. SKAN compresses your entire post-install funnel into a single number between 0 and 63 — the “fine conversion value.” Apple’s crowd anonymity system then withholds even that number when campaign volume is too low to protect individual users. Small campaigns get coarse signals or nothing at all.

Layer on delayed postbacks, no view-through visibility in most reporting surfaces, and a moving target as Apple rolls out AdAttributionKit alongside SKAN, and the honest conclusion is this: on iOS you are optimising against directional signals, not a ledger. Your job is to make those signals as rich and as consistent as possible, then build a decision process that tolerates the remaining noise.

The three measurement methods in Google Ads

Google’s own documentation frames iOS App campaign measurement as three complementary solutions. They are not alternatives you pick between — most mature accounts run all three and use each for a different job.

	Modeled conversions	Integrated Conversion Measurement (ICM)	SKAdNetwork
Where you see it	Google Ads campaign & ad group tables	Your App Attribution Partner’s dashboard	AAP dashboard, BI tools, Google Ads SKAN report
Granularity	Event level, modeled	Event level, real-time	Aggregate, 64 conversion values
Signal source	IDFA + on-device measurement + modeling	On-device measurement + partner attribution	Apple postbacks
Latency	Up to 5-day delays	Near real-time	Variable, tied to Apple’s postback windows
Conversion types	Click-through + engaged-view (no view-through)	Click-through + engaged-view (no view-through)	All types included
Click-through window	Configurable, 30 days default	Configurable in the AAP UI	Configurable, 30 days default
Best used for	Day-to-day bidding and budget decisions	Cross-network truth-seeking, event-level analysis	Cross-network benchmarking, aggregate sanity check

1. Modeled conversions – your bidding surface

This is what you see natively in Google Ads. Google combines observed signals (IDFA where consent exists, on-device conversion measurement everywhere else) with modeling to estimate event-level performance, including in the EEA, UK, and Switzerland.

What to know: modeling means the numbers move. A campaign’s reported conversions for Tuesday can still be climbing on Friday, because of delays of up to five days. Never judge yesterday’s performance on today’s number, building a habit of reading a rolling window that excludes the most recent 3–5 days for anything you’re about to act on.

What it excludes: view-through conversions. If a meaningful share of your iOS spend is on YouTube or Display inventory, modeled conversions structurally undercount that contribution. Engaged-view conversions are included, which softens this, but the gap is real and worth remembering before you cut a video campaign for “underperforming.”

2. Integrated Conversion Measurement – the biggest recent unlock

ICM is the most consequential change to iOS App campaign measurement in years, and it’s the one most accounts have not yet fully implemented. Google began rolling it out in May 2025 and it’s now supported across the major attribution partners — Adjust, AppsFlyer, Branch, Kochava, Airbridge.

What it does: it closes the reporting gap between Google Ads and your MMP. Historically, Google saw conversions your MMP couldn’t attribute, and your MMP treated Google traffic as a partially dark box. ICM feeds Google’s on-device conversion measurement signal into your attribution partner, where it is validated against their own attribution logic and surfaced as deduplicated, real-time, event-level data inside their dashboard.

The practical result is that non-consented iOS users – the 65–75% majority, still roughly two-thirds of your iOS base – stop being invisible in your MMP. Reported coverage increases can be dramatic.

Read those numbers carefully. A 97% “reduction in cost per install” of that kind is almost entirely a measurement artefact, not a media improvement. The same spend bought roughly the same installs; you simply started seeing them. This matters enormously for how you communicate ICM’s rollout internally — if you let a finance stakeholder believe CPI genuinely fell 97%, your next quarter’s targets will be unachievable. Frame it as coverage recovery, and re-baseline your targets on the day ICM goes live.

Setup checklist for iOS:

An active iOS app install campaign running in Google Ads.
On-device conversion measurement implemented with event data – this is the core dependency, and it requires a current Google Analytics for Firebase SDK.
Your App Attribution Partner’s SDK updated to the latest version.
For server-to-server integrations, pass the on-device measurement info string through to your partner.
Align your attribution window with your partner’s recommendation. This step is quietly the most common failure point. Google publishes per-partner guidance, and the setting name differs by partner: Adjust’s Attribution Window for Probabilistic Modeling should be 24 hours (it defaults to 6); Branch’s Attribution Windows for Click To Install should be 24 hours or longer (it defaults to 7 days); Airbridge’s Lookback Window for probabilistic modeling matching should be 24 hours or more; Kochava’s Click Reconciliation for Modeled Lookback should be 24 hours or more. A mismatched window produces exactly the discrepancies ICM is supposed to eliminate.

Availability and SDK timelines still vary by partner, so confirm current status with your account contact rather than assuming.

3. SKAdNetwork – your aggregate cross-check

SKAN is the only one of the three that includes all conversion types, which makes it useful as an independent sanity check even though it’s the least granular.

Where to find it in Google Ads: Campaigns → Reports → Goals and conversions → the SKAdNetwork conversions report. This gives you a campaign-level view of installs and post-install conversion values.

The segments that matter:

SKAdNetwork redistributed fine conv. value – now the default. Combines observed values with values Google redistributes using models trained on recent postback data, filling in postbacks that failed Apple’s privacy threshold. Redistribution only applies where SKAdNetwork attribution credit equals “Won.”
SKAdNetwork conv. value – raw observed values only.
SKAdNetwork installs – postbacks Apple has attributed to your app.

Google recommends the redistributed segment because it closes measurement gaps. Be aware of the trade-off: your third-party SKAN tools report raw values, so if you compare the redistributed segment against your MMP’s SKAN dashboard you will find a discrepancy by design. Pick one convention per report and label it.

Note also that Google’s SKAN modeling supports SKAN versions 3 and 4 but uses fine conversion values only – coarse values aren’t supported. This has a consequence worth understanding. SKAN 4 sends up to three postbacks, in windows covering days 0–2, 3–7, and 8–35, but Apple only includes a fine conversion value in the first one; postbacks two and three carry coarse values. So Google’s modeling effectively sees your day 0–2 window and nothing after it. Long-horizon post-install behaviour – the trial that converts on day 14, the subscription that renews in month two – is invisible to this report by design. Low-volume campaigns that fall back to coarse values are dark here too.

Getting your conversion value schema right

Your SKAN conversion value schema is the single highest-leverage measurement decision you’ll make on iOS, because it determines what 64 numbers can possibly tell you. Get it wrong and every downstream report inherits the mistake.

Configure it in exactly one place. You can set the schema through Google Analytics, your third-party App Attribution Partner, or the Google Ads API. Choose one as the source of truth. Multiple configuration points is how teams end up with schemas that silently diverge.

Design rules that hold up in practice:

Only include events you will actually optimise toward. A schema crowded with diagnostic events wastes the 0–63 space you need for the events that drive bidding.
Respect the volume floors. Each event you track should generate more than roughly 10 conversion events per day, and you want in the region of 50 installs per day per campaign for crowd anonymity to consistently release fine values. Below that, you’re mapping a funnel into values that will mostly arrive as null.
Map the full journey, then prune. Start by laying out your funnel from upper (install, registration, tutorial complete) to lower (trial start, first purchase, subscription). Then cut anything low-volume or non-actionable.
Match the schema to your Google Ads conversion settings. If you bid toward first purchase but your schema’s granularity clusters around registration, your SKAN data can’t validate your bidding.
Measure your null rate before you commit. Run the schema, check what proportion of postbacks come back unavailable, and revise toward higher-volume events if the rate is high.

Typical mappings by vertical: gaming uses in-app purchases and level or achievement milestones; finance uses account linking and first deposit; retail uses add-to-cart through purchase; travel uses search through booking.

The metrics that actually matter on iOS

Given the constraints, some metrics survive the noise better than others.

Cohort ROAS over blended CPI. Install-level cost metrics are the most measurement-sensitive number you have, and – as the ICM case studies show – they can swing by orders of magnitude for purely reporting reasons. Cohort revenue against cohort spend is more robust.

Directional trend over absolute value. A 15% week-over-week movement in a consistently-measured metric is more trustworthy than the absolute level of any single number.

Geo and holdout testing for incrementality. Because per-user attribution is broken, geo splits and holdout tests are how you establish real incremental impact. This is not a nice-to-have on iOS; it’s the only clean read you have on whether spend is producing incremental installs.

Creative-level analysis, sized to what your networks actually send. SKAN 4’s hierarchical source identifiers allow up to four-digit campaign codes against SKAN 3’s two, which would give far more granular breakdowns. The catch is adoption. SKAN 4 postbacks became the majority across the ecosystem during 2025, driven largely by Meta and TikTok – but Google is the notable remaining holdout, still signing primarily on SKAN 3. Plan your Google campaign structure around two-digit granularity, and note that even on SKAN 4 you only reliably get the full four digits at the higher crowd-anonymity tiers.

Target ROAS bidding is available for iOS App campaigns, which changes what’s worth measuring. If you’re bidding to value, your conversion value schema needs to carry value signal, not just event occurrence. One caveat: Google’s in-product bid guidance for App campaigns for installs with tROAS is currently Android-only, so you’ll be setting iOS targets from your own data rather than from a recommendation.

Five mistakes worth avoiding

Judging campaigns on unlagged data. With up to five days of reporting delay, decisions made on yesterday’s numbers are decisions made on incomplete data.
Not implementing ICM. If on-device conversion measurement isn’t live and your partner SDK isn’t current, you are optimising against a fraction of your actual iOS conversions.
Treating measurement gains as performance gains. Re-baseline targets when coverage changes, and say so explicitly to stakeholders.
Over-stuffing the conversion value schema. More events tracked means more nulls, not more insight.
Cutting video campaigns on modeled conversions alone. View-through is excluded from that view. Cross-check against SKAN before you act.

A ninety-minute starting point

If you do nothing else after reading this:

Check your attribution windows. Confirm the click-to-install window in Google Ads matches your attribution partner’s published recommendation. (15 min)
Confirm ICM status. Verify on-device conversion measurement is live and your partner SDK is current. If not, this is your highest-value engineering ticket. (20 min)
Audit your conversion value schema. Check it’s configured in exactly one place, and pull your null rate. (30 min)
Open the SKAdNetwork conversions report and note which value segment you’re reading — redistributed or raw. (10 min)
Write the reconciliation table. One row per data source: window, conversion types, latency, timezone. (15 min)

None of this restores per-user attribution – nothing will. What it does is make the signals you do have consistent, complete, and comparable, which is the practical definition of good iOS measurement in 2026.

Appgrowth