Best Practices für eindeutige Kennzeichnungen

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

Eine allgemeine Übersicht über Android-Berechtigungen finden Sie unter Berechtigungen – Übersicht. Spezifische 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-Kennungen

Verwenden Sie zum Schutz der Privatsphäre Ihrer Nutzer die restriktivste Kennung, die für den Anwendungsfall Ihrer App geeignet ist. Beachten Sie insbesondere die folgenden Best Practices:

1. Wählen Sie nach Möglichkeit vom Nutzer zurücksetzbare Kennungen aus. Die meisten Anwendungsfälle Ihrer App können auch mit anderen Kennungen als nicht zurücksetzbaren Hardware-IDs abgedeckt werden.

2. Verwenden Sie keine Hardwarekennungen. In den meisten Anwendungsfällen können Sie auf die Verwendung von Hardwarekennungen wie der IMEI (International Mobile Equipment Identity) verzichten, ohne die erforderlichen Funktionen einzuschränken.

   In Android 10 (API-Level 29) wurden Einschränkungen für nicht zurücksetzbare Kennungen hinzugefügt, darunter die IMEI und die Seriennummer. Ihre App muss eine Geräte- oder Profilinhaber-App sein, spezielle Mobilfunkanbieterberechtigungen haben oder die privilegierte Berechtigung READ_PRIVILEGED_PHONE_STATE haben, um auf diese Kennungen zuzugreifen.

3. Verwenden Sie eine Werbe-ID nur für die Erstellung von Nutzerprofilen oder für Werbezwecke. Wenn Sie eine Werbe-ID verwenden, müssen Sie immer die Entscheidungen der Nutzer zum Anzeigen-Tracking respektieren. Wenn Sie die Werbe-ID mit personenidentifizierbaren Informationen verknüpfen müssen, tun Sie dies nur mit der ausdrücklichen Zustimmung des Nutzers.

4. Verknüpfen Sie keine zurückgesetzten Werbe-IDs.

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

6. Verwenden Sie APIs, die für Ihren Anwendungsfall geeignet sind, um das Datenschutzrisiko zu minimieren. Verwende die DRM API für den Schutz hochwertiger Inhalte und die Play Integrity APIs für den Schutz vor Missbrauch. Die Play Integrity APIs sind die einfachste Möglichkeit, festzustellen, ob ein Gerät echt ist, ohne dass ein Datenschutzrisiko entsteht.

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

Mit Werbe-IDs arbeiten

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

Respektieren Sie immer die Absicht des Nutzers, wenn er die Werbe-ID zurücksetzt. Umgehe das Zurücksetzen der ID durch den Nutzer nicht, indem du eine andere Kennung oder einen anderen Fingerabdruck verwendest, um nachfolgende Werbe-IDs ohne die Einwilligung des Nutzers miteinander zu verknüpfen. In den Google Play-Inhaltsrichtlinien für Entwickler 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 sind konfigurierbar, sodass Nutzer das Tracking im Zusammenhang mit der ID einschränken können. Verwenden Sie immer die Methode AdvertisingIdClient.Info.isLimitAdTrackingEnabled(), um sicherzustellen, dass Sie die Wünsche Ihrer Nutzer nicht umgehen. In der Google Play-Inhaltsrichtlinie für Entwickler heißt es:

„…Sie müssen die Einstellung des Nutzers zur Deaktivierung interessenbezogener Werbung oder zur Deaktivierung 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.

Beachten Sie 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 Analytics SDK-Richtlinien lesen und einhalten.

Beachten Sie außerdem, dass die Google Play-Richtlinien für Entwickler zu Inhalten vorschreiben, dass die Werbe-ID „nicht mit personenidentifizierbaren Informationen oder gleichbleibenden Geräte-IDs wie SSAID, MAC-Adresse oder IMEI verknüpft werden“ darf.

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

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ürde gegen die Inhaltsrichtlinie für Google Play-Entwickler verstoßen, wenn Sie keine ausdrückliche Erlaubnis von Ihren Nutzern erhalten haben.

