· 15 min read · Samet Durgun · Platform facts checked

Why are my trial and purchase events ineligible for Meta AEM?

I am Samet Durgun, a fractional Head of UA. I run paid UA for subscription apps and mobile games and write up what I find in the accounts I manage. This piece sits under what signal engineering fixes; more about me.

An event that arrives in Events Manager is not yet an event you can optimize for. Meta marks each iOS event eligible or ineligible for Aggregated Event Measurement separately, and among the reasons it lists are an event sent through a different integration from your install event, missing data the route has to carry, or too few signals in the last 30 days. Which of those applies depends on your route: RevenueCat sending straight to Meta has different requirements from RevenueCat sending to AppsFlyer, which then posts back to Meta.

In my accounts, one order usually clears it: set up AEM in Events Manager and turn on probabilistic attribution in the MMP, run an install campaign, and only then move optimization to the trial or purchase once Events Manager shows it eligible. That is my practice, not a fix Meta documents; the section on setup order below has the details.

Scope: Meta app promotion campaigns for iOS 14+ that use AEM and optimize for app events or value (Meta’s goals “maximize number of app events” and “maximize value of conversions”). Two routes, kept apart throughout: RevenueCat direct to Meta, and RevenueCat to AppsFlyer to Meta. The setup order section also names the matching settings in Adjust and Singular. Nothing here is specific to one region. Every vendor page below was checked on 29 September 2026. Meta’s help pages show no dates and change without notice, so check them again before you act.

Where does Meta say an event is ineligible?

In Events Manager. Meta’s page How to check if your app events are eligible for Aggregated Event Measurement gives the path: Datasets, your dataset, the Settings tab, Setup tasks for iOS app events, then Check app eligibility in the “Meta’s attribution for iOS 14+” section. The Eligibility column marks each event eligible or ineligible, More details explains why, and a pending status means Meta is still waiting for or verifying information from your integration.

Meta’s Troubleshoot issues with app eligibility for Aggregated Event Measurement lists each message with what it may mean and the fix. Record the exact message and the date before anyone touches the setup, because each message on that page points to a different fix.

Is it receipt, required data or eligibility?

Three different questions hide behind “the event is not working”:

  • Receipt. Did Meta get the event at all? RevenueCat’s Meta Ads page says Events Manager can take up to 24 hours to show accepted events.
  • Required data. Does the event carry what your route needs for AEM? This differs by route.
  • Optimization eligibility. Will Meta let a campaign optimize for it? RevenueCat’s page is explicit that a successful delivery only means Meta accepted the event, and that Meta still decides whether it is eligible for a campaign, goal or report.

The table sorts the usual symptoms by layer. The route column matters: a requirement documented for one route is not evidence about the other.

Layer Symptom System to inspect Evidence needed Next action
Receipt StartTrial or Subscribe missing from Events Manager (RevenueCat direct) RevenueCat Customer History, Meta Ads delivery row Request and Response tabs; for the Conversions API, the fbtrace_id No row: check the required attributes and follow RevenueCat’s troubleshooting for a missing delivery row. Accepted: allow the up to 24 hours RevenueCat documents before checking Events Manager
Receipt Events missing in AppsFlyer (AppsFlyer route) RevenueCat customer attributes Whether $appsflyerId was set before the purchase Set it after configuring the Purchases SDK and before the first purchase
Required data Few or no App Store events reach Meta (RevenueCat direct) RevenueCat Meta Ads settings and customer attributes $fbAnonId or a real IDFA, ATT status, the “Send events when ATT consent is not authorized” setting Decide the consent setting deliberately, with your own privacy review
Required data Server to server events ineligible (AppsFlyer route) A raw event payload IP address and IDFV present on every event Collect device identifiers in RevenueCat so $ip and $idfv are set before the purchase
Required data “Contact your mobile measurement partner (MMP) to check eligibility steps for Meta’s attribution for iOS 14+” The MMP dashboard Whether the MMP’s AEM setting is on Turn it on; the setup order below names it per MMP
Required data “IP data version isn’t optimal for setup” The integration named in the message Whether IP is missing or sent inconsistently Send IP consistently; on the AppsFlyer route, turn IP masking off
Required data “Advertiser Tracking Enabled parameter volume out-of-range” ATT status on incoming events Share of events with tracking not enabled or a zeroed IDFA Check the ATT consent rate; Meta points to your account manager for this one
Eligibility “Different integrations across multiple event types” Events Manager, the install event and the trial or purchase event Which integration sends each Send the install and the optimization event through the same integration
Eligibility “Multiple integrations for the same event” Events Manager, Manage event Every source sending the event Choose one integration for the event; remove duplicate client side logging
Eligibility “Not enough signals from last 30 days” Events Manager and the test events tool Event counts over 30 days Confirm the setup with test events, then look at how much volume the route lets through
Eligibility Pending, “Awaiting or verifying information from your integration” Events Manager Date the status appeared Recheck in 3 days, as Meta says

