Best Practices für eindeutige Kennzeichnungen

In diesem Dokument finden Sie eine Anleitung zur Auswahl geeigneter IDs für Ihre App basierend auf Ihrem Anwendungsfall.

Allgemeine Informationen zu Android-Berechtigungen finden Sie unter Berechtigungen – Übersicht. Best Practices für die Arbeit mit Android-Berechtigungen finden Sie unter Best Practices für App-Berechtigungen.

Best Practices für die Arbeit mit Android-IDs

Verwenden Sie zum Schutz der Privatsphäre Ihrer Nutzer die strikteste Kennung, die den Anwendungsfall Ihrer App erfüllt. Beachten Sie insbesondere die folgenden Best Practices:

  1. Wählen Sie nach Möglichkeit IDs aus, die vom Nutzer zurückgesetzt werden können. Ihre App kann die meisten Anwendungsfälle erfüllen, auch wenn sie andere IDs als nicht zurücksetzbare Hardware-IDs verwendet.

  2. Verwenden Sie keine Hardware-IDs. In den meisten Fällen können Sie die Verwendung von Hardware-IDs wie der IMEI (International Mobile Equipment Identity) vermeiden, ohne die erforderlichen Funktionen einzuschränken.

    Android 10 (API-Level 29) enthält Einschränkungen für nicht zurücksetzbare Kennungen, einschließlich IMEI und Seriennummer. Ihre App muss eine App zum Verwalten von Geräten oder Profilen sein, besondere Berechtigungen des Mobilfunkanbieters haben oder die Berechtigung READ_PRIVILEGED_PHONE_STATE, um auf diese IDs zuzugreifen.

  3. Verwenden Sie eine Werbe-ID nur für die Nutzerprofilierung oder für Werbezwecke. Wenn Sie eine Werbe-ID verwenden, müssen Sie immer die Auswahl der Nutzer in Bezug auf das Anzeigen-Tracking respektieren. Wenn Sie die Werbe-ID mit personenidentifizierbaren Informationen verknüpfen müssen, tun Sie dies nur mit ausdrücklicher Einwilligung des Nutzers.

  4. Werbe-IDs nicht zurücksetzen.

  5. Verwenden Sie für alle anderen Anwendungsfälle, mit Ausnahme der Betrugsprävention und Telefonie, nach Möglichkeit eine Firebase-Installations-ID (FID) oder eine privat gespeicherte GUID. Für die meisten Anwendungsfälle, die nicht mit Anzeigen zusammenhängen, sollte eine FID oder GUID ausreichen.

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

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

Mit Werbe-IDs arbeiten

Die Werbe-ID ist eine vom Nutzer zurücksetzbare Kennung und eignet sich für Anwendungsfälle im Zusammenhang mit Werbung. Bei der Verwendung dieser ID sind jedoch einige wichtige Punkte zu beachten:

Achten Sie immer darauf, dass Sie die Werbe-ID nur dann zurücksetzen, wenn der Nutzer dies möchte. Nutzer-Resets dürfen nicht überbrückt werden, indem Sie eine andere Kennung oder einen anderen Fingerabdruck verwenden, um nachfolgende Werbe-IDs ohne die Einwilligung des Nutzers zu verknüpfen. In den Google Play-Richtlinien zu Entwicklerinhalten heißt es:

„Nach Zurücksetzen der ID darf eine neue Werbe-ID nur mit ausdrücklicher Zustimmung des Nutzers mit einer vorherigen Werbe-ID oder daraus stammenden Daten verknüpft werden.“

Beachten Sie immer das zugehörige Flag für personalisierte Anzeigen. Werbe-IDs können konfiguriert werden, sodass Nutzer das Tracking einschränken können, das mit der ID verknüpft ist. Verwenden Sie immer die Methode AdvertisingIdClient.Info.isLimitAdTrackingEnabled(), damit Sie die Wünsche Ihrer Nutzer nicht umgehen. In den Google Play-Richtlinien zu Entwicklerinhalten heißt es:

„Sie müssen 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 von personalisierten Anzeigen nutzen. Zulässig sind hingegen kontextbezogene Werbung, Frequency Capping, Conversion-Tracking, die Erstellung von Berichten sowie Sicherheits- und Betrugserkennung."

