Best Practices für eindeutige Kennzeichnungen

Dieses Dokument enthält eine Anleitung zur Auswahl geeigneter IDs für Ihre Anwendung basierend auf Ihrem Anwendungsfall.

Allgemeine Informationen zu Android-Berechtigungen finden Sie in der Berechtigungsübersicht. Spezielle Best Practices für die Arbeit mit Android-Berechtigungen findest du unter Best Practices für App-Berechtigungen.

Best Practices für die Arbeit mit Android-IDs

Um die Daten Ihrer Nutzer zu schützen, verwenden Sie die restriktivste Kennung, die dem Anwendungsfall Ihrer App entspricht. Beachten Sie insbesondere die folgenden Best Practices:

  1. Verwenden Sie nach Möglichkeit vom Nutzer zurücksetzbare Kennungen. Ihre Anwendung kann die meisten Anwendungsfälle auch dann erfüllen, wenn sie andere Kennungen als nicht rücksetzbare Hardware-IDs verwendet.

  2. Vermeiden Sie die Verwendung von Hardware-IDs. In den meisten Anwendungsfällen können Sie die Verwendung von Hardwarekennungen wie International Mobile Equipment Identity (IMEI) vermeiden, ohne die erforderliche Funktionalität einzuschränken.

    Unter Android 10 (API-Level 29) gelten Einschränkungen für nicht rücksetzbare Kennungen, die sowohl die IMEI als auch die Seriennummer umfassen. Deine App muss eine App des Eigentümers von Geräten oder Profilen sein, spezielle Mobilfunkanbieterberechtigungen haben oder die privilegierte READ_PRIVILEGED_PHONE_STATE-Berechtigung haben, um auf diese IDs zugreifen zu können.

  3. Verwenden Sie eine Werbe-ID nur für die Erstellung von Nutzerprofilen oder für Anwendungsfälle mit Anzeigen. Wenn Sie eine Werbe-ID verwenden, respektieren Sie immer die Einstellungen des Nutzers bezüglich des Anzeigen-Trackings. Wenn Sie die Werbe-ID mit personenidentifizierbaren Informationen verknüpfen müssen, ist dies nur mit der ausdrücklichen Einwilligung des Nutzers zulässig.

  4. Rücksetzen der Werbe-ID nicht überbrückt

  5. Verwenden Sie nach Möglichkeit für alle anderen Anwendungsfälle eine Firebase-Installations-ID (FID) oder eine privat gespeicherte GUID. Hiervon ausgenommen sind Zahlungsbetrugsprävention und Telefonie. Für die meisten Anwendungsfälle, bei denen es sich nicht um Anzeigen handelt, sollte eine FID oder GUID ausreichen.

  6. Verwenden Sie geeignete APIs für Ihren Anwendungsfall, um das Datenschutzrisiko zu minimieren. Verwenden Sie die DRM API für den Schutz hochwertiger Inhalte und die Play Integrity APIs zum Schutz vor Missbrauch. Mit den Play Integrity APIs lässt sich am einfachsten feststellen, ob ein Gerät echt ist, ohne dass Datenschutzrisiken entstehen.

In den verbleibenden Abschnitten dieses Leitfadens werden diese Regeln im Kontext der Entwicklung von Android-Apps näher erläutert.

Werbe-IDs verwenden

Die Werbe-ID ist eine vom Nutzer zurücksetzbare Kennung und eignet sich für Anzeigen. Wenn Sie diese ID verwenden, sind jedoch einige wichtige Punkte zu beachten:

Berücksichtigen Sie beim Zurücksetzen der Werbe-ID immer die Absicht des Nutzers. Überbrücken Sie das Zurücksetzen durch den Nutzer nicht, indem Sie eine andere Kennung oder einen anderen Fingerabdruck verwenden, um nachfolgende Werbe-IDs ohne Zustimmung des Nutzers zu verknüpfen. In den Google Play-Inhaltsrichtlinien für Entwickler ist Folgendes festgelegt:

Nach dem Zurücksetzen darf eine neue Werbe-ID ohne ausdrückliche Zustimmung des Nutzers nicht mit einer vorherigen Werbe-ID oder mit Daten verknüpft werden, die aus einer früheren Werbe-ID stammen.

