· 14 min · Samet Durgun · Dati delle piattaforme verificati il

Perché Meta web to app mostra click ma non install in AppsFlyer?

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.

Quando Meta mostra click sul link e AppsFlyer non mostra nessun install, o gli install ci sono ma sotto un’altra etichetta, o il record si è interrotto in una fase tra l’annuncio e l’app. AppsFlyer riporta gli install Meta web to app sotto Facebook Ads, non sotto metaweb_int, quindi il primo controllo è se stai leggendo l’etichetta giusta. Il secondo è seguire un singolo click di test fase per fase, finché non manca un record. Su iOS c’è un’impostazione che cambia ciò che Meta riceve, mentre i report aggregati di AppsFlyer restano uguali: con Advanced Privacy di AppsFlyer attivo, i postback per gli utenti che non hanno concesso il permesso ATT non contengono né il click ID né identificatori del dispositivo. Un telefono di test che ha concesso il permesso può passare il test, mentre nei postback di tutti gli altri manca il click ID che Meta usa per identificare il click.

Ambito: annunci Meta con la conversion location Website, misurati tramite l’integrazione Meta Web di AppsFlyer (metaweb_int), per un’app installata dall’App Store o da Google Play, con eventi trial e purchase inviati dall’SDK di AppsFlyer o da RevenueCat. Ho verificato ogni affermazione sulle piattaforme sulla pagina del vendor stesso il 1 ottobre 2026. Le campagne web che convertono sul sito stesso usano un’altra guida di AppsFlyer e restano fuori da questo post. Restano fuori anche le campagne di app promotion di Meta: se lì un evento arriva a Meta ma non puoi comunque ottimizzare per quello, ne parlo in Perché i miei eventi trial e purchase non sono idonei a Meta AEM?

Cosa può significare “click ma nessun install”?

Può essere una di tre cose, e ognuna richiede una correzione diversa.

  1. Una differenza di etichetta. La guida di AppsFlyer Meta Ads: Create web-based campaigns (modificata il 15 settembre 2026) dice che gli install web to app sono riportati “under the Facebook Ads PID” nelle dashboard e nei raw data. Nei raw data, il campo original_url conserva pid=metaweb_int, e i report dei postback mostrano metaweb_int come media source a cui è andato il postback.
  2. Due click diversi. Meta conta il click sull’annuncio. Nel flusso con landing page di AppsFlyer, il click di AppsFlyer viene registrato quando l’utente tocca la call to action sulla tua pagina. I visitatori che escono senza toccarla sono solo un’impression, che conta per un install solo se attivi l’attribuzione view through di AppsFlyer (lookback fino a 24 ore).
  3. Un’interruzione reale. Il click ID non è mai arrivato al link dello store, non è stato possibile abbinare l’install, oppure l’evento a valle non è mai arrivato a Meta.

Il test qui sotto li distingue.

Come si segue un click di test in ogni fase?

Controllo un percorso dall’inizio alla fine prima di leggere qualsiasi numero aggregato.

Imposta il test in modo che un record mancante possa significare solo un problema di setup:

  • Registra il telefono come dispositivo di test. La pagina di AppsFlyer Registering test devices (modificata il 28 agosto 2026) dice che la finestra di riattribuzione limita le attribuzioni di install a una ogni 90 giorni, quindi install di test ripetuti sullo stesso telefono non registrano nulla se non lo hai registrato. Per un iPhone che consentirà il tracking, il metodo di AppsFlyer è registrarlo tramite IDFA.
  • Concedi il permesso ATT sul telefono di test. Usa il telefono di un membro del team, tocca Allow nel prompt ATT della tua app e accetta il tuo banner di consenso se la landing page ne mostra uno. Secondo Apply Aggregated Advanced Privacy framework di AppsFlyer (modificato l’11 giugno 2026), per il traffico web verso un’app, se l’utente ha autorizzato ATT, i dati di attribuzione a livello utente arrivano sia a te sia all’ad network, quindi Advanced Privacy non limita ciò che mostra questo test.
  • Clicca sull’annuncio come farebbe un utente. Sul telefono, dentro Facebook o Instagram, non da un’anteprima desktop. Se la pagina si apre in Safari, non usare la navigazione privata: il bollettino su Link tracking Privacy (LTP) di AppsFlyer del 2023 dice che iOS 17 rimuove fbclid in quella modalità.
  • Annota l’ora di ogni passaggio, così ritrovi le righe dopo.

