询问用户权限许可的正确方法.pdfVIP

询问用户权限许可的正确方法 你知道平均每个A pp在用户安装后的前三天内就失去 80%的平均日活吗 ？大部分用户下载 一个A pp ，打开一次 ，然后就卸载掉它。这种情况发生是因为用户虽然愿意尝试安装很 多A pp ，但他们还是要决定在开始那几天究竟卸载掉哪些。 用户的这样做是因为你的A pp做的不好吗 ？也不全是 ，但是用户跟你的A pp在最开始的互动确实很 大程度上决定 用户对你的A pp的整体印象 （是好还是坏 ）。现在实际情况是 ，当用户打开一个新 的A pp时 ，他们最先看到的往往是一连串的弹出框询问他们的权限获取请求。如 ： 程序想要获取您的定位权限 程序想要获取您的联系人信息 程序想要获取您的拍照权限 这样的做法对用户体验产生很大的影响 ，常常导致用户放弃使用。正确的做法是A pp应该在提出权 限请求前先跟用户保持一定的对话沟通。本文将引导你走上正确的道路 ，带你避免权限获取中的常 规误区。 一、建立起一套策略 当涉及到权限的许可请求时 ，最糟糕的事情就是A pp使用没有任何解释说明的权限请求炮轰用户。 不管是询问太早还是一次性询问的太多都是普遍的错误做法。但是实际上 ，很多的A pp还是这样做 ，用户启动A pp进来首先看到的就是难以理解的请求。例如 ，Google的Inbox甚至在用户还没有登 入到A pp中时就提出请求 ，没有附带任何其他的信息或上下文环境。 Inbox 当你向用户发出权限许可请求时 ，你当然希望所有用户都能接受这个请求。为 达到这个目标 ，你 应该建立起一套策略。这套策略建立在你所请求的权限类型的清晰度和重要性上。关键性的许可请 求应该在一开始提出 ，次要一些的则可以放在上下文环境中提出。 权限许可请求模式 二、什么时候询问用户 决定用户接受还是拒绝你的请求的最重要的因素之一就是你在何时询问他。 一条简单的原则 ：不要轻率的就向用户提出请求直到你真的需要那个权限。 1、一开始只提关键性请求 对许多A pp来说 ，没有获取对数据的访问权限可能足以改变整个用户体验过程。例如 ，如果一 个A pp依赖于短信服务 ，那么当获取不到这项权限时 ，程序就会无法应用。幸运的是,用户大都期望 一个消息传送应用能够获取短信权限 ，所以这时候预先提出权限请求是非常有意义的。 Google Hango ut s 如果一个功能的正常使用需要多种权限的许可 ，那就只向用户提出这些权限的许可请求 ，而不要再 提出任何其他不相干的。 顺便提醒 ：一定要确保用户能理解这个A pp是用来干嘛的 （这就建立在程序的语言描述以及用户之 前是否有过类似的体验上 ），只在一开始提出那些用户可能期望获取的关键性许可请求 （用户有预 期这个A pp确实需要某种权限来实现自己想用到的功能 ）。 2、在上下文使用环境中提出请求 在大多数情况下 ，如果一个新用户在一开始就要忍受一堆许可请求 ，那你很有可能就错失掉让用户 留下来的关键机会。A pp应该在使用过程中结合具体环境提出许可请求并向用户传达该权限的使用 价值。因为一旦先引导一个用户留存下来 ，他们更有可能在使用中接受你的请求。 来自t hinkw it hgoogle 顺便提醒 ：如果它们出现在一个相关的任务/功能场景 ，用户更有可能授予系统询问的权限。 三、如何询问用户 A pp得向用户阐明为何每一项权限都是必需的 ，不管是通过功能名称还是一个解释说明。请记住 ， 如果你想要征得用户的同意 ，你必须恰到好处的询问用户。 一条简单的原则 ：一定要确保用户能够清楚他们同意授予权限后自己能得到什么。 1、解释可得利益 不太清楚的权限请求应该告诉用户它涉及到什么。如果你的A pp有一个引导演示 ，记得以此来解释 你的程序能干什么以及为什么那些意料之外的权限也是必需的。 Mat erial Design 在上下文使用环境中解释一个权限是另外一种做的很好的例子 它提起普通用户的兴趣并增加他 们对该权限的理解。一定要去试图解释用户在授权后他们能从中获取什么益处。 Google Maps 2、请求的同时给予引导 Fo ursquare通过提供一个背景图片用来解释为何A pp需要这个特定的权限从而引导用户做出选择。 Fo ursquare 3、实际许可请求前的“前置对话” 你只能引发iO S每个功能默认权限请求一次。最用户来讲最糟心的事情可能是用户在系统层级禁止 相关权限 ，而当他要针对某个A pp重新授权的时候是很麻烦的。在大多数情况下 ，在实际的iO S 系统权限访问页面前放一个前置