Beachten Sie immer die zugehörige Kennzeichnung für personalisierte Anzeigen. Werbe-IDs lassen sich so konfigurieren, dass Nutzer das mit der ID verknüpfte Tracking-Umfang einschränken können. Verwenden Sie immer die Methode AdvertisingIdClient.Info.isLimitAdTrackingEnabled(), um die Wünsche Ihrer Nutzer nicht zu umgehen. In der Google Play-Inhaltsrichtlinien für Entwickler ist Folgendes festgelegt:

„...müssen Sie die vom Nutzer gewählte Einstellung zur Deaktivierung interessenbezogener bzw. personalisierter Werbung respektieren. Wenn ein Nutzer diese Einstellung aktiviert hat, dürfen Sie die Werbe-ID nicht zum Erstellen von Nutzerprofilen zu Werbezwecken oder zur Bereitstellung personalisierter Werbung verwenden. Zulässig sind Aktivitäten wie kontextbezogene Werbung, Frequency Capping, Conversion-Tracking, Berichterstellung sowie Sicherheit und Betrugserkennung.“

Beachten Sie die Datenschutz- und Sicherheitsrichtlinien für SDKs, die sich auf die Verwendung von Werbe-IDs beziehen. Wenn Sie beispielsweise true aus dem Google Analytics SDK an die Methode enableAdvertisingIdCollection() übergeben, müssen Sie alle anwendbaren Analytics SDK-Richtlinien lesen und einhalten.

Außerdem ist zu beachten, dass gemäß den Google Play-Inhaltsrichtlinien für Entwickler die Werbe-ID „nicht mit personenidentifizierbaren Informationen verknüpft oder mit gleichbleibenden Geräte-IDs wie SSAID, MAC-Adresse oder IMEI verknüpft sein darf“.

Angenommen, Sie möchten Informationen erfassen, um Datenbanktabellen mit den folgenden Spalten zu füllen:

TABELLE-01
timestamp ad_id account_id clickid
TABELLE-02
account_id name dob country

In diesem Beispiel könnte die Spalte ad_id über die Spalte account_id in beiden Tabellen mit personenidentifizierbaren Informationen verknüpft werden. Dies wäre ein Verstoß gegen die Google Play-Inhaltsrichtlinien für Entwickler, wenn du keine explizite Genehmigung von deinen Nutzern erhältst.

Verknüpfungen zwischen Werbetreibenden-ID und personenidentifizierbaren Informationen sind nicht immer explizit. Es kann vorkommen, dass in Tabellen mit personenidentifizierbaren Informationen und in Tabellen mit Anzeigen-IDs sogenannte Quasi-Identifikatoren vorkommen. Das kann ebenfalls zu Problemen führen. Angenommen, wir ändern TABLE-01 und TABLE-02 wie folgt:

TABELLE-01
timestamp ad_id clickid dev_model
TABELLE-02
timestamp demo account_id dev_model name

Bei ausreichend seltenen Klickereignissen ist es in diesem Fall dennoch möglich, die Werbetreibenden-ID TABLE-01 und die in TABLE-02 enthaltenen personenidentifizierbaren Informationen mithilfe des Zeitstempels des Ereignisses und des Gerätemodells zusammenzuführen.

Obwohl es oft schwierig ist, zu gewährleisten, dass keine solchen Quasi-Identifikatoren in einem Dataset vorhanden sind, können Sie die offensichtlichsten Join-Risiken verhindern, indem Sie nach Möglichkeit eindeutige Daten verallgemeinern. Im vorherigen Beispiel würde dies bedeuten, dass die Genauigkeit des Zeitstempels verringert wird, sodass mehrere Geräte mit demselben Modell für jeden Zeitstempel angezeigt werden.

