· 16 min · Samet Durgun

Perché i miei eventi trial e purchase non sono idonei a Meta AEM?

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.

Un evento che arriva in Events Manager non è ancora un evento per cui puoi ottimizzare. Meta segna separatamente ogni evento iOS come idoneo o non idoneo all’Aggregated Event Measurement, e tra i motivi che elenca ci sono un evento inviato tramite un’integrazione diversa da quella del tuo evento di install, dati mancanti che il percorso deve portare, o troppo pochi segnali negli ultimi 30 giorni. Quale di questi si applica dipende dal tuo percorso: RevenueCat che invia direttamente a Meta ha requisiti diversi da RevenueCat che invia ad AppsFlyer, il quale poi li rimanda a Meta.

Nei miei account, di solito risolve un ordine preciso: configura AEM in Events Manager e attiva l’attribuzione probabilistica nell’MMP, fai partire una campagna install, e solo dopo sposta l’ottimizzazione sul trial o sul purchase quando Events Manager lo mostra come idoneo. Questa è la mia pratica, non una correzione documentata da Meta; i dettagli sono nella sezione sull’ordine di setup più sotto.

Ambito: campagne di app promotion su Meta per iOS 14+ che usano AEM e ottimizzano per eventi app o per valore (gli obiettivi di Meta “maximize number of app events” e “maximize value of conversions”). Due percorsi, tenuti separati dall’inizio alla fine: RevenueCat direttamente a Meta, e RevenueCat ad AppsFlyer a Meta. La sezione sull’ordine di setup nomina anche le impostazioni corrispondenti in Adjust e Singular. Niente di quanto scrivo qui è specifico di una regione. Ogni pagina dei vendor qui sotto è stata verificata il 29 settembre 2026. Le pagine di aiuto di Meta non mostrano date e cambiano senza preavviso, quindi ricontrollale prima di agire.

Dove dice Meta che un evento non è idoneo?

In Events Manager. La pagina di Meta How to check if your app events are eligible for Aggregated Event Measurement indica il percorso: Datasets, il tuo dataset, la scheda Settings, Setup tasks for iOS app events, poi Check app eligibility nella sezione “Meta’s attribution for iOS 14+”. La colonna Eligibility segna ogni evento come idoneo o non idoneo, More details spiega il perché, e uno stato pending significa che Meta sta ancora aspettando o verificando informazioni dalla tua integrazione.

La pagina di Meta Troubleshoot issues with app eligibility for Aggregated Event Measurement elenca ogni messaggio con cosa può significare e la correzione. Annota il messaggio esatto e la data prima che qualcuno tocchi il setup, perché ogni messaggio di quella pagina rimanda a una correzione diversa.

È ricezione, dati richiesti o idoneità?

Dietro “l’evento non funziona” si nascondono tre domande diverse:

  • Ricezione. Meta ha ricevuto l’evento? La pagina Meta Ads di RevenueCat dice che Events Manager può impiegare fino a 24 ore per mostrare gli eventi accettati.
  • Dati richiesti. L’evento porta ciò che serve al tuo percorso per AEM? Cambia da percorso a percorso.
  • Idoneità all’ottimizzazione. Meta lascerà ottimizzare una campagna su di esso? La pagina di RevenueCat è esplicita: una delivery riuscita significa solo che Meta ha accettato l’evento, e Meta decide comunque se è idoneo per una campagna, un obiettivo o un report.

La tabella ordina i sintomi più comuni per livello. La colonna del percorso conta: un requisito documentato per un percorso non è una prova sull’altro.

