Welche Events sollten Sie in der App messen? Eventplan mit Firebase Analytics

Viele Teams behandeln Firebase Analytics wie ein Paket, das man einbaut und dann vergisst. Allerdings verraten die automatisch erfassten Daten nur, wie viele Menschen die App geöffnet haben. Wo Nutzer abspringen, welcher Screen Umsatz bringt oder welches Release die Bindung verschlechtert hat, sehen Sie erst mit einem Eventplan.

Deshalb schreiben wir bei Talha Aslan und Team den Messplan, bevor jemand Trackingcode schreibt. In diesem Leitfaden zeigen wir Ihnen diese Methode Schritt für Schritt:

• Sie erfahren zunächst, welche Events automatisch ankommen.
• Danach sehen Sie, welche Events Sie für Registrierung, ersten Nutzwert, Kauf und Abo ergänzen.
• Außerdem finden Sie Benennungsregeln und Grenzen in einer Tabelle.
• Schließlich lernen Sie, wie Sie ohne personenbezogene Daten messen und die Einrichtung testen.

Was ist ein Event, und worin unterscheidet es sich von einem Screenaufruf?

Ein Event ist der Eintrag einer einzelnen Aktion zu einem bestimmten Zeitpunkt in Ihrer App. Zum Beispiel sind das Hinzufügen eines Produkts zum Warenkorb, der Start eines Videos oder das Öffnen der Kasse jeweils ein Event. Jedes Event hat einen Namen und optionale Parameter. Die Parameter liefern also die Details dieses Moments.

Ein Screenaufruf ist eine besondere Art von Event. Konkret erfasst Firebase Screenwechsel selbstständig unter dem Namen screen_view. Sie sehen also ohne eigenen Code, wie oft jeder Screen geöffnet wird. Trotzdem bedeutet ein geöffneter Screen nicht, dass der Nutzer dort etwas getan hat.

Ein einfaches Beispiel macht das deutlich. Angenommen, tausend Personen öffnen Ihren Bezahlscreen. Wie viele davon Kartendaten eingeben und den Kauf abschließen, zeigen die Screendaten allerdings nicht. Deshalb sind Screenaufrufe nur der Ausgangspunkt, und Events sind die eigentliche Entscheidungsgrundlage. Kurz gesagt beschreiben Screens den Verkehr, Events dagegen das Verhalten.

Wenn Sie die Webseite zum Vergleich heranziehen möchten, erklärt unser Artikel Was ist GA4 dieselbe Eventlogik für Websites.

Welche Events erfasst Firebase Analytics automatisch?

Firebase Analytics zeichnet eine Reihe von Events auf, sobald das SDK in Ihrer App steckt, ganz ohne zusätzlichen Code. Die Liste der automatisch erfassten Events von Google nennt jedes Event und die Plattform, auf der es funktioniert. Für Apps nutzen Sie diese am häufigsten:

• first_open: Der Nutzer startet die App zum ersten Mal nach der Installation oder Neuinstallation.
• session_start und user_engagement: Eine Sitzung beginnt, und die App bleibt mindestens eine Sekunde im Vordergrund.
• screen_view: Ein Screenwechsel findet statt.
• app_update und os_update: Die App oder das Betriebssystem erhält ein Update.
• in_app_purchase: Ein Kauf innerhalb der App ist abgeschlossen.
• app_remove: Der Nutzer deinstalliert die App; dieses Event funktioniert nur unter Android.
• notification_open: Der Nutzer öffnet eine Firebase Benachrichtigung.

Zudem setzt das Event app_exception die Anbindung von Crashlytics voraus. Laut derselben Liste laufen die Abo Events für Umwandlung, Verlängerung und Kündigung nur bei Google Play automatisch. Daher brauchen Sie unter iOS eigene Events oder eine serverseitige Lösung, um dieselben Daten zu sehen.

Warum reichen automatische Events allein nicht aus?

Automatische Events sehen in jeder App gleich aus, denn sie kennen Ihr Geschäftsmodell nicht. Zum Beispiel liefern eine Termin App und ein Spiel dieselben Daten zu first_open und session_start. Dabei misst sich der Erfolg der einen an gebuchten Terminen und der Erfolg des anderen an geschafften Levels.

