上一章我们说了产品设计方法，接下去我们来说第二点，关于隐私审批的设计。上图中，位处左边的展现的是我们关于隐私审计这一模块功能的历史情况，右边是一个新的流程，360的数据还算比较合规，指的是什么？从系统功能开发历史来看，我们从很早以前就已经有相应的审批功能了。所以在任何的时候，如果国家相关的部门需要过来查你的隐私相关的问题，我们基本上都不会出现什么纰漏。

简单介绍一下历史上关于隐私数据审批的流程。基本是这样的一个情况，先是需要用到隐私数据的用户，这些用户需要先发邮件给我们公司内部隐私部门的同学，然后隐私部门的人员需要挨个去审核相关的数据打点采集的详情方案，判断要采集哪些范围内的数据，是否触发隐私事件。

然后，隐私部门的同学在分析完成以后，会回一封邮件说“同意”或者是“不同意”。如果回复结果是“同意”，接着这封邮件就会到我们部门来，由我们部门的人手工去调整线上的相关参数，调整完后，它的 SDK 就已经属于是被隐私审计控制过的。在其中就会存在哪些东西能采集，或者哪些东西不能采集的这样一个情况，这就是历史的情况，会牵扯到线上线下中各种各样的问题。

隐私审计部门的同学也跟我们反馈说，其实他们历史上审批过哪些业务或者哪些数据，其实他们已经很难去核查了，说很多东西已经跟踪不到了。这种情况下，如果哪个业务存在问题，需要去翻很久的邮件，这样会非常的痛苦。此外，业务同学也会有这样的问题，说他们可能采集过一些数据，但是他们也已可能已经记不清这些操作了。

因此，基于这样的一个背景，我们决定把这一套流程做线上留存化了，这样用户在需要做数据审计的时候，就可以打开我们这个平台，然后创建相应的审批，可以直接去选择需要省去的内置属性发送策略，同时他们也可以自己去添加需要审批的自定义的事件，发起相应的审批。这些审批提交之后就会推送到隐私部门，不管审批结果的反馈是成功还是失败，都会是在平台上完成。

对于审批中的内容修改也是这样子的，用户打开了记录之后，可以去修改它的内置属性发送策略，还可以还修改相应的制定意见，去申请相应的审批。同样，推到审批部门以后，会得到一个“成功”或者“失败”的反馈，这个是我们平台做出的关于隐私审批功能的一处创新。

我们通过改造以前的隐私审批方式和流程，推出了创新版本2.0。以前在定制审批内容和流程的时候，它涉及到的是审批类似开关的控制，如果这个开关打开，那么这个事件相关的数据你就能采集了， 同时与你相关的其它所有事件的数据也都能采集。但是如果关掉这个“开关”的话，与你相关的所有事件数据又都不能采集，这样就不够灵活，会存在一些问题。

因为这个问题，后来我专门去问过隐私部门的同事，我问他们说，咱们有没有哪个业务线的自定义事件的开关是关上的，他们告诉我“没有”，如此一来，隐私审计的管控其实就属于是有点形同虚设了，因为大家所授予的权限都比较大。因此，我们基本就是要制定和重构这样隐私审计相关模块，做成了审批流程控制到每一个制定区间的明细，这应该算作是一个创新。

另一个创新点属于“添加自定义事件”，是针对员工使用做出的优化，之前员工们都是手动去添加所有的自定义事件，然后再去发起相应的审批。优化之后，我们现在可以通过平台自动捕获到那个相关的打点事件，同事这些时间的信息会然进入到发现池当中去，这样员工就可以自己通过发现池去发起相应的隐私审批。

讲完隐私审批，还有需要分享的是关于权限的创新。为什么我会想讲权限创新？几乎所有的公司都会有一个内部的权限的设计，但是，据了解大多数公司关于权限的设计，要么是很复杂，要么是太简单，不是很好用，不仅用户用不明白，管理层也用不明白，我们就碰到很多类似这样的权限系统，所以我们决定要从根本上去解决这个问题。

