App Center Analytics (Android)
App Center Analytics hilft Ihnen dabei, das Benutzerverhalten und die Kundenbindung zu verstehen, um Ihre App zu verbessern. Das SDK erfasst automatisch die Sitzungsanzahl und Geräteeigenschaften wie Modell, Betriebssystemversion usw. Sie können Ihre eigenen benutzerdefinierten Ereignisse definieren, um Dinge zu messen, die für Sie wichtig sind. Alle erfassten Informationen sind im App Center-Portal verfügbar, damit Sie die Daten analysieren können.
Befolgen Sie den Abschnitt Erste Schritte mit dem SDK, wenn Sie das SDK noch nicht in Ihrer Anwendung eingerichtet haben.
Sitzungs- und Geräteinformationen
Nachdem Sie Ihrer App App Center Analytics hinzugefügt und das SDK gestartet haben, werden Automatisch Sitzungen und Geräteeigenschaften wie Betriebssystemversion, Modell usw. nachverfolgt, ohne zusätzlichen Code zu schreiben.
Landesvorwahl
Das SDK meldet automatisch die Landesvorwahl eines Benutzers, wenn auf dem Gerät ein mobiles Datenmodem und eine SIM-Karte installiert sind. Nur WLAN-Geräte melden standardmäßig keine Ländervorwahl. Um den Ländercode dieser Benutzer festzulegen, müssen Sie den Standort Ihres Benutzers selbst abrufen und die setCountryCode:
-Methode im SDK verwenden:
AppCenter.setCountryCode("en");
AppCenter.setCountryCode("en")
Hinweis
Damit die Landeskennzahl in Analytics-Sitzungen angezeigt werden kann, AppCenter.setCountryCode
muss vor dem Aufrufen AppCenter.start
von aufgerufen werden.
Benutzerdefinierte Ereignisse
Sie können Ihre eigenen benutzerdefinierten Ereignisse mit bis zu 20 Eigenschaften nachverfolgen, um die Interaktion zwischen Ihren Benutzern und der App zu verstehen.
Nachdem Sie das SDK gestartet haben, verwenden Sie die trackEvent()
-Methode, um Ihre Ereignisse mit Eigenschaften nachzuverfolgen. Sie können bis zu 200 verschiedene Ereignisnamen senden. Außerdem gibt es maximale Zeichengrenzwerte:
- 256 Zeichen pro
event name
. - 125 Zeichen pro
event property name
&event property value
.
Map<String, String> properties = new HashMap<>();
properties.put("Category", "Music");
properties.put("FileName", "favorite.avi");
Analytics.trackEvent("Video clicked", properties);
val properties = hashMapOf("Category" to "Music", "FileName" to "favorite.avi")
Analytics.trackEvent("Video clicked", properties)
Eigenschaften für Ereignisse sind völlig optional. Wenn Sie nur ein Ereignis nachverfolgen möchten, verwenden Sie stattdessen dieses Beispiel:
Analytics.trackEvent("Video clicked");
Analytics.trackEvent("Video clicked")
Ereignispriorität und Persistenz
Sie können unternehmenskritische Ereignisse nachverfolgen, die eine höhere Bedeutung haben als andere Ereignisse.
- Entwickler können die Priorität von Ereignissen als Normal (
Flags.NORMAL
in der API) oder Kritisch (Flags.CRITICAL
in der API) festlegen. - Ereignisse, deren Priorität als Kritisch festgelegt ist, werden zuerst aus dem Speicher abgerufen und vor normalen Ereignissen gesendet.
- Wenn der lokale Speicher voll ist und neue Ereignisse gespeichert werden müssen, werden zuerst die ältesten Ereignisse mit der niedrigsten Priorität gelöscht.
- Wenn der Speicher voll mit Protokollen mit kritischer Priorität ist, schlägt die Nachverfolgung eines Ereignisses mit normaler Priorität fehl, da das SDK in diesem Fall keinen Platz schaffen kann.
- Wenn Sie auch den Absturzdienst verwenden, werden Absturzprotokolle als Kritisch festgelegt und verwenden denselben Speicher wie Ereignisse.
- Das Übertragungsintervall wird nur auf normale Ereignisse angewendet, kritische Ereignisse werden nach 3 Sekunden gesendet.
Sie können die folgende API verwenden, um ein Ereignis als kritisch nachzuverfolgen:
Map<String, String> properties = new HashMap<>();
properties.put("Category", "Music");
properties.put("FileName", "favorite.avi");
Analytics.trackEvent("eventName", properties, Flags.CRITICAL);
// If you're using name only, you can pass null as properties.
val properties = hashMapOf("Category" to "Music", "FileName" to "favorite.avi")
Analytics.trackEvent("Video clicked", properties, Flags.CRITICAL)
// If you're using name only, you can pass null as properties.
Anhalten und Fortsetzen des Sendens von Protokollen
Das Anhalten der Ereignisübertragung kann in Szenarien nützlich sein, in dem die App die Netzwerkbandbreite für geschäftskritischere Anforderungen steuern muss. Sie können das Senden von Protokollen an das App Center-Back-End anhalten. Wenn sie angehalten sind, können Ereignisse weiterhin nachverfolgt und gespeichert werden, aber sie werden nicht sofort gesendet. Alle Ereignisse, die Ihre App während des Anhaltens nachverfolgt, werden erst gesendet, wenn Sie aufrufen resume
.
Analytics.pause();
Analytics.resume();
Analytics.pause()
Analytics.resume()
Aktivieren oder Deaktivieren von App Center Analytics zur Laufzeit
Sie können App Center Analytics zur Laufzeit aktivieren und deaktivieren. Wenn Sie sie deaktivieren, erfasst das SDK keine weiteren Analyseinformationen für die App.
Analytics.setEnabled(false);
Analytics.setEnabled(false)
Um App Center Analytics erneut zu aktivieren, verwenden Sie dieselbe API, übergeben true
Sie jedoch als Parameter.
Analytics.setEnabled(true);
Analytics.setEnabled(true)
Der Zustand wird über Anwendungsstarts hinweg im Speicher des Geräts beibehalten.
Diese API ist asynchron. Weitere Informationen hierzu finden Sie in unserem App Center-Handbuch Für asynchrone APIs .
Hinweis
Diese Methode darf erst nach dem Analytics
Start verwendet werden.
Überprüfen, ob App Center Analytics aktiviert ist
Sie können auch überprüfen, ob App Center Analytics aktiviert ist.
Analytics.isEnabled();
Analytics.isEnabled()
Diese API ist asynchron. Weitere Informationen hierzu finden Sie in unserem App Center-Handbuch Für asynchrone APIs .
Hinweis
Diese Methode darf nur verwendet werden, nachdem Analytics
gestartet wurde. Sie wird immer vor dem Start zurückgegeben false
.
Verwalten der Startsitzung
Standardmäßig hängt die Sitzungs-ID vom Lebenszyklus der Anwendung ab. Wenn Sie den Start einer neuen Sitzung manuell steuern möchten, führen Sie die nächsten Schritte aus:
Hinweis
Achten Sie darauf, dass jeder Aufruf der Analytics.StartSession() -API eine neue Sitzung generiert. Wenn diese API im manuellen Sitzungsnachverfolgungsmodus nicht aufgerufen wird, haben alle sendenden Protokolle einen SITZUNGS-NULL-Wert.
Hinweis
Achten Sie darauf, dass nach dem Starten einer neuen Anwendung die Sitzungs-ID neu generiert wird.
- Rufen Sie die folgende Methode auf, bevor das SDK gestartet wird:
Analytics.enableManualSessionTracker();
Analytics.enableManualSessionTracker()
- Anschließend können Sie die
startSession
API nach verwendenAppCenter.start
:
Analytics.startSession();
Analytics.startSession()
Größe des lokalen Speichers
Standardmäßig speichert das SDK alle Ereignisprotokolle bis zu 10 MB. Entwickler können eine API verwenden, um die Speichergröße zu erhöhen, und das SDK speichert Protokolle, bis der Speicher voll ist.
Kein Internetzugriff
Wenn keine Netzwerkkonnektivität besteht, speichert das SDK bis zu 10 MB An Protokollen im lokalen Speicher. Sobald der Speicher voll ist, beginnt das SDK, alte Protokolle zu verwerfen, um Platz für die neuen Protokolle zu schaffen. Sobald die Netzwerkkonnektivität zurückgegeben wird, sendet das SDK Protokolle im Batch von 50 oder nach 6 Sekunden (standardmäßig).
Hinweis
Protokolle, die älter als 25 Tage sind, werden vom Back-End nicht akzeptiert.
Batchverarbeitung von Ereignisprotokollen
Das App Center SDK lädt Protokolle in einem Batch von 50 hoch, und wenn das SDK nicht über 50 zu sendende Protokolle verfügt, sendet es weiterhin Protokolle nach 6 Sekunden (standardmäßig). Es können maximal drei Batches parallel gesendet werden. Das Übertragungsintervall kann geändert werden:
// Change transmission interval to 10 seconds.
Analytics.setTransmissionInterval(10000);
// Change transmission interval to 10 seconds.
Analytics.setTransmissionInterval(10000)
Der Wert des Übertragungsintervalls muss zwischen 6 Sekunden und 86400 Sekunden (einen Tag) betragen, und diese Methode muss aufgerufen werden, bevor der Dienst gestartet wird.
Wiederholungs- und Backofflogik
Das App Center SDK unterstützt Back-Off-Wiederholungsversuche bei wiederherstellbaren Netzwerkfehlern. Im Folgenden finden Sie die Wiederholungslogik:
- Maximal 3 Versuche pro Anforderung.
- Jede Anforderung verfügt über einen eigenen Wiederholungszustandscomputer.
- Alle Übertragungskanäle werden deaktiviert (bis zum nächsten App-Prozess), nachdem eine Anforderung alle Wiederholungsversuche aufgebraucht hat.
Back-off-Logik
- 50 %-Randomisierung, erster Wiederholungsversuch zwischen 5 und 10 Sekunden, nächster Versuch zwischen 2,5 und 5 Minuten, letzter Versuch zwischen 10 und 20 Minuten.
- Wenn das Netzwerk von aus zu ein (oder von WLAN auf Mobil) wechselt, werden die Wiederholungszustände zurückgesetzt, und Anforderungen werden sofort wiederholt.