Wenn dein Google-Ads-Konto gesunde Android-App-Conversions zeigt, iOS aber auf null steht und die Diagnose “Your gBraid conversion measurement setup is incorrect” meldet (deine gBraid-Einrichtung für die Conversion-Messung ist fehlerhaft), sind deine Daten wahrscheinlich in Ordnung. Deine Attribution ist es nicht. iOS-Anzeigenklicks tragen statt einer GCLID einen gbraid-Parameter, und wenn deine App diesen Parameter nie an ihre Measurement-SDKs weitergibt, wird keine einzige iOS-Conversion zugeordnet.
Genau das ist mir bei einem Schweizer Buchungsmarktplatz passiert, für den ich das Measurement betreue. Das MMP der App zeigte, dass iOS mehr als dreimal so viele In-App-Käufe brachte wie Android. Google Ads rechnete iOS genau eine Conversion zu, gegenüber zwanzig auf Android. Gleiche Kampagnen, gleiche App, gleiche Wochen. iOS schlug Android überall, nur nicht in dem Report, der über Budgets entscheidet.
Das ist Teil drei der Serie zum App-Tracking (Teil eins: die Dual-Stack-Architektur, Teil zwei: stille Fehler beim Umsatz-Tracking). Er ist bewusst der spezifischste der drei: Dieser Fehler hat ein präzises Symptom, eine präzise Ursache und einen präzisen Fix, und fast nichts, was darüber geschrieben wurde, behandelt die App-Seite.
TL;DR
- Symptom: Android-App-Conversions werden normal attribuiert, iOS-Conversion-Aktionen stehen auf null oder auf “Needs attention”, und die Google-Ads-Diagnose meldet ein fehlerhaftes gBraid-Setup, oft für deine Firebase- und deine MMP-Conversion-Aktionen gleichzeitig.
- Ursache: Seit ATT werden Web-to-App-Anzeigenklicks auf iOS mit gbraid/wbraid statt GCLID gemessen. Der Parameter reist in der Klick-URL mit. Wenn deine App die öffnende URL nicht explizit an Firebase übergibt, wird der Parameter nie erfasst, und iOS-Conversions lassen sich keiner Kampagne zuordnen.
- Der primäre Fix ist ein einziger Aufruf:
Analytics.handleOpen(url)an jedem Einstiegspunkt, über den iOS eine URL öffnet (SwiftUI.onOpenURL, UIScene-Delegate-Methoden, Universal-Link-Handler), mit Firebase iOS SDK 6.32.2 oder neuer. - Weitere Voraussetzungen: Universal Links mit durchgehend intaktem Query-String, aktiviertes Auto-Tagging und die Web-to-App-Weiterleitung von gbraid in deinem MMP als sekundärer Pfad.
- Die Erholung kommt schrittweise, nicht sofort: Die gbraid-Erfassung existiert nur in aktualisierten App-Builds, also kommt die Attribution zurück, während Nutzer updaten. Plane ein Validierungsfenster von ein bis zwei Wochen ein.
Zuerst prüfen: Attributionslücke, kein Datenverlust
Bevor du Code anfasst, stell sicher, dass die Conversions existieren. Öffne dein MMP oder Firebase und vergleiche die In-App-Kauf-Events von iOS und Android im selben Zeitraum. Bei uns war das Bild eindeutig: iOS feuerte mehr als dreimal so viele Käufe wie Android, der Umsatz lief korrekt durch, während die Kanalansicht in Google Ads iOS eine einzige Conversion zuschrieb.
Diese Unterscheidung verändert den ganzen Fix. Die Events feuern, die Werte hängen dran, die Nutzer konvertieren. Kaputt ist nur die Verbindung zwischen einem iOS-Anzeigenklick und der späteren In-App-Conversion. Lass niemanden das Event-Tracking neu bauen, um ein Attributionsproblem zu lösen.
Prüf auch die Zeitachse: Unsere letzte erfasste iOS-Conversion in Google Ads war drei Wochen alt. Wenn deine mit einem App-Release oder einem SDK-Update zusammenfällt, ist das dein Regressionspunkt.
gBraid vs. wbraid vs. GCLID: warum die iOS-Attribution bricht
Auf Android, und auf iOS vor App Tracking Transparency, trägt ein Google-Ads-Klick eine GCLID, die bis in die App überlebt und Google den Abgleich von Klick und Conversion erlaubt.
Seit ATT ist dieser Mechanismus für den Großteil des iOS-Traffics weg. Google hat ihn durch zwei datenschutzfreundliche Parameter ersetzt: wbraid für Web-to-Web-Journeys und gbraid für Web-to-App. Die Journey, um die es hier geht: Ein Nutzer tippt in Safari auf iOS auf deine Anzeige, landet auf deiner Website oder einer App-Store-Zwischenseite, öffnet die App und konvertiert. Diese Journey trägt gbraid in der URL.
Und hier ist der Haken. Im Web erfassen Googles eigene Tags diese Parameter automatisch. In einer App passiert nichts automatisch. Apps, die mit UISceneDelegate oder SwiftUI gebaut sind, müssen die öffnende URL explizit an Firebase übergeben, damit es den gbraid-Wert auslesen kann. Fehlt dieser Aufruf, stirbt der Parameter an der Haustür der App: Der Klick ist passiert, die Conversion ist passiert, und kein System der Welt kann die beiden danach noch verbinden.
Deshalb betrifft der Fehler nur iOS, deshalb trifft er deine Firebase- und MMP-Conversion-Aktionen gleichzeitig, und deshalb kann er aus dem Nichts auftauchen, wenn eine App auf SwiftUI oder einen scene-basierten Lifecycle migriert.
Die Lösung
1. Die öffnende URL an Firebase übergeben (der primäre Fix)
Ein Aufruf, an jeder Stelle, an der iOS deiner App eine URL übergibt:
SwiftUI:
import FirebaseAnalytics
.onOpenURL { url in
Analytics.handleOpen(url)
}UIScene delegate:
// scene(_:openURLContexts:) and scene(_:continue:) for Universal Links
Analytics.handleOpen(url)Objective-C:
@import FirebaseAnalytics;
[FIRAnalytics handleOpenURL:url];Deck alle Einstiegspunkte ab: eigene URL-Schemes, Universal Links und den Continue-User-Activity-Pfad. Die gbraid kann über jeden davon ankommen, und genau der, den du auslässt, ist der, den dein Traffic nutzt.
Mindestversion Firebase iOS SDK: 6.32.2. Wenn deine App älter ist, gehört das SDK-Update zum Fix.
2. Sicherstellen, dass die URL den Handler wirklich erreicht, mit intakten Parametern
Analytics.handleOpen(url) kann nur auslesen, was ankommt. Vorgelagert müssen zwei Dinge stimmen:
- Universal Links sind live: das Associated-Domains-Entitlement in der App und eine gültige AASA-Datei auf deiner Domain, damit die gbraid-getaggte Landing-URL die App öffnet und nicht den Browser.
- Der Query-String überlebt: Keine Weiterleitung in der Kette (Link-Shortener, Zwischenseiten, Deferred-Deep-Link-Tools) darf URL-Parameter entfernen. Eine Weiterleitung, die den Query-String verliert, killt die Attribution genauso sicher wie der fehlende Handler-Aufruf.
Teste es durchgehend: Klick auf einem iOS-Gerät auf eine echte getaggte URL und logge die URL, die dein Handler empfängt. Wenn gbraid= nicht drinsteht, arbeite dich rückwärts durch die Kette.
3. Die Voraussetzungen (prüfen, nicht annehmen)
Firebase mit GA4 verknüpft, GA4 mit Google Ads verknüpft, die In-App-Events als Conversions markiert, die Conversion-Aktionen in Google Ads importiert und Auto-Tagging aktiviert im Google-Ads-Konto. All das existiert in einem funktionierenden Android-Setup meistens schon, und genau deshalb prüft es niemand nach. Prüf es nach.
4. Der parallele Pfad über das MMP
Wenn du den Dual Stack aus Teil eins betreibst, ist dein MMP die Secondary-Conversion-Quelle für Google Ads und sollte gbraid ebenfalls in seinen serverseitigen Postbacks weitergeben:
- Aktualisiere das iOS SDK deines MMP auf eine Version mit nativer gbraid/wbraid-Unterstützung.
- Stell sicher, dass Universal Links und Deferred Deep Linking im MMP SDK konfiguriert sind, damit es den Parameter aus der Landing-URL erfasst.
- Prüf in den Google-Ads-Partnereinstellungen des MMP, dass Web-to-App-Measurement aktiviert ist.
Verifizierung, und was du erwarten kannst
Nach dem Deployment des gefixten Builds:
- Diagnose: Der gBraid-Fehler in Google Ads (Ziele, dann Diagnose) sollte für die betroffenen Conversion-Aktionen verschwinden.
- Latenz: Conversions über gbraid können bis zu 72 Stunden in der Verarbeitung brauchen, bei GCLID sind es unter 12. Beurteile den Fix nicht am nächsten Morgen.
- Schrittweise Erholung: Das ist der Teil, der viele überrascht. Der Fix existiert nur im aktualisierten Build, also kommt die Attribution zurück, während deine iOS-Nutzer die App updaten. Rechne mit ein bis zwei Wochen, bis der Trend lesbar ist, schneller, wenn du zu Updates aufforderst.
- Die Erfolgsmetrik: Attribuierte iOS-Conversions in Google Ads sollten von fast null in Richtung dessen steigen, was dein MMP als echte iOS-Leistung ausweist. Bei uns hieß das: Die attribuierte Zahl bewegte sich von eins in Richtung des zweistelligen Android-Niveaus, das das zugrundeliegende Volumen schon immer hergab.
Häufige Fehler
- Event-Tracking neu bauen, um eine Attributionslücke zu schließen. Die Events waren nie kaputt. Prüf, ob die Daten existieren, bevor du änderst, was sie erzeugt.
- Den Handler an einem URL-Einstiegspunkt einbauen und die anderen vergessen. SwiftUI, Scene Delegate und die Universal-Link-Continuation sind drei Türen. Deck alle drei ab.
- Eine Weiterleitung, die den Query-String entfernt. Alles dahinter ist korrekt, und die Attribution stirbt trotzdem. Teste mit einem echten Gerät und einem echten getaggten Klick.
- Den Fix nach 24 Stunden beurteilen. Zwischen 72 Stunden Verarbeitung und einem Rollout, der von Updates abhängt, bedeutet frühe Stille gar nichts.
- Den MMP-Pfad vergessen. Google erholt sich, aber deine Secondary-Quelle bleibt blind, und dein Gegencheck aus Teil zwei verliert seinen Sinn.
FAQ
Woran erkenne ich, ob das meine App betrifft?
Vergleich die Conversions von iOS und Android in Google Ads mit derselben Aufteilung in deinem MMP oder in Firebase. Gesundes iOS-Volumen im Hintergrund plus fast null iOS-Attribution in Google Ads ist die Signatur. Die explizite Diagnosemeldung (“gBraid conversion measurement setup is incorrect”) bestätigt es.
Ist das dasselbe wie SKAdNetwork?
Nein. SKAN (heute AdAttributionKit) ist Apples separate, aggregierte Attributionsebene für App-Install-Kampagnen. gBraid deckt speziell Googles Web-to-App-Measurement in Umgebungen mit eingeschränkter Einwilligung ab. Ein vollständiges iOS-Setup braucht beides funktionierend; dieser Beitrag behandelt die gbraid-Hälfte.
Betrifft das Google App Campaigns oder nur Web-Kampagnen?
gBraid gilt für Journeys, die im Web beginnen: Klicks aus Search, Shopping, Display und Performance Max, die in der App enden. Installs aus App Campaigns werden über einen eigenen Pfad gemessen.
Wir haben es gefixt, und iOS liegt immer noch unter Android. Warum?
Drei legitime Gründe: Noch nicht alle Nutzer haben die App aktualisiert, die gbraid-Verarbeitung dauert bis zu 72 Stunden, und manche iOS-Journeys bleiben unter ATT systembedingt nicht messbar. Das Ziel ist der Trend in Richtung der iOS-Realität deines MMP, nicht Parität am ersten Tag.
Kann ich das ohne App-Release fixen?
Nein. Der fehlende Aufruf steckt im App-Binary. Das ist auch der Grund, warum die Erholung schrittweise kommt: Der Fix wird mit dem Build ausgeliefert, und die Attribution kehrt Nutzer für Nutzer zurück, sobald sie updaten.
Wichtigste Erkenntnisse
- iOS auf null bei gesundem Android ist fast immer ein Attributionsproblem, kein Datenproblem. Belege in deinem MMP, dass die Conversions existieren, bevor du irgendetwas anfasst.
- Die Ursache ist ein einziger fehlender Aufruf: Übergib jede öffnende URL mit
Analytics.handleOpen(url)an Firebase, ab SDK 6.32.2, an allen URL-Einstiegspunkten. - Der Parameter muss die Journey überleben: Universal Links live, AASA gültig, keine Weiterleitung, die den Query-String entfernt.
- Fix auch die gbraid-Weiterleitung deines MMP, sonst bleibt deine Secondary-Quelle blind.
- Die Erholung hängt vom Build ab und kommt schrittweise. Gib ihr zwei Wochen und miss gegen das iOS-Volumen in deinem MMP, nicht gegen deine Hoffnung.
Damit ist die Serie zum App-Tracking komplett: die Architektur, die stillen Fehler und die iOS-Lücke. Wenn du alle drei in einem Durchgang gegen deinen Stack prüfen lassen willst, genau das deckt mein App-Tracking-Audit ab.
Quellen: Google Ads Hilfe, gBraid-Conversion-Messung für iOS einrichten; Google Ads Hilfe, Updates zur Kampagnenmessung unter iOS 14; eigene Diagnose und Fix an einer produktiven iOS-App für einen Schweizer Buchungsmarktplatz (Juni 2026).