Warum sind Trial- und Kauf-Events für Meta AEM nicht berechtigt?

Ein Event, das im Events Manager ankommt, ist noch kein Event, auf das Sie optimieren können. Meta markiert jedes iOS-Event getrennt als berechtigt oder nicht berechtigt für Aggregated Event Measurement. Zu den Gründen, die Meta nennt, gehören ein Event, das über eine andere Integration läuft als Ihr Install-Event, fehlende Daten, die die Route mitführen muss, oder zu wenige Signale in den letzten 30 Tagen. Welcher Grund zutrifft, hängt von Ihrer Route ab. RevenueCat mit direktem Versand an Meta hat andere Anforderungen als RevenueCat mit Versand an AppsFlyer, das dann per Postback an Meta weitergibt.

In meinen Accounts löst meist eine Reihenfolge das Problem: AEM im Events Manager einrichten und im MMP probabilistische Attribution einschalten, eine Install-Kampagne fahren und die Optimierung erst dann auf den Trial oder Kauf umstellen, wenn der Events Manager ihn als berechtigt anzeigt. Das ist meine Praxis, keine Lösung, die Meta dokumentiert. Die Details stehen unten im Abschnitt zur Einrichtungsreihenfolge.

Dieser Beitrag behandelt App-Promotion-Kampagnen von Meta für iOS 14+, die AEM nutzen und auf App-Events oder Wert optimieren (Metas Ziele “maximize number of app events” und “maximize value of conversions”). Zwei Routen halte ich durchgehend getrennt: RevenueCat direkt an Meta und RevenueCat an AppsFlyer an Meta. Der Abschnitt zur Einrichtungsreihenfolge nennt auch die passenden Einstellungen in Adjust und Singular. Nichts davon ist auf eine Region beschränkt. Jede unten genannte Anbieterseite wurde am 29. September 2026 geprüft. Metas Hilfeseiten tragen kein Datum und ändern sich ohne Ankündigung. Prüfen Sie sie deshalb erneut, bevor Sie handeln.

Wo sagt Meta, dass ein Event nicht berechtigt ist?

Im Events Manager. Metas Seite How to check if your app events are eligible for Aggregated Event Measurement nennt den Pfad: Datasets, Ihr Dataset, der Tab Settings, Setup tasks for iOS app events, dann Check app eligibility im Abschnitt “Meta’s attribution for iOS 14+”. Die Spalte Eligibility markiert jedes Event als berechtigt oder nicht berechtigt, More details erklärt den Grund, und der Status Pending bedeutet, dass Meta noch auf Informationen Ihrer Integration wartet oder sie prüft.

Metas Troubleshoot issues with app eligibility for Aggregated Event Measurement listet jede Meldung mit ihrer möglichen Bedeutung und der Lösung auf. Halten Sie die genaue Meldung und das Datum fest, bevor jemand am Setup etwas ändert, denn jede Meldung auf dieser Seite verweist auf eine andere Lösung.

Geht es um Empfang, erforderliche Daten oder Berechtigung?

Wer sagt “das Event funktioniert nicht”, kann drei verschiedene Dinge meinen:

• Empfang. Hat Meta das Event überhaupt erhalten? Die Seite Meta Ads von RevenueCat sagt, dass der Events Manager bis zu 24 Stunden brauchen kann, um akzeptierte Events anzuzeigen.
• Erforderliche Daten. Trägt das Event, was Ihre Route für AEM braucht? Das ist je Route verschieden.
• Berechtigung zur Optimierung. Lässt Meta eine Kampagne darauf optimieren? Die Seite von RevenueCat sagt ausdrücklich, dass eine erfolgreiche Zustellung nur heißt, dass Meta das Event akzeptiert hat. Ob es für eine Kampagne, ein Ziel oder einen Report berechtigt ist, entscheidet weiterhin Meta.

In der Tabelle sind die üblichen Symptome nach Ebene sortiert, und bei jedem steht die Route dabei, denn eine Anforderung, die für eine Route dokumentiert ist, belegt nichts für die andere.

Was braucht die direkte Route von RevenueCat?

Die Seite Meta Ads von RevenueCat nennt vier Punkte, die hier zählen.

Das Meta SDK bleibt. RevenueCat rät, das Meta SDK für Install-, Aktivierungs- und On-Device-Signale zu behalten. Die Server-to-Server-Events von RevenueCat ersetzen das SDK-Setup von Meta für Install-Kampagnen, SKAdNetwork oder AEM nicht. Die Conversions API empfiehlt RevenueCat gegenüber der App Events API, wegen Zuverlässigkeit und langfristigem Support. Außerdem kann RevenueCat Trial-Conversions und Verlängerungen senden, auch wenn die App nicht geöffnet ist.

