Wie man richtig um Zugriff auf Nutzerdaten bittet

stopp.png

Datenschutz und Privatsphäre sind relevanter denn je

Der Schutz von Nutzerdaten ist ein komplexes und wichtiges Thema. Die Skepsis ist groß, was mit all diesen Daten passiert, auf die Apps zugreifen wollen. Zurecht!

Unsere Smartphones wissen eine ganze Menge über uns. Mehr als jedes andere technische Gerät in unserem Leben.

Sie wissen, wo wir sind und wie lange. Was wir sagen, und zu wem. Was in unserem Kalender steht, wie wir in Badehose aussehen, was wir diese Woche noch erledigen wollen und vieles mehr. Wer sich auch nur ein klein wenig mit Big Data auskennt, der ahnt, wie all diese Informationen miteinander kombiniert werden könnten.

In den falschen Händen sind diese Informationen schädlich. Andererseits benötigen viele Apps Zugriff auf diese sensiblen Daten, um den vom User gewünschten Service überhaupt anbieten zu können. Und auch wenn es natürlich schwarze Schafe und kriminelle Energie oder zumindest moralisch fragwürdige Finanzierungsmodelle gibt: Die meisten App Publisher haben mit den Nutzerdaten nichts verwerfliches vor.

Die Kunst ist es also, mit den Nutzern seiner App eine vertrauensvolle Beziehung einzugehen.

Passwords-e1428097765620.png

Technischer Hintergrund

Wenn eine App Zugriff auf Nutzerdaten oder Funktionalitäten des Geräts wie das Mikrofon oder den Kalender haben möchte, muss sie den Nutzer explizit darum bitten. Das ist in dieser Form bei iOS schon lange Usus, bei Android seit den aktuellsten OS-Generationen ebenfalls.

Die Abfrage funktioniert nicht pauschal für alle benötigten Zugriffsrechte auf einen Schlag, sondern muss für jede Berechtigung einzeln geschehen. Das ist nutzerfreundlich, verkompliziert aber das Leben eines App Publishers.

Erschwerend kommt hinzu: die Anzeige des Dialogs mit der Bitte um eine spezifische Erlaubnis ist aus der App heraus nur ein einziges Mal möglich. Wenn sich der Nutzer in diesem Moment bei der Anzeige des sogenannten Permission Alerts also entscheidet, die Berechtigung nicht zu erteilen, hat man ein Problem. Abseits davon, dass der Zugriff auf für die App möglicherweise wichtige oder gar unerlässliche Datenpunkte nicht gegeben ist, muss der Nutzer umständlich in seine Geräteeinstellungen navigieren, wenn er die Berechtigung nachträglich doch noch erteilen möchte. Dafür stehen die Chancen eher schlecht.

Ohne weiteres Zutun des Entwicklers handhaben die Betriebsysteme die Anzeige von Permission Alerts bereits sehr smart. Und zwar erfolgt die Anzeige zu dem Zeitpunkt, an dem die App das erste Mal auf die Daten zugreifen möchte, beispielsweise beim ersten Tap auf den „Foto in der Galerie speichern“ Button. In den meisten Fällen ist das völlig ausreichend so. Noch ein schicker Erklärungstext dazu und fertig.

Alternativ können auch eigene Zeitpunkte definiert werden, zu denen der Alert angezeigt werden soll. Dabei können auch mehrere solche Trigger für jede Zugriffserlaubnis festgelegt werden und die Anzeige erfolgt, sobald der erste Trigger ausgelöst wurde. Das kann in spezielle Fällen mehr Sinn machen, als die zuvor beschriebene Standardlösung.

Ein Beispiel: Eine Shopping App möchte dem Nutzer Push Notifications schicken. Als eigener Trigger definiert wurde die erste abgeschlossene Bestellung, damit der User unter anderem über den Versand seines Pakets per Push informiert werden kann. Das ist in zweierlei Hinsicht super: Erstens ist der Nutzer zu diesem Zeitpunkt sicherlich gut gelaunt, schließlich hat er gerade etwas bestellt. Und zweitens wird ihm der Nutzen von Push in diesem Fall sofort klar. Beides führt dazu, dass er die Berechtigung vermutlich erteilen wird. Zusätzlich könnte man weitere Trigger definieren, beispielsweise den ersten Aufruf der Benachrichtigungseinstellungen oder den zehnten Aufruf einer Produktdetailseite.

All das bedeutet nicht nur, dass man sich über die richtigen Trigger Gedanken machen muss, sondern auch, dass bei der Konzeption und Entwicklung einer App bedacht werden muss, wie sie sich ohne die entsprechenden Berechtigungen verhält.

