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 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) enthält Einschränkungen für nicht zurücksetzbare Kennungen, einschließlich IMEI und Seriennummer. 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. Wann? mit einer Werbe-ID, respektieren Sie immer die Auswahlmöglichkeiten in Bezug auf Anzeigen-Tracking verwenden. Wenn müssen Sie die Werbe-ID mit der personenidentifizierbaren Informationen dürfen nur mit der ausdrücklichen Zustimmung der Nutzer.

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. Bei den meisten Anwendungsfällen ohne Anzeigen ist eine FID oder GUID ausreichend sein.

6. Für Ihren Anwendungsfall geeignete APIs verwenden, um den Datenschutz zu minimieren Risiko. 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 kannst du am einfachsten feststellen, ob ein Gerät authentisch sind, ohne den Datenschutz zu gefährden.

In den verbleibenden Abschnitten dieses Leitfadens werden diese Regeln im Kontext der für die Entwicklung von Android-Apps.

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:

Respektiere immer die Absicht des Nutzers beim Zurücksetzen der Werbe-ID. Nutzer-Resets dürfen nicht überbrückt werden, indem eine andere Kennung oder ein anderer Fingerabdruck verwendet wird, um nachfolgende Werbe-IDs ohne die Einwilligung des Nutzers zu verknüpfen. 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 das zugehörige Flag 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. Die Google Google Play-Entwicklerinhalte legt die Folgendes:

„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 zur Erstellung von Nutzerprofilen für Werbezwecken oder zur Ausrichtung personalisierter Anzeigen auf Nutzer. Zu den zulässigen Aktivitäten gehören kontextbezogene Werbung, Frequency Capping, Conversion- Tracking, Berichterstellung, Sicherheit 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.

Beachten Sie außerdem, dass die Inhalte für Google Play-Entwickler Richtlinie erfordert dass die Werbe-ID "nicht mit personenidentifizierbaren Informationen oder mit dauerhaften Geräte-IDs verknüpft sind (z. B. SSAID, MAC-Adresse, IMEI usw.).“

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 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. Quasi-Identifikatoren sind möglich. die sowohl in den personenidentifizierbaren Informationen Tabellen mit Anzeigen-ID-Schlüssel, die ebenfalls Probleme verursachen. Angenommen, wir ändern TABELLE-01 und TABELLE-02 so:

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.

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 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 der Zugriffssteuerung Folgendes zu tun:

  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. Zugriffs-Logging und -Prüfung implementieren, um Ausnahmen zu erkennen und zu verwalten auf diese Regel anwenden.

Weitere Informationen zum verantwortungsvollen Umgang mit Werbe-IDs findest du in der AdvertisingIdClient API-Referenz

Mit FIDs und GUIDs arbeiten

Die einfachste Lösung, um eine Anwendungsinstanz zu identifizieren, die auf einer ist die Verwendung einer Firebase-Installations-ID (FID). Dies ist die empfohlene in den meisten Anwendungsfällen, die keine Anzeigen sind, eine Lösung. 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 firebase.installations API-Referenz

Falls eine FID nicht praktikabel ist, können Sie auch benutzerdefinierte global eindeutige IDs (GUIDs) zur eindeutigen Identifizierung einer Anwendungsinstanz. Am einfachsten ist es, eine eigene GUID mit dem folgenden Code zu generieren:

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

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 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, MAC-Zufallsauswahl für Passpoint Netzwerke pro Passpoint-Profil an und generiert eine eindeutige MAC-Adresse basierend auf dem folgenden Feldern:

• Voll qualifizierter Domainname (FQDN)
• Bereich
• Anmeldedaten, basierend auf den im Passpoint-Profil verwendeten Anmeldedaten:
  • 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 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. Beispiel: Eine App, die aktuelle Informationen zur Aktuelle Routen können diese Informationen abrufen, indem sie mit ConnectivityManager.registerNetworkCallback() auf Netzwerkänderungen warten und das Aufrufen der zugehörigen LinkProperties.getRoutes()

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 funktionieren. Ihren Anwendungsfall. 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. Android-Geräte gibt es im Allgemeinen 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: Die ID ist für alle auf dem Gerät installierten Apps zugänglich.