Weitere Lösungen:

  • Erstellen Sie keine Tabellen, in denen personenidentifizierbare Informationen ausdrücklich mit Werbe-IDs verknüpft sind. Im ersten Beispiel oben würde dies bedeuten, dass die Spalte account_id nicht in TABLE-01 aufgenommen wird.

  • Zugriffssteuerungslisten für Nutzer oder Rollen mit Zugriff auf Werbe-ID-Daten und personenidentifizierbare Informationen trennen und überwachen Indem Sie die Möglichkeit des gleichzeitigen Zugriffs auf beide Quellen (z. B. durch einen JOIN zwischen Tabellen) genau kontrollieren und prüfen, verringern Sie das Risiko einer Verknüpfung zwischen der Werbe-ID und personenidentifizierbaren Informationen. Im Allgemeinen umfasst die Zugriffssteuerung Folgendes:

    1. Die Access Control Lists (ACLs) für Daten mit Werbetreibenden-IDs und personenidentifizierbare Informationen sollten getrennt sein, um die Anzahl der Personen oder Rollen, die in beiden ACLs enthalten sind, zu minimieren.
    2. Implementieren Sie Zugriffs-Logging und -Prüfungen, um Ausnahmen von dieser Regel zu erkennen und zu verwalten.

Weitere Informationen zur verantwortungsvollen Verwendung von Werbe-IDs finden Sie in der AdvertisingIdClient API-Referenz.

Mit FIDs und GUIDs arbeiten

Die einfachste Lösung zum Identifizieren einer App-Instanz, die auf einem Gerät ausgeführt wird, ist die Verwendung einer Firebase-Installations-ID (FID). Dies ist die empfohlene Lösung für die meisten Anwendungsfälle, die keine Anzeigen sind. Nur die Anwendungsinstanz, für die sie bereitgestellt wurde, kann auf diese ID zugreifen. Sie kann (relativ) einfach zurückgesetzt werden, da sie nur so lange bestehen bleibt, wie die Anwendung installiert ist.

Daher bieten FIDs im Vergleich zu nicht rücksetzbaren Hardware-IDs auf Geräteebene bessere Datenschutzeigenschaften. Weitere Informationen finden Sie in der API-Referenz firebase.installations.

Falls eine FID nicht praktikabel ist, können Sie auch benutzerdefinierte global eindeutige IDs (GUIDs) verwenden, um eine Anwendungsinstanz eindeutig zu identifizieren. Am einfachsten ist es, wenn Sie mit dem folgenden Code eine eigene GUID generieren:

Kotlin

var uniqueID = UUID.randomUUID().toString()

Java

String uniqueID = UUID.randomUUID().toString();

Da die Kennung global eindeutig ist, kann sie zur Identifizierung einer bestimmten Anwendungsinstanz verwendet werden. Speichern Sie GUIDs im internen Speicher statt im externen (freigegebenen) Speicher, um Bedenken im Zusammenhang mit der anwendungsübergreifenden Verknüpfung der ID zu vermeiden. Weitere Informationen finden Sie auf der Seite Übersicht über Daten- und Dateispeicher.

Nicht mit MAC-Adressen funktionieren

MAC-Adressen sind nach dem Zurücksetzen auf die Werkseinstellungen global eindeutig und können nicht vom Nutzer zurückgesetzt werden. Aus diesen Gründen ist der Zugriff auf MAC-Adressen unter Android 6 und höher aus Datenschutzgründen auf System-Apps beschränkt. Drittanbieter-Apps können nicht darauf zugreifen.

Änderungen der Verfügbarkeit von MAC-Adressen unter Android 11

Bei Apps, die auf Android 11 und höher ausgerichtet sind, erfolgt die MAC-Randomisierung für Passpoint-Netzwerke pro Passpoint-Profil. Dabei wird anhand der folgenden Felder eine eindeutige MAC-Adresse generiert:

  • Voll qualifizierter Domainname (FQDN)
  • Bereich
  • Anmeldedaten, basierend auf den im Passpoint-Profil verwendeten Anmeldedaten:
    • Nutzeranmeldedaten: Nutzername
    • Anmeldedaten für das Zertifikat: Zertifikat und Zertifikatstyp
    • SIM-Anmeldedaten: EAP-Typ und IMSI