Livello Sintomo Sistema da controllare Evidenza necessaria Prossima azione
Ricezione StartTrial o Subscribe mancano in Events Manager (RevenueCat diretto) Customer History di RevenueCat, riga di delivery di Meta Ads Schede Request e Response; per la Conversions API, l’fbtrace_id Nessuna riga: controlla gli attributi richiesti e segui il troubleshooting di RevenueCat per una riga di delivery mancante. Accettato: aspetta fino a 24 ore, come documenta RevenueCat, prima di controllare Events Manager
Ricezione Eventi mancanti in AppsFlyer (percorso AppsFlyer) Attributi cliente di RevenueCat Se $appsflyerId è stato impostato prima dell’acquisto Impostalo dopo aver configurato il Purchases SDK e prima del primo acquisto
Dati richiesti Pochi o nessun evento App Store arriva a Meta (RevenueCat diretto) Impostazioni Meta Ads di RevenueCat e attributi cliente $fbAnonId o un IDFA reale, lo stato ATT, l’impostazione “Send events when ATT consent is not authorized” Decidi l’impostazione del consenso in modo deliberato, con una tua verifica sulla privacy
Dati richiesti Eventi server to server non idonei (percorso AppsFlyer) Un payload grezzo di un evento IP address e IDFV presenti su ogni evento Raccogli gli identificatori del dispositivo in RevenueCat in modo che $ip e $idfv siano impostati prima dell’acquisto
Dati richiesti “Contact your mobile measurement partner (MMP) to check eligibility steps for Meta’s attribution for iOS 14+” La dashboard dell’MMP Se l’impostazione AEM dell’MMP è attiva Attivala; l’ordine di setup più sotto la nomina per ogni MMP
Dati richiesti “IP data version isn’t optimal for setup” L’integrazione indicata nel messaggio Se l’IP manca o viene inviato in modo incoerente Invia l’IP in modo coerente; sul percorso AppsFlyer, disattiva l’IP masking
Dati richiesti “Advertiser Tracking Enabled parameter volume out-of-range” Lo stato ATT sugli eventi in ingresso Quota di eventi con tracking non abilitato o con IDFA azzerato Controlla il tasso di consenso ATT; per questo Meta rimanda al tuo account manager
Idoneità “Different integrations across multiple event types” Events Manager, l’evento di install e l’evento trial o purchase Quale integrazione invia ciascuno Invia l’install e l’evento di ottimizzazione tramite la stessa integrazione
Idoneità “Multiple integrations for the same event” Events Manager, Manage event Ogni fonte che invia l’evento Scegli un’integrazione per l’evento; rimuovi il logging duplicato lato client
Idoneità “Not enough signals from last 30 days” Events Manager e lo strumento test events Conteggi degli eventi su 30 giorni Conferma il setup con i test events, poi guarda quanto volume lascia passare il percorso
Idoneità Pending, “Awaiting or verifying information from your integration” Events Manager Data in cui è comparso lo stato Ricontrolla dopo 3 giorni, come dice Meta

Cosa richiede il percorso RevenueCat diretto?

La pagina Meta Ads di RevenueCat stabilisce quattro punti che qui contano.

Il Meta SDK resta. RevenueCat dice di tenere il Meta SDK per install, attivazione e segnali on device; i suoi eventi server to server non sostituiscono il setup del Meta SDK per le campagne install, SKAdNetwork o AEM. Consiglia la Conversions API rispetto alla App Events API per affidabilità e supporto a lungo termine, e osserva che può inviare conversioni di trial e rinnovi quando l’app non è aperta.

La delivery dipende da identificatori e consenso. Per gli eventi App Store tramite la Conversions API, RevenueCat tenta la delivery solo quando il cliente ha $fbAnonId o $idfa, più uno stato ATT authorized, a meno che non sia abilitata l’impostazione della dashboard “Send events when ATT consent is not authorized”. Tratta come mancanti i valori IDFA vuoti o azzerati. IDFV, IP, email e numero di telefono non sono tra gli attributi che richiede per la delivery; li elenca come attributi che Meta può usare per il matching quando sono presenti. RevenueCat ti chiede di impostarli dopo aver configurato il suo SDK e prima del primo acquisto quando possibile, e di raccogliere di nuovo gli identificatori del dispositivo dopo che il permesso ATT è stato concesso.