Poi percorri le fasi in ordine e fermati alla prima che fallisce.

Fase Cosa dovrebbe esistere Dove guardare Se manca Cosa aprire dopo Risultato osservato
1. Destinazione dell’annuncio L’URL della landing page, o il link di attribuzione, con pid=metaweb_int, c, af_c_id e gli altri parametri mappati Anteprima dell’annuncio in Ads Manager, poi l’URL che il telefono apre davvero I parametri URL non sono stati impostati sull’annuncio Fase 2 quando l’URL è corretto URL così come è stato aperto, ora
2. Click di tracking fbclid sull’URL della landing page e lo stesso fbclid sul link in uscita verso lo store URL della landing page e link della call to action sul telefono; i raw data dei click esistono solo in Data Locker Lo script non inoltra i parametri, oppure l’utente non ha mai toccato la call to action Versione di Smart Script e mappatura dei parametri fbclid visto su entrambi i link, sì o no
3. Primo avvio Un install per il dispositivo di test Raw data di AppsFlyer, install, filtrati per ora di install L’SDK non si è avviato, oppure il dispositivo non era registrato e l’install è stato contato come reinstall Integrazione dell’SDK ed elenco dei dispositivi di test Riga trovata, ora
4. Install attribuito Quell’install con media source Facebook Ads e metaweb_int in original_url La stessa riga dei raw data L’install è stato registrato come organico: non è stato possibile abbinare il click all’install Di nuovo la fase 2, poi le impostazioni di privacy Media source, original_url
5. Trial L’evento trial sullo stesso utente Raw data degli eventi in app di AppsFlyer; customer history di RevenueCat se è RevenueCat a inviare l’evento L’evento non è mai stato inviato, oppure RevenueCat non lo ha inviato perché l’attributo $appsflyerId non era impostato Mappatura degli eventi, attributi cliente di RevenueCat Nome dell’evento, ora
6. Transazione a pagamento L’evento purchase con revenue e valuta Gli stessi report; per gli acquisti in sandbox, RevenueCat ha bisogno di una chiave AppsFlyer nel suo campo Sandbox developer key La revenue non è stata inviata, oppure viene inviata due volte Chi gestisce la revenue (vedi sotto) Revenue, valuta, conteggio
7. Consegna degli eventi al partner I postback a metaweb_int per l’install e gli eventi mappati, e gli eventi in Meta Report dei postback di AppsFlyer con metaweb_int aggiunto a mano; Events Manager per lo stesso pixel Postback non mappato, purchase non impostato per includere la revenue, oppure pixel sbagliato Pagina dell’integrazione Meta Web in AppsFlyer Stato del postback, evento in Events Manager

La Raw data reporting overview di AppsFlyer (modificata l’11 agosto 2026) elenca i raw data dei click come report disponibile solo in Data Locker, quindi senza Data Locker controlli la fase 2 sui link stessi. La Raw data export page di AppsFlyer (modificata il 13 agosto 2026) dice che i PID web come metaweb_int non compaiono nel menu a tendina delle media source; per vedere i postback web aggiungi il PID a mano. La pagina dell’integrazione AppsFlyer di RevenueCat nota che la vista Events di AppsFlyer mostra gli eventi in app per data di install dell’utente, quindi un purchase fatto oggi da un utente che ha installato la settimana scorsa finisce nell’intervallo della settimana scorsa.