Einige typische Fragen kann der automatische Datensatz nicht beantworten:

• Wie viele Personen, die das Registrierungsformular geöffnet haben, haben es auch abgeschlossen?
• In welcher Sitzung haben Nutzer zum ersten Mal echten Nutzen erlebt?
• Welche Funktion haben zahlende Nutzer vor dem Upgrade ausprobiert?
• Was taten Nutzer, wenn eine Suche nichts fand?

Screenzahlen lösen also keine dieser Fragen. Außerdem füllen automatische Events Ihre Berichte mit Volumen; jedes Diagramm ohne eigene Events zeigt also nur Verkehr. Deshalb denken wir eine Einrichtung von Firebase Analytics in zwei Schichten. Unten liegen die automatischen Events. Darüber liegen dann empfohlene und eigene Events, die Ihre geschäftlichen Fragen beantworten.

Falls der Umfang Ihrer ersten Version noch offen ist, hilft Ihnen unser Leitfaden zum Mobile App MVP bei der Entscheidung, welche Funktionen und damit welche Events in das erste Release gehören.

Worin unterscheiden sich empfohlene und eigene Events?

Empfohlene Events sind Events, deren Namen und Parameter Google bereits festgelegt hat. Dazu gehören zum Beispiel sign_up, login, search, share, add_to_cart, begin_checkout, purchase und refund. Senden Sie diese Events mit den empfohlenen Namen, erkennen die Berichte sie und füllen die passenden Felder.

Die Firebase Anleitung zum Erfassen von Events empfiehlt genau diesen Weg. Sie erfassen die empfohlenen Events, die zu Ihrer App passen, zusammen mit den vorgesehenen Parametern. Passt kein empfohlenes Event, definieren Sie ein eigenes. Das Beispiel in der Anleitung ist zudem ein eigenes Event namens share_image.

In der Praxis ist die Regel einfach. Zunächst prüfen Sie, ob die Aktion bereits in der empfohlenen Liste steht. Falls ja, übernehmen Sie Namen und Parameter exakt. Falls nein, wählen Sie einen kurzen, klaren eigenen Namen für den Moment, der für Ihr Geschäft zählt, etwa eine Buchung oder die Anzeige einer Paywall.

Andererseits ist es ein häufiger Fehler, ein empfohlenes Event unter eigenem Namen neu zu erfinden. Erfassen Sie einen Kauf als order_completed, bleiben Ihre Umsatzberichte leer. Prüfen Sie also immer zuerst die empfohlene Liste.

Mit welcher Frage sollte Ihr Messplan beginnen?

Ein Messplan beginnt mit geschäftlichen Fragen und nicht mit einer Eventliste. Zuerst schreiben Sie den Satz auf, der den Erfolg Ihrer App beschreibt. Dann wählen Sie die Events, die diesen Satz belegen oder widerlegen. Somit vermeiden Sie eine Einrichtung voller Events, die nie zu einer Entscheidung führen.

In unseren Projekten folgen wir dieser Reihenfolge:

1. Formulieren Sie den Erfolg in einem Satz, etwa ein Nutzer, der mindestens einmal pro Woche bucht.
2. Listen Sie den Weg dorthin Schritt für Schritt auf: Installation, Registrierung, erste Suche, erste Buchung, erneute Buchung.
3. Ordnen Sie jedem Schritt ein Event zu und prüfen Sie, ob ein empfohlenes Event ihn bereits abdeckt.
4. Notieren Sie in einer Zeile, welche Frage jedes Event beantwortet.
5. Begrenzen Sie die Parameter pro Event auf wenige.
6. Teilen Sie den Plan mit Entwicklung und Marketing in einer gemeinsamen Tabelle.

Diese Tabelle dient zudem als gemeinsame Sprache über alle Releases hinweg. Kommt eine neue Funktion hinzu, ergänzen Sie zuerst eine Zeile und schreiben erst dann Code. Anders gesagt ist Messung damit kein Nachgedanke mehr, sondern von Anfang an Teil des Produktdesigns.

