微信官方对小程序接口能力进行调整，旨在增强用户体验和隐私保护。然而，这也给商家带来了更多接口限制和运营规范挑战。作为产品经理，必须平衡用户和商家的利益，并确保遵守微信的运营规范，那么微信小程序该如何做好“授权”设计？
距离上一篇《微信小程序如何做好“授权”设计？》已经过去2年多时间，微信官方对小程序的接口能力做了很多调整。用户层面，微信加大了用户隐私保护和用户体验升级的力度。但对于商家来说，更多接口限制和更严苛的运营规范，增加了获客的难度。作为产品经理，需要在不违反微信运营规范的前提下，使用户和商家的利益达到平衡状态。
最近在设计授权登录流程的时候，跟研发同学产生认知的差异。研发同学一直不理解我说的登录是什么意思，导致他在设计技术方案的时候，出现了纰漏。这是我才意识到，对于不同角色的人来说，登录是全然不同的两种东西。
1. 研发所说的登录小程序的官网文档里有一个接口叫做：小程序登录。
通过微信官方提供的登录能力方便地获取微信提供的用户身份标识，快速建立小程序内的用户体系。而这种登录，只能获取用户的openID、UnionID和会话密钥 session_key。
通俗一点，就是通过小程序的接口获取一个用户的唯一识别ID，对于不同主体（公司主体）的小程序，唯一识别ID也是不同的。这个唯一识别ID，对于业务层面来说，没有任何作用，商家无法获取用户的手机号、姓名等核心要素。
举个例子：把小程序比作一个学校，那唯一识别ID是学生证号。在学校保密的情况下，你拿到一个学生证号，无法查询到这个学生的任何资料信息。并且，不同学校的学生证号有可能会重复。
所以，唯一识别ID，是为了系统层面创建了一个用户，这个用户只有一串ID；还有记录用户的登录状态，下次进入小程序实现免登。
2. 业务所说的登录是指通过手机号/账号，创建用户，并且用手机号/账号作为唯一识别，确定用户在业务层面唯一性的说法。他的核心点是账号/手机号。
所以当时需求描述的功能，是需要【微信授权获取手机号】的接口，而研发误以为是【小程序登录】的接口。
去年这个接口已经作废，微信官网认为获取用户的头像和昵称侵犯了隐私，并且不是必要因素，所以取消了接口。但近期发现，微信官方新加了一个接口用于获取用户信息。如果需求设计中，涉及到需要获取用户的头像和昵称，则必须设计编辑个人信息的界面，让用户主动上传或通过接口获取。特别注意：一般情况下，让用户输入微信号极其敏感，容易违规被封，建议不要收集。
以前的接口，要求必须先【小程序登录】，才能调用【获取手机号】。现在的版本做出修改，两个接口独立，没有前后关联。但依旧需要用户主动触发在页面里点击按钮才能发起获取手机号接口，不能系统自动 API 来调用。
若用户举报较多或被发现在不必要场景下使用，微信有权永久回收该小程序的该接口权限；在使用该接口时，用户可使用微信绑定手机号进行授权，也添加非微信绑定手机号进行授权。若开发者仅通过手机号作为业务关联凭证，在重点场景可适当增加短信验证逻辑。
小程序提审，最常见的驳回原因，就是不符合《小程序运营规范 5.12 收集用户隐私行为》。
所以，大家提审时尽量做到以下几点，会提升过审的几率。
①所有的一级页面（例如首页、个人中心）必须全部在未登录状态下可以访问。
② 长链条的业务，例如商城，用户必须看到商品详情和核对订单后，再触发授权手机号登录。
③ 到店点餐和取餐业务，需设计游客下单模式。例如星巴克，提供非会员订单，用户无需登录，即可享受在线点餐服务。
不可以默认勾选同意，必须用户手动授权同意协议。
为了应对授权手机号接口异常情况（突然被封），需要增加手机号验证码的登录流程。
根据条件触发，一般需要定义：
①进入某页面触发。
②点击页面的某个按钮触发。
一般定义的颗粒度越细，用户体验越好，但相对来说，研发成功就越高。大家可以酌情考虑。
小程序快速便捷的研发模式和迭代模式，可以适应大部分互联网产品快速迭代、快速试错的需求，但是全部依赖于微信生态圈会有诸多限制，作为小程序的产品经理，大家应该熟读小程序和公众号的文档，清楚什么可以做什么无法实现，这样在设计功能时，不会走太多弯路，也避免了与研发同学产生冲突，设计了他们实现不了的需求。
参考网站：https://developers.weixin.qq.com/miniprogram/dev/framework/
本文由@Rzhiyi 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。提供信息存储空间服务。