Außerdem können nicht privilegierte Apps nicht auf die MAC-Adresse des Geräts zugreifen. Nur Netzwerkschnittstellen mit einer IP-Adresse sind sichtbar. Dies wirkt sich auf die Methoden getifaddrs() und NetworkInterface.getHardwareAddress() aus und das Senden von RTM_GETLINK-Netlink-Nachrichten.

Im Folgenden finden Sie eine Liste der Fälle, in denen Apps von dieser Änderung betroffen sind:

  • NetworkInterface.getHardwareAddress() gibt für jede Schnittstelle null zurück.
  • Apps können die Funktion bind() nicht auf NETLINK_ROUTE-Sockets verwenden.
  • Der Befehl ip gibt keine Informationen über Schnittstellen zurück.
  • Apps können keine RTM_GETLINK-Nachrichten senden.

Die meisten Entwickler sollten die übergeordneten APIs von ConnectivityManager anstelle von untergeordneten APIs wie NetworkInterface, getifaddrs() oder Netlink-Sockets verwenden. Beispielsweise kann eine Anwendung, die aktuelle Informationen zu den aktuellen Routen benötigt, diese Informationen abrufen. Dazu überwacht sie mit ConnectivityManager.registerNetworkCallback() auf Netzwerkänderungen und ruft den mit dem Netzwerk verknüpften LinkProperties.getRoutes() auf.

Merkmale der Kennungen

Das Android-Betriebssystem bietet eine Reihe von IDs mit unterschiedlichen Verhaltensmerkmalen. Welche ID Sie verwenden sollten, hängt davon ab, wie die folgenden Eigenschaften bei Ihrem Anwendungsfall funktionieren. Diese Eigenschaften haben jedoch auch Auswirkungen auf den Datenschutz. Daher ist es wichtig zu verstehen, wie diese Eigenschaften miteinander interagieren.

Aufgabenstellung

Anhand des ID-Bereichs wird angegeben, welche Systeme auf die ID zugreifen können. Es gibt im Allgemeinen drei Arten von Android-Kennungen:

  • Einzelne App: Die ID gilt nur für die App und ist nicht für andere Apps zugänglich.
  • Gruppe von Apps: Auf die ID kann eine vordefinierte Gruppe ähnlicher Apps zugreifen.
  • Gerät: Die ID ist für alle auf dem Gerät installierten Apps zugänglich.

Je umfangreicher der einer Kennung gewährt wird, desto höher ist das Risiko, dass sie zu Tracking-Zwecken verwendet wird. Umgekehrt kann eine ID, die nur von einer einzelnen Anwendungsinstanz aufgerufen werden kann, nicht zum transaktionsübergreifenden Tracking eines Geräts in verschiedenen Apps verwendet werden.

Rücksetzbarkeit und Persistenz

Rücksetzbarkeit und Persistenz definieren die Lebensdauer der Kennung und erklären, wie sie zurückgesetzt werden kann. Zu den häufigsten Triggern für das Zurücksetzen gehören das Zurücksetzen in der App, das Zurücksetzen über die Systemeinstellungen sowie das Zurücksetzen beim Start und Zurücksetzen bei der Installation. Android-IDs können eine unterschiedliche Lebensdauer haben, hängt aber in der Regel davon ab, wie die ID zurückgesetzt wird:

  • Nur Sitzung: Jedes Mal, wenn der Nutzer die App neu startet, wird eine neue ID verwendet.
  • Install-reset: Jedes Mal, wenn ein Nutzer die App deinstalliert und neu installiert, wird eine neue ID verwendet.
  • Zurücksetzen auf die Werkseinstellungen: Jedes Mal, wenn der Nutzer das Gerät auf die Werkseinstellungen zurücksetzt, wird eine neue ID verwendet.
  • Dauerhaft auf Werkseinstellungen zurücksetzen: Die ID bleibt auch nach dem Zurücksetzen auf die Werkseinstellungen erhalten.