What does the RevenueCat direct route need?

RevenueCat’s Meta Ads page sets out four points that matter here.

The Meta SDK stays. RevenueCat says to keep the Meta SDK for install, activation and on device signals; its server to server events do not replace Meta’s SDK setup for install campaigns, SKAdNetwork or AEM. It recommends the Conversions API over the App Events API for reliability and long term support, and notes that it can send trial conversions and renewals when the app is not open.

Delivery depends on identifiers and consent. For App Store events through the Conversions API, RevenueCat attempts delivery only when the customer has $fbAnonId or $idfa, plus an ATT status of authorized, unless the dashboard setting “Send events when ATT consent is not authorized” is enabled. It treats empty or zeroed IDFA values as missing. The IDFV, IP, email and phone number are not among the attributes it requires for delivery; it lists them as attributes Meta can use for matching when they are present. RevenueCat asks you to set these after configuring its SDK and before the first purchase whenever possible, and to collect device identifiers again after ATT permission is granted.

RevenueCat says that leaving the setting disabled requires authorized ATT consent before App Store events are sent. Its page does not say in words which way a new integration starts, so look at the setting in your own dashboard before you read anything into Meta’s event counts. So with it disabled, App Store trial and purchase events from users who did not authorize tracking are not sent to Meta on this route, and Meta sees fewer events than RevenueCat records. My reading is that on a small account this is one plausible path to “Not enough signals from last 30 days”. Enabling the setting is a privacy decision, not a measurement tweak.

Subscribe is broad. By default RevenueCat maps Trial Started to StartTrial, and Trial Converted, Initial Purchase and Renewal all to Subscribe. A non renewing purchase goes to fb_mobile_purchase. So a Subscribe count in Events Manager mixes first payments with renewals. RevenueCat lets you choose other Meta standard event names for these events, and notes that Meta recommends standard events for optimizing campaigns. If someone changed the mapping, check which event name your campaign optimizes for before anything else.

One source per event, and the integration question. RevenueCat says to remove client side purchase and revenue logging for the events it sends, because the Meta SDK and RevenueCat do not share an event_id. Meta’s troubleshooting page adds a rule that matters here: an event may be ineligible for app event or value goals when it arrives through a different integration from your install event, and the fix is to use the same integration for both. Meta’s About Partner Integrations for app events page, in its advice for value optimization, names the Facebook SDK, an MMP and the Conversions API as separate channels and asks you to send each event through only one. On the direct route, installs come from the Meta SDK and trials and payments from the Conversions API. The Meta pages cited here do not say whether it treats that pairing as two integrations for this rule, so check the chosen integration for both events in Events Manager rather than assume.

What does the AppsFlyer route need?

RevenueCat sends events to AppsFlyer, which posts them back to Meta. Two pages set the requirements, and they differ.

AppsFlyer’s Meta Ads Aggregate Event Measurement (AEM) for iOS says that for in app events sent server to server, Meta requires both the IP address and the IDFV in the event payload, and that without them the event is not eligible for Meta attribution in AEM. RevenueCat’s AppsFlyer page marks only $appsflyerId as required. It lists $idfa, $idfv and $ip as recommended, and asks you to set attributes after the Purchases SDK is configured and before the first purchase, warning that some events may not be delivered without the AppsFlyer ID. RevenueCat’s collectDeviceIdentifiers helper collects $idfa, $idfv and $ip. On this route, treat “recommended” as required for AEM, because AppsFlyer says Meta needs both.

AppsFlyer’s troubleshooting checklist for ineligible events, in its order, leaving out its step for remarketing campaigns:

  1. Advanced Data Sharing on in the Meta Ads integration (Collaborate, Active Integrations, Meta Ads). With it off, only events from users with an advertiser ID are shared. AppsFlyer’s summary table names it as the toggle that enables AEM for app promotion, and it is the MMP setting in the setup order below.
  2. IP masking off in App Settings. AppsFlyer says events with masked IPs are not eligible.
  3. IP address and IDFV on every server to server event.
  4. ATT consent rate reviewed. Meta accepts a limited volume of events with missing or zeroed IDFAs.
  5. Postbacks mapped to “Send all (including organic)”. Meta’s partner page gives the same advice.
  6. If events stay ineligible, set MMP traffic as the preferred connection in Events Manager.

