? ? ??2 隱私審批設計

? ? ??上一章我們說了產品設計方法，接下去我們來說第二點，關于隱私審批的設計。上圖中，位處左邊的展現的是我們關于隱私審計這一模塊功能的歷史情況，右邊是一個新的流程，360的數據還算比較合規，指的是什么？從系統功能開發歷史來看，我們從很早以前就已經有相應的審批功能了。所以在任何的時候，如果國家相關的部門需要過來查你的隱私相關的問題，我們基本上都不會出現什么紕漏。

? ? ??簡單介紹一下歷史上關于隱私數據審批的流程。基本是這樣的一個情況，先是需要用到隱私數據的用戶，這些用戶需要先發郵件給我們公司內部隱私部門的同學，然后隱私部門的人員需要挨個去審核相關的數據打點采集的詳情方案，判斷要采集哪些范圍內的數據，是否觸發隱私事件。

? ? ??然后，隱私部門的同學在分析完成以后，會回一封郵件說“同意”或者是“不同意”。如果回復結果是“同意”，接著這封郵件就會到我們部門來，由我們部門的人手工去調整線上的相關參數，調整完后，它的 SDK 就已經屬于是被隱私審計控制過的。在其中就會存在哪些東西能采集，或者哪些東西不能采集的這樣一個情況，這就是歷史的情況，會牽扯到線上線下中各種各樣的問題。

? ? ??隱私審計部門的同學也跟我們反饋說，其實他們歷史上審批過哪些業務或者哪些數據，其實他們已經很難去核查了，說很多東西已經跟蹤不到了。這種情況下，如果哪個業務存在問題，需要去翻很久的郵件，這樣會非常的痛苦。此外，業務同學也會有這樣的問題，說他們可能采集過一些數據，但是他們也已可能已經記不清這些操作了。

? ? ??因此，基于這樣的一個背景，我們決定把這一套流程做線上留存化了，這樣用戶在需要做數據審計的時候，就可以打開我們這個平臺，然后創建相應的審批，可以直接去選擇需要省去的內置屬性發送策略，同時他們也可以自己去添加需要審批的自定義的事件，發起相應的審批。這些審批提交之后就會推送到隱私部門，不管審批結果的反饋是成功還是失敗，都會是在平臺上完成。

? ? ??對于審批中的內容修改也是這樣子的，用戶打開了記錄之后，可以去修改它的內置屬性發送策略，還可以還修改相應的制定意見，去申請相應的審批。同樣，推到審批部門以后，會得到一個“成功”或者“失敗”的反饋，這個是我們平臺做出的關于隱私審批功能的一處創新。

? ? ??我們通過改造以前的隱私審批方式和流程，推出了創新版本2.0。以前在定制審批內容和流程的時候，它涉及到的是審批類似開關的控制，如果這個開關打開，那么這個事件相關的數據你就能采集了， 同時與你相關的其它所有事件的數據也都能采集。但是如果關掉這個“開關”的話，與你相關的所有事件數據又都不能采集，這樣就不夠靈活，會存在一些問題。

? ? ??因為這個問題，后來我專門去問過隱私部門的同事，我問他們說，咱們有沒有哪個業務線的自定義事件的開關是關上的，他們告訴我“沒有”，如此一來，隱私審計的管控其實就屬于是有點形同虛設了，因為大家所授予的權限都比較大。因此，我們基本就是要制定和重構這樣隱私審計相關模塊，做成了審批流程控制到每一個制定區間的明細，這應該算作是一個創新。

? ? ??另一個創新點屬于“添加自定義事件”，是針對員工使用做出的優化，之前員工們都是手動去添加所有的自定義事件，然后再去發起相應的審批。優化之后，我們現在可以通過平臺自動捕獲到那個相關的打點事件，同事這些時間的信息會然進入到發現池當中去，這樣員工就可以自己通過發現池去發起相應的隱私審批。

? ? ??3 權限管理創新

? ? ??講完隱私審批，還有需要分享的是關于權限的創新。為什么我會想講權限創新？幾乎所有的公司都會有一個內部的權限的設計，但是，據了解大多數公司關于權限的設計，要么是很復雜，要么是太簡單，不是很好用，不僅用戶用不明白，管理層也用不明白，我們就碰到很多類似這樣的權限系統，所以我們決定要從根本上去解決這個問題。