La guida di AppsFlyer elenca le opzioni in base alla destinazione:

  • Landing page: una pagina con OneLink Smart Script o uno Smart Banner. AppsFlyer la consiglia quando l’app è su più piattaforme, o quando vuoi che la pagina spieghi il prodotto o raccolga dati. Lo Smart Banner costruisce solo link OneLink; Smart Script può costruire anche link a piattaforma singola per altri store.
  • Direttamente allo store: un link di attribuzione di AppsFlyer, OneLink, a piattaforma singola o cross platform. AppsFlyer aggiunge un avvertimento: “Sometimes, the use of AF attribution links may lead to errors”. La correzione che suggerisce è chiedere a Meta oppure usare invece una landing page.

In Ads Manager, la campagna usa la conversion location Website con lo stesso pixel ID che hai inserito in AppsFlyer. Nella sezione Tracking, AppsFlyer dice di non scegliere App Events, “otherwise Meta will claim those conversions using the SRN API”. Se AppsFlyer non mostra affatto click, impression o costi per la campagna web, la sua guida dice che al link serve af_c_id e che l’account pubblicitario deve essere collegato nell’integrazione Facebook Ads.

Cosa deve succedere a fbclid?

Meta lo aggiunge e AppsFlyer lo passa. La pagina per sviluppatori di Meta ClickID and the fbp and fbc Parameters descrive il click ID come un parametro generato da Meta e passato con l’URL quando qualcuno clicca su un annuncio, e avverte che il valore distingue tra maiuscole e minuscole. AppsFlyer dice che Meta aggiunge fbclid all’URL di destinazione automaticamente.

Su una landing page, Set up Smart Script to convert web visitors di AppsFlyer (modificato il 2 settembre 2026) dice che Smart Script inoltra fbclid all’URL in uscita da solo a partire dalla versione 2.8.1. Per la versione 2.8.0 e precedenti, la guida Meta web dice di mapparlo a mano. Per vedere il valore nei raw data, mappalo anche su uno dei parametri da af_sub1 a af_sub5. La guida Meta web definisce fbclid essenziale per inviare a Meta i postback degli eventi in app, ed è per questo che la fase 2 della tabella controlla il valore su entrambi i link.

Perché gli install compaiono sotto Facebook Ads e non sotto metaweb_int?

È voluto. La guida Meta web dice che gli eventi vanno a Meta sotto metaweb_int ma compaiono sotto Facebook Ads nelle dashboard Overview e Activity e nel campo media_source dei raw data e dei report API. Per separare le campagne web dalle campagne app, AppsFlyer suggerisce un prefisso o un suffisso web nel nome della campagna; per confermare un singolo install, leggi il suo original_url.

Cosa cambia il passaggio su Advanced Privacy, e chi lo decide?

La guida Meta web di AppsFlyer include, come passaggio di setup, “Turn off Advanced Privacy (if you are setting an iOS app integration).” Il suo articolo su Aggregated Advanced Privacy spiega cosa fa l’impostazione. Quando è attiva, i partner ricevono solo dettagli aggregati delle campagne per gli utenti con iOS 14.5 e successivi che non hanno concesso il permesso ATT. Tra i dati a livello utente che non ricevono ci sono AppsFlyer ID, customer user ID, click ID, IDFA, IDFV, user agent e indirizzo IP. La guida Meta web dice che Meta usa fbclid per identificare il click specifico, quindi un postback che non lo contiene perde quel collegamento. L’articolo su Aggregated Advanced Privacy dice anche che un ad network senza un’integrazione Advanced Privacy non riceve nessun postback per gli utenti che non hanno dato il consenso, e che l’interruttore di un partner si può disattivare solo quando l’interruttore Aggregated Advanced Privacy a livello di app è disattivato.

