网站地图 | RSS订阅 老铁博客 - 上海SEO优化|上海网站建设|蜘蛛池出租|站群代搭建
你的位置:首页 » 网站建设 » 正文

搞定微信生态内的账户体系看这篇文章就够了

2019-7-12 14:3:44 | 作者:老铁SEO | 0个评论 | 人浏览

  线下课程 空降创业公司做运营总监,业务统筹慢、团队管理难怎么办?

  线上课程 这样学Axure9.0,告别原型效率低不标准,做出带有交互的高保线日

  产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下

  笔者从私域流量出发,论述了不同的业务和场景下如何处理微信私域相关的用户数据,并分享了自己的操作建议。

  最近私域流量的概念非常火,所谓私域流量,就是你可以自由反复利用,无需付费,又能随时触达,被沉淀在公众号、微信群、个人微信号、头条号、抖音等自媒体渠道的用户。相对淘宝、京东、百度这些公域流量平台,它属于商家「私有资产」。

  做私域流量,就会不可避免地涉及到一个问题,说用户进入了自己的「私域」,但是我们真的能认识用户吗?我们能成功地识别这个用户,并且展示该给这个用户展示的数据吗?微信的 openid 和 unionid 机制其中的复杂内容又有多少人知道呢?我们有很好地利用微信给我们提供的这些机制吗?抖音到底是怎么利用这些接口拿到用户的关系链的呢?

  好的用户体系主要就是做两个事情,身份识别和限权。所以下文所有的内容,都是围绕身份识别和限权这两个底层需要去做的。所有系统做的迭代和改进都只有一个目的——如何让用户身份识别的成本降到最低,如何让系统限权做的最准确。上面这段话是整个用户中心设计的「核心思想」,如果想要打造一个靠谱的用户中心,就务必牢记这些内容。

  也就是说,一个公司如果有一个小程序矩阵,同一个用户使用了这 3 个小程序,开发者能够从微信的接口获得到的数据一共有 3 条,3 条数据用户的 openid 是不一致的,但是 unionid 是一致的,openid 和 unionid 都是用户的唯一标示,但是二者唯一性的生成条件是不一致的。

  openid 的唯一性=用户微信号+应用的 appid(不同的公众号,小程序,appid 都是不同的);

  值得一提的是,微信内的网页必须要挂靠一个公众号,所以微信网页授权获得的 openid 和对应挂靠公众号粉丝的 openid 是一致的。开发者可以选择将所有的网页都挂靠在一个公众号下面,这样可以减少授权弹窗的次数。

  「快速精确身份识别」——要能够快速的辨识用户,用户识别要准确,不能出现把用户识别错误的情况,也不能出现明明应该认识但是却不认识的情况。交互层面,最好用户操作成本超级低,点一下,甚至不点就能识别;

  「准确限权」——用户相关的数据可以全部连带展示,不会丢数据,也不会展示不该展示的数据。

  核心机制一,「将 unionid 和 userid 绑定实现限权」——把微信的unionid和自有系统的 userid 绑定起来,通常需要基于登录行为实现;

  核心机制二,「利用 openid 进行快速身份识别」——由于微信内网页可以直接识别用户的 openid,所以需要将 openid 和 unionid 做关联,来实现一种“长效并且精准的 cookie”的效果,这样用户即使更换手机,只要不更改微信号,系统就永远能够以最低成本直接对其进行身份识别;

  核心机制三,「交互层面处理用户拒绝授权」——妥善处理用户拒绝授权,所以拿不到 unionid 的情况。

  虽然我很讨厌微信这个“妥善处理”的说辞,但是在这种情况下,我真的不知道该怎么总结这项工作。

  核心机制一——「将unionid和userid绑定实现限权」的逻辑比较简单,用户在微信内访问系统的页面,触发了「微信网页授权」的弹窗,用户同意授权后,系统拿到了该用户(该微信号)对应的 unionid,然后把这个 unionid 和系统本身的的 userid 关联起来(比如先弹窗,然后要求用户基于手机号和短信验证码登录,也可以做静默注册,看具体业务),然后系统就会有一个【unionid-userid】的数据,两者一一对应。

  核心机制二——「利用 openid 进行快速身份识别」实现起来也不复杂,「微信网页授权」有一种机制叫做「snsapi_base 为 scope 发起的网页授权」,可以获取进入页面的用户的 openid 的,并且是静默授权。同时由于用户已经允许授权,所以系统拿到了【openid-unionid】的关联关系,系统内的数据就变成了【openid(公众号A)-unionid-userid】结构的数据。

  在拿不到 unionid 的情况下获取到的 openid,只能作为前端用来给游客用户种 cookie 的手段,可以落库,给前端当 cookie 标识位使,但是不要落库到「用户中心」的数据库,否则后面填坑真的是火葬场,虽然会有两个填坑的小技巧就在下面,但是有条件不这么做的同学请务必不要这么搞。

  开发者帐号下存在同主体的公众号或移动应用,并且该用户已经授权登录过该公众号或移动应用。

  上面说的授权登录过该公众号其实就是指「微信网页授权」,这点要喷一下微信官方的文档,一个行为搞两个名词,其实挺烦人的。那么如果用户授权过同主体的小程序会是什么效果呢?官方文档没写,我也不敢乱说。

  这个方法不是万能的,假如用户已经把公众号取关了(备注:取关了再关注,openid 和 unionid 不变),系统就拿不回信息了,然后数据库里面就会出现一堆 unionid 字段为空的数据,其实很蛋疼,所以说系统搭建这个事情,有的时候是一步错步步错。但是往往是业务初期,产品经理和开发都不是很在意,给后面人会造成很大的困扰,我会对这个机制如此了解,相信各位读者已经知道我之前踩了多少坑。

  「快速精确身份识别」——要能够快速的辨识用户,用户识别要准确,不能出现把用户识别错误的情况,也不能出现明明应该认识但是却不认识的情况。交互层面,最好用户操作成本超级低,点一下,甚至不点就能识别。

  「准确限权」——用户相关的数据可以全部连带展示,不会丢数据,也不会展示不该展示的数据。

  「快速识别自动绑定」——由于有两个软件环境(微信网页和小程序),会涉及到两个环境下的用户数据的绑定与统一,由于会做电商,用户会对“数据丢失”非常敏感,所以用户数据的绑定就格外重要了。

  上面三点,一、二两点是固有的要求,第三点是涉及到了多Appid的情况之后新增的要求。

  核心机制一,「将 unionid 和 userid 绑定实现限权」——把微信的unionid和自有系统的userid绑定起来,通常需要基于登录行为实现

  核心机制二,「利用 openid 进行快速身份识别」——由于微信网页可以直接识别用户的openid,所以需要将 openid 和 unionid 做关联,来实现一种“长效并且精准的cookie”的效果。

  核心机制三,「利用 openid 进行快速身份识别」(小程序场景)——小程序也可以直接获取用户的openid,所以需要将 openid 和 unionid 做关联,来实现一种“长效并且精准的 cookie”的效果。

  核心机制四,「利用 unionid 与 userid 的绑定关系,实现快捷登录」——从小程序内获得的 unionid 和在微信网页内获得的 unionid 是一致的,所以二者其一如果在数据库已经建立了 unionid 和 userid 的关联数据,另一方应该可以借助数据库内的数据自动建立联系而不需要用户在做任何类似于「手机号验证码登录」的身份识别操作。

  核心机制五,「利用 unionid 与 userid 的绑定关系,实现静默登录」——在某些特定情况下,小程序可以不通过用户授权直接获取 unionid,所以应该要借助这个机制,帮助用户实现无需任何操作即可直接登录的效果。

  核心机制六,「交互层面处理用户拒绝授权」——妥善处理用户拒绝授权,所以拿不到 unionid 的情况。

  「核心机制一」、「二」、「三」、「六」在上面一小节已经详细描述过就不多说了,我们就来着重说说上面「核心机制四」的和「核心机制五」。

  用户在微信内访问系统的页面,触发了「微信网页授权」的弹窗,用户同意授权后,系统拿到了该用户(该微信号)对应的 unionid,然后把这个 unionid 和系统本身的的 userid 关联起来(比如先弹窗,然后要求用户基于手机号和短信验证码登录,也可以做静默注册,看具体业务),然后我们就有一个【unionid-userid】的数据,两者一一对应。

  问题来了,如果这个时候公司又开发了一个小程序,这个用户过来访问,允许授权,系统拿到了 openidC 和 unionidA,那该把用户关联到哪个 userid 上面呢?所以我们可以看出来,如果 unionid 字段为空的数据落入了【用户中心】的数据是多么的麻烦,一旦牵扯到两个 appid 系统就立马歇菜了,非常容易出差错,但是如果 unionid 是不允许为空的,那么其实系统的逻辑依旧比较简单,而且很干净。

  【4】再次去重的目的也比较简单,有可能先前数据库里面有数据【openidA-unionidA-userid 为空】,然后接口传过来【openidA-unionidA-useridA】,第一次去重是不会把这两条数据当做重复数据的,但是经过上面的流程处理后,两条数据都会变为【openidA-unionidA-useridA】,所以需要做去重逻辑。

  这么做的原因有三,一是因为这样做也可以实现业务的需求。二是为了减少测试的成本,通过上方的完整流程图就可以看出来其实上面的逻辑说这很简单,其实麻烦得很,如果再区分是绑定场景还是登录场景,测试起来会非常头疼。三是因为,从底层抽象来看,所谓的「数据绑定」本质是是利用用户无法伪造的 openid 来做了一个身份识别,其实也是一种登录,绑定就是登录的一种。

  因为无论是哪家公司,就算它对「游客生单购买」的支持做的再好,也仍然千方百计地在引导用户登录。本质是是因为「游客生单购买」这件事情其实是把 App 内的 cookie 当成了一种身份识别的唯一标示,而我们都知道 cookie 这种东西其实是很容易就会被抹掉的,如果用户用收集的垃圾清理功能清一下缓存,很可能就洗掉了,对应到用户端的感受就是找不到订单,这其实是比较严重的。

  在 App 内,想要获得用户的授权(这是唯一获得 openid 和 unionid 的方式)需要唤醒微信的 App,然后用户在微信内授权后再返回开发者的 App。这意味着这种唤醒操作不能像之前设计的时候那样随意地在任意节点插入,因为之前的环境内,发起授权不过是一个弹窗,阻断性会比较小,而在 App 内则会直接跳出 App,交互上的代价会比较大,频繁弹出容易导致阻断主流程,得不偿失。

  「快速精确身份识别」——要能够快速的辨识用户,用户识别要准确,不能出现把用户识别错误的情况,也不能出现明明应该认识但是却不认识的情况。交互层面,最好用户操作成本超级低,点一下,甚至不点就能识别。

  「准确限权」——用户相关的数据可以全部连带展示,不会丢数据,也不会展示不该展示的数据。

  「快速识别自动绑定」——由于有多个软件环境(微信网页、小程序、App等),会涉及到多个环境下的用户数据的绑定与统一,由于会做电商,用户会对“数据丢失”非常敏感,所以用户数据的绑定就格外重要了。

  「产品导流后账户绑定相关的交互设计」——由于用户会很大概率先用小程序,再下载 App,所以 App 在核心界面,可能需要引导用户绑定微信账户,这样才能同步数据。(比如用户在小程序以游客身份下单,但是同意了微信网页内授权,来到 App 的订单列表是看不到数据的,需要引导用户绑定微信账户)

  「基于游客身份的自动绑定」——用户在多个微信环境以游客身份生单的关系关联问题,这时用户尽管没有登录,但是基于微信的机制我们仍然能够把他视为同一个人,所以需要做对应的措施。

  上面五点,一、二、三点是上文提到的固有的要求,四、五两点是基于新的业务场景提出来的新的要求。

  核心机制一,「将 unionid 和 userid 绑定实现限权」——把微信的unionid和自有系统的userid绑定起来,通常需要基于登录行为实现

  核心机制二,「利用 openid 进行快速身份识别」——由于微信网页可以直接识别用户的openid,所以需要将 openid 和 unionid 做关联,来实现一种“长效并且精准的cookie”的效果。

  核心机制三,「利用 openid 进行快速身份识别」(小程序场景)——小程序也可以直接获取用户的openid,所以需要将 openid 和 unionid 做关联,来实现一种“长效并且精准的 cookie”的效果。

  核心机制四,「基于交互引导解决App内数据同步问题」在 App 内基于微信授权的交互机制和用户的行为轨迹,在关键页面提示用户「绑定微信账户」。

  核心机制五,「利用 unionid 与 userid 的绑定关系,实现快捷登录」——从小程序内获得的 unionid,在微信网页内获得的 unionid 和 App 基于账户绑定获得的 unionid 是一致的,所以三者其一如果在数据库已经建立了 unionid 和 userid 的关联数据,剩余两方应该可以借助数据库内的数据自动建立联系而不需要用户在做任何类似于「手机号验证码登录」的身份识别操作。这个关联逻辑需要对游客身份生成的虚拟 userid 也同样生效。

  核心机制六,「利用 unionid 与 userid 的绑定关系,实现静默登录」——在某些特定情况下,小程序可以不通过用户授权直接获取 unionid,所以应该要借助这个机制,帮助用户实现无需任何操作即可直接登录的效果。

  核心机制七,「交互层面处理用户拒绝授权」——妥善处理用户拒绝授权,所以拿不到 unionid 的情况。

  核心机制八,「用户标识变更后的广播机制」——所有涉及 userid 之间替换的行为,必须广播至所有业务线,不论是虚拟的 userid 被真实登录的 userid 替换,还是虚拟的 userid 之间的替换。

  其中「核心机制一」、「二」、「三」、「六」、「七」都是在上文讨论过的,「核心机制四」在本小节的开头部分已经讨论过,我们就来说一下「核心机制五」和「核心机制八」。

  从小程序内获得的 unionid,在微信网页内获得的 unionid 和 App 基于账户绑定获得的 unionid 是一致的,所以三者其一如果在数据库已经建立了 unionid 和 userid 的关联数据,剩余两方应该可以借助数据库内的数据自动建立联系而不需要用户在做任何类似于「手机号验证码登录」的身份识别操作。这个关联逻辑需要对游客身份生成的虚拟 userid 也同样生效。

  在做 userid 的关联补充的时候,如果系统能够识别用户身份(基于获取到的 unionid),那么即使当前 userid 是虚拟的,数据库中早先用户数据的 userid 也是虚拟的,也需要保持 userid-unionid 一一对应的关系,将现在这个虚拟的 userid 替换成数据库中更早的那一个,这样用户先前的数据就可以在这个环境被读取出来,具体的应用场景在上方已经描述。但是假如其中有一个 userid 是真实的,那么它应该获得最高的优先级。

  我觉得用户体系这个东西发展了这么多年,看上去很简单,但是其实里面深究起来学问也不少,但是总的来说在实际工作的时候,还是要牢牢把握住底层的核心思想,好的用户体系主要就是做两个事情,身份识别和限权。所有的工作都应该围绕身份之别和限权这两个底层需要去做的,其实我们所做的一切,万变不离其宗,就是如何让用户把身份识别的成本降到最低,如何让系统限权做的最准确。

  从个人角度来看,微信这个 openid 和 unionid 的机制非常的蛋疼,微信自己也作出过不少次改进,但是我觉得这仍然是一件非常操蛋而且麻烦的事情。从微信官方的角度来看,他们或许还是出于保护用户隐私不被滥用的角度在做这件事情,而作为开发者也只有适应的份,毕竟这个机制已经在这边了,没啥好说的。

  上面文章内的很多想法,大部分我都实践过,效果是符合预期的,但是由于客观条件的限制,有一些想法并没有在生产环境得到过验证,并不能保证 100% 正确,况且不同的业务场景,对于同一件事情会衍生出不同的实践方案,比如本文会强调尽量做到【userid-unionid】一一对应,在实践中有一些公司是允许一个 userid 对应多个 unionid 的,其实仔细想一下,好像也没什么大毛病。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

  • 本文来自: 老铁博客,转载请保留出处!欢迎发表您的评论
  • 相关标签:微信网页授权  
  • 已有0位网友发表了一针见血的评论,你还等什么?

    必填

    选填

    记住我,下次回复时不用重新输入个人信息

    必填,不填不让过哦,嘻嘻。

    ◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。