Warum weichen Google Ads, MMP und SKAN bei iOS-Conversions ab?

Google Ads, Ihr MMP und SKAN melden nicht dieselben iOS-Conversions, weil sie Unterschiedliches zählen, Conversions anderen Zeitpunkten zuordnen und andere Nutzer sehen. Nehmen Sie keine davon als die eine wahre Zahl. Nutzen Sie Google Ads für das Bidding-Feedback, den MMP für die Aufteilung des Budgets zwischen den Kanälen und Ihre Umsatzquelle für die Finanzen, und beobachten Sie, ob sich die Lücke zwischen ihnen verschiebt. Die Region macht einen Unterschied. Für iOS-Nutzer im EWR, in Großbritannien und in der Schweiz gibt es im MMP keine ICM-Claims, dort ist die MMP-Sicht auf Google also dünner, und SKAN hat mehr Gewicht.

Umfang: Google App-Kampagnen für Installs auf iOS, gemessen über einen Attributionspartner (für die MMP-Seite nutze ich die Dokumentation von AppsFlyer, andere MMPs haben eigene Regeln), alle Regionen, mit der oben genannten regionalen Ausnahme. Jede Plattformangabe unten ist am 29. September 2026 gegen die jeweilige Primärseite geprüft. Die Meta-Seite desselben Problems steht in Meta vs RevenueCat vs Adjust. Das Setup, das ICM-Claims überhaupt erst erzeugt, steht in der Setup-Anleitung zu ICM und On-Device-Measurement.

Wo steht jede iOS-Zahl, und was zählt sie?

Google veröffentlicht in Understanding iOS App campaign measurement and reporting einen eigenen Vergleich der drei Sichten nebeneinander. Lesen Sie dort die Tabelle. Die drei Sichten im Einzelnen:

• Modellierte Conversions in Google Ads stehen in den Tabellen Campaigns und Ad groups. Sie enthalten Click-Through-Conversions und Engaged-View-Conversions, aber keine View-Through-Conversions. Google sagt, dass sie um bis zu fünf Tage verzögert sein können und alle Nutzer abdecken, einschließlich des EWR, Großbritanniens und der Schweiz.
• ICM-Claims in Ihrem MMP sind Googles Install-Claims, die an Ihren Attributionspartner gesendet und in dessen Oberfläche gezeigt werden. Googles Seite sagt, dass diese Daten heute nicht im Google-Ads-Reporting verfügbar sind, und ergänzt, dass sich das iOS-Measurement in Google Ads künftig stärker an ICM ausrichten wird, für Apps mit ICM und On-Device-Measurement-Eventdaten, ohne ein Datum zu nennen. About Integrated Conversion Measurement for App Campaigns beschreibt ICM als Reporting auf Eventebene und nennt On-Device-Conversion-Measurement mit Eventdaten als iOS-Voraussetzung.
• SKAdNetwork-Postbacks kommen in Ihren MMP- oder BI-Reports an. In Google Ads erscheinen nur SKAdNetwork-Installs, in einem eigenen SKAdNetwork-Report. SKAN ist die einzige der drei Sichten, die View-Through-Conversions enthält, und Google empfiehlt, SKAN wegen schwankender Verzögerungen alle 30 Tage zu prüfen.

In AppsFlyer sagt die Seite Google Ads (AdWords) Integration setup for advertisers, dass deterministische Google-Claims in den Rohdaten einen match_type von srn zeigen und ICM-Claims “probabilistic”. Über diese eine Spalte lassen sich die Google-Installs des MMP in die zwei Arten teilen, bevor Sie irgendetwas vergleichen.

Warum weichen die Zahlen ab, auch wenn alles korrekt eingerichtet ist?

Weil die Unterschiede eingebaut sind. Die Seite Google Ads (AdWords) FAQ and discrepancies von AppsFlyer listet die Ursachen auf, und die meisten davon sind schlicht Definitionen.