Die Rücksetzbarkeit gibt Nutzern die Möglichkeit, eine neue ID zu erstellen, die von vorhandenen Profilinformationen getrennt ist. Je länger und zuverlässiger eine Kennzeichnung beibehalten wird, z. B. bei einem Zurücksetzen auf die Werkseinstellungen, desto höher ist das Risiko, dass der Nutzer einem langfristigen Tracking unterliegt. Wenn die ID bei der Neuinstallation der App zurückgesetzt wird, verringert dies die Persistenz und bietet die Möglichkeit, die ID selbst dann zurückzusetzen, wenn der Nutzer sie nicht explizit über die App oder die Systemeinstellungen zurücksetzen kann.

Einzigartigkeit

Die Eindeutigkeit bestimmt die Wahrscheinlichkeit von Konflikten, d. h., dass identische Kennungen im zugehörigen Bereich vorhanden sind. Auf höchster Ebene kommt eine global eindeutige Kennung niemals zu Konflikten, auch nicht auf anderen Geräten oder in anderen Apps. Andernfalls hängt der Grad der Eindeutigkeit von der Entropie der Kennung und der Quelle der Zufälligkeit ab, auf der sie erstellt wurde. Das Risiko einer Kollision ist beispielsweise bei Zufallskennungen, die dem Installationsdatum hinzugefügt wurden (z. B. 2019-03-01), viel höher als bei Kennungen, die mit dem Unix-Zeitstempel der Installation hinzugefügt wurden (z. B. 1551414181).

Im Allgemeinen können Nutzerkonto-IDs als eindeutig betrachtet werden. Das heißt, jede Kombination aus Gerät und Konto hat eine eindeutige ID. Auf der anderen Seite gilt: Je weniger eindeutige Kennungen innerhalb einer Grundgesamtheit sind, desto größer ist der Datenschutz, da sie weniger nützlich für das Tracking eines einzelnen Nutzers ist.

Integritätsschutz und Nachweisbarkeit

Sie können eine Kennung verwenden, die sich nur schwer fälschen oder wiederholen lässt, um nachzuweisen, dass das verknüpfte Gerät oder Konto bestimmte Eigenschaften hat. So könnten Sie beispielsweise beweisen, dass das Gerät kein virtuelles Gerät ist, das von einem Spammer verwendet wird. Kennungen, die schwer zu fälschen sind, bieten außerdem Eindeutigkeit. Wenn das Gerät eine Nachricht mit einem geheimen Schlüssel signiert, lässt sich nur schwer behaupten, dass die Nachricht vom Gerät einer anderen Person gesendet wurde. Die Unverbindlichkeit kann etwas sein, was ein Nutzer möchte, z. B. wenn eine Zahlung authentifiziert wird. Es kann sich aber auch um eine unerwünschte Eigenschaft handeln, z. B. wenn der Nutzer eine Nachricht sendet, die er bereut.

Gängige Anwendungsfälle und die passende ID

Dieser Abschnitt enthält Alternativen zur Verwendung von Hardware-IDs wie IMEIs. Von der Verwendung von Hardware-IDs wird abgeraten, da der Nutzer diese nicht zurücksetzen kann und sie auf das Gerät beschränkt sind. In vielen Fällen reicht eine ID auf App-Ebene aus.

Konten

Status des Mobilfunkanbieters

In diesem Fall interagiert deine App mit dem Smartphone des Geräts und bietet SMS-Funktionen über das Konto eines Mobilfunkanbieters.

Empfohlene Kennzeichnung:IMEI, IMSI und Line1

Warum sehe ich diese Empfehlung?

Die Nutzung von Hardwarekennungen ist akzeptabel, wenn sie für die Funktionen des Mobilfunkanbieters erforderlich ist. Sie können diese Kennungen beispielsweise verwenden, um zwischen Mobilfunkanbietern oder SIM-Slots zu wechseln oder um SMS-Nachrichten über SIM-basierte Nutzerkonten (für Line1) zu senden. Für nicht privilegierte Apps empfehlen wir jedoch die Verwendung einer Kontoanmeldung, um Nutzergeräteinformationen serverseitig abzurufen. Ein Grund dafür ist, dass diese Kennungen ab Android 6.0 (API-Level 23) und höher nur über eine Laufzeitberechtigung verwendet werden können. Nutzer können diese Berechtigung deaktivieren, sodass Ihre App diese Ausnahmen ordnungsgemäß verarbeiten sollte.