RevenueCat dice che lasciare l’impostazione disabilitata richiede il consenso ATT authorized prima che gli eventi App Store vengano inviati. La sua pagina non dice a parole da quale stato parta una nuova integrazione, quindi guarda l’impostazione nella tua dashboard prima di trarre conclusioni dai conteggi di eventi di Meta. Quindi, con l’impostazione disabilitata, gli eventi trial e purchase dell’App Store degli utenti che non hanno autorizzato il tracking non vengono inviati a Meta su questo percorso, e Meta vede meno eventi di quanti ne registra RevenueCat. La mia lettura è che su un account piccolo questa sia una via plausibile verso “Not enough signals from last 30 days”. Abilitare l’impostazione è una decisione di privacy, non un ritocco di misurazione.

Subscribe copre molto. Di default RevenueCat mappa Trial Started su StartTrial, e Trial Converted, Initial Purchase e Renewal tutti su Subscribe. Un acquisto non rinnovabile va a fb_mobile_purchase. Quindi un conteggio Subscribe in Events Manager mescola primi pagamenti e rinnovi. RevenueCat ti lascia scegliere altri nomi di eventi standard di Meta per questi eventi, e osserva che Meta consiglia gli eventi standard per ottimizzare le campagne. Se qualcuno ha cambiato la mappatura, controlla per prima cosa su quale nome di evento ottimizza la tua campagna.

Una fonte per evento, e la questione dell’integrazione. RevenueCat dice di rimuovere il logging lato client di acquisti e revenue per gli eventi che invia, perché il Meta SDK e RevenueCat non condividono un event_id. La pagina di troubleshooting di Meta aggiunge una regola che qui conta: un evento può non essere idoneo per obiettivi di eventi app o di valore quando arriva tramite un’integrazione diversa da quella del tuo evento di install, e la correzione è usare la stessa integrazione per entrambi. La pagina di Meta About Partner Integrations for app events, nei suoi consigli per l’ottimizzazione del valore, nomina il Facebook SDK, un MMP e la Conversions API come canali separati e ti chiede di inviare ogni evento tramite uno solo. Sul percorso diretto, gli install vengono dal Meta SDK e i trial e i pagamenti dalla Conversions API. Le pagine di Meta citate qui non dicono se consideri quell’abbinamento come due integrazioni per questa regola, quindi controlla in Events Manager l’integrazione scelta per entrambi gli eventi invece di darla per scontata.

Cosa richiede il percorso AppsFlyer?

RevenueCat invia gli eventi ad AppsFlyer, che li rimanda a Meta. Due pagine fissano i requisiti, e sono diversi.

La pagina di AppsFlyer Meta Ads Aggregate Event Measurement (AEM) for iOS dice che per gli eventi in app inviati server to server, Meta richiede sia l’indirizzo IP sia l’IDFV nel payload dell’evento, e che senza di essi l’evento non è idoneo per l’attribuzione Meta in AEM. La pagina AppsFlyer di RevenueCat segna come richiesto solo $appsflyerId. Elenca $idfa, $idfv e $ip come consigliati, e ti chiede di impostare gli attributi dopo la configurazione del Purchases SDK e prima del primo acquisto, avvertendo che alcuni eventi potrebbero non essere consegnati senza l’AppsFlyer ID. L’helper collectDeviceIdentifiers di RevenueCat raccoglie $idfa, $idfv e $ip. Su questo percorso, tratta “consigliato” come richiesto per AEM, perché AppsFlyer dice che Meta ha bisogno di entrambi.

La checklist di troubleshooting di AppsFlyer per gli eventi non idonei, nel suo ordine, escludendo il passaggio per le campagne di remarketing:

  1. Advanced Data Sharing attivo nell’integrazione Meta Ads (Collaborate, Active Integrations, Meta Ads). Se è disattivato, vengono condivisi solo gli eventi degli utenti con un advertiser ID. La tabella riassuntiva di AppsFlyer lo indica come l’interruttore che abilita AEM per l’app promotion, ed è l’impostazione dell’MMP nell’ordine di setup più sotto.
  2. IP masking disattivato in App Settings. AppsFlyer dice che gli eventi con IP mascherati non sono idonei.
  3. IP address e IDFV su ogni evento server to server.
  4. Tasso di consenso ATT rivisto. Meta accetta un volume limitato di eventi con IDFA mancanti o azzerati.
  5. Postback mappati su “Send all (including organic)”. La pagina partner di Meta dà lo stesso consiglio.
  6. Se gli eventi restano non idonei, imposta il traffico MMP come connessione preferita in Events Manager.