Jede Seite zeigt nur ihr eigenes Modell. AppsFlyer sagt, dass Google Ads Installs aus Googles internem Modeling zeigt und keine ICM-Installs, während AppsFlyer ICM-Claims zeigt und Googles intern modellierte Installs nicht. Eine gemeinsame Summe gibt es deshalb nicht.

Klickzeitpunkt gegenüber Startzeitpunkt. Google Ads erfasst den Install zum Klickzeitpunkt. AppsFlyer erfasst ihn zum Startzeitpunkt der App. Googles Seite Understand your conversion tracking data bestätigt, dass sich die primären Conversion-Spalten nach dem Zeitpunkt des Klicks richten, und bietet eine Spalte “Conversions (by conv. time)” an, wenn Sie stattdessen das Conversion-Datum brauchen. Bei In-App-Events gilt dieselbe Trennung. Google ordnet sie dem Klickzeitpunkt zu, das AppsFlyer-Dashboard dem Install-Zeitpunkt.

Last Click gegenüber jedem Engagement. AppsFlyer schreibt den Install dem letzten Klick gut und behandelt frühere Engagements als Assists. Google attribuiert als Self-Reporting-Netzwerk jeden Install, dem ein Engagement mit seinen Anzeigen vorausging, innerhalb seines eigenen Fensters.

Fenster. Für modellierte Conversions listet Googles Vergleich ein konfigurierbares Click-Through-Fenster (Standard 30 Tage) und ein konfigurierbares Engaged-View-Fenster (Standard 2 Tage). Für ICM listet er ein in der Oberfläche des Attributionspartners konfigurierbares Fenster von 6 Stunden bis 30 Tagen, nennt AppsFlyer aber als Ausnahme, ohne zu sagen, wie AppsFlyer abweicht. Die Setup-Seite von AppsFlyer hat eine eigene Lookback-Einstellung für den Install-Click-Through und empfiehlt 30 Tage, passend zu Google Ads. Für SKAN listet Google ein konfigurierbares Click-Through-Fenster von 30 Tagen, ein Engaged-View-Fenster von 30 Tagen, das Sie nicht ändern können, und ein konfigurierbares View-Through-Fenster von 1 Tag.

View-Through-Regeln. AppsFlyer merkt an, dass Google Ads View-Through-Conversions in die Spalte All conversions einträgt, nicht in Conversions, sofern Sie es nicht anders einstellen. Googles Vergleich sagt, dass ICM Click-Through- und Engaged-View-Conversions einschließt, aber keine View-Through-Conversions, und die Setup-Seite von AppsFlyer sagt, dass Google auf iOS derzeit nur Klicks claimt, keine Impressionen.

Die Modeling-Verzögerung. Bis zu fünf Tage für modellierte Conversions in Google Ads. Die letzten Tage jedes Google-Ads-Reports sind noch nicht abgeschlossen.

Abdeckung im EWR, in Großbritannien und in der Schweiz. Googles Seite About on-device conversion measurement for iOS App campaigns sagt, dass On-Device-Measurement mit Eventdaten für Nutzer dort inaktiv ist, und AppsFlyers Bulletin: AppsFlyer and Google attribution solution (Open BETA) sagt, dass ICM für iOS-Traffic aus diesen Regionen nicht verfügbar ist. Modellierte Conversions und SKAN decken sie weiterhin ab. Rechnen Sie also damit, dass die Lücke zwischen Google Ads und dem MMP davon abhängt, wie viel Ihres Google-iOS-Traffics aus diesen drei Regionen kommt.

Redownloads. Google Ads folgt Ihrer Konfiguration, was als Redownload und was als neuer Install zählt, während ICM laut Googles Vergleich eine feste Definition nutzt. AppsFlyer ergänzt, dass Google Ads Reinstalls als session_start-Conversion zeigt, während AppsFlyer sie in seinen Retargeting-Daten führt.