Achten Sie auf alle Datenschutz- oder Sicherheitsrichtlinien, die mit den von Ihnen verwendeten SDKs im Zusammenhang mit der Verwendung von Werbe-IDs verbunden sind. Wenn Sie beispielsweise true an die Methode enableAdvertisingIdCollection() aus dem Google Analytics SDK übergeben, müssen Sie alle anwendbaren Richtlinien für das Analytics SDK lesen und einhalten.

Gemäß den Google Play-Richtlinien für Entwicklerinhalte darf die Werbe-ID nicht mit personenidentifizierbaren Informationen oder gleichbleibenden Geräte-IDs wie SSAID, MAC-Adresse oder IMEI verknüpft werden.

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

TABELLE-01
timestamp ad_id account_id clickid
TABLE-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 zusammengeführt werden. Dies würde gegen die Google Play-Richtlinien für Entwicklerinhalte verstoßen, wenn Sie keine ausdrückliche Genehmigung von Ihren Nutzern erhalten haben.

Beachten Sie, dass die Verknüpfung zwischen Werbetreibenden-ID und personenidentifizierbaren Informationen nicht immer so explizit ist. Es kann vorkommen, dass „Quasi-IDs“ sowohl in Tabellen mit personenidentifizierbaren Informationen als auch in Tabellen mit Anzeigen-IDs vorkommen, was ebenfalls zu Problemen führt. Angenommen, wir ändern TABELLE-01 und TABELLE-02 so:

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

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

Es ist zwar oft schwierig, dafür zu sorgen, dass in einem Datensatz keine solchen Quasi-Identifikatoren vorhanden sind, aber Sie können die offensichtlichsten Join-Risiken vermeiden, indem Sie eindeutige Daten nach Möglichkeit verallgemeinern. Im vorherigen Beispiel würde dies bedeuten, die Genauigkeit des Zeitstempels zu verringern, sodass für jeden Zeitstempel mehrere Geräte mit demselben Modell angezeigt werden.

Weitere Lösungen:

  • Tabellen nicht so entwerfen, dass personenidentifizierbare Informationen explizit mit Werbe-IDs verknüpft werden Im ersten Beispiel oben würde das bedeuten, dass die Spalte account_id nicht in TABELLE-01 enthalten ist.

  • Zugriffssteuerungslisten für Nutzer oder Rollen trennen und überwachen, die sowohl auf Daten mit Werbe-ID als Schlüssel als auch auf personenidentifizierbare Informationen zugreifen können Wenn Sie den Zugriff auf beide Quellen gleichzeitig streng steuern und prüfen (z. B. durch Zusammenführen von Tabellen), verringern Sie das Risiko einer Verknüpfung zwischen der Anzeigen-ID und personenidentifizierbaren Informationen. Im Allgemeinen bedeutet die Zugriffssteuerung Folgendes:

    1. Halten Sie die Zugriffssteuerungslisten (Access Control Lists, ACLs) für Daten mit Anzeigen-ID und personenidentifizierbaren Informationen getrennt, um die Anzahl der Personen oder Rollen in beiden ACLs zu minimieren.
    2. Implementieren Sie Zugriffsprotokollierung und -prüfung, um Ausnahmen von dieser Regel zu erkennen und zu verwalten.

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

Mit FIDs und GUIDs arbeiten

Die einfachste Lösung zur Identifizierung einer App-Instanz, die auf einem Gerät ausgeführt wird, ist die Verwendung einer Firebase-Installations-ID (FID). Diese Lösung wird in den meisten Anwendungsfällen, die nicht mit Anzeigen zusammenhängen, empfohlen. Nur die App-Instanz, für die sie bereitgestellt wurde, kann auf diese Kennung zugreifen. Sie lässt sich (relativ) einfach zurücksetzen, da sie nur so lange vorhanden ist, wie die App installiert ist.

Daher bieten FIDs im Vergleich zu nicht zurücksetzbaren, gerätespezifischen Hardware-IDs bessere Datenschutzeigenschaften. Weitere Informationen finden Sie in der API-Referenz für firebase.installations.

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

Kotlin

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

Java

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

Da die Kennung global eindeutig ist, kann sie verwendet werden, um eine bestimmte App-Instanz zu identifizieren. Speichern Sie GUIDs im internen Speicher statt im externen (freigegebenen) Speicher, um Probleme bei der Verknüpfung der Kennung zwischen Apps zu vermeiden. Weitere Informationen finden Sie auf der Seite Daten- und Dateispeicher.