Die Zustellung hängt von Identifiern und Consent ab. Bei App-Store-Events über die Conversions API versucht RevenueCat die Zustellung nur, wenn der Kunde $fbAnonId oder $idfa hat und der ATT-Status authorized ist, es sei denn, die Dashboard-Einstellung “Send events when ATT consent is not authorized” ist aktiviert. Leere IDFA-Werte oder solche aus lauter Nullen behandelt RevenueCat als fehlend. IDFV, IP, E-Mail und Telefonnummer verlangt RevenueCat für die Zustellung nicht, führt sie aber als Attribute auf, die Meta zum Matching nutzen kann, wenn sie vorhanden sind. Diese Attribute setzen Sie laut RevenueCat nach der Konfiguration des SDK und möglichst vor dem ersten Kauf, und die Geräte-Identifier erfassen Sie erneut, nachdem die ATT-Erlaubnis erteilt wurde.

Bei deaktivierter Einstellung verlangt RevenueCat eine erteilte ATT-Einwilligung, bevor es App-Store-Events sendet. Die Seite sagt nicht ausdrücklich, mit welchem Wert eine neue Integration startet. Sehen Sie die Einstellung also in Ihrem eigenen Dashboard nach, bevor Sie etwas in die Event-Zahlen von Meta hineinlesen. App-Store-Trial- und Kauf-Events von Nutzern, die Tracking nicht erlaubt haben, gehen auf dieser Route dann nicht an Meta, und Meta sieht weniger Events, als RevenueCat aufzeichnet. Meine Lesart ist, dass das bei einem kleinen Account ein plausibler Weg zu “Not enough signals from last 30 days” ist. Ob Sie die Einstellung aktivieren, ist eine Datenschutzentscheidung.

Subscribe ist breit gefasst. Standardmäßig ordnet RevenueCat Trial Started dem Event StartTrial zu und Trial Converted, Initial Purchase und Renewal alle dem Event Subscribe. Ein nicht erneuernder Kauf geht an fb_mobile_purchase. Eine Subscribe-Zahl im Events Manager mischt also Erstzahlungen mit Verlängerungen. RevenueCat lässt Sie für diese Events andere Meta-Standard-Eventnamen wählen und merkt an, dass Meta Standard-Events für die Kampagnenoptimierung empfiehlt. Hat jemand das Mapping geändert, prüfen Sie zuerst, auf welchen Eventnamen Ihre Kampagne optimiert.

Eine Quelle pro Event. RevenueCat rät, das clientseitige Kauf- und Umsatz-Logging für die Events zu entfernen, die es sendet, weil das Meta SDK und RevenueCat keine event_id teilen. Die Troubleshooting-Seite von Meta ergänzt eine Regel, die hier zählt. Ein Event kann für Ziele auf App-Events oder Wert nicht berechtigt sein, wenn es über eine andere Integration ankommt als Ihr Install-Event, und die Lösung ist, für beide dieselbe Integration zu nutzen. Metas Seite About Partner Integrations for app events nennt in ihrem Rat zur Wertoptimierung das Facebook SDK, einen MMP und die Conversions API als getrennte Kanäle und bittet Sie, jedes Event nur über einen davon zu senden. Auf der direkten Route kommen Installs vom Meta SDK und Trials und Zahlungen von der Conversions API. Die hier zitierten Meta-Seiten sagen nicht, ob Meta diese Paarung für diese Regel als zwei Integrationen behandelt. Prüfen Sie also im Events Manager die gewählte Integration für beide Events.

Was braucht die AppsFlyer-Route?

RevenueCat sendet Events an AppsFlyer, das sie per Postback an Meta weitergibt. Zwei Seiten legen die Anforderungen fest, und sie unterscheiden sich.

AppsFlyers Meta Ads Aggregate Event Measurement (AEM) for iOS sagt, dass Meta für In-App-Events, die per Server-to-Server gesendet werden, sowohl die IP-Adresse als auch die IDFV im Event-Payload verlangt, und dass das Event ohne sie in AEM nicht für die Attribution von Meta berechtigt ist. Die Seite AppsFlyer von RevenueCat markiert nur $appsflyerId als erforderlich. Sie führt $idfa, $idfv und $ip als empfohlen auf, bittet Sie, Attribute nach der Konfiguration des Purchases SDK und vor dem ersten Kauf zu setzen, und warnt, dass ohne die AppsFlyer ID womöglich einige Events nicht zugestellt werden. Der Helper collectDeviceIdentifiers von RevenueCat erfasst $idfa, $idfv und $ip. Behandeln Sie auf dieser Route “empfohlen” als erforderlich für AEM, weil AppsFlyer sagt, dass Meta beides braucht.

