Skip to content

Digital Analytics Blog

von Marcus Stade

Menu
Menu
firebase-debugview-overview

Firebase Analytics: Exploration der automatisch erfassten Events screen_view und session_start im DebugView

Posted on 28. Dezember 201929. Dezember 2020 by mstade

Im ersten Teil der Firebase Analytics Serie “ Firebase Analytics: Firebase Analytics in eine App integrieren “ wurden die Grundlagen zur Integration in eine App behandelt. Als Resultat der Integration wurden erste automatisch erfasste Events gesendet. Ohne weitere Änderungen am Quellcode der App werden eine Vielzahl von automatisch erfassten Events erfasst. In zweiten Teil dieser Firebase Analytics Serie wird ein detaillierter Blick auf einige dieser Events im DebugView geworfen.

Zuerst machen wir uns mit den automatisch erfassten Events vertraut. Eine Übersicht findet sich in der Firebase Hilfe. Hier werfen wir einen Blick auf die Events session_start und screen_view.

Um die Events, die von unserer App gesendet werden, zu analysieren, wird der DebugView verwendet. Im DebugView werden die einzelnen Events von Apps im Debug Modus mit geringer Verzögerung angezeigt. Wird der Debug Modus nicht verwendet, werden die Tracking-Daten für zirka eine Stunde in der App gespeichert und dann zeitverzögert gesammelt versendet.

Firebase Analytics Debug Modus aktivieren

Das Android Software Development Kit beinhaltet das Tool Android-Debug-Bridge, kurz adb, und ist ein Teil der platform-tools. Die Tools befinden sich im Android SDK Unterverzeichnis /platform-tools/. In Android Studio wird die Terminal-Funktion genutzt, um in das Verzeichnis zu wechseln.

android-studio-terminal-platform-tools
Terminal in Android Studio mit Wechsel zu den platform-tools

Der Debug Modus kann dann direkt im Terminal unter Angabe des Package-Namens aktiviert werden:

adb shell setprop debug.firebase.analytics.app com.example.introapp

Sollte die folgende Fehlermeldung auftreten, steht kein Device für den Debug Modus zur Verfügung.

Fehlermeldung von adb, falls kein Device zur Verfügung steht

In diesem Fall kann die App im virtuellen Android Studio Device gestartet werden. Danach sollte ein Device verfügbar sein. Das kann durch

adb device

geprüft werden. Wird keine Meldung ausgegeben, kann der Debug Modus getestet werden.

android-studio-adb-debugview-device

Um den Debug Modus zu beenden, kann

adb shell setprop debug.firebase.analytics.app .none.

in das Terminal eingegeben werden. Im folgenden nutzen wir den Debug Modus weiter.

DebugView in Firebase Analytics

Der DebugView in Firebase Analytics zeigt nur die Events aus der App an, die über den Debug Modus gesendet wurden. Die Verzögerung, in der gesendete Events dort angezeigt werden, kann durchaus einige Minuten betragen. Es kann also beim Testen ein wenig Geduld gefragt sein.

Starten wir nun die IntroApp in Android Studio und wechseln in den DebugView.

Nach einiger Zeit erscheinen dort die einzelnen Events. Mit der IntroApp sollten das session_start und screen_view Event auftauchen. Wird die App das erste mal gestartet, erscheint auch das first_open Event.

firebase-debugview
Firebase Analytics DebugView mit eingehenden Events

Beim Klick auf das Event in der Timeline erscheinen die Event-Parameter und User-Properties. Event-Parameter sind an das Event gebundene zusätzlich mitgesendete Informationen, beispielsweise firebase_event_origin, dessen Wert angibt, ob ein Event automatisch oder benutzerdefiniert erfasst wird.

firebase-debugview-events
Automatisch erfasste Event Parameter des session_start Events

User-Properties sind hingegen Informationen, die an den Nutzer gebunden wurden. Automatisch wird die Information first_open_time erfasst und steht in Verbindung mit allen danach erfassten Events zu Verfügung. Event-Parameter und User-Properties werden in nachfolgenden Teilen dieser Artikelserie behandelt.

firebase-debugview-events-up
Automatisch erfasste User-Properties des session_start Events

Das session_start Event

Betrachten wir die Logik des session_start Event näher, denn hierfür können nicht einfach die aus Google Analytics bekannten Defintionen verwendet werden. Der Start einer neuen Session erfolgt, wenn nach einer bestimmten Zeit die App über die Mindestdauer hinaus genutzt wird. Standardmäßig wird eine Zeitdifferenz von 30 Minuten angesetzt, nachdem sich die App nicht mehr im Vordergrund befindet. Danach muss sich die App für mindestens 10 Sekunden im Vordergrund genutzt werden, damit eine neue Sitzung gestartet wird. Diese Zeitangaben können jedoch im Quellcode angepasst werden. Ebenso kann im Quellcode die Aufrechterhaltung der Session bei Nutzung der App im Hintergrund eingestellt werden.