Funktioniert nicht mit MAC-Adressen

MAC-Adressen sind weltweit eindeutig, können nicht vom Nutzer zurückgesetzt werden und bleiben auch nach dem Zurücksetzen auf die Werkseinstellungen erhalten. Aus diesen Gründen und zum Schutz der Privatsphäre der Nutzer ist der Zugriff auf MAC-Adressen in Android-Version 6 und höher auf System-Apps beschränkt. Drittanbieter-Apps können nicht darauf zugreifen.

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

Bei Apps, die auf Android 11 und höher ausgerichtet sind, erfolgt die MAC-Zufallsmixung 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 Anmeldedaten, die im Passpoint-Profil verwendet werden:
    • Nutzeranmeldedaten: Nutzername
    • Zertifikatsanmeldedaten: cert und cert type
    • SIM-Anmeldedaten: EAP-Typ und IMSI

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

Im Folgenden finden Sie eine Liste der Auswirkungen dieser Änderung auf Apps:

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

Die meisten Entwickler sollten die APIs der höheren Ebene von ConnectivityManager verwenden, anstatt APIs der unteren Ebene wie NetworkInterface, getifaddrs() oder Netlink-Sockets. Eine App, die aktuelle Informationen zu den aktuellen Routen benötigt, kann diese Informationen beispielsweise mit ConnectivityManager.registerNetworkCallback() abrufen, indem sie mithilfe von LinkProperties.getRoutes() nach Netzwerkänderungen prüft.

Kennungsmerkmale

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

Aufgabenstellung

Im Bereich „Kennungsbereich“ wird angegeben, welche Systeme auf die Kennung zugreifen können. Der Gültigkeitsbereich von Android-IDs gibt es in der Regel in drei Varianten:

  • Einzelne App: Die ID ist innerhalb der App intern und für andere Apps nicht zugänglich.
  • Gruppe von Apps: Die ID ist für eine vordefinierte Gruppe ähnlicher Apps zugänglich.
  • Gerät: Auf die ID kann jede auf dem Gerät installierte App zugreifen.

Je größer der Umfang einer Kennung ist, desto höher ist das Risiko, dass sie zu Tracking-Zwecken verwendet wird. Wenn hingegen nur eine einzelne App-Instanz auf eine Kennung zugreifen kann, kann sie nicht verwendet werden, um ein Gerät über Transaktionen in verschiedenen Apps hinweg zu erfassen.

Zurücksetzen und Persistenz

Mit den Optionen „Zurücksetzbar“ und „Dauerhaft“ wird die Lebensdauer der Kennung definiert und erläutert, wie sie zurückgesetzt werden kann. Gängige Auslöser für das Zurücksetzen sind: In-App-Zurücksetzungen, Zurücksetzungen über die Systemeinstellungen, Zurücksetzungen beim Starten und Zurücksetzungen bei der Installation. Android-IDs können eine unterschiedliche Lebensdauer haben. Diese hängt 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.
  • Installations-Reset: Jedes Mal, wenn der Nutzer die App deinstalliert und wieder 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.
  • FDR-persistent: Die ID bleibt nach dem Zurücksetzen auf die Werkseinstellungen erhalten.

Durch das Zurücksetzen können Nutzer eine neue ID erstellen, die nicht mit vorhandenen Profilinformationen verknüpft ist. Je länger und zuverlässiger eine Kennung besteht, z. B. eine, die auch nach dem Zurücksetzen auf die Werkseinstellungen erhalten bleibt, desto höher ist das Risiko, dass der Nutzer langfristig beobachtet wird. Wenn die Kennung bei der Neuinstallation der App zurückgesetzt wird, wird die Persistenz verringert und es gibt eine Möglichkeit, die ID zurückzusetzen, auch wenn es keine explizite Nutzersteuerung gibt, um sie über die App oder die Systemeinstellungen zurückzusetzen.

Eindeutigkeit

