· 13 min · Samet Durgun

Come si configurano Google ICM e la misurazione on device per iOS?

Sono Samet Durgun, fractional Head of UA. Mi occupo di paid UA per app in abbonamento e giochi mobile, e qui scrivo quello che vedo negli account che gestisco. Questo articolo rientra nel tema Signal engineering; altro su di me.

Per avere l’Integrated Conversion Measurement (ICM) di Google su iOS ti servono una App campaign iOS per gli install, la misurazione on device (ODM) tramite l’SDK di Google Analytics for Firebase o l’SDK standalone GoogleAdsOnDeviceConversion di Google, l’SDK di un partner di attribuzione alla versione minima documentata o superiore con la sua impostazione Google attivata, e le conversion info recuperate al primo avvio prima che venga inviato first_open. La condizione che cambia la risposta è la regione: al 29 settembre 2026 la documentazione di Google dice che la misurazione on device è inattiva per gli utenti dello SEE, del Regno Unito e della Svizzera, quindi per loro tutto questo non produce ancora claim ICM.

Ambito: App campaign iOS per gli install, misurate tramite AppsFlyer, Adjust o Singular, con il percorso Firebase o SDK standalone, verificate sulle pagine di ciascun vendor il 29 settembre 2026. Google cambia spesso questa area, quindi controlla la data prima di fidarti di un numero di versione.

Ho gestito App campaign iOS con ICM tramite AppsFlyer, su una subscription app a marzo 2026. La lezione che ti trasmetterei da quell’account non aveva niente a che fare con l’ICM in sé, ed è l’ultimo passaggio dell’install di test qui sotto.

Qual è la differenza tra ODM e ICM?

ODM è il segnale. ICM è il posto in cui compare il risultato.

La pagina di Google About on-device conversion measurement for iOS App campaigns descrive due varianti di ODM: una usa dati first party come email o numero di telefono dal tuo flusso di accesso, l’altra usa quelli che Google chiama “de-identified, temporary app event data”, ricavati da segnali come indirizzo IP e timestamp. L’ICM su iOS dipende dalla seconda.

La pagina di Google About Integrated Conversion Measurement for App Campaigns elenca quattro passaggi iOS: una App campaign iOS attiva per gli install, i dati del tuo partner di attribuzione importati in Google Ads, l’ODM con dati evento, e l’ultimo SDK del partner. Le integrazioni server to server devono passare la stringa ODM info al partner. Su Android la stessa pagina dice che non serve nessuna azione.

Quindi l’ODM rende possibili i claim di install di Google, e l’ICM è Google che manda quei claim nel tuo MMP, dove compaiono come attribuzioni probabilistiche.

Cosa richiede ogni percorso di integrazione?

La tabella mette i cinque percorsi uno accanto all’altro, una riga per percorso.

Percorso Minimo documentato Impostazione Ambito regionale Passaggio di verifica Fonte, verificata il
Firebase (GA4F) iOS 12+. GA4F 11.14.0 secondo la pagina di aiuto di Google e il tutorial di Firebase; 12.12.1+ secondo la guida iOS di Google (irrisolto, vedi sotto) Collega la proprietà di Google Analytics all’account Google Ads. Il pod FirebaseAnalytics include già GoogleAdsOnDeviceConversion Inattiva per gli utenti dello SEE, del Regno Unito e della Svizzera Avvia con -FIRDebugEnabled, cerca il log “framework is linked”, poi la user property _psmvalue_gads dopo circa 15 secondi Google 12119136, Firebase tutorial, 29 settembre 2026
SDK GoogleAdsOnDeviceConversion standalone Nessun minimo indicato nella pagina di Google. Ultima release 3.7.0 (1 settembre 2026). Se installi anche GA4F, rispetta la mappa delle versioni di Google setFirstLaunchTime con la vera data del primo avvio, poi fetchAggregateConversionInfo(for: .installation), poi passa il risultato come odm_info La pagina ODM di Google esclude lo SEE, il Regno Unito e la Svizzera; la riga di troubleshooting di questa pagina la contraddice (vedi sotto) Conferma una info string non vuota prima che venga inviato first_open, e odm_info sulla prima chiamata di install Google 16384720, Google developer page, GitHub repo, 29 settembre 2026
AppsFlyer iOS SDK 6.17.9+, più Firebase 11.14.0+ o l’SDK standalone Advanced Data Sharing nell’integrazione con Google Ads. first_open importato come conversione. IDFV con ogni apertura dell’app e ogni evento in app, indirizzo IP con ogni apertura dell’app Non disponibile per gli utenti iOS dello SEE, del Regno Unito e della Svizzera Raw data match_type: srn per i claim deterministici, probabilistic per i claim ICM AppsFlyer bulletin, AppsFlyer setup, 29 settembre 2026
Adjust iOS SDK 5.4.1+ con il plugin ODM (testato con GoogleAdsOnDeviceConversion 3.0.0), più Firebase 11.14.0+ o l’SDK standalone “Enable probabilistic modeling” nelle impostazioni di attribuzione del partner Google Ads. Chiama initSdk il prima possibile Le pagine di Adjust non indicano nessun limite regionale; l’esclusione ODM di Google vale comunque Adjust non documenta nessun passaggio di verifica nelle pagine che ho controllato Adjust Dev Hub, Adjust Help, 29 settembre 2026
Singular Native iOS SDK 12.8.1+ (Unity 5.5.0+) enableOdmWithTimeoutInterval, 5 secondi consigliati. “Include Integrated Conversion Measurement Attributions” nella configurazione del partner Google Ads Non supportata sui dispositivi iOS nello SEE e nel Regno Unito (Svizzera non nominata) Gli install ICM compaiono come install click through, etichettati come probabilistici nei report a livello utente Singular help, 29 settembre 2026