Kostenumfang. Die Discrepancy-Seite von AppsFlyer sagt, dass AppsFlyer die Google-Kosten für alle Kanäle einer Kampagne erhält, in iOS App-Kampagnen aber nur Conversions von YouTube und Display attribuiert, sodass der CPI in AppsFlyer höher aussieht. Die später bearbeitete Setup-Seite sagt, dass jede iOS App-Kampagne für Installs über ICM attribuiert werden kann. Die beiden Seiten lesen sich unterschiedlich. Prüfen Sie daher Ihre eigenen Rohdaten auf probabilistische Google-Installs, bevor Sie entscheiden, welche Beschreibung auf Ihren Account passt.

SKAN-Deduplizierung. Dieselbe Discrepancy-Seite sagt, dass AppsFlyer nur Postbacks mit did_win=TRUE anzeigt, während das Google-Ads-Dashboard diese nicht von did_win=NULL trennt, sodass die SKAN-Install-Zahl des MMP niedriger sein kann.

Wie gleiche ich Google Ads, den MMP und SKAN ab?

Mit einem Arbeitsblatt, eine Zeile pro Feld, für alle drei Quellen ausgefüllt, bevor Sie auf die Summen schauen. Jeder bekannte Grund für die Lücke bekommt einen Namen, damit der Rest klein genug bleibt, um ihn zu untersuchen.

Ein paar Zellen brauchen eine Quelle. Das SKAN-Datum ist eine Schätzung. Die Seite SKAN Conversion Studio von AppsFlyer leitet die Install-Zeit aus der Ankunftszeit des Postbacks ab, abzüglich einer durchschnittlichen Last-Active-Spanne und einer festen iOS-Postback-Verzögerung. Dieselbe Seite sagt, dass SKAN 4 drei Postbacks sendet, nach den Fenstern, die an den Tagen 2, 7 und 35 enden. Apples AdAttributionKit-Seite Receiving postbacks in multiple conversion windows nennt dieselben drei Fenster, Tag 0 bis 2, 3 bis 7 und 8 bis 35 ab dem ersten Start, mit Postbacks, die nach einer zufälligen Verzögerung von 24 bis 48 Stunden für den ersten und 24 bis 144 Stunden für die anderen gesendet werden, und nur der erste Postback kann einen feinen Wert tragen. Beim Umsatz sagt Googles Seite Set up your SKAdNetwork conversion value schema, dass sein Conversion-Modeling nur feine Conversion Values nutzt und die groben Conversion Values von SKAN 4 derzeit nicht unterstützt. Ein Wert, der SKAN nur als grober Wert erreicht, wie beim zweiten und dritten Postback, fließt also nicht in Googles Modeling ein. AppsFlyer warnt außerdem, dass aus Firebase importierte Google-Ads-Daten anders aufgebaut und nicht vollständig mit AppsFlyer-Daten vergleichbar sind. Tragen Sie die Importquelle daher in die Umsatzzeile ein.

Wie sieht eine Lücke aus, die nicht normal ist?

Im Februar und März 2026 habe ich Google App-Kampagnen für eine Subscription-App auf Android und iOS gefahren, mit AppsFlyer als MMP und ICM auf iOS eingeschaltet. Es ist derselbe Account wie in meinem Test zu Gebotsstrategien. Bei 88.920 $ Spend über 39 Tage meldete Google Ads für alle Kampagnen zusammen 37,7% ROAS. AppsFlyer zeigte 29,8% Lifetime-ROAS und 17,0% an Tag 0.

Die erste Lehre ist die Zeile zur Umsatzbasis im Arbeitsblatt. Am D0-Wert von AppsFlyer gemessen, lag Google 21 Punkte zu hoch. Am Lifetime-ROAS von AppsFlyer gemessen, waren es 8 Punkte. Dieselben Kampagnen, dieselben Ausgaben, und die Größe der “Abweichung” hing davon ab, welche AppsFlyer-Spalte ich gewählt habe. Die meisten einzelnen Kampagnen lagen in beide Richtungen innerhalb von etwa 10 Punkten von AppsFlyer, was sich mit den oben genannten Gründen erklären lässt.