Mit welchen Events verfolgen Sie Registrierung und Login?

Zunächst gibt es für diesen Ablauf die empfohlenen Events sign_up und login. Beide nehmen einen Parameter namens method auf. Er beschreibt konkret, ob der Nutzer über E-Mail, Telefon oder einen sozialen Login kam. Folglich können Sie vergleichen, welche Methode am häufigsten abgeschlossen wird.

Allerdings zeigt die reine Zahl abgeschlossener Registrierungen nicht, wo Menschen abspringen. Deshalb empfehlen wir ein kleines eigenes Event am Anfang des Ablaufs. Konkret genügen etwa sign_up_start für das Öffnen des Formulars und otp_request für die Anforderung eines Bestätigungscodes.

Beispielszenario: Ein großer Teil der Nutzer, die den Registrierungsscreen öffnen, verschwindet beim Bestätigungscode. Dann liegt das Problem wahrscheinlich nicht im Design. Eher kommt der Code zu langsam an, oder das Format der Telefonnummer verwirrt. Mit einem Eventplan sucht das Team somit an der richtigen Stelle.

Ein Hinweis gehört an diese Stelle. Schreiben Sie niemals die E-Mail Adresse oder Telefonnummer des Nutzers in einen Parameter. Die Methode reicht aus, weil Sie Verhalten messen und keine Personen. Im Abschnitt zu personenbezogenen Daten gehen wir danach näher darauf ein.

Wie messen Sie den ersten Nutzwert?

Der erste Nutzwert ist der Moment, in dem ein Nutzer den versprochenen Vorteil Ihrer App zum ersten Mal konkret erlebt. Die erste gespeicherte Notiz in einer Notiz App, die erste Buchung in einer Termin App oder das erste Produkt auf der Merkliste einer Shopping App sind gute Beispiele. Meist erfasst daher ein einziges eigenes Event diesen Moment.

Weil die empfohlene Liste dafür keinen direkten Eintrag hat, benennen Sie dieses Event passend zu Ihrem Geschäft. Zum Beispiel first_booking_created oder first_note_saved. Manche Teams nutzen zusätzlich die empfohlenen Events tutorial_begin und tutorial_complete für Einführungsscreens. Somit trennen Sie Nutzer, die die Einführung beenden, von denen, die sie überspringen.

Warum ist dieses Event so wichtig? Weil das Erreichen dieses Moments in den ersten Sitzungen die Bindung stärker prägt als fast alles andere. Sobald Sie es messen, vergleichen Sie das Verhalten der Nutzer, die ihn erreicht haben, mit dem Verhalten derer, die ihn nie erreicht haben.

Möchten Sie Ihre Einführungsscreens auf diesen Moment ausrichten, lesen Sie unseren Beitrag App Onboarding gestalten. Dort beschreiben wir vor allem die Designseite eines kürzeren Wegs zum ersten Nutzwert.

Wie richten Sie Kauf und Warenkorb Events ein?

In einer App mit Verkauf richten Sie die empfohlenen E-Commerce Events der Reihe nach ein: view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_payment_info und purchase. Für Rückerstattungen nutzen Sie außerdem refund. Mit dieser Reihenfolge sehen Sie jeden Schritt des Kauftrichters einzeln.

Beim Kaufevent zählen drei Parameter besonders:

• transaction_id: verhindert, dass dieselbe Bestellung doppelt zählt.
• value: der Bestellbetrag, aus dem sich die Umsatzberichte speisen.
• currency: der Währungscode; ohne ihn lesen die Berichte den Betrag nicht korrekt.

Zusätzlich senden Sie eine Liste der Artikel mit Produktname, Kategorie und Menge. Dadurch erkennen Sie, welche Produkte oder Kategorien sich am besten verkaufen. Falls Sie noch zwischen Kauf in der App und Webzahlung abwägen, erklärt unser Vergleich Kauf in der App oder Webzahlung auch die Folgen für die Messung.

Schließlich senden Sie das Kaufevent erst, wenn die Zahlung tatsächlich bestätigt ist. Senden Sie es beim Tippen auf den Bezahlknopf, erscheinen fehlgeschlagene Zahlungen als Verkäufe.

