一文了解Google Play隐私政策弹窗的最优做法

我们知道,现在一个应用从Google play去上架公开市场时,只要应用内有收集用户隐私数据的行为,就需要在用户第一次打开应用时,进行隐私政策的声明(以下简称声明)。即使应用不涉及相关隐私权限和搜集相关的隐私数据,但是应用集成了广告的sdk或者是或者是firebase的埋点sdk,那么也需要进行声明。

具体哪些算隐私权限呢?哪些算用户的隐私数据呢?可以参照Google Play的这个页面的说明。

https://play.google.com/about/privacy-security-deception

声明形式

目前大家普遍采用的声明的形式是弹窗的形式。

即在用户第一次打开的应用的时候进行弹窗声明。弹窗内详细列出了应用相关的隐私政策,并且在弹窗最下面有两个按钮。左边是不同意按钮,当用户不同意点击不同意的时候直接退出应用;当用户点击同意的时候弹窗消除,用户可正常使用应用。

如果用户点击了不同意,退出应用后再次进入。则重复弹窗动作,直到用户同意为止。

不因隐私声明导致用户流失

那么这个时候,有的朋友会问了。我的应用只是因为埋点,需要使用这个声明。如果用户不同意的话,岂不是都没有办法去使用应用了吗?相当于还没有开始就结束了,就流失了这个用户。这个时候该怎么办呢?

别急。有很多小型的应用,比如收音机啥的,本身的功能并不需要使用到敏感权限。只有在埋点了以后,按照政策会需要进行声明。

那么我们可以做这样一个操作,就是当用户点击声明弹窗里的不同意按钮的时候,我们同样的可以关闭声明的弹窗进入应用正常使用,但是同时,不进行埋点数据的收集,这样也是可以的,是Google Play所允许的。

但是如果需要正常使用应用的时候,就已经涉及到了敏感权限。那么这个时候是不能采用这种方法的。

提高同意率

以上提到了一些小型的应用,本身的功能不需要使用到敏感权限,可以当用户点击不同意的时候不进行相关敏感数据的收集。

那么这个时候又有朋友问了。那如果很多用户不同意的话。岂不是有很多用户的数据,都收集不到,会对影响后期的数据分析啊。

那么这个时候,可以稍微地变通一下。

既不采用第一种方法,即当用户点击不同意之后,不收集数据并退出应用,用户再次进入时再次弹出声明弹窗;也不采用第二种方法,即当用户点击不同意之后,不收集敏感数据,永远关闭弹窗,用户可正常使用应用。

用另一种更灵活的方式来实现。

就是当用户第一次点击不同意之后,关闭弹窗,不收集数据,让用户进入应用并可以正常使用。

当用户退出应用的进程,并在第三次(举例)打开应用的时候,再次弹出声明的弹窗,希望用户可以同意。如果用户再次点击不同意关闭弹窗,那么仍然重复上面的动作,让用户正常使用应用,并不收集相关的敏感数据。

当用户退出应用的进程,并在第十次(举例)打开应用的时候,第三次弹出声明弹窗,希望用户可以同意。如果用户再次点击不同意关闭弹窗,那么仍然重复上面的动作,让用户正常使用应用,并不收集相关的敏感数据。

如果用户同意,那么各自安好。

这里提到的是只按次数进行声明弹窗的重复展示,在实际操作的时候也可以按使用的天数来进行重复弹窗,或者是次数天数两个逻辑在一起进行判断。

数据跟踪

我们做了这个弹窗逻辑,就是为了提高用户点击同意的几率。

那么这个时候,一定要在同意和不同意按钮上做一个数据采集,方便后期来查看有多少用户点击了同意,在第几个弹窗的时候点击的同意,方便后期不断优化弹窗逻辑,以及弹窗次数,对点击同意用户的占比的影响。从而不断调整重复弹窗逻辑,来提高同意用户占比。

灵活配置

由于需要不断地优化声明弹窗逻辑,所以不要像文章最上面提到方式,直接将弹窗的逻辑写死在客户端。

建议把弹窗逻辑的配置,按照天数,按照使用次数,或者按照其他的什么所想到的方式,做在服务端,以接口的形式进行传参,进行一个实时的调整和配置,这样灵活得多。数据是实时的,配置也是实时的,方便随时调整。

以上就是这篇文章,对Google play隐私政策的一个目前来讲,能想到的最优的做法。保证不违背Google Play的政策和相关的隐私法律,又在相关的框架下对开发者的权益做了一个最大化的争取。