Eine Lücke weit außerhalb dieses Bereichs hat meist eine andere Ursache. Die iOS-Kampagne auf Max Conversion Value gab 11.312 $ aus und zeigte in Google Ads 71,4% ROAS gegenüber 17,3% Lifetime-ROAS in AppsFlyer, 54 Punkte Abstand. Zuerst verdächtigte ich modellierte Conversions, View-Through und unterschiedliche Fenster. Die Ursache war einfacher. Das Umsatz-Event der App, AllRevenue, übergab an Google 1 $, wenn kein Conversion-Wert vorlag, statt 0 $. Das blähte Googles ROAS insgesamt auf, und auf iOS, wo weniger Conversions anfielen, überdeckte es die echten Zahlen. Keine Zeile des Arbeitsblatts hätte es aufgedeckt, denn ein falscher Wert ist keine Definition.

Wie gehe ich Schritt für Schritt vor?

Bei einem Audit prüfe ich zuerst, was jedes Event sendet, dann die Datumsbasis und den Event-Filter, denn jedes davon ist schnell bestätigt, und jedes kann einen Vergleich für sich allein verschieben.

1. Prüfen Sie die Werte vor den Modellen. Sehen Sie sich den Wert an, den jedes Umsatz-Event tatsächlich an Google sendet, auch Events ohne Umsatz. Ein Standardwert von 1 dort, wo 0 oder nichts stehen sollte, bläht jede wertbasierte Zahl auf, die Google zeigt, und kein Attributionsmodell erklärt das weg.
2. Vergleichen Sie nur gereifte Kohorten. Lassen Sie für Google Ads mindestens die letzten fünf Tage weg und gehen Sie weiter zurück, wenn das Event später als der Install liegt. Googles eigener Vergleich sagt, dass Sie die volle Länge des Conversion-Fensters abwarten sollen, bevor Sie eine Kampagne beurteilen, und Googles Seite Set a recommended initial Target ROAS for your App campaigns schlägt ein Fenster von 14 bis 30 Tagen vor, das den jüngsten Zeitraum ausschließt. Warten Sie bei SKAN auf die Postbacks, auf die Sie sich stützen.
3. Wählen Sie ein Event und ein Fenster. In Google Ads kann der Conversion-Report laut AppsFlyer Installs, Käufe und Subscriptions mischen. Filtern Sie daher auf die Install-Conversion, bevor Sie Installs vergleichen. Stellen Sie dann die Fenster im Arbeitsblatt nebeneinander.
4. Legen Sie alles auf dieselbe Datumsbasis. Nutzen Sie “Conversions (by conv. time)” in Google Ads, wenn Sie gegen einen MMP vergleichen, der nach Startdatum zählt, oder vergleichen Sie Wochensummen, in denen ein Tag Versatz untergeht.
5. Teilen Sie die Google-Installs des MMP nach match_type auf. Die Zeilen srn und probabilistic stammen aus verschiedenen Claim-Methoden. Vergleichen Sie jede für sich und halten Sie ihre Anteile über die Zeit fest.
6. Addieren Sie SKAN nie zu modellierten Summen. Sie messen dieselben Kampagnen mit unterschiedlichen Methoden. Legen Sie sie nebeneinander.
7. Achten Sie auf eine Veränderung der Lücke. Eine stabile Lücke zwischen Google Ads und dem MMP ist eine Eigenschaft der beiden Methoden. Eine Lücke, die sich in einer Woche verdoppelt, wirft eine Frage auf: ein SDK-Release, eine Consent-Änderung, eine neue Region, eine andere Conversion-Aktion, eine neue Redownload-Einstellung.