Mit dem session_start Event werden für die Analyse wichtige Parameter wie die ga_session_id, ein pro Nutzer eindeutiger Wert, und die ga_session_number, die Nummer der aktuellen Session, gesendet. Diese sind auch in anderen Events wie screen_view vorhanden und ermöglichen eine Verknüpfung der Events.

firebase-debugview-events
Automatisch erfasste Event Parameter des session_start Events

Das screen_view Event und screen_name erfassen

Das screen_view Event ist das Äquivalent zu Pageview in Google Analytics. Wird ein neuer Bildschirm erkannt, wird das Event automatich an Firebase Analytics gesendet. Ein neuer Bildschirm in der App wird erkannt durch eine neue Bildschirm-ID (firebase_screen_id), Bildschirm-Klasse (firebase_screen_class) , beide werden automatisch erfasst, oder nach Integration in dem Quellcode durch einen neuen Bildschirmname (firebase_screen) .

firebase-debugview-screen_view_events
Automatisch erfasste Event Parameter des screen_view Events

Die Bildschirm-Klasse entspricht dem Klassenname im Quellcode der App.

firebase-debugview-screen_view_events_class
firebase_screen_class entspricht der Benennung der Activity im Quellcode (hier MainActivity)

Das ist für eine Auswertung nicht der sinnvollste Workflow, da die Benennung der Klassen den Analysten eventuell nicht bekannt sind. Um den Bildschirm zu benennen, muss dies im Quellcode angepasst werden, indem in der Activity zuerst Firebase per

import com.google.firebase.analytics.FirebaseAnalytics

hinzugefügt und dann das Firebase Object initialisiert wird mit:

private lateinit var firebaseAnalytics: FirebaseAnalytics

Damit ist das Objekt verfügbar und kann über

firebaseAnalytics = FirebaseAnalytics.getInstance(this)

im oncreate genutzt werden.

firebase-debugview-screen_view_events_name_kt
Hinzufügen des Codes zum Quellcode

Soll nun ein neuer Bildschirm erfasst werden, kann dies mit

firebaseAnalytics.setCurrentScreen(this, Screenname, null)

erfolgen. Screenname wird dabei durch den Namen des Bildschirms ersetzt. Soll sich auch die Klasse des Bildschirms ändern, kann dies statt null eingefügt werden.

Die App soll nun so geändert werden, dass ein gesonderter Bildschirm getrackt wird, wenn die App nicht mehr sichtbar ist. Dazu wird die folgende Methode zu MainActivity.kt hinzugefügt:

public override fun onStop() {
    super.onResume()
    firebaseAnalytics.setCurrentScreen(this, "NotVisibleScreen", null)
}

onStop() ist der Licecycle Teil einer Android App, der anzeigt, das die App für den User nicht mehr sichtbar ist.

firebase-debugview-screen_view_events_name_onstop
Hinzufügen des Codes für den Screenname bei einem onstop-Events

Nachdem der Code ergänzt wurde, kann die App wieder in Android Studio gestartet werden. Nachdem der erste screen_view getrackt wurde, wird im Virtual Device die App in den Hintergrund verschoben. Danach erscheint in Firebase Analytics der zweite screen_view mit dem zusätzlichen Parameter „firebase_screen“ der den Wert „NotVisibleScreen“ enthält.

firebase-screenname
Test der App mit den screen_view Event und dem Bildschirmname „NotVisibleScreen“

Nach diesem Beispiel für automatisierte Events, greife ich im nächsten Teil der Firebase Analytics Artikelserie die vordefinierten Events auf.

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Keep in Touch

Supporter: InPignus GmbH

ImPignus

mohrstade

mohrstade.de

Analytics Pioneers

Schlagwörter

App+Web App-Tracking Basic Big Query Customer Data Platform DataQuality DataStudio Events Google Analytics für Firebase ITP Machine Learning Property PWA Quick-Tipp User-Journey Wordpress Überblick

Podcast Empfehlung:

beyond pageview

Neueste Beiträge

  • Tag Management Platform: Commanders Act Platform X – DataCollection (Teil 2)
  • Tag Management Platform: Übersicht (Teil 1)
  • IP und User Agent Identifier: Nachteile
  • GA4 Recipes: Machine Learning Features für Predictive Audiences in anderen Tools nutzen, am Beispiel von Tealium AudienceStream
  • Quick Tipp: GA4 Configuration Tag vs. Universal Analytics Setting Variable – Sequence matters

Kategorien

  • Allgemein
  • Cloud
  • Dashboard
  • Firebase Analytics
  • Google Analytics
  • Google Analytics 4 (App+Web)
  • Google Optimize
  • Google Tag Manager
  • Machine Learning
  • Matomo
  • Tag Management

Links

  • Datenschutzerklärung
  • Hear Me Speak
  • Impressum
  • Meet & Eat
  • Über den Blog
©2023 Digital Analytics Blog | Built using WordPress and Responsive Blogily theme by Superb