Beachten Sie, dass die Verknüpfungen zwischen Werbetreibenden-ID und personenidentifizierbaren Informationen nicht immer so eindeutig sind. Es ist möglich, dass „Quasi-Kennungen“ sowohl in Tabellen mit personenidentifizierbaren Informationen als auch in Tabellen mit Anzeigen-IDs vorkommen, was ebenfalls zu Problemen führt. Angenommen, wir ändern TABLE-01 und TABLE-02 so:

In diesem Fall ist es bei ausreichend seltenen Click-Events immer noch möglich, die Werbetreibenden-ID in TABELLE-01 und die personenidentifizierbaren Informationen in TABELLE-02 mithilfe des Zeitstempels des Ereignisses und des Gerätemodells zu verknüpfen.

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

Weitere Lösungen:

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

• Zugriffssteuerungslisten für Nutzer oder Rollen, die Zugriff auf die mit der Werbe-ID verschlüsselten Daten und personenidentifizierbaren Informationen haben, trennen und überwachen. Wenn Sie die Möglichkeit, gleichzeitig auf beide Quellen zuzugreifen (z. B. durch einen Join zwischen Tabellen), streng kontrollieren und prüfen, verringern Sie das Risiko einer Verknüpfung zwischen der Werbe-ID und personenidentifizierbaren Informationen. Im Allgemeinen bedeutet die Zugriffssteuerung Folgendes:

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

Weitere Informationen zum verantwortungsvollen Umgang mit Werbe-IDs finden Sie in der API-Referenz zu AdvertisingIdClient.

Mit FIDs und GUIDs arbeiten

Die einfachste Lösung, um eine auf einem Gerät ausgeführte App-Instanz zu identifizieren, ist die Verwendung einer Firebase-Installations-ID (FID). Dies ist die empfohlene Lösung für die meisten Anwendungsfälle, die nicht mit Werbung zusammenhängen. 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 beibehalten wird, wie die App installiert ist.

Daher bieten FIDs im Vergleich zu nicht zurücksetzbaren, gerätespezifischen Hardware-IDs einen besseren Datenschutz. Weitere Informationen finden Sie in der API-Referenz zu 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 geht das, indem Sie mit dem folgenden Code eine eigene GUID generieren:

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

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

Da die Kennung global eindeutig ist, kann sie zur Identifizierung einer bestimmten App-Instanz verwendet werden. Um Bedenken im Zusammenhang mit der Verknüpfung der Kennung über Apps hinweg zu vermeiden, sollten Sie GUIDs im internen statt im externen (freigegebenen) Speicher speichern. Weitere Informationen finden Sie auf der Seite Daten- und Dateispeicherung.

Nicht mit MAC-Adressen arbeiten

MAC-Adressen sind weltweit einmalig, können nicht vom Nutzer zurückgesetzt werden und bleiben auch nach dem Zurücksetzen auf die Werkseinstellungen erhalten. 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 bei der Verfügbarkeit von MAC-Adressen in 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 eine eindeutige MAC-Adresse basierend auf den folgenden Feldern generiert:

• Voll qualifizierter Domainname (FQDN)
• Bereich
• Anmeldedaten, basierend auf den im Passpoint-Profil verwendeten Anmeldedaten:
  • Nutzeranmeldedaten: Nutzername
  • Zertifikatsanmeldedaten: 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. 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 Funktion bind() nicht für 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 übergeordneten APIs von ConnectivityManager anstelle von untergeordneten APIs wie NetworkInterface, getifaddrs() oder Netlink-Sockets verwenden. Eine App, die aktuelle Informationen zu den aktuellen Routen benötigt, kann diese Informationen beispielsweise abrufen, indem sie mit ConnectivityManager.registerNetworkCallback() auf Netzwerkänderungen wartet und die zugehörige LinkProperties.getRoutes() des Netzwerks aufruft.

ID-Merkmale

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

Umfang

Der Bereich der Kennung gibt an, welche Systeme auf die Kennung zugreifen können. Android-Kennungen werden im Allgemeinen in drei Bereiche unterteilt:

• Einzelne App: Die ID ist intern für die App und für andere Apps nicht zugänglich.
• Gruppe von Apps: Die ID ist für eine vordefinierte Gruppe von ähnlichen Apps zugänglich.
• Gerät: Die ID ist für alle auf dem Gerät installierten Apps zugänglich.

Je größer der Umfang einer Kennung, desto größer ist das Risiko, dass sie für Tracking-Zwecke verwendet wird. Wenn eine Kennung nur von einer einzelnen App-Instanz abgerufen werden kann, kann sie nicht verwendet werden, um ein Gerät über Transaktionen in verschiedenen Apps hinweg zu verfolgen.

Zurücksetzbarkeit und Persistenz

Die Zurücksetzbarkeit und Persistenz definieren die Lebensdauer der Kennung und erklären, wie sie zurückgesetzt werden kann. Häufige Auslöser für das Zurücksetzen sind: Zurücksetzen in der App, Zurücksetzen über die Systemeinstellungen, Zurücksetzen beim Start und Zurücksetzen bei der Installation. Android-Kennungen können unterschiedlich lange Lebensdauern haben, die jedoch in der Regel davon abhängen, wie die ID zurückgesetzt wird:

• Nur für die Sitzung: Jedes Mal, wenn der Nutzer die App neu startet, wird eine neue ID verwendet.
• Installationszurücksetzung: Jedes Mal, wenn der 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.
• FDR-persistent: Die ID bleibt auch nach dem Zurücksetzen auf die Werkseinstellungen erhalten.

Durch die Möglichkeit zum Zurücksetzen können Nutzer eine neue ID erstellen, die von allen vorhandenen Profilinformationen getrennt ist. Je länger und zuverlässiger eine Kennung erhalten bleibt, z. B. eine Kennung, die auch nach dem Zurücksetzen auf die Werkseinstellungen erhalten bleibt, desto größer ist das Risiko, dass der Nutzer langfristig getrackt wird. Wenn die Kennung bei der Neuinstallation der App zurückgesetzt wird, wird die Persistenz verringert und die ID kann zurückgesetzt werden, auch wenn es keine explizite Nutzersteuerung zum Zurücksetzen in der App oder in den Systemeinstellungen gibt.

Eindeutigkeit

Die Eindeutigkeit bestimmt die Wahrscheinlichkeit von Konflikten, d. h., dass im zugehörigen Bereich identische Kennzeichnungen existieren. Auf der höchsten 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 zu ihrer Erstellung verwendet wurde. Beispielsweise ist die Wahrscheinlichkeit einer Kollision bei zufälligen Kennungen, die mit dem Kalenderdatum der Installation (z. B. 2019-03-01) generiert werden, viel höher als bei Kennungen, die mit dem Unix-Zeitstempel der Installation (z. B. 1551414181) generiert werden.

Im Allgemeinen können Nutzerkontokennungen als eindeutig angesehen werden. Das bedeutet, dass jede Kombination aus Gerät und Konto eine eindeutige ID hat. Je weniger eindeutig eine Kennung innerhalb einer Population ist, desto besser ist der Datenschutz, da sie sich weniger gut für das Tracking einzelner Nutzer eignet.

Integritätsschutz und Nichtabstreitbarkeit

Sie können eine Kennung verwenden, die schwer zu fälschen oder zu wiederholen ist, um nachzuweisen, dass das zugehörige Gerät oder Konto bestimmte Eigenschaften hat. Sie können beispielsweise nachweisen, dass es sich bei dem Gerät nicht um ein virtuelles Gerät handelt, das von einem Spammer verwendet wird. Schwer zu fälschende Kennungen bieten auch Nichtabstreitbarkeit. 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 Nichtabstreitbarkeit kann von Nutzern gewünscht sein, z. B. bei der Authentifizierung einer Zahlung, oder sie kann unerwünscht sein, z. B. wenn sie eine Nachricht senden, die sie bereuen.

Gängige Anwendungsfälle und die zu verwendende Kennung