Die Eindeutigkeit gibt Aufschluss über die Wahrscheinlichkeit von Kollisionen, d. h., ob im zugehörigen Bereich identische Kennungen vorhanden sind. Auf der obersten Ebene kommt es bei einer global eindeutigen Kennung nie zu einer Kollision, auch nicht auf anderen Geräten oder in anderen Apps. Andernfalls hängt der Grad der Eindeutigkeit von der Entropie der Kennung und der Zufallsquelle ab, die zum Erstellen verwendet wurde. So ist die Wahrscheinlichkeit einer Kollision beispielsweise bei zufälligen Kennungen, die mit dem Kalenderdatum der Installation (z. B. 2019-03-01) erstellt wurden, viel höher als bei Kennungen, die mit dem Unix-Zeitstempel der Installation (z. B. 1551414181) erstellt wurden.

Im Allgemeinen können Nutzerkonto-IDs als eindeutig betrachtet werden. Das bedeutet, dass jede Kombination aus Gerät und Konto eine eindeutige ID hat. Je weniger eindeutig eine Kennung innerhalb einer Gruppe ist, desto höher ist der Datenschutz, da sie weniger nützlich ist, um einzelne Nutzer zu verfolgen.

Integritätsschutz und Nichtabstreitbarkeit

Sie können eine ID verwenden, die nur schwer zu fälschen oder zu wiederholen ist, um nachzuweisen, dass das verknüpfte Gerät oder Konto bestimmte Eigenschaften hat. Sie können beispielsweise nachweisen, dass es sich nicht um ein virtuelles Gerät handelt, das von einem Spammer verwendet wird. Mithilfe von schwer zu fälschenden IDs wird auch die Nicht-Abstreitbarkeit gewährleistet. Wenn das Gerät eine Nachricht mit einem geheimen Schlüssel signiert, ist es schwierig zu behaupten, dass das Gerät einer anderen Person die Nachricht gesendet hat. Die Irreversibilität kann für Nutzer wünschenswert sein, z. B. bei der Authentifizierung einer Zahlung, oder eine unerwünschte Eigenschaft, z. B. wenn sie eine Nachricht senden, die sie bereuen.

Gängige Anwendungsfälle und die richtige Kennung

In diesem Abschnitt finden Sie Alternativen zur Verwendung von Hardware-IDs wie der IMEI. Die Verwendung von Hardware-IDs wird nicht empfohlen, da sie vom Nutzer nicht zurückgesetzt werden können und nur für das Gerät gelten. In vielen Fällen reicht eine Kennung auf App-Ebene aus.

Konten

Status des Mobilfunkanbieters

In diesem Fall interagiert Ihre App über ein Mobilfunkkonto mit den Telefon- und SMS-Funktionen des Geräts.

Empfohlene Kennung:IMEI, IMSI und Line1

Warum diese Empfehlung?

Die Verwendung von Hardware-IDs ist zulässig, wenn sie für anbieterbezogene Funktionen erforderlich ist. Sie können diese IDs beispielsweise verwenden, um zwischen Mobilfunkanbietern oder SIM-Slots zu wechseln oder SMS-Nachrichten über IP (für Line1) an SIM-basierte Nutzerkonten zu senden. Bei nicht privilegierten Apps empfehlen wir jedoch, eine Kontoanmeldung zu verwenden, um Nutzergeräteinformationen serverseitig abzurufen. Ein Grund dafür ist, dass diese IDs unter Android 6.0 (API-Ebene 23) und höher nur über eine Laufzeitberechtigung verwendet werden können. Nutzer können diese Berechtigung deaktivieren. Ihre App sollte diese Ausnahmen daher reibungslos verarbeiten.

Status des mobilen Abos

In diesem Fall müssen Sie die App-Funktionen mit bestimmten Abos für mobile Dienste auf dem Gerät verknüpfen. Beispielsweise kann es erforderlich sein, den Zugriff auf bestimmte Premium-App-Funktionen anhand der Mobilfunkabos des Geräts über die SIM-Karte zu bestätigen.

Empfohlene Kennung:Subscription ID API, um SIM-Karten zu identifizieren, die auf dem Gerät verwendet werden.

Die Abo-ID ist ein Indexwert (beginnend mit 1), mit dem installierte SIM-Karten (einschließlich physischer und elektronischer) eindeutig identifiziert werden können, die auf dem Gerät verwendet werden. Über diese ID kann Ihre App ihre Funktionen mit verschiedenen Aboinformationen für eine bestimmte SIM-Karte verknüpfen. Dieser Wert ist für eine bestimmte SIM-Karte stabil, 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 unterschiedliche Abo-ID hat oder verschiedene SIM-Karten auf verschiedenen Geräten dieselbe ID haben.

Warum diese Empfehlung?

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