RevenueCat also asks you to remove client side revenue tracking in the AppsFlyer SDK to avoid double counting. My reading is that this route can put installs and trial or purchase events on one integration, which is what Meta’s same integration fix asks for, as long as no other source sends the same events.

Does Meta still limit apps to eight events?

Meta’s page “How to configure app events to use Meta’s Aggregated Event Measurement”, which set out eight event slots for an app’s AEM configuration, now returns Page Not Found (checked 29 September 2026), so guides that tell you to rank eight app events for AEM describe a setup Meta no longer documents. Meta’s About Meta’s Aggregated Event Measurement says it is gradually rolling out updates to app campaigns, and that with them you can run app promotion campaigns without configuring app events for SKAdNetwork, with more app events available for optimization. The event ranking Meta still documents belongs to the SKAdNetwork configuration: its About value sets page describes priority IDs from 1 to 63 there, and says you do not need to enable value sets for events sent through AEM. None of the messages on Meta’s troubleshooting page is about slot order, so do not spend a diagnosis on it.

How long should I wait after a fix?

Change one thing, write down the date, then wait for the window that applies:

  • Accepted events can take up to 24 hours to show in Events Manager (RevenueCat).
  • A change to the chosen integration can take up to 24 hours to reflect, per Meta’s page Choose a single integration for app events in Meta Events Manager if you send events from multiple integrations.
  • A pending event: recheck in 3 days (Meta).
  • After you select an integration to resolve a message: up to 7 days to recheck, and campaign edits may be unavailable meanwhile (Meta).
  • After AppsFlyer’s checklist: up to 2 to 3 days for Meta to reflect eligibility (AppsFlyer).

Two changes inside one window leave you unable to say which one worked.

What setup order usually clears it?

In my accounts, this order usually clears an ineligible trial or purchase event, and on a new app I set it up before the first install campaign. Meta’s troubleshooting page does not list an install campaign among its fixes, so read the third step as my experience, not Meta’s instruction.

  1. Set up AEM in Events Manager before the first install campaign. I open the dataset’s Settings tab, go to Setup tasks for iOS app events and work through the “Meta’s attribution for iOS 14+” section, accepting Meta’s terms when it asks. The Meta pages I checked do not document a separate AEM switch or a terms step for apps: About Meta’s Aggregated Event Measurement says no action is needed to get the app campaign updates, though you may need to act to make your app eligible. If Events Manager shows you a prompt, accept it; if it shows none, move on.
  2. Turn on probabilistic attribution in the MMP, and its AEM setting. Meta’s Recommendations for setting up Meta Aggregated Event Measurement with a mobile measurement partner asks you to turn on any AEM toggle or setting your MMP dashboard has, to check whether app promotion and retargeting need separate settings, and warns that restricting IP sharing or limiting data sharing for users who opt out can interfere even with the toggle on. Meta’s page does not mention probabilistic attribution; turning it on is my practice. What the settings are called depends on the MMP:
    • AppsFlyer: Advanced Data Sharing in the Meta Ads integration. AppsFlyer’s summary table says it enables AEM for app promotion, including events from users without an advertiser ID and nondeterministic claims where they apply. The probabilistic toggle sits in App Settings, and AppsFlyer’s page gives it two names: “Enable view-through attribution via probabilistic modeling” in the table and “Enable view-through attribution via campaign measurement modeling” in the text. It covers view through claims, and I turn it on as well.
    • Adjust: its Meta setup page says the integration supports AEM install campaigns automatically, and that probabilistic modeling is on by default for all AEM install campaign links even if you turned it off at app level. It can still be changed in a link’s attribution settings, so check that nobody turned it off there. Its “Enable AEM for MAE” toggle is for retargeting campaigns, not installs.
    • Singular: “Include Advanced AEM Attributions” in the Facebook partner configuration, checked by default. Its Meta integration page says the default configuration already sends events from users who did not grant ATT permission.
    • RevenueCat direct: no MMP sits in the path. The nearest setting is “Send events when ATT consent is not authorized”, covered above, and that one is a privacy decision.
  3. Run an install campaign first. I launch an app promotion campaign optimized for installs, and ask Meta to optimize for trials or purchases only after that. My reading of why it works: the install campaign gives Meta installs, and later events from those users, before it is asked to optimize for a rarer event. Meta’s page comes close without saying it: one reason it gives for “Integration quality issue” is “We’ve received a low number of install events”, and its fix is to send all conversion events, not to run an install campaign.
  4. Move the optimization event once it shows eligible. Check the Eligibility column, as described above, before you switch the campaign to maximize number of app events or maximize value of conversions for the trial or purchase.