Status des Mobilfunkabos

In diesem Fall musst du die App-Funktionen mit bestimmten Mobilfunkabos auf dem Gerät verknüpfen. Beispielsweise kann es erforderlich sein, den Zugriff auf bestimmte Premium-App-Funktionen basierend auf den mobilen Abos des Geräts per SIM zu bestätigen.

Empfohlene Kennung:Subscription ID API zur Identifizierung der im Gerät verwendeten SIM-Karten.

Die Abo-ID stellt einen Indexwert (beginnend mit 1) zur eindeutigen Identifizierung der auf dem Gerät installierten physischen und elektronischen SIM-Karten bereit. Über diese ID kann deine App ihre Funktionen mit verschiedenen Aboinformationen für eine bestimmte SIM verknüpfen. Dieser Wert bleibt für die jeweilige SIM-Karte gleich, es sei denn, das Gerät wird auf die Werkseinstellungen zurückgesetzt. Es kann jedoch vorkommen, dass dieselbe SIM-Karte auf verschiedenen Geräten eine andere Abo-ID hat oder verschiedene SIMs auf verschiedenen Geräten dieselbe ID haben.

Warum sehe ich diese Empfehlung?

Einige Anwendungen verwenden derzeit möglicherweise die ICC-ID für diesen Zweck. Da die ICC-ID global eindeutig ist und nicht zurückgesetzt werden kann, wurde der Zugriff seit Android 10 auf Apps mit der Berechtigung READ_PRIVILEGED_PHONE_STATE beschränkt. Ab Android 11 wird der Zugriff auf die ICCID über die getIccId() API weiter eingeschränkt, unabhängig vom Ziel-API-Level der App. Betroffene Apps sollten stattdessen zur Abo-ID migriert werden.

Einmalanmeldung (SSO)

In diesem Fall bietet Ihre Anwendung eine Einmalanmeldung, sodass Nutzer ein vorhandenes Konto mit Ihrer Organisation verknüpfen können.

Empfohlene ID:mit Account Manager kompatible Konten, z. B. die Google-Kontoverknüpfung

Warum sehe ich diese Empfehlung?

Mit der Google-Kontoverknüpfung können Nutzer das vorhandene Google-Konto eines Nutzers mit Ihrer Anwendung verknüpfen und so nahtlos und sicherer auf die Produkte und Dienste Ihrer Organisation zugreifen. Darüber hinaus können Sie benutzerdefinierte OAuth-Bereiche definieren, um nur erforderliche Daten freizugeben. Dadurch wird das Vertrauen der Nutzer gestärkt, indem klar definiert wird, wie ihre Daten verwendet werden.

Werbung

Ausrichtung

In diesem Fall erstellt Ihre App ein Profil zu den Interessen eines Nutzers, um ihm relevantere Anzeigen zu präsentieren.

Empfohlene ID:Wenn in Ihrer App eine ID für Anzeigen und Uploads verwendet oder bei Google Play veröffentlicht wird, muss diese ID die Werbe-ID sein.

Warum sehe ich diese Empfehlung?

Dies ist ein anzeigenbezogener Anwendungsfall, bei dem möglicherweise eine ID erforderlich ist, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die am besten geeignete Lösung. Die Verwendung der Werbe-ID ist für Werbeanwendungsfälle gemäß der Google Play-Inhaltsrichtlinien für Entwickler obligatorisch, da der Nutzer sie zurücksetzen kann.

Wenn du Nutzerdaten in deiner App teilst und zu Werbezwecken teilst, musst du die Werbezwecke in der Play Console im Abschnitt zur Datensicherheit der Seite App-Inhalte deklarieren.

Messung

In diesem Fall erstellt Ihre App ein Nutzerprofil, das auf seinem Verhalten in allen Apps Ihrer Organisation auf demselben Gerät basiert.

Empfohlene zu verwendende Kennung:Werbe-ID oder Play-Installationsverweis-APIs

Warum sehe ich diese Empfehlung?