In diesem Abschnitt finden Sie Alternativen zur Verwendung von Hardware-IDs wie der IMEI. Von der Verwendung von Hardware-IDs wird abgeraten, da der Nutzer sie nicht zurücksetzen kann und sie auf das Gerät beschränkt sind. In vielen Fällen reicht eine App-spezifische Kennung aus.

Konten

Netzbetreiberstatus

In diesem Fall interagiert deine App über ein Mobilfunkanbieterkonto mit den Telefon- und Nachrichtenversandfunktionen des Geräts.

Empfohlene Kennungen: IMEI, IMSI und Line1

Warum sehe ich diese Empfehlung?

Die Verwendung von Hardwarekennungen ist zulässig, wenn dies für netzbetreiberbezogene Funktionen erforderlich ist. Sie können diese Kennungen beispielsweise verwenden, um zwischen Mobilfunkanbietern oder SIM-Steckplätzen zu wechseln oder um SMS-Nachrichten über IP (für Line1) an SIM-basierte Nutzerkonten zu senden. Für nicht privilegierte Apps empfehlen wir jedoch, eine Kontoanmeldung zu verwenden, um Nutzergeräteinformationen serverseitig abzurufen. Ein Grund dafür ist, dass diese Kennungen unter Android 6.0 (API-Level 23) und höher nur über eine Laufzeitberechtigung verwendet werden können. Nutzer können diese Berechtigung deaktivieren. Ihre App sollte diese Ausnahmen daher ordnungsgemäß verarbeiten.

Status des mobilen Abos

In diesem Fall müssen Sie die App-Funktionen mit bestimmten Mobilfunkabos 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 prüfen.

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

Die Abo-ID ist ein Indexwert (beginnend bei 1), mit dem auf dem Gerät installierte SIM-Karten (einschließlich physischer und elektronischer SIM-Karten) eindeutig identifiziert werden können. Über diese ID kann deine 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 andere Abo-ID hat oder dass verschiedene SIM-Karten auf verschiedenen Geräten dieselbe ID haben.

Warum sehe ich diese Empfehlung?

Einige Apps verwenden dafür möglicherweise derzeit die ICC-ID. 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 wurde der Zugriff auf die ICCID über die API getIccId() weiter eingeschränkt, unabhängig vom Ziel-API-Level der App. Betroffene Apps sollten stattdessen die Abo-ID verwenden.

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: Mit dem Account Manager kompatible Konten, z. B. Google-Kontoverknüpfung

Warum sehe ich diese Empfehlung?

Mit der Google-Kontoverknüpfung können Nutzer ihr bestehendes Google-Konto 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.

Anzeigen

Targeting

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

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

Warum sehe ich diese Empfehlung?

Dies ist ein werbebezogener Anwendungsfall, für den 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. Gemäß der Inhaltsrichtlinie für Google Play-Entwickler ist die Verwendung der Werbe-ID für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

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

Messung

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

Empfohlene Kennung:Werbe-ID oder Play Install Referrer API

Warum sehe ich diese Empfehlung?

Dies ist ein werbebezogener Anwendungsfall, für den 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 für Werbezwecke verwenden, muss dies die Werbe-ID sein, da der Nutzer sie zurücksetzen kann. Weitere Informationen findest du in den Inhaltsrichtlinien für Google Play-Entwickler.

Conversions

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

Empfohlene Kennung:Werbe-ID oder Play Install Referrer API

Warum sehe ich diese Empfehlung?

Dies ist ein werbebezogener Anwendungsfall, für den 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. Gemäß der Inhaltsrichtlinie für Google Play-Entwickler ist die Verwendung der Werbe-ID für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

Remarketing

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

Empfohlene ID: Werbe-ID

Warum sehe ich diese Empfehlung?

Dies ist ein werbebezogener Anwendungsfall, für den 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. Gemäß der Inhaltsrichtlinie für Google Play-Entwickler ist die Verwendung der Werbe-ID für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

App-Analysen

In diesem Fall wertet Ihre App das Verhalten eines Nutzers aus, um Folgendes zu ermitteln:

• Welche anderen Produkte oder Apps Ihrer Organisation für den Nutzer geeignet sein könnten.
• Wie Sie das Interesse der Nutzer an Ihrer App aufrechterhalten
• 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 analysieren, die Ihrer Organisation gehören, solange Sie die Nutzerdaten nicht für Werbezwecke verwenden. Wenn Sie auf Geräte mit Google Play-Diensten abzielen, empfehlen wir die Verwendung der App-Set-ID.
• Firebase-ID (FID): Eine FID ist auf die App beschränkt, von der sie erstellt wird. Dadurch wird verhindert, dass die Kennung verwendet wird, um Nutzer über mehrere Apps hinweg zu verfolgen. Sie lässt sich auch leicht zurücksetzen, da der Nutzer die App-Daten löschen oder die App neu installieren kann. Das Erstellen einer FID ist unkompliziert. Weitere Informationen finden Sie im Firebase-Installationsleitfaden.

Anwendungsentwicklung

Absturzberichte

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

Empfohlene Kennung:FID oder App-Set-ID

Warum sehe ich diese Empfehlung?

Eine FID ist auf die App beschränkt, von der sie erstellt wird. Dadurch wird verhindert, dass die Kennung verwendet wird, um Nutzer über mehrere Apps hinweg zu verfolgen. Sie kann auch einfach zurückgesetzt werden, da der Nutzer die App-Daten löschen oder die App neu installieren kann. Die Erstellung einer FID ist unkompliziert. Weitere Informationen finden Sie in der Installationsanleitung für Firebase. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers in mehreren Apps analysieren, die Ihrer Organisation gehören, sofern Sie die Nutzerdaten nicht für Werbezwecke verwenden.

Leistungsberichte

In diesem Fall werden in Ihrer App Leistungsmesswerte wie Ladezeiten und Akkunutzung erhoben, um die Qualität Ihrer App zu verbessern.

Empfohlene Kennung: 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 vorgenommenen Änderung in Ihrer App testen.

Anwendungen testen

In diesem Fall wird die Nutzung Ihrer App durch einen Nutzer zu Test- oder Debugging-Zwecken ausgewertet.

Empfohlene Kennung:FID oder App-Set-ID

Warum sehe ich diese Empfehlung?

Eine FID ist auf die App beschränkt, von der sie erstellt wird. Dadurch wird verhindert, dass die Kennung verwendet wird, um Nutzer über mehrere Apps hinweg zu verfolgen. Sie kann auch einfach zurückgesetzt werden, da der Nutzer die App-Daten löschen oder die App neu installieren kann. Die Erstellung einer FID ist unkompliziert. Weitere Informationen finden Sie in der Installationsanleitung für Firebase. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers in mehreren Apps analysieren, die Ihrer Organisation gehören, sofern Sie die Nutzerdaten nicht für Werbezwecke 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 ist explizit für diesen Zweck konzipiert. Ihr Umfang ist auf die App beschränkt, sodass sie nicht zum Tracking von Nutzern über verschiedene Apps hinweg verwendet werden kann. Außerdem wird sie 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

Missbrauchserkennung

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

Empfohlene Kennung: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 stammt und nicht von einem Emulator oder anderem 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 ID: Werbe-ID

Warum sehe ich diese Empfehlung?

Gemäß der Inhaltsrichtlinie für Google Play-Entwickler ist die Verwendung der Werbe-ID für Werbezwecke obligatorisch, da sie vom Nutzer zurückgesetzt werden kann.

Digitale Rechteverwaltung

In diesem Fall möchte deine App den betrügerischen Zugriff auf geistiges Eigentum oder kostenpflichtige Inhalte verhindern.

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 dieser Schutz nicht ausreicht, 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 gerätespezifischen Nutzerstatus in Ihrer App, insbesondere für Nutzer, die nicht angemeldet sind. Sie können diesen Status auf eine andere App übertragen, die mit demselben Schlüssel auf demselben Gerät signiert ist.

Empfohlene ID:FID oder GUID

Warum sehe ich diese Empfehlung?

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