RevenueCat ti chiede anche di rimuovere il tracking di revenue lato client nell’SDK di AppsFlyer per evitare il doppio conteggio. La mia lettura è che questo percorso possa mettere install ed eventi trial o purchase su un’unica integrazione, che è ciò che chiede la correzione della stessa integrazione di Meta, purché nessun’altra fonte invii gli stessi eventi.

Meta limita ancora le app a otto eventi?

La pagina di Meta “How to configure app events to use Meta’s Aggregated Event Measurement”, che definiva otto slot per la configurazione AEM di un’app, ora restituisce Page Not Found (verificata il 29 settembre 2026), quindi le guide che ti dicono di classificare otto eventi app per AEM descrivono un setup che Meta non documenta più. La pagina di Meta About Meta’s Aggregated Event Measurement dice che sta introducendo gradualmente aggiornamenti alle campagne app, e che con questi puoi far girare campagne di app promotion senza configurare gli eventi app per SKAdNetwork, con più eventi app disponibili per l’ottimizzazione. La classificazione degli eventi che Meta documenta ancora appartiene alla configurazione SKAdNetwork: la sua pagina About value sets descrive lì priority ID da 1 a 63, e dice che non devi abilitare i value set per gli eventi inviati tramite AEM. Nessuno dei messaggi della pagina di troubleshooting di Meta riguarda l’ordine degli slot, quindi non spenderci una diagnosi.

Quanto devo aspettare dopo una correzione?

Cambia una cosa, scrivi la data, poi aspetta la finestra che si applica:

  • Gli eventi accettati possono impiegare fino a 24 ore per comparire in Events Manager (RevenueCat).
  • Un cambio dell’integrazione scelta può impiegare fino a 24 ore per riflettersi, secondo la pagina di Meta Choose a single integration for app events in Meta Events Manager if you send events from multiple integrations.
  • Un evento pending: ricontrolla dopo 3 giorni (Meta).
  • Dopo aver selezionato un’integrazione per risolvere un messaggio: fino a 7 giorni per ricontrollare, e nel frattempo le modifiche alle campagne potrebbero non essere disponibili (Meta).
  • Dopo la checklist di AppsFlyer: fino a 2 o 3 giorni perché Meta rifletta l’idoneità (AppsFlyer).

Due cambiamenti dentro una stessa finestra ti lasciano senza modo di dire quale abbia funzionato.

Quale ordine di setup di solito risolve?