Dies ist ein anzeigenbezogener Anwendungsfall, bei dem möglicherweise eine ID erforderlich ist, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die am besten geeignete Lösung. Wenn Sie eine ID zu Werbezwecken verwenden, muss diese ID die Werbe-ID sein, da der Nutzer sie zurücksetzen kann. Weitere Informationen finden Sie in den Google Play-Inhaltsrichtlinien für Entwickler.

Conversions

In diesem Fall erfassen Sie Conversions, um festzustellen, ob Ihre Marketingstrategie erfolgreich ist.

Empfohlene zu verwendende Kennung:Werbe-ID oder Play-Installationsverweis-APIs

Warum sehe ich diese Empfehlung?

Dies ist ein anzeigenbezogener Anwendungsfall, bei dem möglicherweise eine ID erforderlich ist, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die am besten geeignete Lösung. Die Verwendung der Werbe-ID ist für Werbeanwendungsfälle gemäß der Google Play-Inhaltsrichtlinien für Entwickler obligatorisch, da der Nutzer sie zurücksetzen kann.

Remarketing

In diesem Fall werden in Ihrer App Anzeigen basierend auf den bisherigen Interessen eines Nutzers präsentiert.

Empfohlene ID:Werbe-ID

Warum sehe ich diese Empfehlung?

Dies ist ein anzeigenbezogener Anwendungsfall, bei dem möglicherweise eine ID erforderlich ist, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die am besten geeignete Lösung. Die Verwendung der Werbe-ID ist für Werbeanwendungsfälle gemäß der Google Play-Inhaltsrichtlinien für Entwickler obligatorisch, da der Nutzer sie zurücksetzen kann.

App-Analyse

In diesem Fall wertet Ihre Anwendung das Verhalten eines Nutzers aus, damit Sie Folgendes bestimmen können:

  • Welche anderen Produkte oder Anwendungen Ihrer Organisation für den Nutzer geeignet sein könnten.
  • Wie Nutzer das Interesse an Ihrer App aufrechterhalten
  • Nutzungsstatistiken und Analysen für nicht angemeldete oder anonyme Nutzer messen.

Mögliche Lösungen:

  • App-Set-ID:Mit einer App-Set-ID können Sie das Verhalten eines Nutzers über mehrere Apps hinweg analysieren, die Ihrer Organisation gehören, sofern Sie keine Nutzerdaten für Werbezwecke verwenden. Wenn Sie Ihre Anzeigen auf Geräte mit Google Play-Diensten ausrichten, empfehlen wir die Verwendung der App Set-ID.
  • Firebase-ID (FID): Eine FID ist auf die Anwendung beschränkt, von der sie erstellt wird. Dadurch wird verhindert, dass die ID zum anwendungsübergreifenden Tracking von Nutzern verwendet werden kann. Außerdem kann er leicht zurückgesetzt werden, da der Nutzer App-Daten löschen oder die App neu installieren kann. Die Erstellung einer FID ist unkompliziert. Weitere Informationen finden Sie im Firebase-Installationshandbuch.

App-Entwicklung

Absturzberichte

In diesem Fall erhebt deine App Daten darüber, wann und warum sie auf den Geräten eines Nutzers abstürzt.

Empfohlene ID:FID oder App-Set-ID

Warum sehe ich diese Empfehlung?

Eine FID ist auf die Anwendung beschränkt, von der sie erstellt wird. Dadurch wird verhindert, dass die ID zur anwendungsübergreifenden Verfolgung von Nutzern verwendet wird. Außerdem kann sie einfach zurückgesetzt werden, da der Nutzer die App-Daten löschen oder die App neu installieren kann. Die Erstellung einer FID ist einfach. Weitere Informationen finden Sie im Firebase-Installationshandbuch. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers über mehrere Apps hinweg analysieren, die Ihrer Organisation gehören, sofern Sie keine Nutzerdaten zu Werbezwecken verwenden.

Leistungsberichte

In diesem Fall erfasst Ihre App Leistungsmesswerte wie Ladezeiten und Akkunutzung, um die Qualität der App zu verbessern.

Empfohlene ID zur Verwendung: Firebase Performance Monitoring

Warum sehe ich diese Empfehlung?

