Sitzungen verfolgen

Erfahren Sie, wie Sie Sitzungen über das Braze SDK tracken können.

Hinweis

Für Wrapper-SDKs, die nicht aufgeführt sind, verwenden Sie stattdessen die entsprechende native Android- oder Swift-Methode.

Über den Lebenszyklus einer Sitzung

Eine Sitzung referenziert den Zeitraum, in dem das Braze SDK die Aktivitäten der Nutzer:in Ihrer App nach deren Start verfolgt. Sie können auch eine neue Sitzung erzwingen, indem Sie die Methode changeUser() aufrufen.

• web
• android
• swift

Standardmäßig beginnt eine Sitzung, wenn Sie braze.openSession() zum ersten Mal aufrufen. Die Sitzung bleibt bis zu 30 Minuten der Inaktivität aktiv (es sei denn, Sie ändern den Standard-Timeout für die Sitzung oder der Nutzer:innen schließt die App.

Hinweis

Wenn Sie den Aktivitätslebenszyklus-Callback für Android eingerichtet haben, ruft Braze automatischopenSession() undcloseSession() für jede Aktivität in Ihrer App auf.

Standardmäßig wird eine Sitzung gestartet, wenn openSession() zum ersten Mal aufgerufen wird. Wenn Ihre App in den Hintergrund wechselt und anschließend wieder in den Vordergrund zurückkehrt, überprüft das SDK, ob seit Beginn der Sitzung mehr als 10 Sekunden vergangen sind (es sei denn, Sie ändern die Standard-Sitzungszeitüberschreitung). In diesem Fall wird eine neue Sitzung beginnen. Wenn der Nutzer:innen Ihre App schließt, während sie im Hintergrund läuft, werden die Daten der Sitzung möglicherweise erst dann an Braze gesendet, wenn er die App erneut öffnet.

Wenn Sie closeSession() aufrufen, wird die Sitzung nicht sofort beendet. Stattdessen wird die Sitzung nach 10 Sekunden beendet, wenn openSession() nicht erneut vom Nutzer:innen aufgerufen wird, der eine andere Aktivität startet.

Standardmäßig beginnt eine Sitzung, wenn Sie Braze.init(configuration:) aufrufen. Dies geschieht, wenn die Benachrichtigung UIApplicationWillEnterForegroundNotification getriggert wird, was bedeutet, dass die App in den Vordergrund getreten ist.

Wenn Ihre App in den Hintergrund wechselt,UIApplicationDidEnterBackgroundNotificationwird getriggert. Die App bleibt im Hintergrund nicht in einer aktiven Sitzung. Wenn Ihre App wieder in den Vordergrund rückt, vergleicht das SDK die seit Beginn der Sitzung verstrichene Zeit mit dem Zeitlimit für die Sitzung (es sei denn, Sie ändern das Standard-Zeitlimit für die Sitzung). Wenn die seit Beginn der Sitzung verstrichene Zeit die Zeitüberschreitung überschreitet, wird eine neue Sitzung gestartet.

Definition von Inaktivität

Das Verständnis, wie Inaktivität definiert und gemessen wird, ist entscheidend für die effektive Verwaltung von Sitzungslebenszyklen im Web SDK. Inaktivität bezieht sich auf einen Zeitraum, in dem das Braze Web SDK keine getrackten Events von Nutzer:innen erkennt.

Wie Inaktivität gemessen wird

Das Web SDK trackt Inaktivität basierend auf SDK-getrackten Events. Das SDK führt einen internen Timer, der bei jedem gesendeten getrackten Event zurückgesetzt wird. Wenn innerhalb des konfigurierten Timeout-Zeitraums keine SDK-getrackten Events auftreten, gilt die Sitzung als inaktiv und wird beendet.

Weitere Informationen zur Implementierung des Sitzungslebenszyklus im Web SDK finden Sie im Quellcode zur Sitzungsverwaltung im Braze Web SDK GitHub Repository.

Was standardmäßig als Aktivität zählt:

• Öffnen oder Aktualisieren der Web-App
• Interaktion mit Braze-gesteuerten UI-Elementen (wie In-App-Nachrichten oder Content Cards)
• Aufrufen von SDK-Methoden, die getrackte Events senden (wie angepasste Events oder Aktualisierungen von Nutzerattributen)

Was standardmäßig nicht als Aktivität zählt:

• Wechsel zu einem anderen Browser-Tab
• Minimieren des Browserfensters
• Browser-Fokus- oder Blur-Events
• Scrollen oder Mausbewegungen auf der Seite

Hinweis

Das Web SDK trackt nicht automatisch Änderungen der Browser-Sichtbarkeit, Tab-Wechsel oder Nutzer:innen-Fokus. Sie können diese Browser-Interaktionen jedoch tracken, indem Sie benutzerdefinierte Event-Listener mithilfe der Page Visibility API des Browsers implementieren und angepasste Events an Braze senden. Ein Beispiel für die Implementierung finden Sie unter Tracking benutzerdefinierter Inaktivität.

Konfiguration des Sitzungs-Timeouts

Standardmäßig betrachtet das Web SDK eine Sitzung nach 30 Minuten ohne getrackte Events als inaktiv. Sie können diesen Schwellenwert bei der Initialisierung des SDK mithilfe des Parameters sessionTimeoutInSeconds anpassen. Details zur Konfiguration dieses Parameters, einschließlich Code-Beispielen, finden Sie unter Ändern des Standard-Sitzungs-Timeouts.

Beispiel: Inaktivitätsszenarien verstehen

Betrachten Sie das folgende Szenario:

1. Eine Nutzerin oder ein Nutzer öffnet Ihre Website, und das SDK startet eine Sitzung durch den Aufruf von braze.openSession().
2. Die Person wechselt zu einem anderen Browser-Tab, um 30 Minuten lang eine andere Website zu besuchen.
3. Während dieser Zeit treten keine SDK-getrackten Events auf Ihrer Website auf.
4. Nach 30 Minuten Inaktivität wird die Sitzung automatisch beendet.
5. Wenn die Person zu Ihrem Website-Tab zurückkehrt und ein SDK-Event auslöst (z. B. eine Seite anzeigt oder mit Inhalten interagiert), beginnt eine neue Sitzung.

Tracking benutzerdefinierter Inaktivität

Wenn Sie Inaktivität basierend auf Browser-Sichtbarkeit oder Tab-Wechsel tracken möchten, implementieren Sie benutzerdefinierte Event-Listener in Ihrem JavaScript-Code. Verwenden Sie Browser-Events wie visibilitychange, um zu erkennen, wann Nutzer:innen Ihre Seite verlassen, und senden Sie manuell angepasste Events an Braze oder rufen Sie bei Bedarf braze.openSession() auf.

1
2
3
4
5
6
7
8
9
10
11
// Example: Track when user switches away from tab
document.addEventListener('visibilitychange', function() {
  if (document.hidden) {
    // User switched away - optionally log a custom event
    braze.logCustomEvent('tab_hidden');
  } else {
    // User returned - optionally start a new session and/or log an event
    // braze.openSession();
    braze.logCustomEvent('tab_visible');
  }
});

Weitere Informationen zum Protokollieren angepasster Events finden Sie unter Angepasste Events protokollieren. Details zum Sitzungslebenszyklus und zur Timeout-Konfiguration finden Sie unter Ändern des Standard-Sitzungs-Timeouts.

Updates für Sitzungen abonnieren

Schritt 1: Updates abonnieren

Um Sitzungs-Updates zu abonnieren, verwenden Sie die Methode subscribeToSessionUpdates().

• web
• android
• swift
• react native

1
2
3
4
5
6
7
8
Braze.getInstance(this).subscribeToSessionUpdates(new IEventSubscriber<SessionStateChangedEvent>() {
  @Override
  public void trigger(SessionStateChangedEvent message) {
    if (message.getEventType() == SessionStateChangedEvent.ChangeType.SESSION_STARTED) {
      // A session has just been started
    }
  }
});

1
2
3
4
5
Braze.getInstance(this).subscribeToSessionUpdates { message ->
  if (message.eventType == SessionStateChangedEvent.ChangeType.SESSION_STARTED) {
    // A session has just been started
  }
}

1
2
3
4
5
6
7
8
9
10
11
// This subscription is maintained through a Braze cancellable, which will observe changes until the subscription is cancelled.
// You must keep a strong reference to the cancellable to keep the subscription active.
// The subscription is canceled either when the cancellable is deinitialized or when you call its `.cancel()` method.
let cancellable = AppDelegate.braze?.subscribeToSessionUpdates { event in
  switch event {
  case .started(let id):
    print("Session \(id) has started")
  case .ended(let id):
    print("Session \(id) has ended")
  }
}

1
2
3
4
5
6
7
8
for await event in braze.sessionUpdatesStream {
  switch event {
  case .started(let id):
    print("Session \(id) has started")
  case .ended(let id):
    print("Session \(id) has ended")
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// This subscription is maintained through a Braze cancellable, which will observe changes until the subscription is cancelled.
// You must keep a strong reference to the cancellable to keep the subscription active.
// The subscription is canceled either when the cancellable is deinitialized or when you call its `.cancel()` method.
BRZCancellable *cancellable = [AppDelegate.braze subscribeToSessionUpdates:^(BRZSessionEvent * _Nonnull event) {
  switch (event.state) {
    case BRZSessionStateStarted:
      NSLog(@"Session %@ has started", event.sessionId);
      break;
    case BRZSessionStateEnded:
      NSLog(@"Session %@ has ended", event.sessionId);
      break;
    default:
      break;
  }
}];

Schritt 2: Sitzungs-Tracking testen (optional)

Um das Sitzungs-Tracking zu testen, starten Sie eine Sitzung auf Ihrem Gerät und öffnen Sie dann das Braze-Dashboard und suchen Sie nach der entsprechenden Nutzer:in. Wählen Sie in ihrem Kundenprofil Sessions Overview aus. Wenn die Metriken wie erwartet aktualisiert werden, funktioniert das Sitzungs-Tracking korrekt.

Hinweis

App-spezifische Details werden nur für Nutzer:innen angezeigt, die mehr als eine App verwendet haben.

Ändern des Standard-Sitzungs-Timeouts

Sie können die Zeitspanne ändern, die vergeht, bevor eine Sitzung automatisch beendet wird.

• web
• android
• swift
• react native

1
2
// Sets the session timeout to 15 minutes instead of the default 30
braze.initialize('YOUR-API-KEY-HERE', { sessionTimeoutInSeconds: 900 });

1
2
<!-- Sets the session timeout to 60 seconds. -->
<integer name="com_braze_session_timeout">60</integer>

1
2
3
4
5
6
7
8
// Sets the session timeout to 60 seconds
let configuration = Braze.Configuration(
  apiKey: "<BRAZE_API_KEY>",
  endpoint: "<BRAZE_ENDPOINT>"
)
configuration.sessionTimeout = 60;
let braze = Braze(configuration: configuration)
AppDelegate.braze = braze

1
2
3
4
5
6
7
// Sets the session timeout to 60 seconds
BRZConfiguration *configuration =
  [[BRZConfiguration alloc] initWithApiKey:brazeApiKey
                                  endpoint:brazeEndpoint];
configuration.sessionTimeout = 60;
Braze *braze = [[Braze alloc] initWithConfiguration:configuration];
AppDelegate.braze = braze;

Hinweis

Wenn Sie ein Sitzungs-Timeout festlegen, werden alle Sitzungssemantiken automatisch auf das festgelegte Timeout erweitert.

Fehlerbehebung

Kundenprofil zeigt 0 Sitzungen

Ein Kundenprofil kann 0 Sitzungen aufweisen, wenn die Nutzer:innen außerhalb des SDK erstellt wurden:

• Erstellt über die REST API: Wenn Nutzer:innen über den Endpunkt /users/track mit einer app_id in der Anfrage erstellt werden, erscheint das Profil zwar mit dieser App verknüpft, enthält aber keine Sitzungsdaten, da das SDK für diese Nutzer:innen nie initialisiert wurde.
• Erstellt per CSV-Import: Wenn Nutzer:innen über CSV importiert werden, ohne Werte für die Felder „Erste Sitzung“ oder „Letzte Sitzung“ anzugeben, existiert das Profil mit 0 Sitzungen.

Einige Nutzer:innen protokollieren keine Sitzungen

Da Sitzungen erst nach der Initialisierung des SDK erfasst werden, protokollieren Nutzer:innen, die keine SDK-Initialisierung auslösen, keine Sitzungen. Dies geschieht typischerweise, wenn Ihre App bedingte Logik vor der Initialisierung des SDK verwendet – beispielsweise eine verzögerte Initialisierung hinter einem Anmeldeablauf, einer Einwilligungsabfrage oder einem Feature-Flag. Hinweise zur Implementierung finden Sie unter Verzögerte Initialisierung. In diesen Fällen startet keine Sitzung für Nutzer:innen, die die Bedingung nicht erfüllen.

Wenn einige Nutzer:innen Sitzungen protokollieren und andere nicht, überprüfen Sie Folgendes:

• Prüfen Sie Ihre Initialisierungslogik. Stellen Sie sicher, dass das SDK für alle Nutzer:innen und App-Einstiegspunkte initialisiert wird, nicht nur für einige.
• Achten Sie auf aktuelle App-Änderungen. Neue bedingte Logik rund um die SDK-Initialisierung kann einen plötzlichen Rückgang der Sitzungszahlen verursachen.
• Vergleichen Sie betroffene und nicht betroffene Nutzer:innen. Identifizieren Sie Unterschiede bei App-Version, Gerätetyp oder Nutzerablauf, die erklären könnten, warum die Initialisierung bei bestimmten Nutzer:innen übersprungen wird.

Wenn das Problem nach Überprüfung Ihrer Implementierung weiterhin besteht, reproduzieren Sie das Problem und sammeln Sie die folgenden Informationen, bevor Sie den Support kontaktieren:

• Schritte zur Reproduktion des Problems
• Die betroffene App-Version
• Ausführliche SDK-Logs, die während des Auftretens des Problems aufgezeichnet wurden (oder nach Plattform: Android, Swift, Web)
• Das Code-Snippet für die SDK-Initialisierung
• Eine Zusammenfassung der bedingten Logik, die vor der Initialisierung angewendet wird