Firebase oder ein MMP? Für App-Startups lautet die Antwort: beides

Jeder App-Gründer, der bezahlte Kundengewinnung betreibt, stellt irgendwann dieselbe Frage: Brauchen wir einen Mobile Measurement Partner, oder reicht Firebase? Die ehrliche Antwort ist, dass beide unterschiedliche Probleme lösen. Firebase misst Google. Ein MMP misst alles andere, und „alles andere“ ist größer, als die meisten Vergleiche zugeben. Es geht nicht nur um Meta und TikTok. Es geht um deine organischen Installs, deine eigenen Kanäle und jeden Deep Link, den du versendest. Sobald du echtes Geld für mehr als einen Kanal ausgibst, brauchst du beides, und du brauchst eine klare Entscheidung darüber, welche Quelle welche Plattform speist.

Ich habe ein Jahr damit verbracht, genau diesen Stack für einen Schweizer Buchungsmarktplatz aufzubauen und zu debuggen: Firebase und Adjust liefen parallel und speisten Google Ads und Meta. Das meiste, was ich darüber weiß, habe ich aus Dingen gelernt, die still kaputtgegangen sind.

Das ist der erste Beitrag einer dreiteiligen Serie zum Thema App-Tracking. Dieser hier behandelt die Architektur: warum ein Tool nicht genügt, was ein MMP tatsächlich misst, wie die beiden Pipelines laufen und wer was speisen sollte. Teil zwei behandelt die stillen Fehlermodi. Teil drei behandelt die iOS-Attributionslücke, die fast jede App mit Web-to-App-Kampagnen gerade jetzt hat.

TL;DR

• Die Attribution von Firebase verbindet sich ausschließlich mit Google Ads. Meta, TikTok und andere Netzwerke sehen die Firebase-Daten kaum; Installs und Conversions aus diesen Kanälen landen falsch attribuiert oder werden als organisch einsortiert.
• Ein MMP ist nicht nur ein Workaround für Meta. Ein Mobile Measurement Partner (Adjust, AppsFlyer, Branch, Airbridge) attribuiert Installs und In-App-Events über jede Quelle hinweg: bezahlte Netzwerke, organischen Traffic, eigene Kanäle (E-Mail, On-Site-Banner, Offline/QR) und die Deep Links, die sie antreiben. Es sendet Conversions serverseitig an jedes Netzwerk zurück.
• Der klarste Beweis ist der Kanal-Mix, den es sichtbar macht. In der App, die ich betreut habe, verteilten sich die In-App-Käufe eines Monats auf organischen Traffic (die mit Abstand größte Quelle), Apple Search Ads, ein Web-to-App-Banner, E-Mail und Paid Social. Eine reine Firebase-Sicht hätte fast all das in „organisch/direkt“ zusammenfallen lassen.
• Betreibe beides als parallele Pipelines. In der Praxis sind das oft getrennte Codepfade in deiner App, und der Umsatz muss in jeder unabhängig gesetzt werden. Die eine kann kaputtgehen, während die andere funktioniert. Unsere waren beim Umsatz eine Zeit lang um etwa den Faktor 8 auseinander, und zwar still.
• Entscheide, wer was speist: Firebase als primäre Conversion-Quelle für Google Ads (schnelleres, reichhaltigeres Signal), das MMP dort als sekundär, und das MMP als einzigen Conversion-Pfad zu Meta und als einzige ehrliche Sicht auf organische und eigene Kanäle.
• Ein MMP ist nicht für jeden ab Tag eins Pflicht. Bei minimalem Meta- oder TikTok-Spend berichtet das eigene SDK der Plattform für sich genommen einwandfrei. Das MMP wird unverzichtbar, sobald du skalierst oder drei oder mehr Quellen betreibst, denn dann muss es sich überschneidende Ansprüche deduplizieren und jede Quelle korrekt attribuieren.
• Wenn du die Quellen-Entscheidung überspringst, zählst du entweder Conversions doppelt oder hältst eine Plattform von Signalen ausgehungert. Beides ruiniert das Bidding still.

Warum Firebase allein nicht genügt

Firebase (über GA4) ist kostenlos, tief in Google integriert und wirklich gut in dem, was es tut: Es trackt In-App-Events, baut Zielgruppen auf und speist Conversions direkt ins Google-Ads-Bidding, ohne zusätzlichen Code über das SDK hinaus, das du ohnehin schon installiert hast.