Non lo tratto come un interruttore da azionare durante il debug. AppsFlyer stessa dice di lavorare con i tuoi consulenti legali e con gli altri consulenti professionali su come Apple definisce il tracking prima di disattivare il framework. La pagina di Apple User Privacy and Data Use dice che ti serve il permesso ATT per fare tracking, e che “you may not derive data from a device for the purpose of uniquely identifying it”, qualunque siano le tue impostazioni. AppsFlyer aggiunge che anche con il framework disattivato i dati a livello utente non possono essere usati per identificare in modo univoco un dispositivo. Lo decide il proprietario dell’app insieme al suo consulente legale per la privacy, e il piano di misurazione segue quella decisione. Il telefono di test di cui sopra, con il permesso ATT concesso, ti permette di verificare il setup senza toccare l’impostazione.

I postback a Meta sono configurati come documenta AppsFlyer?

Il postback di install è automatico; tutto il resto si mappa a mano. Dalla guida Meta web di AppsFlyer:

  • L’integrazione richiede il pixel ID e un access token, e l’interruttore del partner deve restare attivo.
  • Gli install sono l’unico postback automatico di default. Trial e purchase richiedono una mappatura su un evento Meta o su CUSTOM.
  • Un postback di purchase deve includere “Values and revenue”. Qualsiasi altra scelta fa fallire il postback.
  • “This partner only” invia gli eventi attribuiti a Meta; “All media sources, including organic” invia anche gli eventi attribuiti ad altri partner e all’organico. È un’impostazione dei postback: cambia ciò che Meta riceve, non se AppsFlyer attribuisce un install a Meta.
  • Gli eventi inviati server to server a metaweb_int devono includere ua e ip. L’SDK li aggiunge; il tuo server deve aggiungerli.
  • I postback per quello che AppsFlyer chiama “re-engagement” non sono supportati su questa integrazione.

Sul lato Meta, la pagina per sviluppatori Using the API dice che gli eventi si possono verificare in Events Manager entro 20 minuti dall’invio, dove la data source mostra gli eventi raw, matched e attributed.

SKAdNetwork può vedere questi install?

Non per un annuncio cliccato dentro l’app di Facebook o Instagram. La pagina di Apple Signing and providing ads elenca gli annunci web attribuibili, “where the ad network presents an ad on a Safari web page”, a partire da SKAdNetwork 4. La pagina di Google Understanding iOS App campaign measurement and reporting descrive l’osservabilità web to app “only on Safari browsers” e definisce Chrome e Firefox non supportati da SKAdNetwork. Un annuncio nell’app di Facebook o Instagram non sta su una pagina web in Safari, e la guida Meta web di AppsFlyer non menziona SKAdNetwork. Non aspettarti che SKAN spieghi qui un install mancante.

E se è RevenueCat a inviare il trial e il purchase?

Allora un solo sistema deve inviare la revenue ad AppsFlyer. La pagina AppsFlyer di RevenueCat dice di “remove all client-side tracking of revenue”, perché tracciare gli acquisti anche con l’SDK di AppsFlyer “can lead to double counting of revenue”. Elenca anche l’attributo $appsflyerId tra quelli richiesti, dice che RevenueCat invia eventi ad AppsFlyer solo quando gli attributi richiesti sono impostati, e avverte che senza l’AppsFlyer ID alcuni eventi potrebbero non arrivare, e in pratica lo vedi come una fase 5 o 6 mancante.

Per gli acquisti fatti sul web tramite Stripe, Paddle o RevenueCat Billing, l’impostazione web store event routing di RevenueCat invia ogni acquisto a una sola API di AppsFlyer, Mobile S2S di default oppure Web S2S, e la pagina dice “a purchase is never sent through both APIs”. Se un acquisto web compare comunque due volte, cerca un tracking degli acquisti ancora attivo nell’app o un altro sistema che li invia senza passare da RevenueCat. La pagina dice anche che AppsFlyer prevede di ritirare People-Based Attribution entro la fine del 2026, che è un piano dichiarato, non un cambiamento già avvenuto. Come confronto Meta, RevenueCat e un MMP quando i loro numeri non coincidono lo spiego in Meta vs RevenueCat vs Adjust: di quale numero ti fidi?

