· 15 Min. · Samet Durgun

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

Ich bin Samet Durgun, Fractional Head of UA. Ich verantworte Paid UA für Subscription-Apps und Mobile Games und schreibe hier auf, was ich in meinen Accounts sehe. Dieser Beitrag gehört zum Thema Signal Engineering; mehr über mich.

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 im Abschnitt zur Einrichtungsreihenfolge weiter unten.

Umfang: 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, die durchgehend getrennt bleiben: 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 also 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 anfasst, denn jede Meldung auf dieser Seite verweist auf eine andere Lösung.

Geht es um Empfang, erforderliche Daten oder Berechtigung?

Hinter “das Event funktioniert nicht” verbergen sich drei verschiedene Fragen:

  • 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 bedeutet, dass Meta das Event akzeptiert hat, und dass Meta weiterhin entscheidet, ob es für eine Kampagne, ein Ziel oder einen Report berechtigt ist.

Die Tabelle sortiert die üblichen Symptome nach Ebene. Die Spalte zur Route ist wichtig: Eine Anforderung, die für eine Route dokumentiert ist, ist kein Beleg für die andere.

Ebene Symptom Zu prüfendes System Nötiger Nachweis Nächste Aktion
Empfang StartTrial oder Subscribe fehlt im Events Manager (RevenueCat direkt) RevenueCat Customer History, Delivery-Zeile von Meta Ads Tabs Request und Response; bei der Conversions API die fbtrace_id Keine Zeile: Prüfen Sie die erforderlichen Attribute und folgen Sie der Fehlersuche von RevenueCat zu einer fehlenden Delivery-Zeile. Akzeptiert: Warten Sie die von RevenueCat dokumentierten bis zu 24 Stunden ab, bevor Sie den Events Manager prüfen
Empfang Events fehlen in AppsFlyer (AppsFlyer-Route) Kundenattribute in RevenueCat Ob $appsflyerId vor dem Kauf gesetzt wurde Setzen Sie es nach der Konfiguration des Purchases SDK und vor dem ersten Kauf
Erforderliche Daten Wenige oder keine App-Store-Events erreichen Meta (RevenueCat direkt) Meta-Ads-Einstellungen und Kundenattribute in RevenueCat $fbAnonId oder eine echte IDFA, ATT-Status, die Einstellung “Send events when ATT consent is not authorized” Entscheiden Sie über die Consent-Einstellung bewusst, mit Ihrer eigenen Datenschutzprüfung
Erforderliche Daten Server-to-Server-Events nicht berechtigt (AppsFlyer-Route) Ein unbearbeiteter Event-Payload IP-Adresse und IDFV in jedem Event vorhanden Erfassen Sie in RevenueCat die Geräte-Identifier, damit $ip und $idfv vor dem Kauf gesetzt sind
Erforderliche Daten “Contact your mobile measurement partner (MMP) to check eligibility steps for Meta’s attribution for iOS 14+” Das MMP-Dashboard Ob die AEM-Einstellung des MMP eingeschaltet ist Schalten Sie sie ein; die Einrichtungsreihenfolge unten nennt sie je MMP
Erforderliche Daten “IP data version isn’t optimal for setup” Die in der Meldung genannte Integration Ob die IP fehlt oder uneinheitlich gesendet wird Senden Sie die IP einheitlich; auf der AppsFlyer-Route schalten Sie IP-Masking aus
Erforderliche Daten “Advertiser Tracking Enabled parameter volume out-of-range” ATT-Status der eingehenden Events Anteil der Events mit nicht aktiviertem Tracking oder mit IDFA aus lauter Nullen Prüfen Sie die ATT-Consent-Rate; Meta verweist dafür an Ihren Account Manager
Berechtigung “Different integrations across multiple event types” Events Manager, das Install-Event und das Trial- oder Kauf-Event Welche Integration jedes davon sendet Senden Sie Install- und Optimierungs-Event über dieselbe Integration
Berechtigung “Multiple integrations for the same event” Events Manager, Manage event Jede Quelle, die das Event sendet Wählen Sie eine Integration für das Event; entfernen Sie doppeltes clientseitiges Logging
Berechtigung “Not enough signals from last 30 days” Events Manager und das Test-Events-Tool Event-Zahlen über 30 Tage Bestätigen Sie das Setup mit Test-Events, dann prüfen Sie, wie viel Volumen die Route durchlässt
Berechtigung Pending, “Awaiting or verifying information from your integration” Events Manager Datum, an dem der Status erschienen ist Prüfen Sie nach 3 Tagen erneut, wie Meta es sagt

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 sagt, das Meta SDK für Install-, Aktivierungs- und On-Device-Signale zu behalten; seine Server-to-Server-Events ersetzen Metas SDK-Setup für Install-Kampagnen, SKAdNetwork oder AEM nicht. Es empfiehlt die Conversions API gegenüber der App Events API wegen Zuverlässigkeit und langfristigem Support und weist darauf hin, dass es Trial-Conversions und Verlängerungen senden kann, 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, dazu einen ATT-Status authorized, 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 es als fehlend. IDFV, IP, E-Mail und Telefonnummer gehören nicht zu den Attributen, die es für die Zustellung verlangt; es führt sie als Attribute auf, die Meta zum Matching nutzen kann, wenn sie vorhanden sind. RevenueCat bittet Sie, diese nach der Konfiguration seines SDK und möglichst vor dem ersten Kauf zu setzen und die Geräte-Identifier erneut zu erfassen, nachdem die ATT-Erlaubnis erteilt wurde.