Ogni riga dei partner elenca solo ciò che quel partner documenta per sé. La scelta tra Firebase e SDK standalone ha una conseguenza sul bidding che le pagine di setup non spiegano. La pagina di Google About bidding in App campaigns dice che il tROAS richiede l’SDK di Google Analytics for Firebase, e l’articolo di setup di AppsFlyer dice che puoi escludere audience dalle App campaign solo quando la campagna ottimizza verso gli eventi dell’SDK Firebase, non verso quelli dell’MMP. Se prevedi di fare bid sul valore più avanti, il percorso standalone risolve la misurazione ma non questo. Se installi entrambi, il repository GoogleAdsOnDeviceConversion di Google pubblica una mappa delle versioni: GA4F 12.19.0 si abbina a ODM 3.7.0, 12.12.1 a 3.5.0, e 11.14.0 a 2.0.0.

Qual è la versione minima di Firebase, 11.14.0 o 12.12.1?

La documentazione di Google dà due risposte, e non ho trovato una fonte che chiuda la questione.

La pagina di aiuto di Google sulla misurazione on device chiede “version 11.14.0 available in June 2025”, e il Tutorial: Measure iOS Ads conversions using event data di Firebase (ultimo aggiornamento 25 settembre 2026) dice 11.14.0 o superiore. La iOS Best Practices Guide: Do the iOS Three to maximize your ROI di Google, che non ha data, indica nei suoi passaggi di implementazione l’SDK Firebase a “minimum version 12.12.1+”. AppsFlyer e Adjust ripetono entrambe 11.14.0.

La considero una differenza irrisolta tra due fonti di Google. Annota quale versione è inclusa nell’app che rilasci, e porta la discrepanza a Google prima di fissare l’app sotto la 12.12.1.

Perché conta l’ordine del primo avvio?

Perché le conversion info devono esistere prima che l’install venga riportato. La pagina per sviluppatori di Google per la App Conversion API, Integrated Conversion Measurement, dice di recuperare le conversion info subito dopo il primo avvio dell’app, prima che venga inviato l’evento first_open, e di passarle come parametro odm_info. La pagina di Google sull’SDK standalone aggiunge che il recupero vale sia per first_open sia per reinstall_open, e che setFirstLaunchTime deve ricevere la data in cui l’app è stata davvero avviata la prima volta.

I partner gestiscono l’attesa in modi diversi:

  • L’SDK di Singular aspetta le ODM info fino al timeout che imposti, 5 secondi consigliati, e Singular avverte che questo ritarda le callback dell’SDK, deep link compresi. Per i setup server to server nota che il recupero è asincrono e che potresti dover trattenere l’evento di sessione finché non è completato.
  • Adjust dice di chiamare initSdk il prima possibile, idealmente in application:didFinishLaunchingWithOptions:. Con First Session Delay chiami comunque initSdk presto così l’ODM registra il momento del lancio, e chiudi il ritardo più tardi.

In un audit, la prima cosa da controllare è se una schermata di consenso, un paywall o un flusso di onboarding avvia l’SDK dell’MMP più tardi di quanto la documentazione si aspetta. La documentazione non dà alcun valore di ritardo universale, quindi testa l’ordine su un install reale.

L’ICM funziona per gli utenti iOS nello SEE, nel Regno Unito e in Svizzera?