AppsFlyers Troubleshooting-Checkliste für nicht berechtigte Events, in seiner Reihenfolge und ohne seinen Schritt für Remarketing-Kampagnen:

1. Advanced Data Sharing in der Meta-Ads-Integration eingeschaltet (Collaborate, Active Integrations, Meta Ads). Ist es ausgeschaltet, werden nur Events von Nutzern mit einer Werbe-ID geteilt. AppsFlyers Übersichtstabelle bezeichnet es als den Schalter, der AEM für App Promotion aktiviert, und es ist die MMP-Einstellung in der Einrichtungsreihenfolge unten.
2. IP-Masking in den App Settings ausgeschaltet. AppsFlyer sagt, dass Events mit maskierten IPs nicht berechtigt sind.
3. IP-Adresse und IDFV in jedem Server-to-Server-Event.
4. ATT-Consent-Rate geprüft. Meta akzeptiert ein begrenztes Volumen an Events mit fehlenden IDFAs oder IDFAs aus lauter Nullen.
5. Postbacks auf “Send all (including organic)” gemappt. Metas Partnerseite gibt denselben Rat.
6. Bleiben Events nicht berechtigt, setzen Sie MMP-Traffic im Events Manager als bevorzugte Verbindung.

RevenueCat rät außerdem, clientseitiges Umsatz-Tracking im AppsFlyer SDK zu entfernen, um Doppelzählung zu vermeiden. Meine Lesart ist, dass diese Route Installs und Trial- oder Kauf-Events auf eine Integration legen kann, wie es Metas Lösung (dieselbe Integration für beide) verlangt, solange keine andere Quelle dieselben Events sendet.

Begrenzt Meta Apps noch auf acht Events?

Metas Seite “How to configure app events to use Meta’s Aggregated Event Measurement”, auf der acht Event-Slots für die AEM-Konfiguration einer App standen, zeigt jetzt Page Not Found (geprüft am 29. September 2026). Anleitungen, die empfehlen, acht App-Events für AEM in eine Rangfolge zu bringen, beschreiben also ein Setup, das Meta nicht mehr dokumentiert. Metas About Meta’s Aggregated Event Measurement sagt, dass Meta Updates für App-Kampagnen schrittweise ausrollt und dass Sie damit App-Promotion-Kampagnen fahren können, ohne App-Events für SKAdNetwork zu konfigurieren, und mehr App-Events für die Optimierung zur Verfügung haben. Das Event-Ranking, das Meta weiterhin dokumentiert, gehört zur SKAdNetwork-Konfiguration. Metas Seite About value sets beschreibt dort Priority IDs von 1 bis 63 und sagt, dass Sie Value Sets für Events, die über AEM gesendet werden, nicht aktivieren müssen. Keine der Meldungen auf Metas Troubleshooting-Seite betrifft die Reihenfolge der Slots. Sparen Sie sich also die Diagnose dazu.

Wie lange sollte ich nach einer Korrektur warten?

Ändern Sie eine Sache, notieren Sie das Datum und warten Sie dann die passende Zeit ab:

• Akzeptierte Events können bis zu 24 Stunden brauchen, bis sie im Events Manager erscheinen (RevenueCat).
• Eine Änderung der gewählten Integration kann bis zu 24 Stunden brauchen, bis sie sich niederschlägt, laut Metas Seite Choose a single integration for app events in Meta Events Manager if you send events from multiple integrations.
• Ein Pending-Event: nach 3 Tagen erneut prüfen (Meta).
• Nach der Auswahl einer Integration, um eine Meldung zu beheben: bis zu 7 Tage bis zur erneuten Prüfung, und Kampagnenänderungen sind in der Zwischenzeit womöglich nicht verfügbar (Meta).
• Nach AppsFlyers Checkliste: bis zu 2 bis 3 Tage, bis Meta die Berechtigung widerspiegelt (AppsFlyer).

Wer zwei Dinge innerhalb derselben Wartezeit ändert, kann nicht sagen, welche gewirkt hat.

Welche Einrichtungsreihenfolge löst das Problem meist?

