App-Umsatz-Tracking geht fast nie laut kaputt. Kein Fehler, kein Alarm, kein rotes Banner in einem Dashboard. Es geht still kaputt: Ein Event feuert weiter, während sein Wert leise auf null steht, eine Pipeline funktioniert weiter, während ihr Zwilling Umsatz fallen lässt, und Smart Bidding gibt weiter Geld gegen Zahlen aus, die aufgehört haben, etwas zu bedeuten.
Ich weiß das, weil ich jeden Fehler in diesem Beitrag selbst ausgeliefert habe. Sie alle stammen aus einem echten Stack, den ich für einen Schweizer Buchungsmarktplatz betreibe: eine React Native App, Firebase direkt an GA4 und Google Ads, Adjust über eine Customer Data Platform an Meta.
Das ist der zweite Beitrag einer dreiteiligen Serie zum Thema App-Tracking. Teil eins behandelte die Dual-Stack-Architektur und wer was speist: warum ein Tool nicht genügt und wie die Firebase- und die MMP-Pipeline parallel laufen. Dieser hier ist der Fehlerkatalog: fünf Arten, wie dieser Stack kaputtgeht, ohne es dir zu sagen, und das Monitoring, das jeden einzelnen früher gefangen hätte, als ich es tat. Teil drei behandelt die iOS-Attributionslücke, die App-Conversions vor Google Ads verbirgt.
TL;DR
- Die fünf stillen Fehler: die falsche GA4-Metrik ablesen, Events ohne Wert-Parameter, eine von zwei Pipelines, die Umsatz fallen lässt, pauschale Standard-Conversion-Werte und tote Events, die niemand bemerkt.
- Keiner davon erzeugt einen Fehler. Alle verfälschen das Bidding, denn die Plattformen optimieren auf die Zahlen hin, die eben ankommen.
- Jeder Fehler hat eine günstige Erkennung: ein wöchentlicher Abgleich des Umsatzes zwischen Firebase, MMP und Backend, eine Aktualitätsprüfung pro Event und eine Prüfung der Wert-Abdeckung in beiden Pipelines.
- Die unbequeme Regel: Dass ein Event-Name ankommt, ist kein Beweis, dass sein Wert angekommen ist. Prüfe Werte separat, pro Pipeline.
Fehler 1: die Metrik, die per Definition lügt
Als wir den App-Umsatz zum ersten Mal in GA4 prüften, lautete die Antwort 0,00. Jedes Buchungs-Event, null Umsatz. Wir gingen davon aus, dass die Implementierung kaputt war.
Die eine Hälfte lag woanders: GA4 hat zwei Umsatz-Metriken, die sich unterschiedlich verhalten. „Gesamtumsatz“ zählt nur Standard-Event-Namen wie purchase oder in_app_purchase. Unsere Buchungs-Events verwendeten eigene Namen, und Events mit eigenen Namen melden ihr Geld unter „Ereigniswert“, nicht unter „Gesamtumsatz“. Der Umsatz kam an; wir lasen die Metrik, die per Definition ausgelegt ist, ihn zu ignorieren.
Das ist kein Bug, es ist eine Namensregel, und sie ist dokumentiert. Aber niemand liest die Definition einer Metrik, die eine plausible Null anzeigt. Wir haben Tage daran verloren.
Die Prüfung: Baue für Conversion-Events mit eigenen Namen Berichte auf „Ereigniswert“ auf. Reserviere „Gesamtumsatz“ für Standard-E-Commerce-Event-Namen. Schreibe das in deine Dashboard-Spezifikation, damit die nächste Person es nicht neu entdecken muss.
Fehler 2: die Events, die wirklich nichts gesendet haben
Die andere Hälfte dieser Null war echt. Zum Zeitpunkt des Audits feuerte die App über 200 verschiedene Events, und die Umsatz-Events darunter trugen überhaupt keinen Wert-Parameter. Buchungen feuerten als nackte Signale: Die Plattformen wussten, dass etwas passiert war, aber nicht, was es wert war.
Die Folge ist schlimmer als fehlendes Reporting. Google und Meta bieten auf Werte. Ein Event-Stream ohne Werte erzwingt Volumen-Bidding: Jede Conversion zählt als eine, also jagt der Algorithmus die günstigsten Conversions, die er findet, und eine hochwertige Buchung ist ihm genau so viel wert wie eine belanglose. Die Web-Variante davon habe ich im Beitrag über dynamische Conversion-Werte behandelt; in Apps ist die Mechanik identisch, nur leichter zweimal falsch zu machen, weil es zwei Pipelines gibt.
Die Prüfung: Bestätige für jedes Umsatz-Event, in jeder Pipeline, dass die Parameter für Wert und Währung im Live-Traffic vorhanden sind. Event-Abdeckung und Wert-Abdeckung sind unterschiedliche Audits.
Fehler 3: zwei Pipelines, eine still kaputt
Das ist der teure. Nachdem die Entwicklung den Wert-Fix ausgeliefert hatte, funktionierte der Firebase-Umsatz: echte Buchungswerte, die an GA4 und Google Ads flossen. Die Adjust-(MMP-)Pipeline erhielt dieselben Events, aus denselben Nutzeraktionen, an denselben Tagen, und erfasste rund ein Achtel des Umsatzes, den Firebase sah. Dann fiel sie auf null, während Firebase weiter Geld verzeichnete.
Nichts warf einen Fehler. Die Ursache steckte in der Verrohrung der zweiten Pipeline: Die App schickte Events über eine Customer Data Platform an das MMP, und der Umsatz-Aufruf hatte Fehlermodi, die der direkte Firebase-Aufruf nicht hatte. Ein Preis-Helper, der für manche Buchungstypen null zurückgab, machte den Umsatz zu NaN. Ein Umsatz-Feld, das als String statt als Zahl ankam. Ein Währungskürzel, das nicht exakt der ISO-Code war, den das SDK erwartete. Jedes davon bringt ein MMP-SDK dazu, das Anhängen von Umsatz still zu überspringen: Das Event kommt trotzdem an, sieht gesund aus, ist nichts wert.
Weil das MMP unser einziger Conversion-Pfad zu Meta war, bedeutete das: Meta optimierte auf leere Werte, während Google auf echte optimierte, und der Unterschied war in keiner der beiden Plattformen für sich allein sichtbar.
Die Prüfung: Gleiche den Umsatz zwischen Firebase, dem MMP und deinem Backend wöchentlich ab, mit einer Toleranz, die du vorab festlegst. Die drei werden nie exakt übereinstimmen. Aber eine Abweichung um den Faktor 8 ist keine Attributions-Nuance, sondern ein Bug mit verlorenem Umsatz, und nur ein quellenübergreifender Vergleich bringt ihn ans Licht. Wenn du ihn findest, debugge mit einer Log-Zeile vor dem SDK-Aufruf: Typ und Wert von Umsatz und Währung. NaN, undefined, "NaN" als String oder ein Nicht-ISO-Währungskürzel ist dein Bug.
Fehler 4: der pauschale Standardwert
Während die Werte kaputt waren, fielen die Conversion-Aktionen in Google Ads auf einen Standardwert von 1,00 zurück. Der echte durchschnittliche Buchungswert war rund 11-mal so hoch.
Ein falscher Standardwert ist schlimmer, als er klingt, weil er nicht falsch aussieht. Conversions fließen, Dashboards füllen sich, die ROAS-Rechnung läuft. Aber der Bidding-Algorithmus optimiert gegen Zahlen, die um eine Größenordnung danebenliegen, und jede automatisierte Budgetentscheidung erbt die Verzerrung. Als wir die Pipeline reparierten, hoben wir auch den Standardwert an, damit eine künftige Lücke wenigstens in Richtung realistischer Zahlen fehlschlägt statt in Richtung 1,00.
Die Prüfung: Öffne jede App-Conversion-Aktion in Google Ads und lies drei Einstellungen: den Wert (Standard vs. dynamisch), ob die Aktion primär oder sekundär ist, und das Attributionsfenster. Standardwerte werden einmal gesetzt, meist während eines Setup-Sprints, und überleben dann jahrelang ungeprüft.
Fehler 5: das Event, das starb und niemand bemerkte
Ein Conversion-Event, eine Registrierung auf der Anbieterseite, die uns wichtig war, kam gar nicht mehr an. Als ein Audit es aufdeckte, war es seit mehr als zwei Monaten tot. Es gab keinen Alarm, denn Event-Pipelines schlagen nicht Alarm; sie hören einfach auf.
Jedes Tracking-Setup verfällt. App-Releases benennen Dinge um, SDK-Updates ändern das Verhalten, ein Refactor lässt einen Aufruf fallen. Die Frage ist nicht, ob ein Event stirbt, sondern wie lange es tot bleibt, bevor jemand es bemerkt. Zwei Monate fehlendes Conversion-Signal sind zwei Monate, in denen eine Plattform falsch lernt, was deine Nutzer tun.
Die Prüfung: ein Aktualitäts-Alarm pro Event. Die einfachste Variante ist ein wöchentlicher Blick auf die Tage-seit-letztem-Event für jedes Conversion-Event, in beiden Pipelines. Alles über ein paar Tagen bei einem Event, das täglich feuern sollte, ist ein Vorfall, keine Kuriosität.
Die Monitoring-Checkliste
Alles oben lässt sich zu fünf wiederkehrenden Prüfungen verdichten. Auf einem kleinen Stack brauchen sie weniger als eine Stunde pro Woche:
- Wert-Abdeckung: Jedes Umsatz-Event trägt Wert + Währung, in Firebase und im MMP, im Live-Traffic.
- Quellenübergreifender Abgleich: Umsatz aus Firebase vs. MMP vs. Backend, wöchentlich, gegen eine vorab vereinbarte Toleranz.
- Event-Aktualität: Tage-seit-letztem-Feuern pro Conversion-Event, beide Pipelines. Tote Events sind Vorfälle.
- Plattform-Einstellungen: Werte der Conversion-Aktionen, Primär/Sekundär-Status und Attributionsfenster in Google Ads; Empfang von Event und Wert im Meta Events Manager.
- Metrik-Definitionen: Dashboards lesen „Ereigniswert“ für Events mit eigenen Namen, und jedes Diagramm nennt die Quelle, aus der es zeichnet.
Nichts davon erfordert Budget für Tools. Es erfordert die Entscheidung, dass Tracking ein Produktivsystem ist, das auch so überwacht wird.
FAQ
Wie viel Umsatz-Abweichung zwischen Quellen ist normal?
Firebase, ein MMP und ein Backend messen unterschiedliche Dinge (Attributionslogik, Consent, Timing), daher sind Abweichungen von 10–30 % auf bestimmten Ausschnitten üblich. Lege deine eigene Toleranz aus ein paar sauberen Wochen fest. Vielfache, wie die Abweichung um den Faktor 8, die uns traf, sind immer Bugs.
Warum stimmen meine Umsatzzahlen aus Firebase und Adjust nicht überein?
Eine gewisse Abweichung ist normal, aber ein Vielfaches ist ein Bug, keine Attributions-Nuance. Bei uns meldete Firebase rund das 8-Fache des Umsatzes, den Adjust erfasste, weil die Adjust-Pipeline fehlerhafte Werte still verwarf (NaN, ein String statt einer Zahl oder ein Nicht-ISO-Währungskürzel), während der direkte Firebase-Aufruf sie korrekt anhängte. Siehe Fehler 3: Gleiche beide wöchentlich gegen dein Backend ab, und wenn eine Quelle nur einen Bruchteil der anderen anzeigt, logge Typ und Wert von Umsatz und Währung direkt vor dem SDK-Aufruf, um zu finden, wo er verloren geht.
Mein GA4 zeigt 0,00 Umsatz bei App-Events. Kaputt oder nicht?
Prüfe zuerst die Metrik: Events mit eigenen Namen melden unter „Ereigniswert“, nicht unter „Gesamtumsatz“. Ist auch der „Ereigniswert“ null, dann fehlt der Wert-Parameter wirklich, und du hast Fehler 2.
Warum hat das MMP Umsatz ohne jeden Fehler fallen lassen?
MMP-SDKs validieren den Umsatz-Aufruf und überspringen ihn still, wenn die Eingabe fehlerhaft ist: NaN, ein String, wo eine Zahl erwartet wird, oder ein unerwartetes Währungskürzel. Das Event selbst kommt trotzdem an, und genau das macht es unsichtbar.
Sollte der Standard-Conversion-Wert einfach null sein?
Nein. Setze ihn nahe an deinen echten Durchschnitt, damit eine künftige Pipeline-Lücke sanft degradiert. Ein Standardwert von 1,00 bei einem hochwertigen Produkt ist eine stehende Einladung zur Bidding-Verzerrung.
Wer sollte diese Prüfungen verantworten?
Wer für Paid Performance verantwortlich ist, nicht die Entwicklung. Die Entwicklung repariert Pipelines; das Marketing leidet still, wenn sie kaputtgehen. Die Checkliste gibt es, damit die Person, die das Budget ausgibt, es zuerst bemerkt.
Wichtigste Erkenntnisse
- App-Umsatz-Tracking geht per Definition still kaputt: SDKs überspringen fehlerhafte Werte ohne Fehler, und Plattformen bieten bereitwillig auf alles, was ankommt.
- Dass ein Event ankommt, ist kein Beweis, dass sein Wert ankam. Prüfe Event-Abdeckung und Wert-Abdeckung separat, pro Pipeline.
- Die Dual-Stack-Architektur bedeutet, dass jeder Fehler zweimal passieren kann, unabhängig voneinander. Gleiche wöchentlich über die Quellen hinweg ab.
- Standardwerte zählen: Conversion-Werte, Primär/Sekundär-Status und Attributionsfenster steuern still jede automatisierte Entscheidung.
- Behandle Tracking als Produktivsystem mit Aktualitäts-Alarmen. Zwei tote Monate bei einem Event sind ein echter Kostenpunkt ohne Rechnung.
Als Nächstes in der Serie: der iOS-spezifische Fehler, den selbst ein gesunder Stack gerade jetzt hat, bei dem iOS mehr Käufe treibt als Android und Google Ads fast keinen davon attribuiert.
Wenn du diese fünf Prüfungen einmal richtig gegen deinen Stack laufen lassen willst, ist das der Kern meines App-Tracking-Audits.
Quellen: Erfahrung aus einer First-Party-Implementierung und Debugging auf einem dualen Firebase-+-Adjust-Stack für einen Schweizer Buchungsmarktplatz (2026); GA4 documentation on revenue metrics; Teil eins dieser Serie, Firebase oder ein MMP?.