Mit Firebase Performance Monitoring können Sie sich auf die Messwerte konzentrieren, die für Sie am wichtigsten sind, und die Auswirkungen einer kürzlich erfolgten Änderung in Ihrer App testen.

App-Tests

In diesem Fall bewertet die Anwendung zu Test- oder Fehlerbehebungszwecken die Erfahrung eines Nutzers mit Ihrer Anwendung.

Empfohlene ID:FID oder App-Set-ID

Warum sehe ich diese Empfehlung?

Eine FID ist auf die Anwendung beschränkt, von der sie erstellt wird. Dadurch wird verhindert, dass die ID zur anwendungsübergreifenden Verfolgung von Nutzern verwendet wird. Außerdem kann sie einfach zurückgesetzt werden, da der Nutzer die App-Daten löschen oder die App neu installieren kann. Die Erstellung einer FID ist einfach. Weitere Informationen finden Sie im Firebase-Installationshandbuch. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers über mehrere Apps hinweg analysieren, die Ihrer Organisation gehören, sofern Sie keine Nutzerdaten zu Werbezwecken verwenden.

Geräteübergreifende Installation

In diesem Fall muss deine App die richtige Instanz der App identifizieren, wenn sie auf mehreren Geräten für denselben Nutzer installiert ist.

Empfohlene ID:FID oder GUID

Warum sehe ich diese Empfehlung?

Eine FID wurde explizit für diesen Zweck entwickelt. Ihr Umfang ist auf die App beschränkt, sodass sie nicht verwendet werden kann, um Nutzer über verschiedene Apps hinweg zu verfolgen. Sie wird bei der Neuinstallation der App zurückgesetzt. In den seltenen Fällen, in denen eine FID nicht ausreicht, können Sie auch eine GUID verwenden.

Sicherheit

Erkennung von Missbrauch

In diesem Fall versuchen Sie, mehrere gefälschte Geräte zu erkennen, die Ihre Back-End-Dienste angreifen.

Empfohlene ID:das Integritätstoken der Google Play Integrity API

Warum sehe ich diese Empfehlung?

Mit der Google Play Integrity API kannst du prüfen, ob eine Anfrage von einem echten Android-Gerät und nicht von einem Emulator oder Code-Spoofing eines anderen Geräts stammt.

Werbebetrug

In diesem Fall prüft deine App, ob die Impressionen und Aktionen eines Nutzers in deiner App echt und überprüfbar sind.

Empfohlene ID:Werbe-ID

Warum sehe ich diese Empfehlung?

Die Verwendung der Werbe-ID ist für Werbeanwendungsfälle gemäß der Google Play-Inhaltsrichtlinien für Entwickler obligatorisch, da der Nutzer sie zurücksetzen kann.

Digitale Rechteverwaltung (Digital Rights Management, DRM)

In diesem Fall möchte Ihre Anwendung betrügerischen Zugriff auf geistiges Eigentum oder kostenpflichtige Inhalte schützen.

Empfohlene zu verwendende ID:Wenn Sie eine FID oder GUID verwenden, wird der Nutzer dazu gezwungen, die App neu zu installieren, um die Inhaltsbeschränkungen zu umgehen. Für die meisten Nutzer reicht dies jedoch aus, um davon abzuschrecken. Wenn dies kein ausreichender Schutz ist, bietet Android eine DRM-API, mit der der Zugriff auf Inhalte eingeschränkt werden kann. Sie enthält eine Kennung pro APK, die Wivine-ID.

Nutzereinstellungen

In diesem Fall speichert Ihre App den Nutzerstatus für jedes Gerät in Ihrem App-Nutzerstatus, insbesondere für nicht angemeldete Nutzer. Sie können diesen Status an eine andere App übertragen, die auf demselben Gerät mit demselben Schlüssel signiert ist.

Empfohlene ID:FID oder GUID

Warum sehe ich diese Empfehlung?

Es wird nicht empfohlen, Informationen bei Neuinstallationen beizubehalten, da Nutzer ihre Einstellungen möglicherweise durch eine Neuinstallation der App zurücksetzen möchten.