Es gilt, ein elegantes Handling zu finden, was den User auf die eingeschränkte Funktionalität hinweist, ihn daran erinnert, warum das so ist und einen Hinweis enthält, wie er die Berechtigung nachträglich erteilen kann. So erhöht man die Chancen deutlich, dass ein Nutzer doch noch den umständlichen Umweg über seine Geräteeinstellungen eingeht und seine Meinung revidiert.

app-berechtigung_text3.jpg

Kontext und Timing

@@Es gibt keine zweite Chance für den ersten Eindruck.@@ Zum Zeitpunkt der Anzeige eines Permission Alerts ist es entscheidend, dass dem Nutzer unmissverständlich klar wird, was er davon hat, wenn er der App den Zugriff auf die geforderten Daten erlaubt und wofür sie den Zugriff überhaupt braucht.

In einigen Fällen ist das für den Nutzer selbsterklärend. Wenn man in seiner gerade frisch installierten Banking App das erste Mal nach einem Geldautomaten in der Nähe sucht und sich über die Kartenansicht die Frage nach dem Zugriff auf den Standort legt, dann versteht man das auch als technisch wenig begabter Nutzer sofort. Spätestens mit dem selbst definierbaren Erklärungstext innerhalb des Dialogs sollten alle Zweifel ausgeräumt sein.

In anderen Fällen ist es weniger offensichtlich. Oder die App braucht die Erlaubnis tatsächlich direkt zum Start und kann nicht warten, bis der Permission Alert zu einem natürlichen Zeitpunkt aufgebracht werden kann.

In diesen Fällen empfiehlt sich ein kleines Tutorial. Darin kann der User inhaltlich abgeholt werden, im Zweifelsfall sogar sehr komplexe Sachverhalte mit Text, Bildern, Animationen oder sogar Videos erklärt werden und der Nutzer dann gefragt werden, ob er alles verstanden hat und die Erlaubnis jetzt erteilen möchte.

Das schöne daran: Nur wenn er sich für Ja entscheidet, wird der Permission Alert angezeigt. In diesem Moment stehen die Chancen ausgezeichnet, dass er den Zugriff gewährt. Hat er sich aber für Nein entschieden, kann man die Anzeige des Permission Alerts für einen späteren Zeitpunkt in der Hinterhand behalten und den User bis dahin weiter bearbeiten und wiederholt fragen, ob er jetzt die Erlaubnis geben möchte.

Now-Pregnant-Womens-Are-Becoming-Victim-Of-iPhone7-Blast.jpg

Typische Fehler

Am schlimmsten, aber heutzutage zum Glück nicht mehr sonderlich verbreitet, ist das Bombardement des Nutzers direkt zum App Start. Schlechter als mit einem völlig unvermittelten "Darf ich dir Push schicken? Darf ich auf deine Fotos zugreifen? Und auf den Kalender vielleicht auch noch?" kann man eigentlich gar nicht loslegen. Zu diesem Zeitpunkt hat der Nutzer noch keine Ahnung, was die App überhaupt genau leistet, ob er sie langfristig nutzen und ihr seine sensiblen Daten anvertrauen möchte. Nach einem derartigen Fehlstart vermutlich eher nicht.

Auch ein Klassiker sind kryptische, viel zu technische Erklärungen, wofür der Zugriff benötigt wird. Was der Nutzer nicht versteht, wird er tendenziell ablehnen. Nicht in technischen Anforderungen denken, sondern stattdessen in seine Nutzer hineinversetzen und in einfachen, wenigen Worten die Mehrwerte beschreiben.

Hin und wieder passiert es auch, dass eigene Trigger blöd oder zu defensiv definiert wurden, so dass sie bei einigen Nutzern nie ausgelöst werden. So kann man eine schöne Möglichkeit verschenken, um beispielsweise seine inaktiven Nutzer über Notifications zu reaktivieren. Und das nur, weil man bei den ersten fünf Nutzungen der App nicht um Erlaubnis dafür gefragt hat.

Fazit

Wenn ein Nutzer versteht, dass eine App nichts Böses plant und ihm nach dem Zugriff einen Mehrwert bietet, dann wird er sein Ok geben. Wenn nicht, dann nicht. Die Verantwortung dafür, dass zwischen einer App und ihren Usern ein Vertrauensverhältnis entsteht, liegt beim Publisher. Wer die erste Chance dafür verpatzt, der bekommt oft keine zweite mehr.


Zu diesem Artikel gibt es auch eine Podcastfolge.