Two limits. If More details names a missing field or a split integration, that fix comes first: an install campaign does not add a missing IDFV, unmask an IP or move an event onto the install’s integration, and more budget does not either. If the route is clean and the event is too rare, the question becomes which event a subscription app should optimize for.

Is sending IP and IDFV for users who declined tracking allowed?

That is your legal call, and nothing here is legal advice. Apple’s User privacy and data use says the IDFV may not be combined with other data to track a user across other companies’ apps and websites, and leaves you responsible for complying with applicable law. AppsFlyer asks you to confirm Advanced Data Sharing complies with your platform policies and regulations before turning it on.

What evidence should I collect before escalating to Meta support?

Meta’s troubleshooting page points several messages to your Meta account manager, and AppsFlyer asks for a screenshot of the ineligible events with any ticket. Arrive with:

  1. A dated screenshot of the Eligibility column and the full More details message.
  2. Dataset ID, app ID and each event name exactly as sent, noting whether it is standard or custom.
  3. The chosen integration for the install event and for the trial or purchase event, and a list of every source that sends each one.
  4. For RevenueCat direct: one recent test customer’s delivery row with the Request, the Response and the fbtrace_id.
  5. For the AppsFlyer route: one redacted server to server event showing IP and IDFV present, plus the Advanced Data Sharing, IP masking and postback settings.
  6. The ATT authorization share over the last 30 days.
  7. A log of every change with its date, and how long you waited after each.

Who can fix CAPI and event mapping for Meta?

This is the work I take on under signal engineering: tracing each event from the purchase to Events Manager, deciding which integration owns it, and fixing what the route is missing before anyone touches bids or budgets.

Before an app’s first install campaign on Meta, I set up AEM in Events Manager, accept Meta’s terms where it asks, and turn on probabilistic attribution in the MMP along with any AEM setting it has. Only then does the install campaign go live, and the trial or purchase becomes the optimization event once Events Manager marks it eligible.

Sources

Each page was opened and checked on 29 September 2026.

Questions people ask

Does sending a purchase from RevenueCat make it eligible for Meta AEM?

No. RevenueCat's Meta Ads page says a successful delivery means Meta accepted the event, and that Meta can still decide the event is not eligible for a campaign, optimization goal or report. Receipt and eligibility are separate checks.

Do server to server events need the IP address and IDFV for Meta AEM?

On the AppsFlyer route, yes: AppsFlyer documents that Meta requires both in the payload of in app events sent server to server, and that events without them are not eligible for Meta attribution in AEM. RevenueCat's direct Meta integration does not require the IDFV or IP for delivery and uses them for matching when present, so the requirement belongs to the route, not to every setup.

How long does Meta take to update AEM eligibility after a fix?

It depends on the fix. AppsFlyer says up to 2 to 3 days after its checklist is done. Meta says a pending event should be rechecked in 3 days, and that after you select an integration the recheck can take up to 7 days, with campaign edits possibly unavailable meanwhile.

Does Meta still limit iOS apps to eight AEM events?

Meta's page on configuring app events for AEM, which set out eight event slots, returns Page Not Found (checked 29 September 2026), so guides that tell you to rank eight app events for AEM describe a setup Meta no longer documents. The event ranking Meta still documents belongs to the SKAdNetwork configuration, and none of its AEM eligibility messages is about slot order.

Will an install campaign or more budget make my events eligible?

In my experience an install campaign usually clears it, when it runs after two setup steps: AEM set up in Events Manager, with Meta's terms accepted where it asks, and probabilistic attribution turned on in the MMP, along with any AEM setting it has. I move optimization to the trial or purchase once Events Manager shows it eligible. That is my practice, not Meta's instruction: its troubleshooting page lists no spend level and no install campaign among its fixes. More budget alone does not add a missing field or move an event onto the install's integration.