Einmalanmeldung (SSO)

In diesem Fall bietet Ihre App eine Einmalanmeldung, mit der Nutzer ein bestehendes Konto mit Ihrer Organisation verknüpfen können.

Empfohlene Kennung:Konten, die mit dem Account Manager kompatibel sind, z. B. die Google-Kontoverknüpfung

Warum diese Empfehlung?

Mit der Google-Kontoverknüpfung können Nutzer das vorhandene Google-Konto eines Nutzers mit Ihrer App verknüpfen und so nahtlos und sicherer auf die Produkte und Dienste Ihrer Organisation zugreifen. Außerdem können Sie benutzerdefinierte OAuth-Bereiche definieren, um nur die erforderlichen Daten freizugeben. So stärken Sie das Vertrauen der Nutzer, indem Sie klar definieren, wie ihre Daten verwendet werden.

Werbung

Ausrichtung

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

Empfohlene Kennung:Wenn Ihre App eine ID für Werbung verwendet und bei Google Play hochgeladen oder veröffentlicht wird, muss diese ID die Werbe-ID sein.

Warum diese Empfehlung?

Bei diesem werbebezogenen Anwendungsfall ist möglicherweise eine ID erforderlich, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die beste Lösung. Gemäß den Google Play-Richtlinien für Entwicklerinhalte ist die Verwendung der Werbe-ID für Anwendungsfälle im Zusammenhang mit Werbung obligatorisch, da der Nutzer sie zurücksetzen kann.

Unabhängig davon, ob Sie Nutzerdaten in Ihrer App weitergeben, müssen Sie die Zwecke, für die Sie sie erheben und verwenden, im Abschnitt zur Datensicherheit auf der Seite App-Inhalte in der Play Console angeben.

Messung

In diesem Fall erstellt Ihre App ein Profil eines Nutzers basierend auf seinem Verhalten in den Apps Ihrer Organisation auf demselben Gerät.

Empfohlene Kennung:Advertising ID oder Play-Installations-Referenz-APIs

Warum diese Empfehlung?

Bei diesem werbebezogenen Anwendungsfall ist möglicherweise eine ID erforderlich, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die beste Lösung. Wenn Sie eine ID für Werbezwecke verwenden, muss es sich dabei um die Werbe-ID handeln, da der Nutzer sie zurücksetzen kann. Weitere Informationen finden Sie in den Google Play-Richtlinien zu Entwicklerinhalten.

Conversions

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

Empfohlene Kennung:Advertising ID oder Play-Installations-Referenz-APIs

Warum diese Empfehlung?

Bei diesem werbebezogenen Anwendungsfall ist möglicherweise eine ID erforderlich, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die beste Lösung. Gemäß den Google Play-Richtlinien für Entwicklerinhalte ist die Verwendung der Werbe-ID für Anwendungsfälle im Zusammenhang mit Werbung 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 Kennung:Werbe-ID

Warum diese Empfehlung?

Bei diesem werbebezogenen Anwendungsfall ist möglicherweise eine ID erforderlich, die in den verschiedenen Apps Ihrer Organisation verfügbar ist. Daher ist die Verwendung einer Werbe-ID die beste Lösung. Gemäß den Google Play-Richtlinien für Entwicklerinhalte ist die Verwendung der Werbe-ID für Anwendungsfälle im Zusammenhang mit Werbung obligatorisch, da der Nutzer sie zurücksetzen kann.

App-Analyse

In diesem Fall wird das Verhalten eines Nutzers in Ihrer App ausgewertet, um Folgendes zu ermitteln:

  • Welche anderen Produkte oder Apps Ihrer Organisation könnten für den Nutzer geeignet sein.
  • So halten Sie Nutzer an Ihrer App interessiert.
  • Nutzungsstatistiken und Analysen für abgemeldete oder anonyme Nutzer erfassen

Mögliche Lösungen:

  • App-Set-ID:Mit einer App-Set-ID können Sie das Verhalten eines Nutzers in mehreren Apps Ihrer Organisation analysieren, sofern Sie Nutzerdaten nicht zu Werbezwecken 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 App beschränkt, in der sie erstellt wird. So kann die Kennung nicht verwendet werden, um Nutzer über Apps hinweg zu erfassen. Außerdem lässt sie sich ganz einfach zurücksetzen, da der Nutzer App-Daten löschen oder die App neu installieren kann. Das Erstellen einer FID ist ganz einfach. Weitere Informationen finden Sie im Installationsleitfaden für Firebase.