Welche Events zählen in einer Abo App am meisten?

Die Messung im Abo teilt sich in zwei Teile: die Entscheidungsmomente vor dem Abschluss und den Lebenszyklus danach. Für die Entscheidungsmomente definieren Sie zunächst eigene Events wie paywall_view, plan_select und trial_start. Im Lebenszyklus verfolgen Sie die Umwandlung der Testphase, die Verlängerung und die Kündigung.

Laut der Google Liste automatischer Events laufen app_store_subscription_convert, app_store_subscription_renew und app_store_subscription_cancel nur bei Google Play automatisch. Daher empfangen Sie unter iOS die Benachrichtigungen des Stores auf Ihrem Server und ordnen sie eigenen Events zu, um denselben Lebenszyklus zu sehen.

Beispielszenario: Viele Nutzer sehen die Paywall, aber nur wenige starten eine Testphase. Bevor Sie am Preis drehen, prüfen Sie, wo und wann die Paywall erscheint. Ein Parameter für die Quelle der Paywall, etwa Einstellungen, gesperrte Funktion oder erster Start, beantwortet diese Frage in einem einzigen Bericht.

Halten Sie die Abo Events außerdem auf beiden Plattformen einheitlich. Sendet Android trial_start und iOS start_trial, zerfällt Ihr Trichter in zwei Hälften, die nie zusammenpassen. Eine gemeinsame Benennungstabelle verhindert das.

Welche Benennungsregeln bewähren sich bei Events?

Eventnamen unterscheiden zwischen Groß und Kleinschreibung. Purchase und purchase sind also zwei getrennte Events, und Ihre Berichte zerfallen. Laut den Google Regeln für Eventnamen beginnen Namen mit einem Buchstaben und enthalten keine Leerzeichen. Zahlen und Unterstriche sind erlaubt. Einige Namen reserviert das System zudem für sich.

Die folgende Tabelle verbindet die Werte der Google Seite zu den Grenzen der Eventerfassung mit den Benennungsgewohnheiten, die wir in der Praxis nutzen. Grenzen können sich ändern; prüfen Sie den aktuellen Wert deshalb auf der offiziellen Seite.

Die vierte Zeile ist die wichtigste. Ein eigenes Event für jede Variante verbraucht die Grenze schnell. Nutzen Sie stattdessen ein Event mit einem beschreibenden Parameter.

Wie wählen Sie Parameter und Nutzereigenschaften aus?

Ein Parameter liefert Kontext zu einem einzelnen Event, eine Nutzereigenschaft beschreibt dagegen den Nutzer über längere Zeit. Der Parameter source am Event paywall_view sagt zum Beispiel, wo die Paywall erschien. Die Nutzereigenschaft plan_type zeigt hingegen, ob die Person einen kostenlosen oder einen Premium Tarif nutzt.

Laut Firebase Dokumentation registrieren Sie eigene Parameter in der Konsole als benutzerdefinierte Definitionen, bevor sie in Berichten erscheinen. Textwerte dienen als Dimensionen, Zahlenwerte als Messwerte. Lassen Sie diesen Schritt aus, kommen die Daten zwar an, tauchen aber nie in Ihren Berichten auf.

Stellen Sie sich vor jedem neuen Parameter diese Fragen:

• Möchte ich einen Bericht nach diesem Wert filtern oder vergleichen?
• Ändert sich der Wert mit jedem Event, oder gehört er zum Nutzer?
• Könnte der Wert eine Person identifizieren?
• Stammt der Wert aus einer kurzen festen Liste, oder ist er Freitext?

Vermeiden Sie Freitext. Rohe Suchbegriffe sprengen zum Beispiel schnell die Wertgrenze, und Nutzer tippen versehentlich persönliche Angaben ein. Nutzen Sie stattdessen begrenzte Werte wie Trefferzahl oder Kategorie.

Wie ordnen Sie Events für die Trichteranalyse?

Eine Trichteranalyse zeigt, welcher Anteil der Nutzer jeden Schritt zu einem Ziel abschließt. App öffnen, Produkt ansehen, in den Warenkorb legen und kaufen bilden etwa einen Kauftrichter. Jeder Schritt entspricht einem Event; deshalb müssen die Events vollständig sein, bevor Sie den Trichter bauen.