Non nella documentazione verificata il 29 settembre 2026.

  • La pagina di Google sulla misurazione on device: la funzione “will be inactive for all users located within” lo SEE, il Regno Unito e la Svizzera.
  • Il tutorial di Firebase: il messaggio di verifica non comparirà per i dispositivi che si trovano lì.
  • Il Bulletin: AppsFlyer and Google attribution solution [Open BETA] di AppsFlyer (modificato il 5 agosto 2026) esclude il traffico iOS degli utenti in tutti e tre, e il suo articolo di setup (modificato il 15 settembre 2026) elenca UE, Regno Unito e Svizzera come non supportati.
  • Singular (aggiornato il 24 settembre 2026) dice che l’ICM non è supportato sui dispositivi iOS nello SEE e nel Regno Unito.

A maggio 2026 l’annuncio di Google iOS App campaign advancements parlava di “expanding measurement support for EEA, UK, and Switzerland users”. Non dà nessuna data. Un annuncio è un piano, quindi non pianifico il budget su questa base finché la pagina di aiuto di Google e la documentazione degli MMP non cambiano.

Un’incoerenza nella documentazione: l’elenco di troubleshooting nella pagina di Google sull’SDK standalone dice di controllare che la tua app stia girando nello SEE, nel Regno Unito e in Svizzera. Questo contraddice la pagina di Google sulla misurazione on device. La leggo come un errore della documentazione, non come prova che il supporto per l’Europa sia partito.

Gli utenti iOS europei sono comunque misurati, solo non tramite l’ICM. La pagina di Google Understanding iOS App campaign measurement and reporting dice che le conversioni modellate in Google Ads e SKAdNetwork sono disponibili per tutti gli utenti, compresi quelli dello SEE, del Regno Unito e della Svizzera. La colonna ICM non fa nessuna affermazione del genere.

Cosa copre l’ICM, e cosa lascia fuori?

Dall’articolo di setup di AppsFlyer, che ha l’elenco più completo:

  • Solo install e re-attribution. Nessun re-engagement.
  • Solo click su iOS. “Google currently claims only clicks on iOS. It does not claim impressions.” Anche Singular descrive solo la misurazione degli install click through, e Adjust dice che l’ICM è supportato solo per le App Campaign for Install.
  • Campagna e ad group, non l’annuncio. AppsFlyer dice che i claim includono campagna e ad group “in most cases” e nessuna informazione sull’annuncio. Singular dice che l’ID dell’ad group non è disponibile, e la guida di Google dice dati a livello di campagna adesso, a livello di ad group “soon”. Pianifica sul livello campagna.
  • Un canale parziale. Il campo channel mostra ACI_ senza un suffisso di rete.
  • Timestamp arrotondati. I timestamp dei claim probabilistici sono arrotondati a intervalli di 15 minuti.

La guida di Google dice anche che l’ICM supporta finestre di lookback post install fino a 180 giorni, il che conta per le subscription app i cui eventi a pagamento arrivano settimane dopo l’install. La guida lega quelle finestre al tROAS, ma la pagina di Google sul bidding dice ancora che il tROAS richiede l’SDK di Firebase, quindi la scelta del percorso di cui sopra vale ancora.

Come testo un install da inizio a fine?

Per un install di test, annota:

  1. Versioni. Build dell’app, versione di GA4F o GoogleAdsOnDeviceConversion, versione dell’SDK dell’MMP. Controlla la coppia sulla mappa delle versioni di Google.
  2. Regione. Dove si trova il dispositivo. Un dispositivo dello SEE, del Regno Unito o della Svizzera non dovrebbe produrre ODM info.
  3. Stato di ATT e consenso. La risposta ATT e le scelte della tua piattaforma di consenso, e se una delle due trattiene l’SDK dell’MMP.
  4. Ordine. Se le conversion info sono state recuperate prima che first_open venisse inviato, e se odm_info era presente sulla prima chiamata di install. Sul percorso Firebase, la sequenza di log di debug dalla tabella.
  5. Impostazioni. L’interruttore del partner dalla tabella, e first_open importato come conversione in Google Ads.
  6. La riga raw dell’MMP. In AppsFlyer, match_type di srn o probabilistic. In Singular, la suddivisione probabilistica nei report a livello utente.
  7. Valori. Cosa manda a Google ogni evento di revenue, compresi gli eventi che non portano revenue. Nell’account di cui sopra, l’evento di revenue mandava 1 $ invece di 0 $ quando non c’era valore. Google Ads mostrava il 71,4% di ROAS sulla campagna iOS contro il 17,3% di ROAS lifetime in AppsFlyer, e la causa non era l’ICM. Come leggo quel divario è in perché Google Ads, il tuo MMP e SKAN riportano conversioni iOS diverse.