Nei miei account, questo ordine di solito risolve un evento trial o purchase non idoneo, e su una nuova app lo imposto prima della prima campagna install. La pagina di troubleshooting di Meta non elenca una campagna install tra le sue correzioni, quindi leggi il terzo passaggio come la mia esperienza, non come un’indicazione di Meta.

  1. Configura AEM in Events Manager prima della prima campagna install. Apro la scheda Settings del dataset, vado a Setup tasks for iOS app events e lavoro sulla sezione “Meta’s attribution for iOS 14+”, accettando i termini di Meta quando li chiede. Le pagine di Meta che ho controllato non documentano un interruttore AEM separato né un passaggio di termini per le app: About Meta’s Aggregated Event Measurement dice che non serve nessuna azione per ottenere gli aggiornamenti delle campagne app, anche se potresti dover intervenire per rendere la tua app idonea. Se Events Manager ti mostra un prompt, accettalo; se non ne mostra nessuno, vai avanti.
  2. Attiva l’attribuzione probabilistica nell’MMP, e la sua impostazione AEM. La pagina di Meta Recommendations for setting up Meta Aggregated Event Measurement with a mobile measurement partner ti chiede di attivare qualsiasi interruttore o impostazione AEM che la dashboard del tuo MMP offre, di verificare se app promotion e retargeting richiedono impostazioni separate, e avverte che limitare la condivisione dell’IP o limitare la condivisione dei dati per gli utenti che rifiutano può interferire anche con l’interruttore attivo. La pagina di Meta non menziona l’attribuzione probabilistica; attivarla è una mia pratica. Come si chiamano le impostazioni dipende dall’MMP:
    • AppsFlyer: Advanced Data Sharing nell’integrazione Meta Ads. La tabella riassuntiva di AppsFlyer dice che abilita AEM per l’app promotion, compresi gli eventi degli utenti senza advertiser ID e i claim non deterministici dove si applicano. L’interruttore probabilistico sta in App Settings, e la pagina di AppsFlyer gli dà due nomi: “Enable view-through attribution via probabilistic modeling” nella tabella e “Enable view-through attribution via campaign measurement modeling” nel testo. Copre i claim view through, e attivo anche quello.
    • Adjust: la sua pagina di setup Meta dice che l’integrazione supporta automaticamente le campagne install AEM, e che il modeling probabilistico è attivo di default per tutti i link delle campagne install AEM anche se lo avevi disattivato a livello di app. Si può comunque cambiare nelle impostazioni di attribuzione di un link, quindi controlla che nessuno lo abbia disattivato lì. Il suo interruttore “Enable AEM for MAE” è per le campagne di retargeting, non per gli install.
    • Singular: “Include Advanced AEM Attributions” nella configurazione del partner Facebook, selezionato di default. La sua pagina di integrazione Meta dice che la configurazione di default invia già gli eventi degli utenti che non hanno concesso il permesso ATT.
    • RevenueCat diretto: nessun MMP nel percorso. L’impostazione più vicina è “Send events when ATT consent is not authorized”, trattata sopra, ed è una decisione di privacy.
  3. Fai partire prima una campagna install. Lancio una campagna di app promotion ottimizzata per gli install, e chiedo a Meta di ottimizzare per trial o purchase solo dopo. La mia lettura del perché funziona: la campagna install dà a Meta gli install, e gli eventi successivi di quegli utenti, prima che le si chieda di ottimizzare per un evento più raro. La pagina di Meta ci si avvicina senza dirlo: un motivo che dà per “Integration quality issue” è “We’ve received a low number of install events”, e la sua correzione è inviare tutti gli eventi di conversione, non far girare una campagna install.
  4. Sposta l’evento di ottimizzazione quando risulta idoneo. Controlla la colonna Eligibility, come descritto sopra, prima di cambiare la campagna su maximize number of app events o maximize value of conversions per il trial o il purchase.

Due limiti. Se More details nomina un campo mancante o un’integrazione divisa, quella correzione viene prima: una campagna install non aggiunge un IDFV mancante, non smaschera un IP e non sposta un evento sull’integrazione dell’install, e nemmeno più budget lo fa. Se il percorso è pulito e l’evento è troppo raro, la domanda diventa su quale evento dovrebbe ottimizzare una subscription app.

È lecito inviare IP e IDFV per gli utenti che hanno rifiutato il tracking?

Questa è una decisione legale che spetta a te, e niente di quanto scrivo qui è consulenza legale. La pagina di Apple User privacy and data use dice che l’IDFV non può essere combinato con altri dati per tracciare un utente tra le app e i siti web di altre aziende, e ti lascia responsabile del rispetto della legge applicabile. AppsFlyer ti chiede di confermare che Advanced Data Sharing rispetti le policy e le normative della tua piattaforma prima di attivarlo.

Che evidenze devo raccogliere prima di rivolgermi al supporto Meta?