Ein guter Trichter braucht Events, die drei Bedingungen erfüllen. Erstens darf zwischen den Schritten keine Lücke sein; ohne begin_checkout sehen Sie den Verlust zwischen Warenkorb und Kauf nicht. Zweitens trägt jeder Schritt auf jeder Plattform denselben Namen. Drittens spiegeln Events den echten Moment, denn ein geöffneter Screen und ein funktionierender Knopf sind nicht dasselbe.

Beispielszenario: Android sendet add_to_cart beim Tippen auf den Knopf, iOS dagegen beim Öffnen des Warenkorbs. Dann lassen sich beide Trichter nicht vergleichen. Die Lösung besteht darin, den Auslösemoment jedes Events im Messplan festzuhalten.

Die Marketingseite von Trichtern und die Definition der Stufen erklären wir in Was ist ein Conversion Funnel. Ein App Trichter funktioniert genauso; nur sind die Schritte Events statt Seiten.

Welche Events brauchen Sie für Kohorten und Bindung?

Eine Kohorte ist eine Gruppe von Nutzern, die die App im selben Zeitraum zum ersten Mal geöffnet hat. Die Bindung zeigt, wie viele davon in den folgenden Tagen zurückkehren. Firebase nutzt dafür first_open und die Sitzungsevents; die einfache Bindungskurve sehen Sie also ohne Code.

Allerdings misst die einfache Kurve nur Rückkehr. Die eigentliche Frage lautet meist anders: Haben zurückkehrende Nutzer die wertschaffende Aktion wiederholt? Dafür wählen Sie im Kohortenbericht das Event des ersten Nutzwerts und das wichtigste Wiederholungsevent, etwa booking_created oder purchase, als Kriterium.

Beachten Sie beim Lesen von Kohorten diese Punkte:

• Trennen Sie Kohorten nach Releasedatum, damit Sie die Wirkung jeder neuen Version sehen.
• Bewerten Sie Kampagnenzeiträume separat, weil sich bezahlte Nutzer anders verhalten.
• Vergleichen Sie Kohorten von Android und iOS nebeneinander.
• Betrachten Sie einen Trend über mehrere Wochen statt einer einzelnen Kohorte.

Wie sich Werbeverkehr unter iOS messen lässt, erklärt unser Beitrag zu App Tracking Transparency (ATT), inklusive der Wirkung der Berechtigungsabfrage auf die Messung.

Welche personenbezogenen Daten dürfen Sie nie an Firebase Analytics senden?

Die Richtlinie zu personenbezogenen Daten von Google verlangt, dass Sie an Analytics keine Daten senden, mit denen Google eine Person identifizieren könnte. Als Beispiele nennt Google E-Mail Adressen, private Mobilnummern und Ausweisnummern. Die Liste ist nur beispielhaft und nicht abschließend.

In Apps verstoßen Teams an diesen Stellen am häufigsten gegen die Regel:

• Die E-Mail Adresse als Parameter am Registrierungsevent.
• Der Text aus dem Suchfeld genau so, wie der Nutzer ihn eingetippt hat.
• Eine Telefonnummer im Feld für die Nutzerkennung.
• Ein genauer Standort als Parameter.

Die Richtlinie untersagt außerdem genaue Standortdaten. Nutzen Sie stattdessen allgemeine Werte wie Stadt oder Region. Müssen Sie Nutzer unterscheiden, verwenden Sie eine Kennung aus Ihrem eigenen System, die die Person nicht direkt identifiziert.

Für das größere Bild zu Datenschutzhinweisen und Einwilligung beschreibt unser DSGVO Leitfaden Grundsätze, die auch für Apps gelten. Dieser Artikel ist keine Rechtsberatung; bitte sprechen Sie für Ihren Fall mit einer Anwältin oder einem Anwalt.

Wie wirkt sich Ihr Eventplan auf die Datenschutzangaben im Store aus?