Cosa non devi concludere da un solo test?

Un test superato dimostra che il percorso funziona per un utente che ha concesso il permesso ATT su un telefono, non il match rate per tutti gli altri. Un test fallito non mostra quale impostazione sia la causa finché non cambi una cosa e lo rifai. Nessuna pagina dei vendor che ho controllato documenta una singola impostazione come la correzione per gli install web to app mancanti, e se cambi più cose insieme non capisci quale ha contato. Annota ogni volta la fase, la modifica e il nuovo risultato osservato.

Che parte ha il signal engineering in tutto questo?

Seguire un click in questo modo fa parte del signal engineering: far sì che l’evento su cui ottimizza la piattaforma ads sia quello che conta per il business, e che arrivi. Per capire se la misurazione c’entra con una campagna web di Meta che sembra debole c’è il growth audit, che si prenota anche da solo. Il lato Google del web to app, dove click ID e upload delle conversioni funzionano in modo diverso, è in Perché Google web to app non mostra conversioni in AppsFlyer? Il motivo per cui un team manderebbe il traffico di Google Search a un’app in questo modo è in Le Google Search Ads funzionano per gli install di app?

Fonti

Tutte verificate il 1 ottobre 2026.

Domande frequenti

Perché i miei install Meta web to app non compaiono sotto metaweb_int in AppsFlyer?

Perché AppsFlyer li riporta sotto Facebook Ads. La sua guida alle campagne web di Meta dice che le attribuzioni web to app compaiono sotto Facebook Ads nelle dashboard Overview e Activity e nel campo media_source dei raw data, mentre il campo original_url conserva pid=metaweb_int e i report dei postback mostrano metaweb_int. Una dashboard filtrata su metaweb_int può sembrare vuota anche se gli install ci sono.

Un annuncio Meta web to app deve portare a una landing page o direttamente all'App Store?

AppsFlyer supporta entrambe le opzioni. Consiglia una landing page con Smart Script o Smart Banner quando l'app è su più piattaforme o vuoi che la pagina spieghi il prodotto o raccolga dati, e i link di attribuzione OneLink, a piattaforma singola o cross platform per mandare gli utenti direttamente allo store. Avverte anche che i link di attribuzione possono portare a errori e indica una landing page come alternativa.

Devo disattivare Advanced Privacy per le campagne web di Meta su iOS?

Il passaggio di setup di AppsFlyer dice di disattivarlo per un'integrazione di app iOS. Con Advanced Privacy attivo, AppsFlyer non passa ai partner i dati a livello utente, come click ID, IDFV, user agent e indirizzo IP, per gli utenti con iOS 14.5 e successivi che non hanno concesso il permesso ATT. Cambiarlo è una decisione di privacy e legale che spetta al proprietario dell'app, non un passaggio di debug. In ogni caso Apple vieta di ricavare dati da un dispositivo per identificarlo.

SKAdNetwork può misurare gli install dagli annunci web di Meta?

Solo in un caso ristretto. Apple documenta gli annunci web attribuibili, cioè quelli che un ad network firma e mostra su una pagina web in Safari, a partire da SKAdNetwork 4. La pagina di Google sulla misurazione iOS dice che Chrome e Firefox non sono supportati da SKAdNetwork. La guida Meta web di AppsFlyer non menziona SKAdNetwork, quindi non aspettarti che colmi il vuoto.

Perché un purchase web to app compare due volte nella revenue di AppsFlyer?

Controlla se un secondo sistema invia la revenue. RevenueCat ti dice di rimuovere tutto il tracking di revenue lato client quando la sua integrazione con AppsFlyer è attiva, perché tracciare gli acquisti anche con l'SDK di AppsFlyer può contare la revenue due volte. Per gli acquisti da web store dice che un acquisto non viene mai inviato tramite entrambe le API di AppsFlyer che usa, quindi cerca un tracking degli acquisti ancora attivo nell'app o un altro sistema che li invia senza passare da RevenueCat.