Datenschutzeinstellungen gehören in diese Liste nur als Fakten, die Sie festhalten. Die Setup-Seite von AppsFlyer sagt, dass Google-attribuierte Daten in den Rohdaten-Reports als restricted erscheinen, wenn der Schalter Aggregated Advanced Privacy eingeschaltet ist, und dass IP-Masking ICM beeinflussen kann. Das sind Datenschutzentscheidungen des App-Inhabers. Ich schreibe auf, wie sie gesetzt sind; ich schalte sie nicht ab, damit die Zahlen zusammenpassen.

Welche Zahl nutze ich für welche Entscheidung?

Bidding-Feedback: Google Ads. tCPA- und tROAS-Ziele werden in Google Ads gesetzt und beurteilt, anhand der Conversions, die Google Ads meldet. Wenn ich frage, ob ein Ziel zu eng ist, lese ich Googles eigene Spalte, an gereiften Tagen, über das Fenster von 14 bis 30 Tagen, das Google vorschlägt. Wer ein Google-Ziel an MMP-Zahlen prüft, mischt zwei Modelle und ändert unter Umständen ein Ziel, das in Ordnung war.

Budget zwischen Kanälen: der MMP. Er wendet über jedes Netzwerk dieselbe Last-Click-Regel an, und das können weder Google noch Meta für das jeweils andere. Damit eignet er sich besser, um Google mit Meta oder allem anderen zu vergleichen, solange Sie bedenken, dass er nur die Google-Installs zählt, die Google ihm claimt, und dass der Anteil Ihres Google-iOS-Traffics aus dem EWR, aus Großbritannien und aus der Schweiz überhaupt keine ICM-Claims hat. Wo dieser Anteil groß ist, nutze ich SKAN als zweite Lesart für die Richtung.

Finanzen: keine der beiden Werbeplattformen. Der Umsatz sollte von dort kommen, wo er abgerechnet wird, also aus Ihrer Subscription-Plattform oder den Stores. Gleichen Sie ihn mit Paid anhand der Prüfungen im Beitrag zum Meta-Abgleich ab. Der MMP liefert Ihnen Umsatz nach Kanal, und SKAN liefert eine unabhängige Prüfung, ob sich ein Kanal bewegt, aber keine der drei Quellen ist ein Hauptbuch.

Das gehört zu meiner Arbeit im signal engineering: entscheiden, welches Event jedes System sieht, aus welcher Quelle, und wie ich die Lücken dazwischen lese. Dasselbe Bild für Meta und TikTok, mit den SKAN-Stufen und einem Änderungsprotokoll, steht in was Paid UA nach ATT auf iOS noch messen kann. Wenn Ihre Google-iOS-Zahlen nicht zusammenpassen und Sie nicht wissen, welche Lücke normal ist, beginnt ein growth audit mit diesem Arbeitsblatt und lässt sich bei jedem Spend-Level einzeln buchen.

Quellen

Alle Seiten geprüft am 29. September 2026.

1. Understanding iOS App campaign measurement and reporting, Google Ads Help, kein Seitendatum angezeigt
2. About Integrated Conversion Measurement for App Campaigns, Google Ads Help
3. About on-device conversion measurement for iOS App campaigns, Google Ads Help
4. Understand your conversion tracking data, Google Ads Help
5. Set a recommended initial Target ROAS for your App campaigns, Google Ads Help
6. Set up your SKAdNetwork conversion value schema, Google Ads Help
7. Google Ads (AdWords) FAQ and discrepancies, AppsFlyer, zuletzt bearbeitet am 16. März 2026
8. Google Ads (AdWords) Integration setup for advertisers, AppsFlyer, zuletzt bearbeitet am 15. September 2026
9. Bulletin: AppsFlyer and Google attribution solution (Open BETA), AppsFlyer, zuletzt bearbeitet am 5. August 2026
10. SKAN Conversion Studio, AppsFlyer, zuletzt bearbeitet am 26. April 2026
11. Receiving postbacks in multiple conversion windows, Apple Developer, kein Seitendatum angezeigt