Je breiter der Geltungsbereich einer Kennung ist, desto größer ist das Risiko, die für Tracking-Zwecke verwendet werden. 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.
• 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 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.

Einzigartigkeit

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. So ist die Wahrscheinlichkeit einer Kollision beispielsweise bei zufälligen Kennungen, die mit dem Kalenderdatum der Installation (z. B. 2019-03-01) initialisiert wurden, viel höher als bei Kennungen, die mit dem Unix-Zeitstempel der Installation (z. B. 1551414181) initialisiert wurden.

Nutzerkonto-IDs werden im Allgemeinen als eindeutig betrachtet. Das heißt, jede Die Kombination aus Gerät und Konto hat eine eindeutige ID. 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 Kennung verwenden, die schwer zu fälschen oder zu wiederholen ist, um nachzuweisen, dass der verknüpftes Gerät oder Konto bestimmte Eigenschaften hat. Zum Beispiel könnten Sie Nachweis, dass das Gerät kein virtuelles Gerät ist, 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, dass das Gerät einer anderen Person die Nachricht gesendet hat. Die Nicht-Überprüfbarkeit könnte etwas sein, das Nutzende wollen, wie etwa bei der Authentifizierung einer Zahlung. Es könnte sich auch um eine unerwünschte Eigenschaft handeln, als 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 die App mit dem Smartphone des Geräts und sendet über das Konto des Mobilfunkanbieters.

Empfohlene Kennzeichnung: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. Mit diesen Kennungen können Sie beispielsweise zwischen Mobilfunkanbietern oder SIM-Steckplätzen wechseln oder SMS über IP (für Zeile 1) – SIM-basierte Nutzerkonten. 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 von Mobilfunkabo

In diesem Fall müssen Sie App-Funktionen bestimmten mobilen Dienstabos auf dem Gerät. Beispielsweise kann es erforderlich sein, den Zugriff auf bestimmte Premium-App-Funktionen basierend auf dem über die SIM-Karte.

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

Die Abo-ID stellt einen Indexwert (beginnend mit 1) für eindeutige die eingebauten SIM-Karten identifiziert (einschließlich physischer und elektronischer SIM-Karten), die auf dem . Ü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, Android den Zugriff auf die ICCID über die getIccId() API unabhängig vom Ziel-API-Level der App. 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 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.

Unabhängig davon, ob Sie Nutzerdaten in Ihrer App teilen, wenn Sie diese erheben und verwenden zu Werbezwecken müssen Sie die Werbezwecke in der Abschnitt zur Datensicherheit der Seite App-Inhalte in der Play Console.

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 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. 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 zu verwendende Kennung:Werbe-ID oder Referrer API für die Play-Installation

Warum 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.

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?

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.

App-Analyse

In diesem Fall bewertet Ihre App das Verhalten der Nutzer, um zu ermitteln, Folgendes:

• Welche anderen Produkte oder Apps Ihrer Organisation könnten für den Nutzer geeignet sein.
• So halten Sie das Interesse der Nutzer an Ihrer App aufrecht.
• 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 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 auf die App beschränkt, in der sie erstellt wird. Dadurch kann die Kennung nicht verwendet werden, um Nutzer über Apps hinweg zu erfassen. 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 darüber, wann und warum sie Geräte der Nutzer.

Empfohlene Kennung: FID oder App-Set-ID

Warum sehe ich 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. 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 Ihrer App zu verbessern.

Empfohlene Kennung: 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 bewertet Ihre App die Nutzererfahrung mit Ihrer App zu Testzwecken. oder zur Fehlerbehebung.

Empfohlene Kennung: FID oder App-Set-ID

Warum sehe ich 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 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 ermitteln, wenn sie für denselben Nutzer auf mehreren Geräten installiert ist.

Empfohlene Kennung: 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 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 von Nutzern in Ihrer App echt und überprüfbar sind.

Empfohlene Kennung: Werbe-ID

Warum sehe ich 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 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 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 mit demselben Schlüssel auf demselben Gerät signiert ist.

Empfohlene Kennzeichnung:FID oder GUID

Warum sehe ich diese Empfehlung?

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