Die Einschränkung ist struktureller Natur. Die Attribution von Firebase verbindet sich mit Google Ads und im Grunde mit nichts anderem. Betreibe Meta App Ads oder TikTok daneben, und Firebase hat keinen Einblick in diese Klicks. Conversions, die sie ausgelöst haben, tauchen als organisch oder direkt auf. Analysen aus der Praxis sind da unmissverständlich: Meta-getriebene Installs werden in einem reinen Firebase-Setup massiv unterberichtet.

Aber Meta ist nur der offensichtlichste blinde Fleck. Firebase ist genauso blind für Apple Search Ads, für eine E-Mail-Kampagne, die per Deep Link in die App führt, für ein On-Site-Banner „Hol dir die App“, für einen Offline-Flyer mit QR-Code. All das landet im selben undifferenzierten Topf „organisch/direkt“. Wenn dein gesamtes bezahltes Budget in Google App Campaigns fließt, ist Firebase allein vertretbar. In dem Moment, in dem dir ein zweiter Kanal wichtig wird, bezahlt oder eigen, fliegst du dort blind.

Was ein MMP tatsächlich misst (und es ist nicht nur Meta)

Ein Mobile Measurement Partner sitzt zwischen deiner App und der Außenwelt. Jeder Install und jedes In-App-Event wird einer Quelle zugeordnet, über Kanäle hinweg dedupliziert und mit Betrugsfilterung versehen. Die meisten Vergleiche hören hier auf und rahmen das MMP als „den Weg, Meta zu messen“. Das verkauft es unter Wert. Drei Aufgaben sind genauso wichtig wie die mit den bezahlten Netzwerken:

Organischer Traffic und eigene Kanäle werden sichtbar. Das MMP attribuiert Installs und Events, die nie ein Werbenetzwerk berührt haben: App-Store-Stöbern und -Suche, Empfehlungen, deine E-Mail-Liste, On-Site-Banner, Offline-QR-Codes. Auf dem Marktplatz, den ich betreut habe, trackte das MMP mehr als zehn verschiedene Kanäle, und organischer Traffic war durchgängig die mit Abstand größte Quelle für In-App-Buchungen, größer als jeder bezahlte Kanal. Genau diese Zahl kann dir ein reines Firebase-Setup nicht liefern, weil es organischen Traffic und alles Nicht-Google unter demselben Label ablegt. Du kannst nicht entscheiden, ob du in ASO, Empfehlungen oder E-Mail investierst, wenn das Tool sie buchstäblich nicht sehen kann.

Deep Links sind eine MMP-Funktion, kein Nebeneffekt. Die Tracking-Links, die ein MMP ausgibt, sind zugleich Deep Links (und Deferred Deep Links): Sie leiten einen Nutzer aus einer E-Mail, einer SMS, einem Web-Smart-Banner, einem QR-Code oder einem Influencer-Link an die richtige Stelle innerhalb der App, sogar über einen App-Store-Install hinweg, und attribuieren die gesamte Journey. So werden Owned Media überhaupt erst gemessen. Ein konkretes Beispiel: Ein Instagram-Kanal, den wir organisch betrieben, war monatelang unsichtbar und wurde als „organisch/direkt“ einsortiert. In dem Monat, in dem wir die individuellen Tracking-Links des MMP hinzufügten, wurde er über Nacht zu einer gemessenen Quelle. Kein neuer Spend, nur Attribution, die endlich existierte.

Eine deduplizierte kanalübergreifende Sicht. Weil jede Quelle über dieselbe Schicht berichtet, ist das MMP der eine Ort, an dem ein zusammengeführtes, dedupliziertes Bild des gesamten Funnels existiert. Es ist das, mit dem du alles andere abgleichst.

„Ein MMP misst alle anderen“ ist also wörtlich zu nehmen. Es ist der Schiedsrichter für bezahlte Netzwerke und die einzige ehrliche Messung, die du für organischen, eigenen und über Deep Links gelieferten Traffic hast.

Ein Vorbehalt ist erwähnenswert, weil er die Kehrseite desselben Mechanismus ist: Die Attribution eines MMP ist nur so gut wie die Links dahinter. In unserem Stack konnte das On-Site-App-Banner die ursprüngliche Quelle nicht durch den MMP-Link durchreichen, sodass jeder Install darüber als „website_banner“ einsortiert wurde und seine echte vorgelagerte Quelle (Paid Search, Meta, organisch) verloren ging. Deep-Link- und Owned-Channel-Messung ist real und wertvoll, aber sie muss bewusst verdrahtet werden, Link für Link, sonst schreibt sie still dem zu wenig gut, was den Traffic überhaupt ausgelöst hat.