Sobald Sie ein Analytics SDK einbauen, geben Sie die erfassten Daten in beiden Stores an. Laut Google Play Hilfe deckt das Formular zur Datensicherheit auch Daten ab, die Bibliotheken und SDKs von Drittanbietern erfassen. Die Kategorie App Aktivitäten und der Zweck Analysen sind typische Teile dieser Angabe.

Apple geht ähnlich vor. Laut der Seite zu den App Datenschutzdetails geben Sie auch Daten an, die Code von Drittanbietern in Ihrer App erfasst, und Analysewerkzeuge zählen ausdrücklich dazu. Auch dort begegnen Ihnen der Datentyp Produktinteraktion und der Zweck Analysen.

Ihr Messplan ist somit zugleich Ihre Liste für die Angaben. Ergänzen Sie ein neues Event oder einen Parameter, prüfen Sie, ob die Angaben noch stimmen. Wie streng Apple bei Pflichtfunktionen prüft, zeigt etwa unser Beitrag zur Pflicht zur Kontolöschung im App Store.

Was bedeutet die Verknüpfung von Firebase mit GA4?

Die Analysedaten in Firebase laufen auf der Plattform von Google Analytics. Praktisch heißt das: Sie können Ihre App Daten auch in einer Google Analytics Property ansehen. Liegt Ihre Website in derselben Property, betrachten Sie App und Web nebeneinander.

Diese Verknüpfung hat drei praktische Folgen. Erstens markieren Sie wichtige Events als Schlüsselereignisse; laut Google misst ein Schlüsselereignis eine Aktion, die für den Erfolg Ihres Unternehmens besonders wichtig ist. Zweitens erstellen Sie Zielgruppen für Werbung und Benachrichtigungen. Drittens exportieren Sie Rohdaten für tiefere Analysen nach BigQuery.

Laut der Liste automatischer Events gelten die Abo Events für Umwandlung und Verlängerung bei Google Play standardmäßig als Schlüsselereignisse. Ihre übrigen wichtigen Events, etwa die erste Buchung oder den Kauf, markieren Sie selbst.

Zeigen Schlüsselereignisse weniger als erwartet, finden Sie typische Ursachen in unserem Beitrag GA4 Conversions fehlen.

Wie testen Sie Firebase Analytics Events vor dem Release?

Sie testen Firebase Analytics Events vor dem Release mit DebugView. DebugView zeigt Events von einem Gerät im Debugmodus nahezu in Echtzeit. So prüfen Sie, ob Eventname, Parameter und Auslösemoment zum Plan passen.

Laut der DebugView Dokumentation aktivieren Sie den Debugmodus unter Android über eine Einstellung per Kommandozeile und unter iOS über ein Startargument in Xcode. Beim Testen empfehlen wir diese Schritte:

1. Lösen Sie jedes Event aus dem Messplan einzeln aus.
2. Prüfen Sie Schreibweise sowie Groß und Kleinschreibung jedes Eventnamens.
3. Kontrollieren Sie, dass Parameter die richtigen Werte tragen und nie leer ankommen.
4. Schließen Sie in einer Testumgebung einen Kauf ab und prüfen Sie das Feld transaction_id.
5. Wiederholen Sie denselben Ablauf auf einem Android Gerät und einem iPhone.

Dieselbe Dokumentation weist darauf hin, dass Debugevents standardmäßig im täglichen BigQuery Export landen. Damit Testverkehr nicht in Berichte gelangt, empfehlen wir einen Filter für Entwicklerverkehr in Ihrer Property.

Welche Fehler passieren bei der Eventeinrichtung am häufigsten?

Die meisten Fehler, die wir sehen, entstehen in der Planung und nicht im Code. Die Einrichtung funktioniert, doch die Daten führen zu keiner Entscheidung. Diese Fehler begegnen uns am häufigsten:

• Ein eigener Name, obwohl bereits ein empfohlenes Event existiert.
• Unterschiedliche Namen für dasselbe Event unter Android und iOS.
• Ein eigenes Event für jeden Screen oder Knopf, bis die Grenze erreicht ist.
• Vergessene Registrierung eigener Parameter in der Konsole.
• Ein Kaufevent vor der Zahlungsbestätigung.
• Personenbezogene Daten in Parametern oder in der Nutzerkennung.
• Testverkehr, der sich mit Livedaten mischt.

