Se una campagna web di Google non mostra conversioni app, controlla quattro passaggi separati in ordine e fermati al primo che fallisce: il tracking link è adatto al Final URL, l’annuncio è approvato, AppsFlyer ha attribuito l’install sotto la media source che stai leggendo, e Google ha accettato l’upload della conversione. Parti dal tipo di campagna e dal Final URL, perché la destinazione cambia la risposta. Se i tuoi annunci mandano le persone direttamente all’App Store o a Google Play, l’upload di AppsFlyer verso la Offline Conversion API di Google è il percorso che AppsFlyer documenta, e Google dice che il suo Web to App Acquisition Measurement non è disponibile per gli account le cui campagne web mandano gli utenti a un app store.
Ambito: campagne web di Google Ads (qualsiasi obiettivo tranne App promotion) che promuovono un’app iOS o Android, misurate tramite l’integrazione Google Ads Web di AppsFlyer (googleads_int), con le differenze di Singular e Adjust segnalate. Nessuna delle pagine qui sotto indica un limite regionale. Verificato sulle pagine di ciascun vendor il 1 ottobre 2026. Perché scegliere questo percorso invece delle App campaign lo trovi in Le Google Search Ads funzionano per gli install di app?. Questo post parla solo di come farlo misurare.
Cosa devi controllare per primo?
Il tipo di campagna e il Final URL, perché ogni altra regola dipende da questi due. La guida di AppsFlyer, Google Ads (AdWords): Create web-based campaigns, vale per ogni obiettivo di Google tranne App promotion e per ogni tipo di campagna tranne Shopping. Una App campaign è un’integrazione diversa, quindi se gestisci quella, questo non è il post giusto.
Poi leggi il Final URL dell’annuncio. È una scheda dello store, una tua pagina web o, per errore, un link AppsFlyer, e ognuno richiede un tracking link diverso.
Quale link e quale fonte di conversioni vanno con il tuo Final URL?
Nella tabella le regole sui link sono di AppsFlyer, quelle sulla misurazione di Google.
| Final URL | Tracking template (AppsFlyer) | Cosa fallisce | Da dove arrivano le conversioni di Google | Come verificare | Limiti noti |
|---|---|---|---|---|---|
| Scheda dell’App Store o di Google Play | Link di attribuzione a piattaforma singola con af_r={lpurl} |
Un OneLink qui restituisce “Tracking call unsuccessful” da Google | L’upload di AppsFlyer verso la Offline Conversion API (OCI) di Google. Il Web to App Acquisition Measurement di Google non è disponibile per un account con campagne web che mandano gli utenti a uno store | Il pulsante Test di Google sul template, poi un click reale che compare in AppsFlyer | I parametri di AppsFlyer possono stare solo nel template. L’attribuzione view through di AppsFlyer per queste campagne richiede una landing page con Smart Script o Smart Banners, quindi qui non si applica |
| Una tua pagina web con Smart Script o Smart Banners | Facoltativo. OneLink con af_android_url, af_ios_url e af_web_dp tutti impostati su {lpurl}, oppure af_r={lpurl} |
Senza template: le persone che saltano il pulsante della pagina e vanno allo store da sole non possono essere attribuite. Con un template: le persone che toccano il pulsante registrano due click | L’upload OCI di AppsFlyer, e separatamente il Web to App Acquisition Measurement di Google se importi i first open e nessuna campagna web dell’account manda gli utenti a uno store | L’URL in uscita del pulsante porta gclid, gbraid o wbraid |
Smart Script inoltra gclid automaticamente dalla versione 2.8.1 e gbraid e wbraid dalla 2.9.0. Gli Smart Banners generano solo link OneLink. La pagina stessa deve superare la policy di Google sulle destinazioni |
| Un link AppsFlyer (OneLink o a piattaforma singola) | Non applicabile | AppsFlyer avverte che questo può far rifiutare la campagna | Nessuna finché il Final URL non viene corretto | Non applicabile | Il Final URL deve essere un indirizzo diretto senza redirect |
Tieni separate le due fonti. L’upload di AppsFlyer manda ciò che AppsFlyer ha attribuito, abbinato ai click di Google tramite click ID. Il Web to App Acquisition Measurement di Google è Google che conta gli install per conto suo a partire dai first open importati. In un account le cui campagne web vanno direttamente allo store, è disponibile solo la prima.
Di cosa ha bisogno il tracking template?
La guida di AppsFlyer elenca le parti, e ne basta una mancante o sbagliata per rompere il link o l’annuncio:
pid=googleads_int, obbligatorio.af_siteid, obbligatorio, con un valore qualsiasi scelto da te.c, obbligatorio e statico. AppsFlyer dice che non esiste un parametro ValueTrack per questo, quindi scrivi il nome a mano. Metti l’ID della campagna inaf_c_id={campaignid}, che serve ad AppsFlyer anche per i dati di costo, click e impression.af_force_transparent=true, obbligatorio. AppsFlyer dice che senza questo Google può non approvare l’annuncio.- Un redirect a
{lpurl}. Il valore{lpurl}deve usare HTTPS, essere codificato e stare su un dominio presente nella tua allowlist dei redirect.
AppsFlyer rifiuta af_dp, af_android_store_csl, af_ios_store_cpp, af_og_title, af_og_description e af_og_image in questo flusso, e vieta af_base_params_forward e af_param_forwarding perché alterano {lpurl}. Nessun parametro duplicato, nessun parametro senza valore, nessun parametro ValueTrack che Google lascia vuoto, e i valori impostati sotto Campaign URL options in Google Ads devono corrispondere al template.
Sul lato Google, About tracking in Google Ads dice che il template e ogni redirect devono essere HTTPS ed eseguiti sul server, e il pulsante Test controlla che il Final URL più il tuo tracking si risolva. About parallel tracking dice che il parallel tracking è obbligatorio per Search, Shopping, Display, Video e Performance Max: l’utente va direttamente al Final URL mentre il template si carica in background. AppsFlyer lega la sua regola sul redirect a {lpurl} proprio a questo.
Perché un redirect che funziona non dimostra che il setup funziona?
Un click che atterra nel posto giusto ha superato solo il primo di quattro controlli. Testali separatamente, con un click reale su un telefono, e annota il primo che fallisce.
- Validazione del link. Il pulsante Test di Google va a buon fine, e il click di test compare in AppsFlyer sotto la campagna che ti aspetti. Un errore “Tracking call unsuccessful” rimanda al tipo di link nella tabella.
- Approvazione dell’annuncio. La policy Destination requirements di Google non approva un tracking template che non porta allo stesso contenuto del Final URL, né le destinazioni “solely designed to send users elsewhere”, cosa che conta se la tua landing page si limita a rimandare le persone allo store. About ValueTrack parameters dice che le modifiche al template impiegano da 24 a 48 ore per arrivare agli annunci in pubblicazione, quindi testa dopo quella finestra. About tracking in Google Ads dice che le opzioni URL impostate o modificate a livello di annuncio, keyword o sitelink tornano in revisione, mentre quelle a livello di account, campagna o ad group no.
- Attribuzione dell’MMP. L’install compare in AppsFlyer. AppsFlyer lo attribuisce in modo probabilistico, o deterministico quando è disponibile un install referrer.
- Accettazione dell’upload. Google ha ricevuto la conversione, l’ha abbinata a un click e l’ha contata sull’azione di conversione giusta.
Un test del redirect non dice niente sui passaggi 3 e 4, e una segnalazione di “nessuna conversione” riguarda proprio quelli.
Dove compaiono in AppsFlyer gli install web to app di Google?
Per lo più non sotto il partner che hai configurato. AppsFlyer manda le conversioni a Google sotto googleads_int, ma le sue dashboard e i suoi raw data le riportano sotto googleadwords_int, la media source della sua integrazione principale con Google Ads, così i risultati delle campagne web e delle App campaign stanno in un’unica vista. Il campo original_url dei raw data e i report dei postback mantengono googleads_int. La tabella dei traits della stessa pagina aggiunge che gli install possono comparire sotto googleads_int con i re-engagement sotto googleadwords_int quando accanto è attiva un’integrazione SRN googleadwords_int. AppsFlyer dice anche che Google può rivendicare da sé alcuni install delle campagne web, come attribuzioni googleadwords_int self reported, e che questo “may become more common as Google expands support for web campaign install attribution”. Per iOS indirizza queste campagne alla Classic Dashboard e dice che la SKAN Dashboard, nella maggior parte dei casi, non è rilevante per queste campagne.
Quindi, prima di concludere che non ci sono install, filtrerei la dashboard per googleadwords_int e per l’ID della campagna, controllerei anche googleads_int, e poi confermerei nei raw data che original_url contiene googleads_int.
Perché AppsFlyer mostra l’install ma Google non mostra niente?
Allora l’upload sta fallendo, o arriva dove non stai guardando. I passaggi di setup e di troubleshooting di AppsFlyer indicano i controlli:
- Gli eventi sono mappati. Gli install sono l’unico postback automatico. Ogni altro evento ha bisogno di un’azione di conversione Google creata come click import, con il suo valore
ctidincollato nella mappatura degli eventi di AppsFlyer. Una nuova azione di conversione compare come Inactive finché non arrivano dati. - Count è impostato su Every. AppsFlyer dice che l’azione di conversione deve usare Every, non One, per accettare gli upload di
gbraidewbraid. - I click ID non si perdono. Google aggiunge
gclidper Android e per gli utenti iOS che danno il consenso, egbraidewbraidper gli utenti iOS che non lo hanno dato. Su una landing page, l’URL in uscita del pulsante deve contenerne uno, altrimenti il postback non viene registrato. Per vederli nei raw data, mappa anche ciascuno sul proprio parametroaf_sub. - Il token funziona. Lo scope OAuth
https://www.googleapis.com/auth/adwords, Sign in with Google fatto in AppsFlyer e l’ID del manager account (MCC) in entrambi i campi Customer ID quando più di un account Google Ads gestisce l’app. Un errore “Missing token” significa che questo passaggio non è stato fatto. - Account di agenzia. Se la campagna è gestita da un’agenzia, devono essere attive sia l’integrazione
googleads_intdell’inserzionista sia quella dell’agenzia, e l’agenzia deve fare Sign in with Google, altrimenti il postback fallisce. - Il piano. AppsFlyer dice che
googleads_intè disponibile solo sui suoi piani Growth ed Enterprise, non su Zero o Welcome. - Impostazione di privacy su iOS. Il setup di AppsFlyer dice alle app iOS di disattivare Advanced Privacy per questo partner. La sua pagina Apply Aggregated Advanced Privacy framework dice che finché è attivo l’interruttore Aggregated Advanced Privacy a livello di app o l’interruttore Advanced Privacy di un partner, identificatori come click ID, IDFV, user agent e IP degli utenti iOS 14.5+ senza consenso ATT non sono disponibili per i partner, e che l’interruttore del partner può essere cambiato solo una volta disattivato quello a livello di app. Dice anche agli inserzionisti di lavorare con i consulenti legali su come Apple definisce il tracking prima di disattivare l’impostazione a livello di app. La pagina User Privacy and Data Use di Apple dice “you may not derive data from a device for the purpose of uniquely identifying it”. Quell’impostazione la decidono il proprietario dell’app e il consulente legale per la privacy, prima del test.
In Google Ads, apri l’azione di conversione indicata nella mappatura, perché la colonna Conversions può lasciarla fuori. La pagina di Google About primary and secondary conversion actions dice che le azioni secondarie sono riportate in All conversions e non sono usate per il bidding, a meno che non stiano in un custom goal.
Nemmeno quando Google accetta l’upload hai finito. In un test su una Google App campaign che ho fatto a febbraio e marzo 2026, misurato in AppsFlyer, l’evento di revenue mandava 1 $ invece di 0 $ quando non c’era valore. Google ha ricevuto quei valori, e il ROAS che riportava era gonfiato ovunque, soprattutto su iOS, dove i volumi di conversione erano più bassi. Era una App campaign, non una campagna web, ma la lezione vale lo stesso: controlla i valori che Google ha ricevuto oltre al conteggio. Ho raccontato il resto di quel test in qual è la migliore bid strategy di Google Ads per le app.
In cosa è diversa la misurazione web to app di Google?
È Google che conta gli install senza l’upload del tuo MMP. La pagina di Google About Web to App Acquisition Measurement dice:
- Copre le campagne Search, Performance Max, Shopping, Hotel, Video e Demand Gen, su Android e iOS, e non è disponibile per gli account con campagne web che mandano gli utenti a un app store.
- Gli install indiretti richiedono gli eventi first open di entrambe le piattaforme importati nell’account che contiene le campagne web, e compaiono in All conv. La colonna Web to app first conv. richiede anche le azioni in app importate e una di queste usata per il bidding come azione primaria.
- L’Integrated Conversion Measurement si è esteso all’acquisizione web to app tramite la misurazione on device, cosa che secondo Google migliora l’attribuzione degli install iOS sull’inventario Search e Shopping delle tue campagne web presso i partner di attribuzione di terze parti. L’inventario Video e Display è descritto come in arrivo più avanti.
- Una conversione è attribuita a una sola campagna, senza doppio reporting tra App campaign e campagne web, e Google dice che la stessa logica si estende al reporting dei partner.
Google dice anche di aver iniziato a rivendicare e riportare i first open dell’app generati dall’inventario Search e Shopping nelle campagne Search, Performance Max e Shopping. Google indica quel cambiamento e l’estensione dell’ICM come i motivi per cui gli install attribuiti alle campagne web possono aumentare presso il tuo partner di attribuzione senza nessuna modifica ai tuoi link. In AppsFlyer, gli install che Google rivendica arrivano come attribuzioni googleadwords_int self reported, non tramite il tuo upload googleads_int. Nella mia guida al setup per le App campaign iOS trovi cosa richiedono l’ICM e la misurazione on device dentro l’app, MMP per MMP.
Funziona allo stesso modo su Singular o Adjust?
No, e le differenze contano per iOS.
La guida Google Ads Web - Web to App Campaigns di Singular mette il link Singular nel tracking template con l’URL dello store come Final URL (o il tuo sito con il suo Web SDK), richiede _global_redirect={lpurl} nel link, altrimenti l’annuncio viene rifiutato, e dice che il deep linking deve essere disattivato. La sua FAQ dice che l’upload offline passa gclid automaticamente ed elenca gbraid e wbraid come in arrivo a breve, e indica come limiti della Offline Conversions API le sole conversioni da click, senza modeling. Richiede anche che in Google Ads siano attive le enhanced conversions for leads. Il suo riepilogo dell’integrazione segna view through e re-engagement come non supportati. Quindi, secondo la pagina stessa di Singular, i click iOS senza consenso, che portano gbraid o wbraid invece di gclid, non hanno ancora un click ID che Singular possa caricare.
La pagina Extend your Google Ads setup beyond app campaigns di Adjust dice che Google Ads non accetta gli universal link o i branded link di Adjust come tracking template, che modificare il link di Adjust può farlo rifiutare, e che Google Ads potrebbe non rivendicare l’attribuzione per certi utenti nelle campagne web to app.
Dove entra il mio lavoro in questo caso?
Per il signal engineering il punto è uno: il bidding ottimizza solo sulle conversioni che riceve, e qui si tratta di far arrivare a Google quelle di una campagna web. L’ordine segue dalle regole qui sopra: definisci il Final URL, abbina a quello il tipo di tracking link, fai i quattro controlli e leggi la performance solo dopo che l’upload è stato accettato. Se non sei sicuro che sia la misurazione a frenare l’account, lo verifico nel growth audit, che si può prenotare anche da solo. Per il confronto con le App campaign c’è perché una Google App campaign spende su YouTube. Lo stesso percorso di verifica per Meta lo trovi in perché il web to app di Meta mostra click ma nessun install in AppsFlyer.
Fonti
Tutte verificate il 1 ottobre 2026.
- AppsFlyer: Google Ads (AdWords): Create web-based campaigns, modificato il 15 settembre 2026.
- AppsFlyer: Apply Aggregated Advanced Privacy framework, modificato l’11 giugno 2026.
- Google Ads Help: About Web to App Acquisition Measurement, senza data di pagina.
- Google Ads Help: About primary and secondary conversion actions, senza data di pagina.
- Google Ads Help: About tracking in Google Ads, senza data di pagina.
- Google Ads Help: About parallel tracking, senza data di pagina.
- Google Ads Help: About ValueTrack parameters, senza data di pagina.
- Advertising Policies Help: Destination requirements, senza data di pagina.
- Singular: Google Ads Web - Web to App Campaigns, modificato il 24 agosto 2026.
- Adjust Help Center: Extend your Google Ads setup beyond app campaigns, senza data di pagina.
- Apple Developer: User Privacy and Data Use, senza data di pagina.
Domande frequenti
Posso usare un OneLink come tracking template quando il Final URL è l'App Store?
No. La guida di AppsFlyer alle campagne web di Google dice che quando il Final URL punta direttamente a Google Play o all'App Store, il tracking template deve essere un link di attribuzione a piattaforma singola, e che un OneLink in quella posizione restituisce un errore "Tracking call unsuccessful" da Google. Il OneLink va nel template quando il Final URL è una tua pagina web.
Il Web to App Acquisition Measurement di Google funziona se i miei annunci mandano le persone direttamente all'App Store?
No. La pagina di aiuto di Google dice che la funzione non è disponibile per gli account con campagne web che indirizzano gli utenti a un app store come l'Apple App Store o Google Play. In un account così, il percorso che AppsFlyer documenta per un Final URL verso lo store è il suo upload verso la Offline Conversion API di Google. Verificato il 1 ottobre 2026.
Perché i miei install web di Google compaiono sotto googleadwords_int invece di googleads_int?
Perché AppsFlyer li riporta così. Le conversioni vengono mandate a Google sotto googleads_int, ma le dashboard e i raw data di AppsFlyer le mostrano sotto googleadwords_int. Il campo original_url mantiene googleads_int, e così i report dei postback. La tabella dei traits di AppsFlyer aggiunge che gli install possono comparire sotto googleads_int con i re-engagement sotto googleadwords_int quando è attiva anche un'integrazione SRN googleadwords_int, quindi controlla entrambi prima di concludere che niente è stato attribuito.
Devo disattivare Advanced Privacy in AppsFlyer per il web to app su iOS?
I passaggi di setup di AppsFlyer dicono di disattivarlo per un'integrazione iOS. La sua pagina su Aggregated Advanced Privacy dice che finché quell'impostazione è attiva, identificatori come click ID, IDFV, user agent e IP degli utenti iOS 14.5+ senza consenso ATT non sono disponibili per i partner, e dice agli inserzionisti di lavorare con i consulenti legali su come Apple definisce il tracking prima di disattivare l'impostazione a livello di app. Se cambiarla o no lo decidono il proprietario dell'app e il consulente legale, prima di iniziare il debug.