Warum auch ein MMP allein nicht genügt

Wenn das MMP alles sieht, warum nicht einfach nur das MMP nutzen? Zwei Gründe, beide in der Produktion gelernt:

Google bietet besser auf sein eigenes Signal. Google Ads akzeptiert Conversions von einem MMP, aber der Firebase-Pfad ist schneller und reichhaltiger. Firebase-Events kommen mit mehr Granularität und weniger Verzögerung an, was für tROAS- und tCPA-Bidding zählt. In dem Konto, das ich betreue, wurde Firebase zur primären Quelle für Google Ads, weil das Signal schlicht besser war.

Die MMP-Pipeline hat mehr bewegliche Teile. In unserem Aufbau gingen die Firebase-Events direkt aus der App über das Firebase-SDK, während das MMP die Events über eine Customer Data Platform (RudderStack) erhielt, die sie auf das Adjust-SDK abbildete. Zwei Codepfade, zwei Stellen, an denen der Umsatz gesetzt wird, zwei Fehleroberflächen. Mehr dazu, was uns das gekostet hat, in Teil zwei, aber der architektonische Punkt bleibt bestehen: Der MMP-Pfad ist selten der einfache.

Die Dual-Stack-Architektur

Hier ist die Form, die funktioniert und die ich wieder so bauen würde:

App events
  ├── Firebase SDK (direct)
  │     └── GA4 → Google Ads          (Primary for Google)
  └── CDP or direct → MMP SDK (Adjust)
        ├── → Meta (S2S postbacks)     (ONLY path to Meta)
        ├── → Google Ads               (Secondary, cross-check)
        ├── → TikTok / Apple Search Ads / others
        └── → organic, email, banner, QR / deep links  (attribution + routing)

Drei Eigenschaften dieses Setups zählen mehr als jede Tool-Wahl:

1. Die Pipelines sind unabhängig. Firebase und das MMP teilen keinen Zustand. Ein Event kann in der einen Umsatz tragen und in der anderen ohne ihn ankommen. Behandle sie als zwei separate Produkte, die zufällig denselben Nutzer beschreiben.

2. Der Umsatz wird zweimal gesetzt, bewusst. Der Firebase-Aufruf und der MMP-Aufruf brauchen jeweils Wert und Währung explizit angehängt. Anzunehmen, dass der eine vom anderen erbt, ist die einzelne teuerste Annahme im App-Tracking. In unserem Stack waren die beiden Pipelines beim erfassten Umsatz eine Zeit lang um etwa den Faktor 8 auseinander. Die eine Pipeline hängte die Werte korrekt an, während die andere sie still fallen ließ, und nichts warf einen Fehler. Der Fix lag auf Code-Ebene, in nur einer Pipeline. (Die vollständige Obduktion ist Teil zwei.)

3. Jede Plattform bekommt ihre beste verfügbare Quelle. Was uns zu der Entscheidung bringt, die die meisten Teams nie explizit treffen.

Wer was speist: die operative Entscheidung

Das ist der Teil, den die Tool-Vergleiche überspringen, und es ist der Teil, der deine Bidding-Qualität entscheidet.

Google Ads: Firebase als primär, MMP als sekundär. Importiere beide, aber markiere die Firebase-Conversion-Aktionen als primär (fürs Bidding genutzt) und die des MMP als sekundär (nur zur Beobachtung). Du bekommst Googles schnellstes Signal für Smart Bidding plus einen unabhängigen Abgleich vom MMP. Setze niemals beide auf primär: Google zählt dann denselben Kauf zweimal, und dein berichteter CPA sieht besser aus als die Realität, während das Bidding auf eine Fiktion hin optimiert.

Meta und andere Netzwerke: das MMP, Punkt. Firebase spricht nicht mit Meta. Die serverseitigen Postbacks des MMP sind dein einziger sauberer Conversion-Pfad für App Ads, einschließlich der Conversion-Werte, die Meta für die Wertoptimierung braucht. Dasselbe gilt für TikTok und Apple Search Ads. Das bedeutet auch, dass deren Signalqualität nur so gut ist wie deine MMP-Pipeline, und genau dort verlor unsere still Umsatz. Eine Ausnahme, ganz am Anfang: unterhalb von trivialem Spend können die eigenen SDKs von Meta und TikTok ihre Events direkt melden, weshalb das Hinzufügen des MMP eigentlich eine Skalierungsentscheidung ist (mehr zum Timing weiter unten).

