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.

Einen allgemeinen Überblick ü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-Kennzeichnungen

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

  1. Verwenden Sie nach Möglichkeit vom Nutzer zurücksetzbare IDs. Die meisten Anwendungsfälle Ihrer App können auch dann erfüllt werden, wenn sie andere Kennungen als nicht zurücksetzbare Hardware-IDs verwendet.

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

    In Android 10 (API-Level 29) wurden Einschränkungen für nicht zurücksetzbare Kennungen eingeführt, zu denen sowohl die IMEI als auch die Seriennummer gehören. Ihre App muss eine App für den Geräte- oder Profilinhaber sein, besondere Berechtigungen des Mobilfunkanbieters haben oder die Berechtigung READ_PRIVILEGED_PHONE_STATE haben, um auf diese IDs zugreifen zu können.

  3. Verwenden Sie eine Werbe-ID nur für die Erstellung von Nutzerprofilen oder für Werbezwecke. Wenn Sie eine Werbe-ID verwenden, müssen Sie immer die Auswahl der Nutzer in Bezug auf das Ad-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. Werbe-ID-Zurücksetzungen nicht überbrücken.

  5. Verwenden Sie nach Möglichkeit für alle anderen Anwendungsfälle eine Firebase-Installations-ID (FID) oder eine privat gespeicherte GUID, mit Ausnahme der Betrugsprävention bei Zahlungen und der Telefonie. 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. Verwenden Sie die DRM API zum Schutz hochwertiger Inhalte und die Play Integrity APIs zum Schutz vor Missbrauch. Die Play Integrity APIs sind die einfachste Möglichkeit, festzustellen, ob ein Gerät echt ist, ohne das Risiko zu bergen, die Privatsphäre der Nutzer zu verletzen.

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 Werbezwecke. Bei der Verwendung dieser ID sind jedoch einige wichtige Punkte zu beachten:

Die Absicht des Nutzers, die Werbe-ID zurückzusetzen, muss immer respektiert werden. Nutzer-Resets dürfen nicht durch die Verwendung einer anderen ID oder eines Fingerprints überbrückt werden, um nachfolgende Werbe-IDs ohne 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.“

Das zugehörige Flag für personalisierte Anzeigen muss immer berücksichtigt werden. Werbe-IDs sind konfigurierbar, da Nutzer die Menge der mit der ID verknüpften Daten begrenzen können. Verwenden Sie immer die Methode AdvertisingIdClient.Info.isLimitAdTrackingEnabled(), um sicherzustellen, dass Sie die Wünsche Ihrer Nutzer nicht umgehen. In den Google Play-Inhaltsrichtlinien für Entwickler 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 verknüpft sind und sich auf die Verwendung von Werbe-IDs beziehen. Wenn Sie beispielsweise true über die Methode enableAdvertisingIdCollection() aus dem Google Analytics SDK übergeben, müssen Sie alle anwendbaren Richtlinien für das Analytics SDK lesen und einhalten.

Außerdem ist gemäß der Google Play-Richtlinie für Entwicklerinhalte die Werbe-ID „nicht mit personenidentifizierbaren Informationen oder gleichbleibenden Geräte-IDs wie SSAID, MAC-Adresse oder IMEI zu verknüpfen“.

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

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

In diesem Beispiel könnte die Spalte ad_id über die Spalte account_id in beiden Tabellen mit personenbezogenen Daten verknüpft werden. Das wäre ein Verstoß gegen die Inhaltsrichtlinie für Google Play-Entwickler, wenn Sie keine ausdrückliche Einwilligung Ihrer Nutzer eingeholt haben.

Die Verknüpfung zwischen der Werbetreibenden-ID und personenbezogenen Daten ist nicht immer so explizit. Es ist möglich, dass „Quasi-Identifier“ sowohl in Tabellen mit personenidentifizierbaren Informationen als auch in Tabellen mit Anzeigen-IDs vorkommen, was ebenfalls Probleme verursacht. Angenommen, wir ändern TABLE-01 und TABLE-02 so:

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

In diesem Fall ist es bei ausreichend seltenen Klickereignissen weiterhin möglich, die Advertiser ID TABLE-01 und die in TABLE-02 enthaltenen personenbezogenen Daten anhand des Zeitstempels des Ereignisses und des Gerätemodells zu verknüpfen.

