Best Practices für eindeutige Kennzeichnungen

In diesem Dokument erfahren Sie, wie Sie geeignete Kennzeichnungen für Ihr für Ihren Anwendungsfall.

Allgemeine Informationen zu Android-Berechtigungen finden Sie unter Berechtigungen – Übersicht. Für bestimmte 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

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 vom Nutzer zurücksetzbare Kennungen. Ihre App kann können die meisten Anwendungsfälle auch dann erreicht werden, wenn andere Kennungen als nicht rücksetzbaren Hardware-IDs.

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) fügt Einschränkungen für nicht zurücksetzbare Kennungen hinzu, die sowohl die IMEI als auch die Seriennummer enthält. Bei Ihrer App muss es sich um ein Gerät oder Profilinhaber App, haben einen speziellen Mobilfunkanbieter Berechtigungen oder haben die privilegierte Berechtigung READ_PRIVILEGED_PHONE_STATE, um auf diese IDs.

3. Verwenden Sie eine Werbe-ID nur für die Nutzerprofilerstellung oder für Anwendungsfälle von Anzeigen. 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. Überbrücken Sie das Zurücksetzen von Werbe-IDs nicht.

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 dass ein Datenschutzrisiko entsteht.

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 Kennung, die vom Nutzer zurückgesetzt werden kann und für Anzeigen geeignet ist. Anwendungsfälle. Es gibt jedoch einige wichtige Punkte zu beachten, wenn Sie dieses ID:

Achten Sie immer darauf, dass Sie die Werbe-ID nur dann zurücksetzen, wenn der Nutzer dies möchte. Nutzerrücksetzungen nicht mithilfe einer anderen Kennung oder eines anderen Fingerabdrucks verknüpfen Werbe-IDs gemeinsam verwenden, ohne der Einwilligung des Nutzers. Die Google Play-Entwicklerinhalte legt die Folgendes:

„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 die zugehörige Markierung für personalisierte Anzeigen. Werbe-IDs sind ist so konfigurierbar, dass Nutzer den Umfang des Trackings, das mit der ID. Verwenden Sie immer die Methode AdvertisingIdClient.Info.isLimitAdTrackingEnabled(), damit Sie die Wünsche Ihrer Nutzer nicht umgehen. In den Google Play-Richtlinien für Entwicklerinhalte heißt es:

"...müssen Sie die vom Nutzer gewählte Einstellung zur Deaktivierung interessenbezogener Werbung befolgen. oder „Personalisierte Werbung deaktivieren“ Einstellung. Wenn ein Nutzer diese Einstellung aktiviert hat, dürfen Sie die Werbe-ID nicht zur Erstellung von Nutzerprofilen für Werbezwecken oder zur Ausrichtung personalisierter Anzeigen auf Nutzer. Zulässig sind hingegen kontextbezogene Werbung, Frequency Capping, Conversion-Tracking, die Erstellung von Berichten sowie Sicherheits- und Betrugserkennung."

Achten Sie auf Datenschutz- und Sicherheitsrichtlinien in Bezug auf die von Ihnen verwendeten SDKs, die sich auf die Verwendung der Werbe-ID beziehen. 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:

In diesem Beispiel könnte die Spalte ad_id über account_id mit personenidentifizierbaren Informationen zusammengeführt werden. Spalte in beiden Tabellen enthält, was einen Verstoß gegen die Google Play Developer Console- Inhaltsrichtlinien, 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. Nehmen wir beispielsweise an, wir ändern TABLE-01 und TABLE-02:

In diesem Fall ist es mit ausreichend seltenen Klickereignissen möglich, zwischen der Werbetreibenden-ID TABLE-01 und den in TABLE-02 enthaltenen personenidentifizierbaren Informationen mithilfe der Methode Zeitstempel des Ereignisses und Gerätemodell.

Auch wenn es oft schwierig ist, zu garantieren, dass solche Quasi-Identifikatoren nicht existieren in einem Dataset können Sie die offensichtlichsten Join-Risiken verhindern, indem Sie eindeutige Daten enthalten. 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 sind:

• Es werden keine Tabellen entworfen, die personenidentifizierbare Informationen explizit mit Werbe-IDs verknüpfen. In im ersten Beispiel oben bedeutet dies, dass die Spalte account_id nicht berücksichtigt wird. in TABLE-01.

• Zugriffssteuerungslisten für Nutzer oder Rollen trennen und beobachten, die Zugriff sowohl auf die Werbe-ID-Daten als auch auf personenidentifizierbare Informationen haben Durch die genaue Kontrolle und Prüfung der Zugriffsmöglichkeiten auf beide Quellen gleichzeitig (z. B. durch einen JOIN zwischen Tabellen), reduzieren Sie das Risiko einer Verknüpfung zwischen der Werbe-ID und personenidentifizierbaren Informationen. Im Allgemeinen bedeutet die Zugriffssteuerung Folgendes:

  1. Access Control Lists (ACLs) für Daten, die mit der Werbetreibenden-ID verknüpft sind, und personenidentifizierbare Informationen aufbewahren voneinander getrennt sind, um die Anzahl der Personen oder Rollen zu minimieren, ACLs.
  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 Anwendungsinstanz, für die auf diese Kennung zugreifen, und sie ist (relativ) leicht zurücksetzbar, da sie nur so lange bestehen bleiben, 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. Die einfachste Generieren Sie dazu Ihre eigene GUID mit folgendem Code:

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

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

Da die ID global eindeutig ist, kann sie verwendet werden, um eine bestimmte Anwendungsinstanz. 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 unter Daten- und Dateispeicherung .

Funktioniert nicht mit MAC-Adressen

MAC-Adressen sind global eindeutig, können nicht vom Nutzer zurückgesetzt werden und bestehen nach dem Werk wird zurückgesetzt. 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 auf sie nicht zugreifen können.

Ä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-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. nur sind Netzwerkschnittstellen mit einer IP-Adresse sichtbar. Dies wirkt sich auf die getifaddrs() und NetworkInterface.getHardwareAddress() sowie zum Senden von RTM_GETLINK Netlink-Nachrichten.

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 Eigenschaften für Ihren Anwendungsfall geeignet sind. Diese Eigenschaften haben auch Auswirkungen auf den Datenschutz, Daher ist es wichtig zu verstehen, wie diese Eigenschaften sich gegenseitig helfen.

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 App-intern und kann nicht für andere Apps verwendet werden.
• Gruppe von Apps: Die ID ist für eine vordefinierte Gruppe ähnlicher 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 ist, desto höher ist das Risiko, dass sie zu Tracking-Zwecken verwendet wird. Umgekehrt gilt: Wenn auf eine Kennung nur eine einzelne App-Instanz haben, kann sie nicht verwendet werden, um ein Gerät transaktionsübergreifend zu verfolgen. in verschiedenen Apps.

Rücksetzbarkeit und Persistenz

Rücksetzbarkeit und Persistenz definieren die Lebensdauer der Kennung und erklären, wie es zurückgesetzt werden kann. Häufige Auslöser für das Zurücksetzen sind u. a. das Zurücksetzen in der App oder über Systemeinstellungen. Wird beim Start und bei der Installation zurückgesetzt. Android-Geräte Kennzeichnungen können unterschiedliche Lebenserwartungen haben, aber die Lebenserwartung hängt in der Regel damit zusammen. wie die ID zurückgesetzt wird:

• Nur Sitzung: Jedes Mal, wenn der Nutzer die App neu startet, wird eine neue ID verwendet.
• Installation – Zurücksetzen: Bei jeder Deinstallation und Neuinstallation der App wird eine neue ID verwendet. in der App.
• FDR-reset (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 über das 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 wird die ID bei der Neuinstallation der App zurückgesetzt. bietet eine Möglichkeit zum Zurücksetzen der ID, auch wenn kein expliziter Nutzer um ihn über die App oder die Systemeinstellungen zurückzusetzen.

Eindeutigkeit

Die Eindeutigkeit bestimmt die Wahrscheinlichkeit von Konflikten. Das heißt, dass identische Kennzeichnungen im zugehörigen Bereich vorhanden sind. Auf höchster Ebene, eindeutige ID, auch nicht auf anderen Geräten oder in anderen Apps, kollidiert. Andernfalls hängt der Grad der Eindeutigkeit von der Entropie der Kennung und die Quelle der Zufälligkeit, die bei der Erstellung verwendet wurde. Zum Beispiel kann die Chance, ist die Kollision viel höher für Zufallskennungen, die mit dem Kalenderdatum (z. B. 2019-03-01) als für IDs, die mit Unix- Zeitstempel der Installation (z. B. 1551414181).

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 einzigartig ist, eine ID zu einer Population gehört, desto besser ist der Datenschutz, ist dies weniger nützlich, wenn es darum geht, einen einzelnen Nutzer zu verfolgen.

Integritätsschutz und Nachweisbarkeit

Sie können eine ID verwenden, die sich nur schwer fälschen oder wiedergeben lässt, 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. Kennungen, die schwer zu fälschen sind, sorgen außerdem für unzuverlässige Identifizierung. Wenn das Gerät eine Nachricht mit einem geheimen Schlüssel signiert, ist es schwierig, zu behaupten, 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 IMEI. Mit Hardware-IDs wird nicht empfohlen, da der Nutzer sie nicht zurücksetzen kann die dem Gerät zugeordnet sind. In vielen Fällen reicht eine Kennung auf App-Ebene aus.

Konten

Status des Mobilfunkanbieters

In diesem Fall interagiert die App mit dem Smartphone des Geräts und sendet über das Konto des Mobilfunkanbieters.

Empfohlene Kennung: IMEI, IMSI und Line1

Warum sehe ich diese Empfehlung?

Die Verwendung von Hardwarekennungen ist akzeptabel, wenn sie für die auf den jeweiligen Mobilfunkanbieter bezogen sind. 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: Abo-ID API für die im Gerät verwendeten SIM-Karten identifizieren.

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 können die Funktionen Ihrer App verschiedenen Aboinformationen für eine bestimmte SIM-Karte. 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 Fälle geben, in denen dieselben SIM hat auf verschiedenen Geräten eine andere Abo-ID oder auf verschiedenen SIM-Karten dieselbe ID auf verschiedenen Geräten.

Warum sehe ich diese Empfehlung?

Einige Apps verwenden derzeit möglicherweise ICC. ID dafür zu verstehen. Da die ICC-ID global eindeutig ist und nicht rücksetzbar ist, wurde auf Apps mit READ_PRIVILEGED_PHONE_STATE beschränkt Berechtigung seit Android 10. 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 migriert werden zu Verwende stattdessen die Abo-ID.

Einmalanmeldung (SSO)

In diesem Fall bietet Ihre App eine Einmalanmeldung (SSO), mit der Nutzer ein bestehendes Konto mit Ihrer Organisation zu verknüpfen.

Empfohlene zu verwendende Kennung: Mit Account Managern kompatible Konten, z. B.: Google-Kontoverknüpfung

Warum sehe ich 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, Anzeigen mit höherer Relevanz.

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

Warum sehe ich diese Empfehlung?

Dies ist ein anzeigenbezogener Anwendungsfall, für den möglicherweise eine ID erforderlich ist, die in den verschiedenen Apps Ihrer Organisation. Die Verwendung einer Werbe-ID am besten geeignet ist. 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 zu verwendende Kennung:Werbe-ID oder Referrer API für die Play-Installation

Warum sehe ich diese Empfehlung?

Dies ist ein anzeigenbezogener Anwendungsfall, für den möglicherweise eine ID erforderlich ist, die in den verschiedenen Apps Ihrer Organisation. Die Verwendung einer Werbe-ID am besten geeignet ist. 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 der Google Play-Inhaltsrichtlinien für Entwickler

Conversions

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

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

Warum sehe ich diese Empfehlung?

Dies ist ein anzeigenbezogener Anwendungsfall, für den möglicherweise eine ID erforderlich ist, die in den verschiedenen Apps Ihrer Organisation. Die Verwendung einer Werbe-ID am besten geeignet ist. Die Verwendung der Werbe-ID ist obligatorisch für im Bereich Werbung, gemäß den Google Play-Inhaltsrichtlinien für Entwickler 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 Kennung: Werbe-ID

Warum diese Empfehlung?

Bei diesem nutzungsbezogenen 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. Die Verwendung der Werbe-ID ist obligatorisch für im Bereich Werbung, gemäß den Google Play-Inhaltsrichtlinien für Entwickler da der Nutzer sie zurücksetzen kann.

App-Analyse

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

• Welche anderen Produkte oder Apps Ihrer Organisation könnten für die Nutzer.
• 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. Bei der Ausrichtung auf Geräte, die von Google Play bereitgestellt werden empfehlen wir die Verwendung der App-Set-ID.
• Firebase-ID (FID): Eine FID ist der App zugeordnet, von der sie erstellt wurde. verhindert, dass die ID verwendet wird, um Nutzer über Apps hinweg nachzuverfolgen. Es ist auch einfach zurücksetzbar, da der Nutzer App-Daten löschen oder die App neu installieren kann. Die Die Erstellung einer FID ist ganz einfach: Firebase-Installationen ansehen .

App-Entwicklung

Absturzberichte

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

Empfohlene Kennung: FID oder App-Set-ID

Warum diese Empfehlung?

Eine FID ist auf die Anwendung beschränkt, von der sie erstellt wird. Dadurch wird verhindert, dass die Kennung um Nutzer über verschiedene Apps hinweg zu beobachten. Sie lässt sich auch leicht zurücksetzen, kann App-Daten löschen oder die App neu installieren. Der Prozess zum Erstellen einer FID unkompliziert; sieh dir die Firebase-Installationsanleitung 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 erfasst Ihre App Leistungsmesswerte wie Ladezeiten und Akkunutzung, um die Qualität deiner App zu verbessern.

Empfohlene Kennzeichnung: Firebase Performance Monitoring

Warum diese Empfehlung?

Mit Firebase Performance Monitoring können Sie sich auf die wichtigsten Messwerte konzentrieren und die Auswirkungen einer kürzlich vorgenommenen Änderung an Ihrer App zu 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 Anwendung beschränkt, die sie erstellt. Dadurch wird verhindert, dass die Kennung um Nutzer über verschiedene Apps hinweg zu beobachten. Außerdem lässt sich die FID 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, für einen Nutzer auf mehreren Geräten installiert ist.

Empfohlene Kennzeichnung:FID oder GUID

Warum diese Empfehlung?

Eine FID ist explizit für diesen Zweck vorgesehen. ist der Geltungsbereich auf die damit Nutzer über verschiedene Apps hinweg nicht nachverfolgt werden können. die bei der Neuinstallation der App zurückgesetzt werden. In den seltenen Fällen, in denen eine FID nicht ausreichend ist, 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 Kennzeichnung:das Integritätstoken der Google Play Integrity API

Warum sehe ich diese Empfehlung?

Um zu überprüfen, ob eine Anfrage von einem echten Android-Gerät und nicht von einem oder anderen Code-Spoofing-Code, der auf einem anderen Gerät auftritt, verwenden Sie Google Play Integrity API

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?

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

Digitale Rechteverwaltung

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 mühsam. 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 auf dem jeweiligen Gerät, insbesondere für nicht angemeldete Nutzer. Sie können diesen Status auf eine andere App übertragen, die auf demselben Gerät mit demselben Schlüssel signiert ist.

Empfohlene Kennzeichnung:FID oder GUID

Warum diese Empfehlung?

Wir raten davon ab, Informationen auch bei Neuinstallationen beizubehalten, Einstellungen durch eine Neuinstallation der App zurücksetzen möchten.