Cambia un componente alla volta. Un claim mancante non è la prova di un setup rotto: AppsFlyer convalida ogni claim probabilistico di Google con il suo modello, e un claim accettato deve comunque vincere contro gli altri candidati di attribuzione.

Conviene cambiare le impostazioni di privacy o il masking dell’IP per ottenere più claim?

Non li tratto come interruttori per la copertura. Sono decisioni di compliance del proprietario dell’app.

L’articolo di setup di AppsFlyer dice che il masking dell’IP può influire sull’ICM e che Google consiglia di disattivarlo. Dice anche che con l’interruttore Aggregated Advanced Privacy attivo i dati attribuiti a Google compaiono come restricted nei report raw, e che Advanced Data Sharing manda gli install a Google con o senza un device ID. La pagina di Apple User Privacy and Data Use dice “you may not derive data from a device for the purpose of uniquely identifying it”, e che fare tracking di un utente richiede il permesso ATT.

Due fatti aiutano quella decisione: il pod FirebaseAnalytics include già la libreria ODM, e l’opt out di Google è escludere GoogleAdsOnDeviceConversion dalla build. Decidi con il tuo consulente legale per la privacy, poi misura quello che permette il setup scelto.

Perché Google Ads, l’MMP e SKAN continueranno a non coincidere?

Perché sono tre misurazioni diverse. La pagina di Google su misurazione e reporting dice che i dati ICM oggi non sono disponibili nel reporting di Google Ads, che Google Ads mostra le sue conversioni modellate con ritardi fino a cinque giorni, e che SKAdNetwork è il feed aggregato di Apple con le sue finestre. Google dice anche che il reporting iOS in Google Ads passerà dalle conversioni modellate alla ground truth attribution per le campagne con dati evento della misurazione on device. Riconcilio i tre sullo stesso evento, sulla stessa base di date e sulla stessa finestra invece di sommarli, e spiego quel metodo in perché Google Ads, il tuo MMP e SKAN riportano conversioni iOS diverse.

Dove si colloca tutto questo nel mio lavoro?

Questa è la parte Google iOS del signal engineering: fare in modo che il sistema di bidding veda le conversioni che contano davvero per il business. In pratica significa scegliere il percorso Firebase o standalone pensando al bidding, confermare l’ordine del primo avvio su un install reale, e scrivere quanto dovrebbero distare tra loro Google Ads, l’MMP e SKAN prima che qualcuno sposti budget. Se non sei sicuro che il problema sia la misurazione, è nel growth audit che lo verifico. Una misurazione migliore non decide dove spende una App campaign, cosa che spiego in perché una App campaign sposta la spesa su YouTube.

Fonti

Tutte verificate il 29 settembre 2026.

Domande frequenti

Mi serve Firebase per la misurazione on device di Google su iOS?

Non per la misurazione in sé. Google documenta un SDK GoogleAdsOnDeviceConversion standalone per le app che non possono integrare Google Analytics for Firebase, e AppsFlyer e Adjust accettano entrambi i percorsi. Firebase conta per il bidding: Google dice che il tROAS sulle App campaign richiede l'SDK di Firebase, e AppsFlyer dice che l'esclusione delle audience funziona solo quando la campagna ottimizza verso gli eventi Firebase.

Google ICM è disponibile in Europa per iOS?

Non secondo la documentazione al 29 settembre 2026. La pagina di Google sulla misurazione on device dice che la funzione è inattiva per gli utenti dello SEE, del Regno Unito e della Svizzera, AppsFlyer esclude quel traffico iOS dall'ICM, e Singular esclude i dispositivi iOS nello SEE e nel Regno Unito. Google ha annunciato un supporto esteso per quegli utenti a maggio 2026, senza una data. Le conversioni modellate in Google Ads e SKAdNetwork li coprono comunque.

Gli install ICM compariranno in Google Ads?

Oggi no. Google dice che i dati ICM non sono disponibili nel reporting di Google Ads e compaiono invece nel tuo partner di attribuzione, mentre Google Ads mostra le sue conversioni modellate. Google dice anche che il reporting iOS in Google Ads passerà dalle conversioni modellate alla ground truth attribution per le campagne con dati evento della misurazione on device.

Devo disattivare il masking dell'IP o le impostazioni di privacy per ottenere più claim ICM?

È una decisione di compliance del proprietario dell'app, non un passaggio di troubleshooting. AppsFlyer nota che il masking dell'IP può influire sull'ICM e che il suo interruttore di privacy mostra i dati di Google come restricted. Apple vieta di ricavare dati da un dispositivo per identificarlo e richiede il permesso ATT per fare tracking. Decidi quelle impostazioni con il tuo consulente legale per la privacy, poi misura quello che permette il setup scelto.