RevenueCat sagt, dass bei deaktivierter Einstellung eine erteilte ATT-Einwilligung nötig ist, bevor App-Store-Events gesendet werden. Seine Seite sagt nicht in Worten, mit welchem Wert eine neue Integration startet. Sehen Sie sich die Einstellung also in Ihrem eigenen Dashboard an, bevor Sie etwas in Metas Event-Zahlen hineinlesen. Bei deaktivierter Einstellung werden App-Store-Trial- und Kauf-Events von Nutzern, die Tracking nicht erlaubt haben, auf dieser Route nicht an Meta gesendet, und Meta sieht weniger Events, als RevenueCat aufzeichnet. Ich lese das so, dass dies bei einem kleinen Account ein plausibler Weg zu “Not enough signals from last 30 days” ist. Die Einstellung zu aktivieren ist eine Datenschutzentscheidung und keine Measurement-Anpassung.

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, und die Integrationsfrage. RevenueCat sagt, clientseitiges Kauf- und Umsatz-Logging für die Events zu entfernen, die es sendet, weil das Meta SDK und RevenueCat keine event_id teilen. Metas Troubleshooting-Seite 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, statt es anzunehmen.

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 Advertiser-ID geteilt. AppsFlyers Übersichtstabelle nennt es 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 bittet Sie außerdem, clientseitiges Umsatz-Tracking im AppsFlyer SDK zu entfernen, um Doppelzählung zu vermeiden. Ich lese das so, dass diese Route Installs und Trial- oder Kauf-Events auf eine Integration legen kann, was Metas Lösung, dieselbe Integration zu nutzen, 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”, die acht Event-Slots für die AEM-Konfiguration einer App festlegte, liefert jetzt Page Not Found (geprüft am 29. September 2026). Anleitungen, die vorschlagen, acht App-Events für AEM zu ranken, 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 ohne Konfiguration von App-Events für SKAdNetwork fahren können, bei mehr App-Events, die zur Optimierung zur Verfügung stehen. Das Event-Ranking, das Meta weiterhin dokumentiert, gehört zur SKAdNetwork-Konfiguration: Seine 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 das Zeitfenster ab, das gilt:

  • 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).

Zwei Änderungen innerhalb eines Zeitfensters lassen Sie nicht erkennen, welche gewirkt hat.

Welche Einrichtungsreihenfolge löst das Problem meist?

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

  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, wobei ich Metas Bedingungen akzeptiere, wenn danach gefragt wird. Die Meta-Seiten, die ich geprüft habe, 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, und seine AEM-Einstellung. 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, die Opt-out gewählt haben, selbst bei eingeschaltetem Schalter stören kann. Metas Seite erwähnt probabilistische Attribution nicht; sie einzuschalten ist meine Praxis. Wie die Einstellungen heißen, hängt vom MMP ab:
    • 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 Advertiser-ID und nichtdeterministischer Claims, wo sie zutreffen. Der probabilistische Schalter sitzt in den App Settings, und AppsFlyers Seite gibt ihm zwei Namen: “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: Seine Meta-Einrichtungsseite sagt, dass die Integration AEM-Install-Kampagnen automatisch unterstützt und dass probabilistisches Modeling für alle AEM-Install-Kampagnenlinks standardmäßig an ist, auch wenn Sie es auf App-Ebene ausgeschaltet haben. In den Attributionseinstellungen eines Links lässt es sich weiterhin ändern, prüfen Sie also, ob es dort jemand ausgeschaltet hat. Sein Schalter “Enable AEM for MAE” ist für Retargeting-Kampagnen, nicht für Installs.
    • Singular: “Include Advanced AEM Attributions” in der Facebook-Partnerkonfiguration, standardmäßig angehakt. Seine Meta-Integrationsseite sagt, dass die Standardkonfiguration bereits Events von Nutzern sendet, die keine ATT-Erlaubnis erteilt haben.
    • RevenueCat direkt: Kein MMP liegt im Pfad. Die nächstliegende Einstellung ist “Send events when ATT consent is not authorized”, oben behandelt, und 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 soll. Metas Seite kommt dem nahe, ohne es zu sagen: Einer ihrer Gründe für “Integration quality issue” ist “We’ve received a low number of install events”, und ihre Lösung ist, alle Conversion-Events zu senden, nicht eine Install-Kampagne zu fahren.
  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.