In meinen Accounts behebt diese Reihenfolge meist ein nicht berechtigtes Trial- oder Kauf-Event, und bei einer neuen App richte ich sie vor der ersten Install-Kampagne ein. Die Troubleshooting-Seite von Meta nennt keine Install-Kampagne unter ihren Lösungen. Lesen Sie den dritten Schritt deshalb als meine Erfahrung, nicht als Anweisung von Meta.

1. AEM im Events Manager vor der ersten Install-Kampagne einrichten. Ich öffne den Tab Settings des Datasets, gehe zu Setup tasks for iOS app events und arbeite den Abschnitt “Meta’s attribution for iOS 14+” durch. Wenn Meta nach den Bedingungen fragt, akzeptiere ich sie. Die geprüften Meta-Seiten dokumentieren für Apps keinen eigenen AEM-Schalter und keinen Schritt für Bedingungen. About Meta’s Aggregated Event Measurement sagt, dass für die Updates der App-Kampagnen keine Aktion nötig ist, Sie aber womöglich handeln müssen, damit Ihre App berechtigt wird. Zeigt der Events Manager Ihnen eine Aufforderung, akzeptieren Sie sie; zeigt er keine, machen Sie weiter.
2. Probabilistische Attribution im MMP einschalten, dazu die AEM-Einstellung des MMP. Metas Recommendations for setting up Meta Aggregated Event Measurement with a mobile measurement partner bittet Sie, jeden AEM-Schalter oder jede Einstellung einzuschalten, die das Dashboard Ihres MMP hat, zu prüfen, ob App Promotion und Retargeting getrennte Einstellungen brauchen, und warnt, dass eine Einschränkung des IP-Sharings oder eine Begrenzung des Data Sharing für Nutzer mit Opt-out selbst bei eingeschaltetem Schalter stören kann. Metas Seite erwähnt probabilistische Attribution nicht. Sie einzuschalten ist meine Praxis. Die Einstellungen heißen je nach MMP anders:
   • AppsFlyer: Advanced Data Sharing in der Meta-Ads-Integration. AppsFlyers Übersichtstabelle sagt, dass es AEM für App Promotion aktiviert, einschließlich Events von Nutzern ohne Werbe-ID und nichtdeterministischer Claims, wo sie zutreffen. Der probabilistische Schalter sitzt in den App Settings, und AppsFlyer nennt ihn auf seiner Seite unterschiedlich: “Enable view-through attribution via probabilistic modeling” in der Tabelle und “Enable view-through attribution via campaign measurement modeling” im Text. Er umfasst View-through-Claims, und ich schalte ihn ebenfalls ein.
   • Adjust: Laut der Meta-Einrichtungsseite unterstützt die Integration AEM-Install-Kampagnen automatisch, und probabilistisches Modeling ist für alle Links von AEM-Install-Kampagnen standardmäßig an, auch wenn Sie es auf App-Ebene ausgeschaltet haben. In den Attributionseinstellungen eines Links lässt es sich weiterhin ändern. Prüfen Sie deshalb, ob es dort jemand ausgeschaltet hat. Der Schalter “Enable AEM for MAE” gilt für Retargeting-Kampagnen, nicht für Installs.
   • Singular: “Include Advanced AEM Attributions” in der Facebook-Partnerkonfiguration, standardmäßig angehakt. Laut der Meta-Integrationsseite sendet die Standardkonfiguration bereits Events von Nutzern, die keine ATT-Erlaubnis erteilt haben.
   • RevenueCat direkt: Hier liegt kein MMP im Pfad. Am nächsten kommt die Einstellung “Send events when ATT consent is not authorized”, die oben behandelt ist. Sie ist eine Datenschutzentscheidung.
3. Zuerst eine Install-Kampagne fahren. Ich starte eine App-Promotion-Kampagne, optimiert auf Installs, und bitte Meta erst danach, auf Trials oder Käufe zu optimieren. Ich vermute, dass es wirkt, weil die Install-Kampagne Meta Installs und spätere Events dieser Nutzer liefert, bevor es auf ein selteneres Event optimieren muss. Metas Seite sagt das nicht. Einer ihrer Gründe für “Integration quality issue” ist “We’ve received a low number of install events”, und als Lösung nennt sie, alle Conversion-Events zu senden, ohne eine Install-Kampagne zu erwähnen.
4. Das Optimierungs-Event umstellen, sobald es berechtigt ist. Prüfen Sie die Spalte Eligibility, wie oben beschrieben, bevor Sie die Kampagne für den Trial oder Kauf auf maximize number of app events oder maximize value of conversions umstellen.