Organische, eigene und über Deep Links gelieferte Kanäle: das MMP ist die einzige Quelle. Es gibt kein Firebase-Äquivalent für „wie viele Buchungen kamen aus dem E-Mail-Deep-Link, dem On-Site-Banner oder organisch“. Wenn du ASO-, Empfehlungs- oder CRM-Entscheidungen mit Daten statt mit Bauchgefühl treffen willst, kommt es von hier.

Reporting: GA4 für Verhalten, das MMP für kanalübergreifende Attribution, dein Backend für die Wahrheit. Drei Zahlen, die nie perfekt übereinstimmen werden und das auch nicht müssen. Was sie brauchen, ist, sich innerhalb einer Toleranz abzugleichen, die du im Voraus festgelegt hast. Wenn der App-Umsatz im MMP nur ein Bruchteil dessen ist, was das Backend zeigt, ist das kein Problem der Attributionsphilosophie. Das ist ein Bug.

Wann du das MMP hinzufügst

Staffle es nach Spend, nicht nach Ambition, und sei ehrlich über deine Phase. Ein MMP ist nicht für jede App ab Tag eins Pflicht.

• Nur Google, kleines Budget: Firebase allein ist in Ordnung. Richte es sauber ein (Events, Werte, importierte Conversions) und spare dir die MMP-Gebühr.
• Ein zweiter Kanal, aber winziger Spend: Auch hier kannst du das MMP aufschieben. Meta und TikTok haben beide ihre eigenen SDKs, die App-Events direkt an die jeweilige Plattform melden, und bei ein paar Hundert Euro im Monat reicht das, um einen einzelnen Kanal zu optimieren. Der Haken ist, dass jede Plattform sich isoliert selbst attribuiert, sodass nichts dedupliziert wird und du keine einzige, ehrliche kanalübergreifende Sicht hast. Bei trivialem Spend ist diese Lücke tolerierbar. Wisse nur, dass es ein Provisorium ist, nicht das Ziel.
• Skalieren oder drei und mehr Quellen: Jetzt ist das MMP die Antwort, und das ist der Grund, warum es existiert. Sobald echtes Budget über Google, Meta, TikTok plus organische und eigene Kanäle fließt, beginnen die Plattformen, denselben Install und denselben Kauf für sich zu beanspruchen, und deine Zahlen blähen sich auf. Das MMP ist die Schicht, die jedes Event auf eine einzige verlässliche Datenquelle dedupliziert und jeden Install und jede Conversion der Quelle zuordnet, die sie tatsächlich verdient hat. Füge es hinzu, bevor du skalierst, nicht danach, denn rückwirkende Attribution existiert nicht: Was auch immer läuft, bevor das SDK ausgeliefert wird, bleibt für immer unmessbar.
• Im großen Maßstab zahlt es sich weiter aus: Kohorten-Exporte, Betrugsfilterung, Deep-Link-Routing für Lifecycle-Kampagnen und SKAdNetwork-Management auf iOS.

Die MMP-Preisgestaltung skaliert in der Regel mit attribuierten Installs oder Events. Für eine App in der Frühphase sind die Einstiegsstufen gegenüber selbst einem kleinen bezahlten Budget bescheiden, und sobald du skalierst, ist die Alternative, Installs zu kaufen, die du nicht attribuieren kannst, und jede Plattform doppelt zählen zu lassen, teurer als jedes Tool.

Häufige Fehler

1. Das MMP als Ersatz für Firebase bei Google behandeln. Du verlierst Googles bestes Bidding-Signal und gewinnst nichts.
2. Das MMP als „nur die Meta-Leitung“ behandeln. Du hast für kanalübergreifende, organische und Deep-Link-Messung bezahlt. Nutze sie. Der Kanal, den es sichtbar macht, könnte dein größter sein.
3. Beide Quellen in Google Ads auf primär gesetzt. Doppelt gezählte Conversions, schmeichelnde Dashboards, korrumpiertes Bidding.
4. Annehmen, dass der Umsatz in beide Pipelines fließt, weil das Event es tut. Ankommende Event-Namen sind nicht dasselbe wie ankommende Werte. Prüfe jede Pipeline separat.
5. Das MMP hinzufügen, nachdem die Kampagnen gestartet sind. Attribution beginnt, wenn das SDK ausgeliefert wird, nicht wenn du den Vertrag unterschrieben hast.
6. Niemand besitzt das Mapping. Web-Events, Firebase-Events und MMP-Events brauchen ein dokumentiertes Mapping (welches App-Event welcher Conversion auf welcher Plattform entspricht und welcher Deep Link welchen Kanal speist). Ohne es startet jede Debugging-Session bei null.

