Google Ads, il tuo MMP e SKAN non riporteranno le stesse conversioni iOS, perché contano cose diverse, le attribuiscono a momenti diversi e vedono utenti diversi. Non usarne nessuno come unico numero vero. Usa Google Ads per il feedback di bidding, l’MMP per dividere il budget tra i canali e la tua fonte di revenue per la finance, e guarda se il divario tra loro si muove. La condizione che cambia la risposta è la regione: per gli utenti iOS di SEE, Regno Unito e Svizzera nell’MMP non ci sono claim ICM, quindi lì la vista dell’MMP su Google è più sottile e SKAN pesa di più.
Ambito: Google App campaign per install su iOS, misurate tramite un partner di attribuzione (per il lato MMP uso la documentazione di AppsFlyer, e gli altri MMP hanno regole proprie), tutte le regioni, con l’eccezione regionale sopra. Ogni fatto di piattaforma qui sotto è stato verificato sulla pagina primaria il 29 settembre 2026. Per il lato Meta dello stesso problema, leggi Meta vs RevenueCat vs Adjust. Per il setup che produce i claim ICM leggi la guida al setup di ICM e della misurazione on device.
Dove vive ciascun numero iOS, e cosa conta?
Google pubblica un proprio confronto affiancato in Understanding iOS App campaign measurement and reporting. Leggi la tabella in quella pagina. In breve:
- Le conversioni modellate di Google Ads stanno nelle tabelle Campaigns e Ad groups. Includono le conversioni click through ed engaged view, non view through. Google dice che possono essere ritardate fino a cinque giorni, e coprono tutti gli utenti, compresi quelli di SEE, Regno Unito e Svizzera.
- I claim ICM nel tuo MMP sono i claim di install di Google inviati al tuo partner di attribuzione e mostrati nella sua interfaccia. La pagina di Google dice che questi dati oggi non sono disponibili nel reporting di Google Ads, e aggiunge che la misurazione iOS in Google Ads cambierà in futuro per allinearsi di più all’ICM per le app con ICM e dati evento della misurazione on device, senza una data. About Integrated Conversion Measurement for App Campaigns lo descrive come reporting a livello di evento ed elenca la misurazione delle conversioni on device con dati evento come requisito iOS.
- I postback SKAdNetwork arrivano nei report del tuo MMP o di BI. In Google Ads compaiono solo gli install SKAdNetwork, in un report SKAdNetwork dedicato. SKAN è l’unico dei tre che include le conversioni view through, e Google consiglia di controllarlo ogni 30 giorni a causa dei ritardi variabili.
Dentro AppsFlyer, la pagina Google Ads (AdWords) Integration setup for advertisers dice che i claim deterministici di Google mostrano un match_type srn nei raw data, e i claim ICM mostrano “probabilistic”. Quella colonna ti permette di dividere gli install Google dell’MMP nei due tipi prima di confrontare qualsiasi cosa.
Perché i numeri differiscono anche quando tutto è configurato correttamente?
Perché le differenze sono strutturali. La pagina Google Ads (AdWords) FAQ and discrepancies di AppsFlyer elenca le cause, e per la maggior parte sono questioni di definizione, non errori.
Ogni lato mostra solo il proprio modello. AppsFlyer dice che Google Ads mostra gli install dal modeling interno di Google e non mostra gli install ICM, mentre AppsFlyer mostra i claim ICM e non mostra gli install modellati internamente da Google. Due modelli, due output, nessun totale condiviso.
Momento del click e momento del lancio. Google Ads registra l’install al momento del click. AppsFlyer lo registra al momento del lancio. La pagina Understand your conversion tracking data di Google conferma che le colonne principali delle conversioni si basano sul momento del click, e offre una colonna “Conversions (by conv. time)” quando ti serve la data della conversione. Gli eventi in app seguono la stessa divisione: Google li attribuisce al momento del click, e la dashboard di AppsFlyer li attribuisce al momento dell’install.
Last click e ogni engagement. AppsFlyer attribuisce il last click e tratta gli engagement precedenti come assist. Google, come self reporting network, attribuisce tutti gli install successivi a un engagement con i suoi annunci, entro la propria finestra.
Finestre. Per le conversioni modellate, il confronto di Google elenca una finestra click through configurabile con default di 30 giorni e una finestra engaged view configurabile con default di 2 giorni. Per l’ICM elenca una finestra configurabile nell’interfaccia del partner di attribuzione, da 6 ore a 30 giorni, ma indica AppsFlyer come eccezione senza dire in cosa AppsFlyer differisca. La pagina di setup di AppsFlyer ha una propria impostazione di lookback per il click through dell’install e consiglia 30 giorni per allinearsi a Google Ads. Per SKAN, Google elenca una finestra click through configurabile di 30 giorni, una finestra engaged view di 30 giorni non modificabile e una finestra view through configurabile di 1 giorno.
Regole del view through. AppsFlyer nota che Google Ads mette le conversioni view through nella colonna All conversions, non in Conversions, a meno che tu non imposti diversamente. Il confronto di Google dice che l’ICM include le conversioni click through ed engaged view ma non view through, e la pagina di setup di AppsFlyer dice che Google al momento rivendica solo i click su iOS, non le impression.
Il ritardo del modeling. Fino a cinque giorni per le conversioni modellate di Google Ads. Gli ultimi giorni di qualsiasi report di Google Ads non sono ancora completi.
Copertura di SEE, Regno Unito e Svizzera. About on-device conversion measurement for iOS App campaigns di Google dice che la misurazione on device con dati evento è inattiva per gli utenti di quelle regioni, e Bulletin: AppsFlyer and Google attribution solution (Open BETA) di AppsFlyer dice che l’ICM non è disponibile per il traffico iOS di quelle regioni. Le conversioni modellate e SKAN le coprono comunque. Quindi aspettati che il divario tra Google Ads e l’MMP dipenda da quanta parte del tuo traffico iOS Google arriva da quelle tre regioni.
Redownload. Google Ads applica ciò che hai configurato come redownload o come nuovo install, mentre l’ICM usa una definizione fissa, secondo il confronto di Google. AppsFlyer aggiunge che Google Ads mostra i reinstall come conversione session_start, mentre AppsFlyer li mette nei suoi dati di retargeting.
Ambito del costo. La pagina di AppsFlyer sulle discrepanze dice che riceve il costo Google di tutti i canali di una campagna ma attribuisce solo le conversioni di YouTube e Display nelle App campaign iOS, quindi il CPI appare più alto in AppsFlyer. La sua pagina di setup, modificata più di recente, dice che qualsiasi App campaign iOS per install può essere attribuita tramite ICM. Le due pagine si leggono in modo diverso, quindi controlla i tuoi raw data per install Google probabilistici prima di decidere quale descrizione si adatta al tuo account.
Deduplica SKAN. La stessa pagina sulle discrepanze dice che AppsFlyer mostra solo i postback con did_win=TRUE, mentre la dashboard di Google Ads non li separa da quelli con did_win=NULL, quindi il conteggio degli install SKAN dell’MMP può essere più basso.
Come riconcilio Google Ads, l’MMP e SKAN?
Con un foglio di lavoro, una riga per campo, compilato per tutte e tre le fonti prima di guardare i totali. Lo scopo è dare un nome a ogni motivo noto del divario, così che quello che resta sia abbastanza piccolo da poterlo indagare.
| Campo | Google Ads modellato | MMP (claim ICM e srn) | SKAN |
|---|---|---|---|
| Fonte del reporting | Tabelle Campaigns e Ad groups | La dashboard o i raw data del tuo partner di attribuzione, divisi per match_type | Report dell’MMP o di BI; il report SKAdNetwork in Google Ads |
| Definizione dell’evento | L’azione di conversione importata su cui filtri, per esempio solo first_open | Il nome dell’evento install o in app nell’MMP | L’evento o gli eventi che il tuo schema di conversion value mappa |
| Finestra di attribuzione | Finestre click through ed engaged view configurate | L’impostazione di lookback dell’MMP, e come si applica ai claim ICM | Le finestre di Apple più le finestre SKAN di Google |
| Base della data di coorte o evento | Data del click, o “by conv. time” se cambi colonna | Data del lancio per gli install; data dell’install per gli eventi nella dashboard, data dell’evento nei raw data | Data di install stimata |
| Fuso orario | Il fuso che usa il report di Google Ads | Il fuso che usa l’app nell’MMP | Il fuso che usa il tuo report SKAN |
| Età della coorte | Almeno cinque giorni dopo l’ultimo click, più la finestra | Oltre il lookback dell’MMP | Oltre l’ultimo postback da cui dipendi |
| Reinstall | Le tue impostazioni di redownload; reinstall come session_start | Riattribuzioni nei dati di retargeting | Il confronto di Google non dà nessuna regola; annota come li tratta il tuo MMP |
| Base della revenue | Valore associato all’azione di conversione importata, e da dove viene | Revenue che l’SDK o il server inviano, gross o net, con o senza rimborsi | Revenue implicita nello schema di conversion value |
| Differenza residua non spiegata | Lascia vuoto finché ogni riga sopra non coincide |
Alcune celle hanno bisogno di una fonte. La data SKAN è una stima: la pagina SKAN Conversion Studio di AppsFlyer ricava il momento dell’install dal momento di arrivo del postback meno un intervallo medio di ultima attività e un ritardo fisso del postback iOS. La stessa pagina dice che SKAN 4 invia tre postback, dopo le finestre che terminano ai giorni 2, 7 e 35. La pagina Apple di AdAttributionKit Receiving postbacks in multiple conversion windows indica le stesse tre finestre, giorni da 0 a 2, da 3 a 7 e da 8 a 35 dal primo avvio, con postback inviati dopo un ritardo casuale da 24 a 48 ore per il primo e da 24 a 144 ore per gli altri, e solo il primo postback può portare un fine value. Per la revenue, Set up your SKAdNetwork conversion value schema di Google dice che il suo conversion modeling usa solo i fine conversion value e al momento non supporta i coarse conversion value di SKAN 4, quindi il valore che arriva a SKAN solo come coarse value, come nel secondo e nel terzo postback, non alimenta il modeling di Google. AppsFlyer avverte anche che i dati di Google Ads importati da Firebase sono strutturati in modo diverso e non del tutto confrontabili con i dati di AppsFlyer, quindi scrivi la fonte dell’import nella riga della revenue.
Che aspetto ha un divario che non è normale?
Eccone uno dal mio lavoro. A febbraio e marzo 2026 ho gestito Google App campaign per una subscription app su Android e iOS, con AppsFlyer come MMP e ICM attivo su iOS. È lo stesso account del mio test sulla bid strategy. In 39 giorni e 88.920 $, Google Ads ha riportato un ROAS del 37,7% su tutte le campagne. AppsFlyer mostrava un ROAS lifetime del 29,8% e del 17,0% al giorno 0.
La prima lezione è la riga della base della revenue nel foglio di lavoro. Confrontato con la cifra del giorno 0 di AppsFlyer, Google sembrava 21 punti troppo alto. Confrontato con il ROAS lifetime di AppsFlyer, il divario era di 8 punti. Stesse campagne, stessa spesa, e la dimensione della “discrepanza” dipendeva da quale colonna di AppsFlyer scegliessimo. La maggior parte delle singole campagne stava entro circa 10 punti da AppsFlyer, in entrambe le direzioni, cosa che i motivi sopra spiegano.
La seconda lezione è cosa significa di solito un divario ben fuori da quell’intervallo. La campagna iOS su Max Conversion Value ha speso 11.312 $ e mostrava un ROAS del 71,4% in Google Ads contro un ROAS lifetime del 17,3% in AppsFlyer, 54 punti di distanza. I motivi documentati sono stati i primi sospettati: conversioni modellate, view through, finestre diverse. La causa era più semplice. L’evento di revenue dell’app, AllRevenue, passava a Google un valore di 1 $ quando non c’era un conversion value, invece di 0 $. Questo ha gonfiato il ROAS di Google su tutta la linea, e su iOS, dove i volumi di conversione erano più bassi, ha sommerso i numeri reali. Nessuna riga del foglio di lavoro l’avrebbe spiegato, perché niente era una questione di definizioni. Era un valore sbagliato.
Qual è la procedura, passo per passo?
Quando faccio questo audit, controllo prima cosa invia ciascun evento, poi la base della data e il filtro dell’evento, perché ognuno è veloce da confermare e ciascuno da solo può spostare un confronto.
- Controlla i valori prima dei modelli. Guarda il valore che ogni evento di revenue invia davvero a Google, compresi gli eventi che non portano revenue. Un default di 1 dove dovrebbe esserci 0 o niente gonfia ogni numero basato sul valore che Google mostra, e nessun modello di attribuzione lo spiega.
- Confronta solo coorti mature. Lascia fuori almeno gli ultimi cinque giorni per Google Ads, e vai oltre quando l’evento arriva più tardi dell’install. Il confronto di Google dice di aspettare l’intera lunghezza della finestra di conversione prima di valutare una campagna, e la pagina Set a recommended initial Target ROAS for your App campaigns di Google suggerisce una finestra da 14 a 30 giorni che escluda il periodo più recente. Per SKAN, aspetta i postback su cui fai affidamento.
- Scegli un evento e una finestra. In Google Ads, AppsFlyer nota che il report delle conversioni può mescolare install, acquisti e abbonamenti, quindi filtra sulla conversione install prima di confrontare gli install. Poi imposta le finestre nel foglio di lavoro affiancate.
- Metti tutto sulla stessa base di data. Usa “Conversions (by conv. time)” in Google Ads quando confronti con un MMP che conta per data di lancio, oppure confronta i totali settimanali dove un giorno di scarto si annulla.
- Dividi gli install Google dell’MMP per match_type. Le righe srn e probabilistic vengono da metodi di claim diversi, quindi confronta ciascuna a parte e registra le loro quote nel tempo.
- Non sommare mai SKAN ai totali modellati. Misurano le stesse campagne con metodi diversi. Mettili uno accanto all’altro, non uno sopra l’altro.
- Tratta la variazione del divario come il segnale, non il divario. Un divario stabile tra Google Ads e l’MMP è una proprietà dei due metodi. Un divario che raddoppia in una settimana è una domanda: una release dell’SDK, un cambio di consenso, una nuova regione, un’azione di conversione cambiata, una nuova impostazione di redownload.
Le impostazioni di privacy appartengono a questo elenco solo come fatti da registrare. La pagina di setup di AppsFlyer dice che con l’interruttore Aggregated Advanced Privacy attivo, i dati attribuiti a Google nei raw report risultano restricted, e che il masking dell’IP può influire sull’ICM. Sono decisioni di privacy del proprietario dell’app. Scrivo come sono impostate; non le disattivo per far tornare i numeri.
Quale numero dovrei usare per quale decisione?
Feedback di bidding: Google Ads. I target tCPA e tROAS si impostano e si giudicano in Google Ads, sulle conversioni che Google Ads riporta. Quando mi chiedo se un target è troppo stretto, leggo la colonna di Google, sui giorni maturati, nella finestra da 14 a 30 giorni che Google suggerisce. Controllare un target di Google con i numeri dell’MMP mescola due modelli e può portarti a cambiare un target che andava bene.
Budget tra i canali: l’MMP. Applica un’unica regola di last click su ogni network, cosa che Google e Meta non possono fare l’uno per l’altro. Questo lo rende il posto più equo per confrontare Google con Meta o con qualsiasi altro canale, purché ricordi che conta solo gli install Google che Google gli rivendica, e che la quota di SEE, Regno Unito e Svizzera del tuo traffico iOS Google non ha nessun claim ICM. Dove quella quota è grande, uso SKAN come seconda lettura sulla direzione.
Finance: nessuna delle due piattaforme ads. La revenue dovrebbe venire da dove viene addebitata: la tua piattaforma di subscription o gli store, abbinata al paid con i controlli del pezzo sulla riconciliazione Meta. L’MMP ti dà la revenue per canale, e SKAN ti dà un controllo indipendente sul fatto che un canale si stia muovendo, ma nessuno dei tre è un libro contabile.
Questo fa parte del lavoro di signal engineering che faccio: decidere quale evento vede ogni sistema, da quale fonte, e come si leggono i divari tra loro. Se i tuoi numeri iOS di Google non concordano e non sai quale divario sia normale, un growth audit parte da questo foglio di lavoro, ed è prenotabile da solo a qualsiasi livello di spesa.
Fonti
Tutte le pagine verificate il 29 settembre 2026.
- Understanding iOS App campaign measurement and reporting, Google Ads Help, nessuna data di pagina indicata
- About Integrated Conversion Measurement for App Campaigns, Google Ads Help
- About on-device conversion measurement for iOS App campaigns, Google Ads Help
- Understand your conversion tracking data, Google Ads Help
- Set a recommended initial Target ROAS for your App campaigns, Google Ads Help
- Set up your SKAdNetwork conversion value schema, Google Ads Help
- Google Ads (AdWords) FAQ and discrepancies, AppsFlyer, ultima modifica 16 marzo 2026
- Google Ads (AdWords) Integration setup for advertisers, AppsFlyer, ultima modifica 15 settembre 2026
- Bulletin: AppsFlyer and Google attribution solution (Open BETA), AppsFlyer, ultima modifica 5 agosto 2026
- SKAN Conversion Studio, AppsFlyer, ultima modifica 26 aprile 2026
- Receiving postbacks in multiple conversion windows, Apple Developer, nessuna data di pagina indicata
Domande frequenti
Posso sommare gli install SKAN a quelli di Google Ads per avere il totale iOS completo?
No. Google descrive le conversioni modellate, ICM e SKAdNetwork come tre modi di misurare le stesse App campaign iOS, dice che la scelta tra loro dipende dallo stato della tua implementazione, e precisa che le conversioni modellate sono a loro volta informate da SKAdNetwork quando opportuno. I loro install si sovrappongono. Sommarli significa contare gli stessi utenti più di una volta. Confrontali invece affiancati, sullo stesso evento e nella stessa finestra.
Perché Google Ads non mostra gli install ICM che mostra il mio MMP?
Perché oggi Google li tiene separati. La pagina di Google sulla misurazione iOS dice che i dati ICM non sono disponibili nel reporting di Google Ads, e AppsFlyer dice che Google Ads non mostra gli install basati su ICM, mentre AppsFlyer mostra i claim ICM e non mostra gli install modellati internamente da Google. Ogni lato mostra il proprio modello. Google dice che la misurazione iOS in Google Ads si avvicinerà all'ICM per le app con ICM e dati evento della misurazione on device, ma non dà nessuna data.
Perché il mio CPI di Google è più alto in AppsFlyer che in Google Ads?
La pagina di AppsFlyer sulle discrepanze dice che riceve il costo Google di ogni canale di una campagna, ma attribuisce le conversioni delle App campaign iOS solo da YouTube e Display, quindi l'MMP divide il costo intero per meno install. Controlla i tuoi raw data per claim ICM probabilistici prima di dare per scontato che questa descrizione valga ancora per il tuo account.
Quanto devo aspettare prima di confrontare i tre numeri?
Google dice che le conversioni iOS modellate possono richiedere fino a cinque giorni e consiglia di aspettare l'intera finestra di conversione prima di giudicare una campagna. SKAN è più lento: la terza finestra di conversione di Apple finisce 35 giorni dopo il primo avvio, e quel postback arriva dopo un ulteriore ritardo casuale fino a 144 ore.
L'ICM funziona per gli utenti iOS nello SEE, nel Regno Unito e in Svizzera?
Non al 29 settembre 2026. La pagina di Google sulla misurazione on device dice che la misurazione on device con i dati evento, che Google indica come requisito iOS per ICM, è inattiva per gli utenti di quelle regioni, e il bollettino ICM di AppsFlyer dice che l'ICM non è disponibile per il traffico iOS di quelle regioni. Le conversioni modellate di Google Ads e SKAN le coprono comunque.