Es ist oft schwierig, zu garantieren, dass keine solchen Quasi-Identifier in einem Dataset vorhanden sind. Sie können jedoch die offensichtlichsten Join-Risiken vermeiden, indem Sie eindeutige Daten nach Möglichkeit verallgemeinern. Im vorherigen Beispiel würde das 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 erstellen, in denen personenidentifizierbare Informationen explizit mit Werbe-IDs verknüpft werden: Im ersten Beispiel oben würde das bedeuten, dass die Spalte account_id nicht in TABLE-01 enthalten ist.

  • Zugriffskontrolllisten für Nutzer oder Rollen, die sowohl auf die mit der Werbe-ID verschlüsselten Daten als auch auf personenbezogene Daten zugreifen können, trennen und überwachen: Wenn Sie den gleichzeitigen Zugriff auf beide Quellen (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 Zugriffssteuerungslisten (Access Control Lists, ACLs) für Daten mit Advertiser-ID und personenidentifizierbare Informationen (PII) getrennt, um die Anzahl der Personen oder Rollen zu minimieren, die in beiden ACLs enthalten sind.
    2. Implementieren Sie die Protokollierung und Prüfung des Zugriffs, um alle Ausnahmen von dieser Regel zu erkennen und zu verwalten.

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

Mit FIDs und GUIDs arbeiten

Die einfachste Lösung zum Identifizieren einer App-Instanz, die auf einem Gerät ausgeführt wird, ist die Verwendung einer Firebase-Installations-ID (FID). Dies ist die empfohlene Lösung für die meisten Anwendungsfälle, die nicht mit Anzeigen 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 vorhanden ist, wie die App installiert ist.

Daher bieten FIDs einen besseren Datenschutz als nicht zurücksetzbare, gerätespezifische Hardware-IDs. Weitere Informationen finden Sie in der API-Referenz für firebase.installations.

In Fällen, in denen 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, wenn Sie Ihre eigene GUID mit dem folgenden Code generieren:

Kotlin

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

Java

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

Da die Kennung weltweit eindeutig ist, kann sie verwendet werden, um eine bestimmte App-Instanz zu identifizieren. Um Bedenken im Zusammenhang mit der Verknüpfung der Kennung über Apps hinweg zu vermeiden, sollten Sie GUIDs im internen Speicher anstelle des externen (gemeinsamen) Speichers speichern. Weitere Informationen finden Sie auf der Seite Datenspeicher und Dateispeicher – Übersicht.

Nicht mit MAC-Adressen arbeiten

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 ist der Zugriff auf MAC-Adressen in Android-Versionen 6 und höher zum Schutz der Privatsphäre der Nutzer auf System-Apps beschränkt. Drittanbieter-Apps können nicht darauf zugreifen.

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

In Apps, die auf Android 11 und höher ausgerichtet sind, erfolgt die MAC-Adress-Randomisierung für Passpoint-Netzwerke pro Passpoint-Profil. Dabei wird eine eindeutige MAC-Adresse basierend auf den folgenden Feldern generiert:

  • Vollständig 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 APIs der höheren Ebene von ConnectivityManager anstelle von APIs der niedrigeren Ebene 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.

Kennzeichnungsmerkmale

Das Android-Betriebssystem bietet eine Reihe von IDs mit unterschiedlichen Verhaltensmerkmalen. Welche ID Sie verwenden sollten, hängt davon ab, wie die folgenden Merkmale zu Ihrem Anwendungsfall passen. Diese Merkmale haben jedoch auch Auswirkungen auf den Datenschutz. Daher ist es wichtig, dass Sie wissen, wie sie sich gegenseitig beeinflussen.

Umfang

Der Bereich der Kennung gibt an, welche Systeme auf die Kennung zugreifen können. Der Umfang von Android-Kennungen lässt sich in der Regel in drei Kategorien einteilen:

  • Einzelne App: Die ID ist intern für die App und für andere Apps nicht zugänglich.
  • App-Gruppe: 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, der einem Identifier gewährt wird, desto größer ist das Risiko, dass er zu Trackingzwecken verwendet wird. Wenn umgekehrt nur über eine einzelne App-Instanz auf eine Kennung zugegriffen werden kann, kann sie nicht verwendet werden, um ein Gerät über Transaktionen in verschiedenen Apps hinweg zu erfassen.

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 unterschiedliche Lebensdauern haben. Die Lebensdauer hängt in der Regel davon ab, wie die ID zurückgesetzt wird:

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

Durch die Zurücksetzbarkeit können Nutzer eine neue ID erstellen, die nicht mit vorhandenen Profilinformationen verknüpft ist. Je länger und zuverlässiger ein Identifier bestehen bleibt, z. B. einer, der 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 es gibt eine Möglichkeit, die ID zurückzusetzen, auch wenn es keine explizite Nutzersteuerung zum Zurücksetzen der ID in der App oder den Systemeinstellungen gibt.

Eindeutigkeit

Die Eindeutigkeit gibt die Wahrscheinlichkeit von Kollisionen an, d. h. dass identische Kennungen im zugehörigen Bereich vorhanden sind. 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 Quelle der Zufälligkeit ab, die zum Erstellen der Kennung verwendet wurde. Die Wahrscheinlichkeit einer Kollision ist beispielsweise bei zufälligen Kennungen, die mit dem Installationsdatum (z. B. 2019-03-01) initialisiert werden, viel höher als bei Kennungen, die mit dem Unix-Zeitstempel der Installation (z. B. 1551414181) initialisiert werden.

Im Allgemeinen können Nutzerkonto-IDs als eindeutig betrachtet werden. Jede Geräte-/Kontokombination hat also eine eindeutige ID. Je weniger eindeutig eine Kennung innerhalb einer Population ist, desto besser ist der Datenschutz, da sie weniger nützlich ist, um einen einzelnen Nutzer zu verfolgen.

Integritätsschutz und Nichtabstreitbarkeit

Sie können einen schwer zu fälschenden oder wiederzugebenden Bezeichner verwenden, um nachzuweisen, dass das zugehörige Gerät oder Konto bestimmte Eigenschaften hat. So können Sie 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 Rechtsverbindlichkeit. Wenn das Gerät eine Nachricht mit einem geheimen Schlüssel signiert, ist es schwierig zu behaupten, dass die Nachricht von einem anderen Gerät gesendet wurde. Die Nichtabstreitbarkeit kann für einen Nutzer wünschenswert sein, z. B. bei der Authentifizierung einer Zahlung, oder eine unerwünschte Eigenschaft sein, z. B. wenn er eine Nachricht sendet, die er bereut.

Gängige Anwendungsfälle und die zu verwendende Kennzeichnung

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

Konten

Carrier-Status

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

Empfohlene Kennzeichnungen: IMEI, IMSI und Line1

Warum sehe ich diese Empfehlung?

Die Verwendung von Hardware-IDs ist zulässig, wenn sie für Funktionen im Zusammenhang mit Mobilfunkanbietern erforderlich ist. Sie können diese Kennungen beispielsweise verwenden, um zwischen Mobilfunkanbietern oder SIM-Karten-Slots zu wechseln oder SMS-Nachrichten über IP (für Line1) an SIM-basierte Nutzerkonten zu senden. Für Apps ohne Berechtigungen empfehlen wir jedoch, die Geräteinformationen des Nutzers serverseitig über die Kontoanmeldung abzurufen. Ein Grund dafür ist, dass diese Kennungen in 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 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: Verwenden Sie die Abo-ID-API, um auf dem Gerät verwendete SIMs zu identifizieren.

Die Abo-ID stellt einen Indexwert (beginnend mit 1) zur eindeutigen Identifizierung der auf dem Gerät verwendeten installierten SIMs (einschließlich physischer und elektronischer SIMs) bereit. Über diese ID kann Ihre App ihre Funktionen mit verschiedenen Aboinformationen für eine bestimmte SIM-Karte verknüpfen. Dieser Wert bleibt für eine bestimmte SIM-Karte stabil, sofern das Gerät nicht auf die Werkseinstellungen zurückgesetzt wird. 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 ICCID. Da die ICCID global eindeutig und nicht zurücksetzbar ist, wurde 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 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: Konten, die mit dem Kontomanager kompatibel sind, z. B. Google-Konto-Verknüpfung

Warum sehe ich diese Empfehlung?

Durch die Verknüpfung von Google-Konten können Nutzer ihr vorhandenes 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 können Sie das Vertrauen der Nutzer stärken, 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 ID: Wenn in Ihrer App eine ID für Werbung verwendet wird und sie bei Google Play hochgeladen oder veröffentlicht wird, muss es sich bei dieser ID um die Werbe-ID handeln.

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 beste Lösung. Die Verwendung der Werbe-ID ist gemäß der Google Play-Inhaltsrichtlinie für Entwickler für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

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

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: Werbe-ID oder Play Install Referrer APIs

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 beste Lösung. Wenn Sie eine ID für Werbezwecke verwenden, muss es sich um die Werbe-ID handeln, da der Nutzer sie zurücksetzen kann. Weitere Informationen

Conversions

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

Empfohlene Kennung: Werbe-ID oder Play Install Referrer APIs

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 beste Lösung. Die Verwendung der Werbe-ID ist gemäß der Google Play-Inhaltsrichtlinie für Entwickler für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

Remarketing

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

Empfohlene Kennung: 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 beste Lösung. Die Verwendung der Werbe-ID ist gemäß der Google Play-Inhaltsrichtlinie für Entwickler für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

App-Analyse

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

  • Welche anderen Produkte oder Apps Ihrer Organisation sind für den Nutzer geeignet?
  • Wie Sie Nutzer dazu bringen, Ihre App weiterhin zu verwenden
  • 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 Ihrem Unternehmen gehören, sofern Sie Nutzerdaten nicht für Werbezwecke verwenden. Wenn Sie Geräte mit Google Play-Diensten als Zielgruppe verwenden, empfehlen wir die App-Set-ID.
  • Firebase-ID (FID): Eine FID ist auf die App beschränkt, in der sie erstellt wird. So wird verhindert, dass die ID zum appübergreifenden Tracking von Nutzern verwendet wird. Sie lässt sich auch einfach zurücksetzen, da der Nutzer App-Daten löschen oder die App neu installieren kann. Das Erstellen einer FID ist unkompliziert. Weitere Informationen finden Sie im Firebase Installations-Leitfaden.

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 sehe ich diese Empfehlung?

Eine FID ist auf die App beschränkt, in der sie erstellt wird. So wird verhindert, dass die ID zum appübergreifenden Tracking von Nutzern verwendet wird. Sie lässt sich auch einfach zurücksetzen, da der Nutzer App-Daten löschen oder die App neu installieren kann. Das Erstellen einer FID ist unkompliziert. Weitere Informationen finden Sie im Firebase-Installationsleitfaden. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers in mehreren Apps analysieren, die Ihrer Organisation gehören, sofern Sie Nutzerdaten nicht für Werbezwecke verwenden.

Leistungsberichte

In diesem Fall werden von 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.

App-Tests

In diesem Fall bewertet Ihre App die Nutzerfreundlichkeit Ihrer App zu Test- oder Debugging-Zwecken.

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 ID zum appübergreifenden Tracking von Nutzern verwendet wird. Sie lässt sich auch einfach zurücksetzen, da der Nutzer App-Daten löschen oder die App neu installieren kann. Das Erstellen einer FID ist unkompliziert. Weitere Informationen finden Sie im Firebase-Installationsleitfaden. Mit einer App-Set-ID können Sie das Verhalten eines Nutzers in mehreren Apps analysieren, die Ihrer Organisation gehören, sofern Sie Nutzerdaten nicht für Werbezwecke 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 sehe ich diese Empfehlung?

Eine FID ist speziell für diesen Zweck konzipiert. Ihr Umfang ist auf die App beschränkt, sodass sie nicht verwendet werden kann, um Nutzer in verschiedenen Apps zu verfolgen. 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?

Wenn Sie prüfen möchten, 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, verwenden Sie die Google Play Integrity API.

Werbebetrug

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

Empfohlene Kennung: Werbe-ID

Warum sehe ich diese Empfehlung?

Gemäß der Google Play-Richtlinie zu Entwicklerinhalten ist die Verwendung der Werbe-ID für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

Digitale Rechteverwaltung (Digital Rights Management, DRM)

In diesem Fall soll Ihre 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 eine ausreichende Hürde. Wenn dies nicht ausreicht, bietet Android eine DRM API, mit der der Zugriff auf Inhalte eingeschränkt werden kann. Sie enthält eine ID pro APK, die Widevine-ID.

Nutzereinstellungen

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

Empfohlene Kennung: FID oder GUID

Warum sehe ich diese Empfehlung?

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