? ? ??我們先來一起了解一下權限在是干啥的，它本質上是在解決用戶和是權限之間的一種關聯關系，也就是給哪些人綁定到哪些權限上去。權限本身要能夠去拆分成“功能權限”和“資源權限”。

? ? ??功能權限，指的是類似于是菜單操作或者是資產改善相關的東西；資源權限是與產品渠道、推廣活動、或者是某一張單圖、某一張看板相關類型的，或者某張數據表、數據庫數據財產管理這樣的稱之為資源。后來的演變過程中，我們發現用戶開始有了組織的概念，比如說你是運營組的，他是產品組的，功能權限會變成一個角色了。可能你是管理員，或者是成員，或者是運維人員、運營人員、投放人員，那么對應的權限就會針對某一模塊的功能，做相關的拆分，對應到相應的角色。

? ? ??我們發現資源依然留在原地，假設我是個投放人員，有 A 游戲的投放的權限，沒有 B 游戲的投放權限，你也是投放人員，但是你有B游戲的投放權限，可有A游戲的投放權限，我們都是投放人員，所以我們的角色是一樣的，但是我們對應的資源是不一樣的，這就就屬于是最老版的RBAC的原型。我不確定這個概念是什么出現的，反正我在十年前做第一個產品的時候，就是做的公司的權限系統，那時候我就已經把公司的權重做成了第二個級別，那個時候沒有 RBAC，這些東西基本比我做相關的東西要晚至少 5 年左右才出現。

? ? ??再后來我們慢慢發現，其實資源相關的配置，涉及到的點非常的多，如果一個一個去做那么工作量就會比較多，所以就涉及到一個“分享”的概念。目前市面上的很多產品能夠去做到，類似于某個員工能夠把相應的資源做一些分享的還是比較少。比如，我們可能常見市面上的一些友盟、數據看板，都會使用分享的設置給他 同事，同事在數據表、數據源也有配置有一些權限分享相關的功能相關，這說明這些公司在權限研發這一塊是做的比較好的。

? ? ??基于這些，我們基于 RBAC 把資源相關的東西給抽離出來，然后做相關的分享功能，這也是對系統的升級操作。

? ? ??接下去我們據說說說改造了哪些內容。基于公司內部的情況，首先我們會分析組織角色和分享需要改造的原因，公司內部有 100 多個團隊，部門太多了，這樣就很難通過一些簡單的組織設置就能夠完整的區分，因此我們這個組織就很有可能會有團隊的概念在里面，也會有各種各樣的小組的概念，所以我們就做成了團隊以及團隊角色。

? ? ??另外，因為我們內部的產品應用也非常多，有上百個吧，所以需要在應用層面再做一個區分，我們就會有相應的應用跟應用角色的一個拆分。

? ? ??最后是有相應的分享和組織分享的區分。這樣，對于某一塊內容或者是資源，不僅僅可以分享給個人，同樣也可以分享給某一個小組。

? ? ??這個是我們內部的一個權限的改造，改造完之后能夠解決哪些問題？上圖中左邊部分可以看出這個是我們非常常見的一個權限管理系統的一個界面。我們公司內部一些歷史上一些老系統的權限模塊基本就是長這樣子。很多管理員都會找我們咨詢權限問題，因為他們真的不知道如何使用這個系統，關于有什么權限，需要找什么平臺，這些用戶都需要來找我們部門的人去幫他們查。

? ? ??他們也看不到相關的用戶列表，時間久了之后根本就不知道他們給誰開通過權限。看到左邊的菜單項，你發現功能非常多，用戶自己都不知道怎么去申請什么權限。然后權限的名詞概念也很多，用戶基本看不懂都代表著哪些意思。

? ? ??針對這樣的問題我們對平臺做了創新的優化，實現了團隊、應用、分享權限的可視化的管理需求，滿足了管理員可以隨時查看、改動和刪除的需求。而且，管理權限邏輯非常簡單，一看就會，一點就通。從目前的使用情況來看，我們的用戶來使用這個平臺上手真的是非常快。

? ? ??再看圖中右下部分的樹形結構，會有一個團隊管理、團隊成員的管理。同時可以給團隊配置相關的角色，在運營和應用的過程中，也會有相應的成員改查角色一個流程，可以分享看板、單圖、數據報表等等資源上的東西，這個是我們做完改造之后的樣子，目前應該是用戶使用起來非常的簡單，而且是審計非常容易，因為你可以隨時去查看，去管理，這個是我們的權限的創新。