Google Ads, Ihr MMP und SKAN melden nicht dieselben iOS-Conversions, weil sie Verschiedenes zählen, Conversions unterschiedlichen Zeitpunkten zuordnen und unterschiedliche 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 Bedingung, die die Antwort ändert, ist die Region: 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 wurde am 29. September 2026 gegen die jeweilige Primärseite geprüft. Für die Meta-Seite desselben Problems lesen Sie Meta vs RevenueCat vs Adjust. Für das Setup, das ICM-Claims überhaupt erst erzeugt, lesen Sie die Setup-Anleitung zu ICM und On-Device-Measurement.
Wo steht jede iOS-Zahl, und was zählt sie?
Google veröffentlicht einen eigenen Vergleich der drei Sichten nebeneinander in Understanding iOS App campaign measurement and reporting. Lesen Sie dort die Tabelle. Kurz gefasst:
- 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 Datum. About Integrated Conversion Measurement for App Campaigns beschreibt es als Reporting auf Event-Ebene 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, sie wegen variabler 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”. Mit dieser einen Spalte können Sie die Google-Installs des MMP in die zwei Arten aufteilen, 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 Definitionen, keine Fehler.
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. Zwei Modelle, zwei Ergebnisse, keine gemeinsame Summe.
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 die primären Conversion-Spalten auf dem Zeitpunkt des Klicks basieren, und bietet eine Spalte “Conversions (by conv. time)” an, wenn Sie stattdessen das Conversion-Datum brauchen. In-App-Events folgen derselben Trennung: Google ordnet sie dem Klickzeitpunkt zu, und das AppsFlyer-Dashboard ordnet sie dem Install-Zeitpunkt zu.
Last Click gegenüber jedem Engagement. AppsFlyer schreibt den letzten Klick gut und behandelt frühere Engagements als Assists. Google attribuiert als Self-Reporting-Netzwerk alle Installs nach einem Engagement mit seinen Anzeigen, innerhalb seines eigenen Fensters.
Fenster. Für modellierte Conversions listet Googles Vergleich ein konfigurierbares Click-Through-Fenster mit 30 Tagen als Standard und ein konfigurierbares Engaged-View-Fenster mit 2 Tagen als Standard. Für ICM listet er ein Fenster, das in der Oberfläche des Attributionspartners konfigurierbar ist, 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 wendet an, was Sie als Redownload gegenüber einem neuen Install konfiguriert haben, 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 also 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. Es geht darum, jeden bekannten Grund für die Lücke zu benennen, damit der Rest klein genug ist, um ihn zu untersuchen.
| Feld | Google Ads modelliert | MMP (ICM- und srn-Claims) | SKAN |
|---|---|---|---|
| Reporting-Quelle | Tabellen Campaigns und Ad groups | Dashboard oder Rohdaten Ihres Attributionspartners, aufgeteilt nach match_type | MMP- oder BI-Reports; der SKAdNetwork-Report in Google Ads |
| Event-Definition | Die importierte Conversion-Aktion, auf die Sie filtern, zum Beispiel nur first_open | Der Install- oder In-App-Event-Name im MMP | Das Event oder die Events, die Ihr Conversion-Value-Schema abbildet |
| Attributionsfenster | Konfigurierte Click-Through- und Engaged-View-Fenster | Die Lookback-Einstellung des MMP und wie sie auf ICM-Claims wirkt | Apples Fenster plus Googles SKAN-Fenster |
| Basis für Kohorten- oder Event-Datum | Klickdatum, oder “by conv. time”, wenn Sie die Spalten wechseln | Startdatum für Installs; Install-Datum für Events im Dashboard, Event-Datum in den Rohdaten | Geschätztes Install-Datum |
| Zeitzone | Die Zone, die der Google-Ads-Report nutzt | Die Zone, die die MMP-App nutzt | Die Zone, die Ihr SKAN-Report nutzt |
| Alter der Kohorte | Mindestens fünf Tage nach dem letzten Klick, plus das Fenster | Nach dem Lookback des MMP | Nach dem letzten Postback, auf den Sie sich stützen |
| Reinstalls | Ihre Redownload-Einstellungen; Reinstalls als session_start | Reattributionen in den Retargeting-Daten | Googles Vergleich nennt keine Regel; notieren Sie, wie Ihr MMP sie behandelt |
| Umsatzbasis | Wert, der an die importierte Conversion-Aktion gehängt ist, und woher er kommt | Umsatz, den das SDK oder der Server sendet, brutto oder netto, mit oder ohne Erstattungen | Umsatz, der sich aus dem Conversion-Value-Schema ergibt |
| Verbleibende ungeklärte Differenz | Leer lassen, bis jede Zeile oben übereinstimmt |
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 Fine Value tragen. Beim Umsatz sagt Googles Seite Set up your SKAdNetwork conversion value schema, dass sein Conversion-Modeling nur Fine Conversion Values nutzt und SKAN-4-Coarse-Conversion-Values derzeit nicht unterstützt. Wert, der SKAN nur als Coarse Value 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 Import-Quelle daher in die Umsatzzeile ein.
Wie sieht eine Lücke aus, die nicht normal ist?
Hier ein Beispiel aus meiner eigenen Arbeit. 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. Über 39 Tage und 88.920 $ meldete Google Ads über alle Kampagnen 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. Gegen den Tag-0-Wert von AppsFlyer gehalten, sah Google 21 Punkte zu hoch aus. Gegen den Lifetime-ROAS von AppsFlyer gehalten, betrug die Lücke 8 Punkte. Dieselben Kampagnen, dieselben Ausgaben, und die Größe der “Discrepancy” hing davon ab, welche AppsFlyer-Spalte wir gewählt haben. Die meisten einzelnen Kampagnen lagen in beide Richtungen innerhalb von etwa 10 Punkten von AppsFlyer, was die Gründe oben erklären.
Die zweite Lehre ist, was eine Lücke weit außerhalb dieses Bereichs meist bedeutet. 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 auseinander. Die dokumentierten Gründe waren die ersten Verdächtigen: modellierte Conversions, View-Through, unterschiedliche Fenster. Die Ursache war einfacher. Das Umsatz-Event der App, AllRevenue, übergab an Google einen Wert von 1 $, wenn es keinen Conversion-Wert gab, statt 0 $. Das blähte Googles ROAS insgesamt auf, und auf iOS, wo die Conversion-Volumen niedriger waren, überdeckte es die echten Zahlen. Keine Zeile des Arbeitsblatts hätte es erklärt, weil nichts daran eine Definition war. Es war ein falscher Wert.
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.
- 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 Default 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.
- 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.
- 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 also auf die Install-Conversion, bevor Sie Installs vergleichen. Stellen Sie dann die Fenster im Arbeitsblatt nebeneinander.
- 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.
- Teilen Sie die Google-Installs des MMP nach match_type auf. Die Zeilen srn und probabilistic stammen aus verschiedenen Claim-Methoden, vergleichen Sie also jede für sich und halten Sie ihre Anteile über die Zeit fest.
- Addieren Sie SKAN nie zu modellierten Summen. Sie messen dieselben Kampagnen mit unterschiedlichen Methoden. Legen Sie sie nebeneinander, nicht übereinander.
- Behandeln Sie eine Veränderung der Lücke als das Signal, nicht die 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, ist eine Frage: ein SDK-Release, eine Consent-Änderung, eine neue Region, eine gewechselte 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 bei eingeschaltetem Schalter Aggregated Advanced Privacy Google-attribuierte Daten in den Rohdaten-Reports als restricted erscheinen 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 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. Ein Google-Ziel an MMP-Zahlen zu prüfen, mischt zwei Modelle und kann dazu führen, dass Sie ein Ziel ändern, das in Ordnung war.
Budget zwischen Kanälen: der MMP. Er wendet eine einzige Last-Click-Regel über jedes Netzwerk an, was Google und Meta jeweils für das andere nicht können. Das macht ihn zum faireren Ort, um Google mit Meta oder allem anderen zu vergleichen, solange Sie im Kopf behalten, 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 der Richtung.
Finanzen: keine der beiden Werbeplattformen. Der Umsatz sollte von dort kommen, wo er abgerechnet wird: Ihrer Subscription-Plattform oder den Stores, abgeglichen mit Paid anhand der Prüfungen im Beitrag zum Meta-Abgleich. 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 die Lücken zwischen ihnen gelesen werden. 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.
- Understanding iOS App campaign measurement and reporting, Google Ads Help, kein Seitendatum angezeigt
- About Integrated Conversion Measurement for App Campaigns, Google Ads Help
- About on-device conversion measurement for iOS App campaigns, Google Ads Help
- Understand your conversion tracking data, Google Ads Help
- Set a recommended initial Target ROAS for your App campaigns, Google Ads Help
- Set up your SKAdNetwork conversion value schema, Google Ads Help
- Google Ads (AdWords) FAQ and discrepancies, AppsFlyer, zuletzt bearbeitet am 16. März 2026
- Google Ads (AdWords) Integration setup for advertisers, AppsFlyer, zuletzt bearbeitet am 15. September 2026
- Bulletin: AppsFlyer and Google attribution solution (Open BETA), AppsFlyer, zuletzt bearbeitet am 5. August 2026
- SKAN Conversion Studio, AppsFlyer, zuletzt bearbeitet am 26. April 2026
- Receiving postbacks in multiple conversion windows, Apple Developer, kein Seitendatum angezeigt
Häufige Fragen
Kann ich SKAN-Installs zu den Google-Ads-Installs addieren, um die volle iOS-Summe zu bekommen?
Nein. Google beschreibt modellierte Conversions, ICM und SKAdNetwork als drei Wege, dieselben iOS App-Kampagnen zu messen, sagt, dass Ihre Wahl zwischen ihnen vom Stand Ihrer Implementierung abhängt, und merkt an, dass in modellierte Conversions selbst gegebenenfalls Informationen aus SKAdNetwork einfließen. Ihre Installs überschneiden sich. Wer sie addiert, zählt dieselben Nutzer mehrfach. Vergleichen Sie sie stattdessen nebeneinander für dasselbe Event und dasselbe Fenster.
Warum zeigt Google Ads nicht die ICM-Installs, die mein MMP zeigt?
Weil Google sie heute getrennt hält. Googles Seite zum iOS-Measurement sagt, dass ICM-Daten im Google-Ads-Reporting nicht verfügbar sind, und AppsFlyer sagt, dass Google Ads keine auf ICM basierenden Installs zeigt, während AppsFlyer ICM-Claims zeigt und Googles intern modellierte Installs nicht. Jede Seite zeigt ihr eigenes Modell. Google sagt, dass das iOS-Measurement in Google Ads für Apps mit ICM und On-Device-Measurement-Eventdaten näher an ICM heranrücken wird, nennt aber kein Datum.
Warum ist mein Google-CPI in AppsFlyer höher als in Google Ads?
Die Discrepancy-Seite von AppsFlyer sagt, dass AppsFlyer die Google-Kosten für jeden Kanal einer Kampagne erhält, Conversions von iOS App-Kampagnen aber nur von YouTube und Display attribuiert, sodass der MMP die vollen Kosten durch weniger Installs teilt. Prüfen Sie Ihre Rohdaten auf probabilistische ICM-Claims, bevor Sie annehmen, dass das noch auf Ihren Account zutrifft.
Wie lange sollte ich warten, bevor ich die drei Zahlen vergleiche?
Google sagt, dass modellierte iOS-Conversions bis zu fünf Tage brauchen können, und empfiehlt, das volle Conversion-Fenster abzuwarten, bevor Sie eine Kampagne beurteilen. SKAN ist langsamer: Apples drittes Conversion-Fenster endet 35 Tage nach dem ersten Start, und dieser Postback kommt nach einer weiteren zufälligen Verzögerung von bis zu 144 Stunden an.
Funktioniert ICM für iOS-Nutzer im EWR, in Großbritannien und in der Schweiz?
Mit Stand 29. September 2026 nicht. Googles Seite zu On-Device-Measurement sagt, dass On-Device-Measurement mit Eventdaten, das Google als iOS-Voraussetzung für ICM nennt, für Nutzer dort inaktiv ist, und das ICM-Bulletin von AppsFlyer sagt, dass ICM für iOS-Traffic aus diesen Regionen nicht verfügbar ist. Modellierte Conversions in Google Ads und SKAN decken sie weiterhin ab.