Die gemeinsame Lösung ist ein schriftlicher Messplan. Ohne ihn benennt jeder Entwickler Events nach eigener Gewohnheit. Nach einigen Releases taucht dieselbe Aktion dann unter drei Namen auf, und historische Daten lassen sich kaum noch zusammenführen.

Ein weiteres häufiges Problem ist die verlorene Kampagnenquelle. Für Links, die Nutzer direkt zum richtigen Screen Ihrer App führen, hilft unser Leitfaden Was ist ein Deep Link, damit die Quelle erhalten bleibt.

Beispielszenario: ein Eventplan für eine Termin App

Stellen Sie sich eine Termin App für ein Kosmetikstudio vor. Die Erfolgsdefinition lautet: ein Nutzer, der in der ersten Woche bucht und im Folgemonat erneut bucht. Daraus ergibt sich der folgende Eventplan. Beispielhaft ist hier nur die Struktur, keine Zahlen oder Ergebnisse.

1. first_open und screen_view: kommen automatisch an.
2. sign_up: empfohlenes Event mit dem Parameter method.
3. search: trägt die Leistungskategorie als Parameter, nie Freitext.
4. slot_view: eigenes Event für die Liste freier Zeitfenster.
5. booking_created: erster Nutzwert und Hauptevent, als Schlüsselereignis markiert.
6. booking_cancel: der Grund stammt aus einer kurzen festen Liste.
7. notification_open: automatisches Event, das die Wirkung von Erinnerungen zeigt.

Mit diesem Plan beantwortet das Team drei Fragen. Wie viele neue Nutzer haben eine Buchung erreicht? Wie oft kamen diese Nutzer zurück? Haben Erinnerungen Stornierungen verringert? Zusammengefasst speisen sieben Events die meisten Produktentscheidungen.

Checkliste zur Messung vor dem Release

Bevor Sie die App bei den Stores einreichen, haken Sie am besten diese Punkte einzeln ab. Die Liste verhindert Datenverluste, die Sie nach dem Release nicht mehr aufholen:

• Der Messplan liegt schriftlich vor, und das ganze Team kennt ihn.
• Empfohlene Events tragen ihre empfohlenen Namen.
• Eigene Eventnamen sind kurz, kleingeschrieben und auf beiden Plattformen identisch.
• Eigene Parameter sind in der Konsole als benutzerdefinierte Definitionen registriert.
• Das Kaufevent enthält transaction_id, value und currency.
• Kein Event enthält E-Mail Adresse, Telefonnummer oder genauen Standort.
• Wichtige Events sind als Schlüsselereignisse markiert.
• Der Test mit DebugView ist auf beiden Plattformen abgeschlossen.
• Ein Filter für Entwicklerverkehr ist aktiv.
• Die Datenschutzangaben im Store passen zum Messplan.

Gehen Sie diese Liste bei jedem größeren Release erneut durch. Denn neue Funktionen bringen meist neue Events und neue Angaben mit sich.

Wer sollte den Messplan gemeinsam mit der App aufbauen?

Am gesündesten ist es, den Messplan mit dem Team aufzubauen, das die App entwickelt. Die Entscheidung, wann ein Event auslöst, hängt direkt am Ablauf im Code. Nachträglich ergänzte Messung endet daher oft mit fehlenden Schritten und Abweichungen zwischen den Plattformen.

Wir bei Talha Aslan und Team decken in unseren Projekten zur App Entwicklung den ganzen Weg ab: Wir entwickeln Ihre App und bringen sie in die Stores. Der Messplan gehört von Anfang an dazu. Wir übersetzen Ihre geschäftlichen Fragen in Events, richten Firebase Analytics ein, testen mit DebugView und bereiten Datenschutzangaben vor, die zum Plan passen.

Haben Sie bereits eine App, gehen wir genauso vor. Zunächst prüfen wir Ihre vorhandenen Events und Namen. Danach schließen wir die Lücken Release für Release. Für den Umfang fordern Sie einfach ein Angebot über unsere Leistungsseite zur App Entwicklung an.