App-Entwicklung

Absturzberichte

In diesem Fall erhebt Ihre App Daten dazu, wann und warum sie auf den Geräten der Nutzer abstürzt.

Empfohlene Kennung:FID oder App-Set-ID

Warum diese Empfehlung?

Eine FID ist auf die App beschränkt, in der sie erstellt wird. So wird verhindert, dass die Kennung verwendet wird, um Nutzer über Apps hinweg zu verfolgen. Außerdem lässt sie sich ganz einfach zurücksetzen, da der Nutzer App-Daten löschen oder die App neu installieren kann. Das Erstellen einer FID ist ganz einfach. Weitere Informationen finden Sie im Leitfaden zur Installation von Firebase. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers in mehreren Apps Ihrer Organisation analysieren, sofern Sie Nutzerdaten nicht zu Werbezwecken verwenden.

Leistungsberichte

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

Empfohlene Kennung: Firebase Performance Monitoring

Warum diese Empfehlung?

Mit Firebase-Leistungsüberwachung können Sie sich auf die für Sie wichtigsten Messwerte konzentrieren und die Auswirkungen einer kürzlichen Änderung an Ihrer App testen.

App-Tests

In diesem Fall wird die Nutzererfahrung mit Ihrer App zu Test- oder Fehlerbehebungszwecken ausgewertet.

Empfohlene Kennung:FID oder App-Set-ID

Warum diese Empfehlung?

Eine FID ist auf die App beschränkt, in der sie erstellt wird. So wird verhindert, dass die Kennung verwendet wird, um Nutzer über Apps hinweg zu verfolgen. Außerdem lässt sie sich ganz einfach zurücksetzen, da der Nutzer App-Daten löschen oder die App neu installieren kann. Das Erstellen einer FID ist ganz einfach. Weitere Informationen finden Sie im Leitfaden zur Installation von Firebase. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers in mehreren Apps Ihrer Organisation analysieren, sofern Sie Nutzerdaten nicht zu Werbezwecken verwenden.

Geräteübergreifende Installation

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

Empfohlene Kennung:FID oder GUID

Warum diese Empfehlung?

Eine FID wurde speziell für diesen Zweck entwickelt. Ihr Umfang ist auf die App beschränkt, sodass sie nicht zum Tracking von Nutzern in verschiedenen Apps verwendet werden kann. Außerdem wird sie bei der Neuinstallation der App zurückgesetzt. In seltenen Fällen, in denen eine FID nicht ausreicht, können Sie auch eine GUID verwenden.

Sicherheit

Missbrauchserkennung

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

Empfohlene Kennung:Integritätstoken der Google Play Integrity API

Warum diese Empfehlung?

Verwenden Sie die Google Play Integrity API, um zu prüfen, ob eine Anfrage von einem echten Android-Gerät stammt und nicht von einem Emulator oder anderen Code, der ein anderes Gerät vortäuscht.

Werbebetrug

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

Empfohlene Kennung:Werbe-ID

Warum diese Empfehlung?

Gemäß den Google Play-Richtlinien für Entwicklerinhalte ist die Verwendung der Werbe-ID für Werbeanwendungen obligatorisch, da der Nutzer sie zurücksetzen kann.

Digitale Rechteverwaltung (Digital Rights Management, DRM)

In diesem Fall soll Ihre App vor betrügerischen Zugriffen auf geistiges Eigentum oder kostenpflichtige Inhalte schützen.

Empfohlene Kennung:Wenn Sie eine FID oder GUID verwenden, muss der Nutzer die App neu installieren, um die Inhaltsbeschränkungen zu umgehen. Das ist für die meisten Nutzer zu aufwendig. Wenn dies nicht für ausreichenden Schutz sorgt, bietet Android eine DRM API, mit der der Zugriff auf Inhalte eingeschränkt werden kann. Sie enthält eine APK-spezifische Kennung, die Widevine-ID.

Nutzereinstellungen

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

Empfohlene Kennung:FID oder GUID

Warum diese Empfehlung?

Das Speichern von Informationen über Neuinstallationen wird nicht empfohlen, da Nutzer ihre Einstellungen möglicherweise durch eine Neuinstallation zurücksetzen möchten.