如果你有更好的做法,欢迎留言。

应用上线Google Play常见问题解答

虽然说前几年也做过Google Play上线应用的管理,但毕竟过了好几年,有些关键点淡忘了,Google Play经过了这几年,开发者后台也做了不少更新。

而最近正好操作了一揽子应用上架Google Play的过程。重新将在这个过程中碰到的一些关键点和常被问到的问题进行了整理,如下。

1. 应用的包名在Google Play上有什么作用?

Google Play是以应用的包名为唯一身份识别ID的。Google Play上每一个应用的详情页都会有一个链接,如下为chrome浏览器的链接(包名为com.android.chrome):

https://play.google.com/store/apps/details?id=com.android.chrome

其中链接末尾的com.android.chrome就是chrome浏览器的包名。Google Play上所有应用详情页的链接格式都是如此,只要你知道了某个应用的包名,就可以找到它在Google Play上的详情页面。

2. 应用在某个时候需要换包名怎么办?

应用一旦更换包名就相当于是一个新的应用,两者之间不存在任何关联关系,当然也不可能进行升级。同时,更换包名后,需将旧包名应用进行下架处理,防止被Google Play认为是同一应用多包名刷自然流量。

3. 为什么Google Play上没有我应用包名的详情页,应用仍然无法上传Google Play后台?

Google Play上没有该应用包名的详情页,有可能是曾经有相同应用在Google Play上发布过,现在已经被下架或删除,也有可能是该应用的开发者只将其上传至Google Play后台,尚未发布。由于Google Play上包名的唯一性,一旦该应用上传至后台,无论是否发布,是否下架,该包名均在Google Play上唯一。

4. Google Play是否会对应用统一签名?

在应用首次上传Google Play时,Google Play会展示对应用统一签名的功能,由运营人员选择开启或者关闭。注意,这里一旦开启,并上传安装包后,后面将无法关闭。那么,由于签名的不统一,Google Play将无法升级用户从其他渠道下载的该应用。

往往我们为了应用在多渠道上的升级方便,一般来说,首次上传时会关闭此项功能,即用应用开发团队的自签名。

5. Google Play以什么来判断版本新旧?

首先,应用新版本需要保持和旧版本包名与签名一致,否则无法上传;

其次,应用新版本上传时,Google Play还会自动检测安装包的version name和version code,如version code低于或等于曾经上传的任何一个版本的version code,则无法上传。

也就是说,在应用包名和签名一致的情况下,Google Play以version code来判定版本的新旧,每一次升级发版本,都必须增加version code的值。version code的最大值为2100000000。

而version name是用作显示给用户的版本号。除了向用户显示和内部人员方便识别外,version name 没有其他用途。

6. Google Play是否可以限制应用兼容的安卓版本?

Google Play后台无法控制,需要开发者在应用内进行控制。Google Play会自动检测,并采用该限制。

7. Google Play上是否给应用分o和go版本?

Google Play上不会帮助应用进行区分o和go版本。如果应用同时具有o和go版本,那么则采用两个包名进行发布,即可以视为两个独立应用。

8. 什么时候应用需要做隐私政策声明?

一旦应用功能涉及使用用户敏感数据的权限,那么就需要进行隐私政策声明,并且未征得用户明确许可之前,不得开始收集个人数据或敏感数据。

敏感数据包括但不限于个人身份信息、财务和付款信息、身份验证信息、电话簿、联系人短信和通话相关数据、麦克风和相机传感器数据,以及敏感的设备或使用情况数据。

9. 我如何知道哪些是敏感权限,哪些是非敏感权限?

可以在此页面上自查 – 利用好”ctrl+f”搜索https://developer.android.com/reference/android/Manifest.permission

10. 涉及敏感权限除了需要做隐私政策声明,还需要做什么?

所有请求获取敏感权限的应用(例如短信或通话记录权限组)都必须在Google Play后台填写《权限声明表单》。如果未声明所有使用这些权限的功能,则会导致应用被下架,甚至开发者账号被封禁。

11. 我的应用由于广告或数据统计等原因,需要通过获取phone权限拿到imei,是否合规?

如果应用为通讯类应用,有相关功能必须要获取phone权限才可以正常使用,则需要进行敏感权限申报。如应用为非通讯类应用,无相关功能,则不可以获取phone权限,否则无法通过Google Play上架审核。简而言之,就是不允许获取该应用正常功能外的权限。