Zwei Grenzen. Nennt More details ein fehlendes Feld oder eine geteilte Integration, kommt diese Lösung zuerst: 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 tut es ebenfalls nicht. Ist die Route sauber und das Event zu selten, wird 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. Apples User privacy and data use sagt, dass die IDFV nicht mit anderen Daten kombiniert werden darf, um einen Nutzer in Apps und auf Websites anderer Unternehmen zu tracken, und überlässt Ihnen die Verantwortung, geltendes Recht einzuhalten. AppsFlyer bittet Sie zu bestätigen, dass Advanced Data Sharing die Richtlinien Ihrer Plattform und die Vorschriften einhält, bevor Sie es einschalten.

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, entscheiden, welche Integration es besitzt, und beheben, was der Route fehlt, bevor jemand an Geboten oder Budgets dreht.

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.

Häufige Fragen

Macht der Versand eines Kaufs aus RevenueCat ihn für Meta AEM berechtigt?

Nein. Die Meta-Ads-Seite von RevenueCat sagt, dass eine erfolgreiche Zustellung bedeutet, dass Meta das Event akzeptiert hat, und dass Meta trotzdem entscheiden kann, dass das Event für eine Kampagne, ein Optimierungsziel oder einen Report nicht berechtigt ist. Empfang und Berechtigung sind getrennte Prüfungen.

Brauchen Server-to-Server-Events für Meta AEM die IP-Adresse und die IDFV?

Auf der AppsFlyer-Route ja: AppsFlyer dokumentiert, dass Meta beide im Payload von In-App-Events verlangt, die per Server-to-Server gesendet werden, und dass Events ohne sie in AEM nicht für die Attribution von Meta berechtigt sind. Die direkte Meta-Integration von RevenueCat verlangt IDFV oder IP nicht für die Zustellung und nutzt sie zum Matching, wenn sie vorhanden sind. Die Anforderung gehört also zur Route und nicht zu jedem Setup.

Wie lange braucht Meta, um die AEM-Berechtigung nach einer Korrektur zu aktualisieren?

Das hängt von der Korrektur ab. AppsFlyer sagt, bis zu 2 bis 3 Tage nach Abschluss seiner Checkliste. Meta sagt, ein Pending-Event solle nach 3 Tagen erneut geprüft werden, und nach der Auswahl einer Integration könne die erneute Prüfung bis zu 7 Tage dauern, wobei Kampagnenänderungen in der Zwischenzeit womöglich nicht verfügbar seien.

Begrenzt Meta iOS-Apps noch auf acht AEM-Events?

Metas Seite zur Konfiguration von App-Events für AEM, die acht Event-Slots festlegte, liefert Page Not Found (geprüft am 29. September 2026). Anleitungen, die vorschlagen, acht App-Events für AEM zu ranken, beschreiben also ein Setup, das Meta nicht mehr dokumentiert. Das Event-Ranking, das Meta weiterhin dokumentiert, gehört zur SKAdNetwork-Konfiguration, und keine seiner AEM-Berechtigungsmeldungen betrifft die Reihenfolge der Slots.

Machen eine Install-Kampagne oder mehr Budget meine Events berechtigt?

In meiner Erfahrung behebt eine Install-Kampagne das Problem meist, wenn sie nach zwei Einrichtungsschritten läuft: AEM im Events Manager eingerichtet, Metas Bedingungen dort akzeptiert, wo danach gefragt wird, und probabilistische Attribution im MMP eingeschaltet, zusammen mit jeder AEM-Einstellung, die er hat. Die Optimierung stelle ich auf den Trial oder Kauf um, sobald der Events Manager ihn als berechtigt anzeigt. Das ist meine Praxis, keine Anweisung von Meta: Seine Troubleshooting-Seite nennt unter den Lösungen weder ein Spend-Level noch eine Install-Kampagne. Mehr Budget allein fügt kein fehlendes Feld hinzu und verschiebt kein Event auf die Integration des Installs.