FAQ

Ist GA4 dasselbe wie Firebase für das App-Tracking?

Für diese Diskussion praktisch ja: Das Firebase-SDK speist GA4, und Google Ads importiert die Conversions von dort. Das Paar ist eine Pipeline.

Welches MMP sollte ein Startup wählen?

Adjust, AppsFlyer, Branch und Airbridge decken alle die Kernaufgabe ab. Wähle nach Preismodell, den Netzwerken, die du tatsächlich nutzt, deinen Deep-Linking-Anforderungen und der SDK-Passung mit deinem Stack. Die Architektur in diesem Beitrag gilt für sie alle.

Kann ich Firebase-Daten irgendwie an Meta senden?

Nicht sinnvoll. Metas App-Attribution läuft über ihr SDK oder über serverseitige MMP-Postbacks. Genau deshalb verdient sich das MMP seinen Platz an dem Tag, an dem Meta Budget bekommt.

Wenn die meisten unserer Installs organisch sind, brauchen wir dann trotzdem ein MMP?

Das ist das stärkste Argument für eines, nicht dagegen. Firebase kann organischen Traffic nicht von Meta, E-Mail oder einem Web-to-App-Banner unterscheiden. Es legt sie zusammen ab. Wenn organischer Traffic deine größte Quelle ist, ist ein MMP der einzige Weg, das zu bestätigen, es zu schützen und es (per ASO, Empfehlungen, per Deep Link gelieferte Lifecycle-Kampagnen) mit echten Daten wachsen zu lassen.

Zählen die beiden Pipelines den Umsatz in meinem Reporting doppelt?

Nur wenn du sie zusammenführst. Halte Google Ads über primär/sekundär dedupliziert, und behandle GA4, das MMP und dein Backend als drei Sichten mit bekannten, erwarteten Abweichungen.

Was ist mit iOS und SKAdNetwork?

iOS fügt eine dritte Messebene (SKAN/AdAttributionKit) über beiden Pipelines hinzu, plus die gBraid-Mechanik für Web-to-App-Kampagnen. Das ist Teil drei dieser Serie; die Kurzfassung lautet: Die iOS-Attribution versagt auf Arten, die Android dir nie zeigt.

Wichtigste Erkenntnisse

1. Firebase misst Google; ein MMP misst alles andere: bezahlte Netzwerke und ebenso wichtig organischen Traffic, eigene Kanäle und Deep Links. Beides, parallel, ist die Standardantwort, sobald mehr als ein Kanal zählt.
2. Das MMP ist nicht nur die Meta-Leitung. Bei einer echten App war sein wertvollster Output die Erkenntnis, dass organischer Traffic, für Firebase unsichtbar, die mit Abstand größte Buchungsquelle war.
3. Die Pipelines sind unabhängige Codepfade. Der Umsatz muss in jeder explizit gesetzt werden, und die eine kann kaputtgehen, während die andere funktioniert.
4. Mach die Quellen-Entscheidung explizit: Firebase primär für Google Ads, MMP dort sekundär, MMP ausschließlich für Meta und für die Messung von organischem, eigenem und Deep-Link-Traffic.
5. Gleiche die drei Sichten (GA4, MMP, Backend) planmäßig ab, mit einer Toleranz. Abweichung darüber hinaus ist ein Bug, keine Philosophie.

Als Nächstes in der Serie: die fünf stillen Fehlermodi, die ich auf genau diesem Stack ausgeliefert habe, und die Monitoring-Checkliste, die jeden von ihnen früher erwischt hätte.

Wenn du das gerade verdrahtest oder vermutest, dass eine Pipeline still Umsatz fallen lässt, so wie unsere es tat, prüfe es, bevor du skalierst, denn du solltest nicht auf Zahlen bieten, denen du noch nicht trauen kannst. Ein vollständiges App-Tracking-Audit sagt dir, in welcher dieser beiden Gruppen du steckst, und wenn du lieber erst mal nur eine zweite Meinung hättest, prüfe ich dein Setup gerne auf Plausibilität.

Quellen: Google Ads Help, importing app conversions from Firebase and App Attribution Partners; AppSprint, Firebase vs MMP; AppsFlyer on measuring Google App Campaigns; Adjust on deep linking and deferred deep linking; Erfahrung aus einer First-Party-Implementierung auf einem dualen Firebase-+-Adjust-Stack (2026).