La pagina di troubleshooting di Meta rimanda diversi messaggi al tuo account manager Meta, e AppsFlyer chiede con qualsiasi ticket uno screenshot degli eventi non idonei. Presentati con:

  1. Uno screenshot con data della colonna Eligibility e il messaggio completo di More details.
  2. Dataset ID, app ID e ogni nome di evento esattamente come inviato, indicando se è standard o custom.
  3. L’integrazione scelta per l’evento di install e per l’evento trial o purchase, e l’elenco di ogni fonte che invia ciascuno.
  4. Per RevenueCat diretto: la riga di delivery di un cliente di test recente con Request, Response e fbtrace_id.
  5. Per il percorso AppsFlyer: un evento server to server redatto che mostri IP e IDFV presenti, più le impostazioni di Advanced Data Sharing, IP masking e postback.
  6. La quota di autorizzazione ATT negli ultimi 30 giorni.
  7. Un registro di ogni modifica con la sua data, e quanto hai aspettato dopo ciascuna.

Chi può sistemare CAPI e mappatura degli eventi per Meta?

È il lavoro che faccio sotto il signal engineering: seguire ogni evento dall’acquisto fino a Events Manager, decidere quale integrazione gestisce ciascun evento, e sistemare ciò che manca al percorso prima che qualcuno tocchi bid o budget.

Prima della prima campagna install di un’app su Meta, configuro AEM in Events Manager, accetto i termini di Meta dove li chiede, e attivo l’attribuzione probabilistica nell’MMP insieme a qualsiasi impostazione AEM che l’MMP offre. Solo allora la campagna install va live, e il trial o il purchase diventa l’evento di ottimizzazione quando Events Manager lo segna come idoneo.

Fonti

Ogni pagina è stata aperta e verificata il 29 settembre 2026.

Domande frequenti

Inviare un purchase da RevenueCat lo rende idoneo per Meta AEM?

No. La pagina Meta Ads di RevenueCat dice che una delivery riuscita significa che Meta ha accettato l'evento, e che Meta può comunque decidere che l'evento non è idoneo per una campagna, un obiettivo di ottimizzazione o un report. Ricezione e idoneità sono controlli separati.

Gli eventi server to server hanno bisogno di indirizzo IP e IDFV per Meta AEM?

Sul percorso AppsFlyer sì: AppsFlyer documenta che Meta richiede entrambi nel payload degli eventi in app inviati server to server, e che gli eventi senza di essi non sono idonei per l'attribuzione Meta in AEM. L'integrazione diretta di RevenueCat con Meta non richiede IDFV o IP per la delivery e li usa per il matching quando sono presenti, quindi il requisito appartiene al percorso, non a ogni setup.

Quanto tempo ci mette Meta ad aggiornare l'idoneità AEM dopo una correzione?

Dipende dalla correzione. AppsFlyer dice fino a 2 o 3 giorni dopo aver completato la sua checklist. Meta dice che un evento in sospeso va ricontrollato dopo 3 giorni, e che dopo aver selezionato un'integrazione il ricontrollo può richiedere fino a 7 giorni, con le modifiche alle campagne che nel frattempo potrebbero non essere disponibili.

Meta limita ancora le app iOS a otto eventi AEM?

La pagina di Meta sulla configurazione degli eventi app per AEM, che definiva otto slot per gli eventi, restituisce Page Not Found (verificata il 29 settembre 2026), quindi le guide che ti dicono di classificare otto eventi app per AEM descrivono un setup che Meta non documenta più. La classificazione degli eventi che Meta documenta ancora appartiene alla configurazione SKAdNetwork, e nessuno dei suoi messaggi di idoneità AEM riguarda l'ordine degli slot.

Una campagna install o più budget rendono idonei i miei eventi?

Nella mia esperienza una campagna install di solito risolve, quando parte dopo due passaggi di setup: AEM configurato in Events Manager, con i termini di Meta accettati dove li chiede, e l'attribuzione probabilistica attiva nell'MMP, insieme a qualsiasi impostazione AEM che l'MMP offre. Sposto l'ottimizzazione sul trial o sul purchase quando Events Manager lo mostra come idoneo. Questa è la mia pratica, non un'indicazione di Meta: la sua pagina di troubleshooting non elenca nessun livello di spesa e nessuna campagna install tra le correzioni. Più budget da solo non aggiunge un campo mancante né sposta un evento sull'integrazione dell'install.