我们先来一起了解一下权限在是干啥的，它本质上是在解决用户和是权限之间的一种关联关系，也就是给哪些人绑定到哪些权限上去。权限本身要能够去拆分成“功能权限”和“资源权限”。

功能权限，指的是类似于是菜单操作或者是资产改善相关的东西；资源权限是与产品渠道、推广活动、或者是某一张单图、某一张看板相关类型的，或者某张数据表、数据库数据财产管理这样的称之为资源。后来的演变过程中，我们发现用户开始有了组织的概念，比如说你是运营组的，他是产品组的，功能权限会变成一个角色了。可能你是管理员，或者是成员，或者是运维人员、运营人员、投放人员，那么对应的权限就会针对某一模块的功能，做相关的拆分，对应到相应的角色。

我们发现资源依然留在原地，假设我是个投放人员，有 A 游戏的投放的权限，没有 B 游戏的投放权限，你也是投放人员，但是你有B游戏的投放权限，可有A游戏的投放权限，我们都是投放人员，所以我们的角色是一样的，但是我们对应的资源是不一样的，这就就属于是最老版的RBAC的原型。我不确定这个概念是什么出现的，反正我在十年前做第一个产品的时候，就是做的公司的权限系统，那时候我就已经把公司的权重做成了第二个级别，那个时候没有 RBAC，这些东西基本比我做相关的东西要晚至少 5 年左右才出现。

再后来我们慢慢发现，其实资源相关的配置，涉及到的点非常的多，如果一个一个去做那么工作量就会比较多，所以就涉及到一个“分享”的概念。目前市面上的很多产品能够去做到，类似于某个员工能够把相应的资源做一些分享的还是比较少。比如，我们可能常见市面上的一些友盟、神策的数据看板，都会使用分享的设置给他 同事，同事在数据表、数据源也有配置有一些权限分享相关的功能相关，这说明这些公司在权限研发这一块是做的比较好的。

基于这些，我们基于 RBAC 把资源相关的东西给抽离出来，然后做相关的分享功能，这也是对系统的升级操作。

接下去我们据说说说改造了哪些内容。基于公司内部的情况，首先我们会分析组织角色和分享需要改造的原因，公司内部有 100 多个团队，部门太多了，这样就很难通过一些简单的组织设置就能够完整的区分，因此我们这个组织就很有可能会有团队的概念在里面，也会有各种各样的小组的概念，所以我们就做成了团队以及团队角色。

另外，因为我们内部的产品应用也非常多，有上百个吧，所以需要在应用层面再做一个区分，我们就会有相应的应用跟应用角色的一个拆分。

最后是有相应的分享和组织分享的区分。这样，对于某一块内容或者是资源，不仅仅可以分享给个人，同样也可以分享给某一个小组。

这个是我们内部的一个权限的改造，改造完之后能够解决哪些问题？上图中左边部分可以看出这个是我们非常常见的一个权限管理系统的一个界面。我们公司内部一些历史上一些老系统的权限模块基本就是长这样子。很多管理员都会找我们咨询权限问题，因为他们真的不知道如何使用这个系统，关于有什么权限，需要找什么平台，这些用户都需要来找我们部门的人去帮他们查。

他们也看不到相关的用户列表，时间久了之后根本就不知道他们给谁开通过权限。看到左边的菜单项，你发现功能非常多，用户自己都不知道怎么去申请什么权限。然后权限的名词概念也很多，用户基本看不懂都代表着哪些意思。

针对这样的问题我们对平台做了创新的优化，实现了团队、应用、分享权限的可视化的管理需求，满足了管理员可以随时查看、改动和删除的需求。而且，管理权限逻辑非常简单，一看就会，一点就通。从目前的使用情况来看，我们的用户来使用这个平台上手真的是非常快。

再看图中右下部分的树形结构，会有一个团队管理、团队成员的管理。同时可以给团队配置相关的角色，在运营和应用的过程中，也会有相应的成员改查角色一个流程，可以分享看板、单图、数据报表等等资源上的东西，这个是我们做完改造之后的样子，目前应该是用户使用起来非常的简单，而且是审计非常容易，因为你可以随时去查看，去管理，这个是我们的权限的创新。

-END-