Das hat zwei Grenzen. Nennt More details ein fehlendes Feld oder eine geteilte Integration, beheben Sie zuerst das. Eine Install-Kampagne fügt keine fehlende IDFV hinzu, hebt keine IP-Maskierung auf und verschiebt kein Event auf die Integration des Installs, und mehr Budget ändert daran ebenfalls nichts. Ist die Route sauber und das Event zu selten, geht es um die Frage, welches Event eine Subscription-App optimieren sollte.

Ist es erlaubt, IP und IDFV für Nutzer zu senden, die Tracking abgelehnt haben?

Das ist Ihre rechtliche Entscheidung, und nichts hier ist Rechtsberatung. Laut Apples User privacy and data use darf die IDFV nicht mit anderen Daten kombiniert werden, um einen Nutzer in Apps und auf Websites anderer Unternehmen zu tracken, und die Verantwortung, geltendes Recht einzuhalten, liegt bei Ihnen. Bevor Sie Advanced Data Sharing einschalten, sollen Sie laut AppsFlyer bestätigen, dass es die Richtlinien Ihrer Plattform und die geltenden Vorschriften einhält.

Welche Nachweise sollte ich sammeln, bevor ich an den Meta-Support eskaliere?

Metas Troubleshooting-Seite verweist bei mehreren Meldungen an Ihren Meta Account Manager, und AppsFlyer bittet bei jedem Ticket um einen Screenshot der nicht berechtigten Events. Bringen Sie mit:

1. Einen datierten Screenshot der Spalte Eligibility und die vollständige Meldung unter More details.
2. Dataset-ID, App-ID und jeden Eventnamen genau wie gesendet, mit dem Vermerk, ob er Standard oder Custom ist.
3. Die gewählte Integration für das Install-Event und für das Trial- oder Kauf-Event sowie eine Liste jeder Quelle, die eines davon sendet.
4. Für RevenueCat direkt: die Delivery-Zeile eines aktuellen Testkunden mit Request, Response und fbtrace_id.
5. Für die AppsFlyer-Route: ein geschwärztes Server-to-Server-Event, das IP und IDFV zeigt, dazu die Einstellungen für Advanced Data Sharing, IP-Masking und Postbacks.
6. Den Anteil der ATT-Erlaubnisse über die letzten 30 Tage.
7. Ein Protokoll jeder Änderung mit Datum und der Wartezeit nach jeder.

Wer kann CAPI und Event-Mapping für Meta beheben?

Das ist die Arbeit, die ich unter signal engineering übernehme: jedes Event vom Kauf bis zum Events Manager nachverfolgen, festlegen, welche Integration für das Event zuständig ist, und beheben, was der Route fehlt, bevor jemand an Geboten oder Budgets dreht. Wie sich AEM neben SKAN und AdAttributionKit einordnet, steht in was Paid UA nach ATT auf iOS noch messen kann.

Vor der ersten Install-Kampagne einer App auf Meta richte ich AEM im Events Manager ein, akzeptiere Metas Bedingungen, wo danach gefragt wird, und schalte probabilistische Attribution im MMP ein, zusammen mit jeder AEM-Einstellung, die er hat. Erst dann geht die Install-Kampagne live, und der Trial oder Kauf wird zum Optimierungs-Event, sobald der Events Manager ihn als berechtigt markiert.

Quellen

Jede Seite wurde am 29. September 2026 geöffnet und geprüft.

• Meta Business Help Center: Troubleshoot issues with app eligibility for Aggregated Event Measurement
• Meta Business Help Center: How to check if your app events are eligible for Aggregated Event Measurement
• Meta Business Help Center: Choose a single integration for app events in Meta Events Manager if you send events from multiple integrations
• Meta Business Help Center: About Meta’s Aggregated Event Measurement
• Meta Business Help Center: About Partner Integrations for app events
• Meta Business Help Center: Recommendations for setting up Meta Aggregated Event Measurement with a mobile measurement partner
• Meta Business Help Center: About value sets
• Meta Business Help Center: How to configure app events to use Meta’s Aggregated Event Measurement (https://www.facebook.com/business/help/1267713610367185), Page Not Found
• AppsFlyer: Meta Ads Aggregate Event Measurement (AEM) for iOS, zuletzt bearbeitet am 25. Mai 2026
• Adjust Help Center: Set up Meta in Adjust
• Singular Help Center: Facebook (Meta) Ads Attribution Integration, zuletzt bearbeitet am 26. August 2026
• RevenueCat Docs: Meta Ads
• RevenueCat Docs: AppsFlyer
• Apple Developer: User privacy and data use