国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

在本文，作者描繪了一個理想的數(shù)據(jù)BI系統(tǒng)應(yīng)該長成的樣子。你是這樣的么？enjoy~

在日常工作中，無論是to C還是to B的產(chǎn)品汪，都需要面臨一個問題，那就是在業(yè)務(wù)發(fā)展到一定規(guī)模的時候，由于林林總總的原因，譬如出于安全性考慮，亦或是業(yè)務(wù)場景愈加復(fù)雜等等，市面上的第三方數(shù)據(jù)分析平臺或者自家的平臺已經(jīng)無法滿足業(yè)務(wù)發(fā)展的需求，這時候，就要著手搭建一個強(qiáng)力的BI工具，以適應(yīng)高速發(fā)展的業(yè)務(wù)。

而一個好用的工具，將會解放生產(chǎn)力，極大的提高工作效率。加持了這個增益buff的運(yùn)營和分析師們，將會如虎添翼，向你展示什么叫地表最強(qiáng)戰(zhàn)斗力。

就算沒有KPI的壓力，那試想下，運(yùn)營小姐姐因?yàn)槟阋皇衷O(shè)計的出色BI系統(tǒng)而驚喜時，作為產(chǎn)(dan)品(shen)汪的你，是不是有機(jī)會……咳~

在進(jìn)行產(chǎn)品設(shè)計前，先花點(diǎn)篇幅來講講數(shù)據(jù)在從產(chǎn)生到消亡（歸檔）的生命周期中需要經(jīng)歷哪些階段吧。

圖：圖片來自網(wǎng)絡(luò)，侵刪

數(shù)據(jù)采集

數(shù)據(jù)來源分兩塊，一塊是內(nèi)部數(shù)據(jù)，一塊是外部數(shù)據(jù)。對于to B的業(yè)務(wù)，內(nèi)部數(shù)據(jù)多為業(yè)務(wù)數(shù)據(jù)，譬如零售業(yè)的供應(yīng)鏈倉儲以及GMV的細(xì)分?jǐn)?shù)據(jù)等，金融業(yè)的交易流水和風(fēng)控模型(風(fēng)控模型也包含了用戶行為數(shù)據(jù))等，對于to C的業(yè)務(wù)或產(chǎn)品，除了基礎(chǔ)的流量數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)外還會有用戶行為數(shù)據(jù)等。這類內(nèi)部數(shù)據(jù)的獲取較為基礎(chǔ)，常規(guī)的CS/BS的接口數(shù)據(jù)交互即可完成數(shù)據(jù)采集，對于C端產(chǎn)品，比較重要的是用戶行為數(shù)據(jù)的采集，這里就需要做好數(shù)據(jù)埋點(diǎn)的工作，細(xì)化到每個事件的節(jié)點(diǎn)。

這里拿微信舉例，從安裝，啟動，登錄/注冊的前期行為到聊天，公眾號閱讀，朋友圈查看等后期行為，不同流程的事件線會共用一些數(shù)據(jù)埋點(diǎn)。

一個用戶從喚醒a(bǔ)pp開始，記錄一系列的操作節(jié)點(diǎn)，帶上序號和時間戳，就可以完善的記錄用戶行為日志，不過這類技術(shù)的問題就不深入探究，看研發(fā)團(tuán)隊怎么選擇技術(shù)方案了。下面臆造一條行為組的日志信息。

先拋開數(shù)據(jù)加密的問題，這串日志的意思是下午13:40:03，ID為498161的用戶，通過點(diǎn)擊ID為164618的推送主動將app被喚醒，此時生成該條行為組信息的ID為341325，喚醒后按照推送給到的參數(shù)打開app進(jìn)入微信tab頁面，也就是首頁，接下來停留了約4秒后，進(jìn)行了拖拽操作，手指拖拽區(qū)間從x:334,y:130到x:560,y:363的位置，然后暫停了大概2s以后，點(diǎn)擊了坐標(biāo)x:634,y:30的位置，這個位置的目標(biāo)是一欄ID為76316的對話信息，停留了約2秒后，點(diǎn)擊頁面中的輸入框，過了約10秒鐘，輸入框失去焦點(diǎn)，此時輸入框的內(nèi)容為‘\u8001\u54e5\u53ef\u4ee5\u7684’（這里是Unicode，假裝加密了：），與此同時按下了發(fā)送按鈕。到了這里，這一系列的流程就已經(jīng)完成了，收到好友信息的推送提醒了用戶，用戶做出了回應(yīng)，并進(jìn)行一系列的操作，完成了回復(fù)。

那么，這樣一組信息數(shù)據(jù)有什么意義呢？

在微信5.3.1的版本新特性中，新增了一個這樣的功能：可以撤回兩分鐘內(nèi)發(fā)出的最后一次消息。

圖：微信5.3.1新特性

對于這個特性，筆者進(jìn)行了簡單的思考：

1. 只考慮用戶需求，不考慮商業(yè)需求。
2. 這個操作多為撤回者的需求。
3. 假設(shè)數(shù)據(jù)統(tǒng)計出一般用戶從收到消息和看到消息的時間應(yīng)該是在10s~30min，假設(shè)前兩分鐘有60%的用戶已經(jīng)閱讀了消息。
4. 對想要撤回消息的用戶進(jìn)行研究，發(fā)現(xiàn)撤回者出于保密、失誤、反悔或其它原因想要撤回消息，那這個準(zhǔn)許反悔時間大概是90s，為了容錯，將容錯時間擴(kuò)大一定的范圍。
5. 出于對被撤回者體驗(yàn)的考慮，再壓縮這個撤回的時間，避免用戶閱讀了消息，消息卻被撤回，造成閱讀者的不適。這個時間設(shè)定在120s。

上述的數(shù)值都為猜測，進(jìn)行‘撤回’這一的功能設(shè)計前，需要通過數(shù)據(jù)來對用戶行為進(jìn)行研究分析，可以量化的數(shù)據(jù)為功能設(shè)計提供了衡量的標(biāo)準(zhǔn)，并在功能實(shí)現(xiàn)后進(jìn)行數(shù)據(jù)反饋，從而修正功能設(shè)計。

為了簡潔的表達(dá)，上文的日志信息只展示行為日志，缺少了客戶端和服務(wù)端響應(yīng)或監(jiān)聽這些行為的日志，從一開始app被喚醒，服務(wù)器就和app建立了數(shù)據(jù)傳輸，接收第一條請求時就錄入了請求的終端信息，像設(shè)備型號，地理位置等等，一般來說app被喚醒的推送也會帶有喚起方的渠道標(biāo)記等信息。除了那些輸入法開發(fā)商們，敲擊鍵盤的行為選擇不采集，因?yàn)閷τ诮^大多數(shù)產(chǎn)品而言這類行為價值不是很大，還有一點(diǎn)就是，因?yàn)橄到y(tǒng)的權(quán)限限制，可能采集不到這類數(shù)據(jù)。

關(guān)于這類日志的采集，只要在需求的范圍內(nèi)，采集地越詳細(xì)越好，這樣可以精準(zhǔn)的定位問題，是技術(shù)支持、運(yùn)營策略，還是產(chǎn)品設(shè)計上的問題。在一些web類應(yīng)用中也見到過每次拖動或點(diǎn)擊就記錄行為并回傳給服務(wù)器的，這類高頻的傳輸方式能夠保障數(shù)據(jù)的完整性，但在高并發(fā)時會對服務(wù)器造成一定的壓力，產(chǎn)品汪可在需求評審會上提出此類需求和顧慮，提前讓研發(fā)團(tuán)隊了解到這種業(yè)務(wù)場景，并出具應(yīng)對的方案，下文講述數(shù)據(jù)處理時會順帶概述一些技術(shù)的方案。

內(nèi)部數(shù)據(jù)都是自家的，只要權(quán)限允許，那就可以進(jìn)行增刪改查的操作，但外部的數(shù)據(jù)大多不公開，需要購買，有些甚至無處購買，且外部數(shù)據(jù)的結(jié)構(gòu)不一，在進(jìn)行數(shù)據(jù)歸類的時候可能會造成一些困擾。對于那些能買的到的數(shù)據(jù)，往往需要進(jìn)行數(shù)據(jù)清洗。

2015年號稱互聯(lián)網(wǎng)消費(fèi)金融的元年，相關(guān)產(chǎn)業(yè)蓬勃發(fā)展。銀行系、電商巨頭以及一些傳統(tǒng)企業(yè)陸續(xù)進(jìn)軍這個市場，這些巨頭們手里掌握這充足的數(shù)據(jù)，足已支撐起一個較為全面合理的風(fēng)控系統(tǒng)。但對于那些新入局的互聯(lián)網(wǎng)團(tuán)隊，就沒這么充足的數(shù)據(jù)源去搭建其風(fēng)控系統(tǒng)，這時候，這些團(tuán)隊就需要從市場上‘專業(yè)’從事大數(shù)據(jù)服務(wù)的公司手頭購買數(shù)據(jù)。然而，這些都是經(jīng)過二道販子，三道販子甚至不知道幾手了的數(shù)據(jù)了，每一層中間商為了盈利，往數(shù)據(jù)里面兌水，一些互金巨頭為了干擾市場，也會對其中的數(shù)據(jù)進(jìn)行加工并借殼售賣，到了這些使用數(shù)據(jù)的團(tuán)隊手里時，這些充斥著垃圾的數(shù)據(jù)能有效利用的可能不到一成。而清洗這些數(shù)據(jù)，需要花費(fèi)的成本將無限大。一個用戶風(fēng)控模型的迭代修正，至少需要走完一個消費(fèi)-還貸的周期，這中間需要的時間成本不是一般的團(tuán)隊所能接受的。

對于那些買不到，但又可見的前端數(shù)據(jù)，就可以通過爬蟲的方式進(jìn)行采集。爬蟲的歷史比較悠久，自第一個搜索引擎誕生已經(jīng)過去了近三十年，而最早出現(xiàn)的爬蟲卻沒有明確的說法，唯一可以知道的是自主機(jī)web時代開始的。而發(fā)展到現(xiàn)在，爬蟲技術(shù)及其社區(qū)已經(jīng)枝繁葉茂了，從近幾年流行的python到最好的語言php，以及C語言系都可以拿來寫爬蟲。一般爬蟲的原理都是構(gòu)造請求，向目標(biāo)服務(wù)器請求相關(guān)內(nèi)容。數(shù)據(jù)本身就是一個相對敏感的點(diǎn)，有些數(shù)值類的數(shù)據(jù)往往是一個公司的命脈，為了遏制爬蟲來采集數(shù)據(jù)，公司一般會設(shè)計不同的機(jī)制來反爬蟲。譬如常規(guī)的服務(wù)器判斷請求頭部的UA和Referer，對cookie和驗(yàn)證碼的驗(yàn)證，對IP訪問次數(shù)的限制，通過對CDN標(biāo)識的判別。還有一些前端的限制的方法，比如用JS動態(tài)加載數(shù)據(jù)以及一些能加大解析頁面難度的做法。

比較成熟的就是一些前后端結(jié)合的方法，比如前文所講的用戶行為記錄，再通過用戶模型算法找出爬蟲的特征，從而進(jìn)行封殺。對于爬蟲，大多數(shù)網(wǎng)站還是比較寬容的，或者說，沒有一個萬全之策來分辨真實(shí)用戶和爬蟲，因?yàn)檎`傷率一直是個繞不過去的坎。關(guān)于如何應(yīng)對反爬蟲機(jī)制，感興趣的觀眾老爺可以繞道去攜程技術(shù)中心的公眾號看看，作為各類爬蟲教程的目標(biāo)網(wǎng)站，攜程對Anti-Crawler這個課題還是有些心得的。

圖：某公眾號的前端反爬蟲策略

數(shù)據(jù)處理

一般來說，涉及的數(shù)據(jù)的存儲處理，不在產(chǎn)品崗的只能范圍內(nèi)。但是產(chǎn)品汪么需要明確數(shù)據(jù)調(diào)用的需求，以便DB開發(fā)設(shè)計合理的技術(shù)架構(gòu)。按照數(shù)據(jù)所在的生命周期，或者數(shù)據(jù)被調(diào)用的頻率，可以將其分為四個等級，活躍數(shù)據(jù)、休眠數(shù)據(jù)、沉默數(shù)據(jù)和歸檔數(shù)據(jù)。這里拿電商的訂單周期作為范本解釋。

• 活躍數(shù)據(jù)：這里的活躍數(shù)據(jù)一般指的是需求確定需要長期存儲的數(shù)據(jù)。不包括那些存儲在緩存里，在短時間會過期的數(shù)據(jù)。用戶確認(rèn)提交訂單后，一直到確認(rèn)收貨，這個期間的訂單的數(shù)據(jù)會以高頻率被訪問，用戶、商家、平臺、物流等多方角色需要查看這條數(shù)據(jù)，以確保這個訂單完成。
• 休眠數(shù)據(jù)：休眠數(shù)據(jù)被訪問的頻率一般。訂單走完正常的周期，已經(jīng)超過退換貨的期限時，可能因?yàn)楸Ｐ?，統(tǒng)計分析等情況任會被調(diào)用。
• 沉默數(shù)據(jù)：這類數(shù)據(jù)被訪問的頻率相對較低，在常規(guī)處理和存儲后，已經(jīng)將需要長期調(diào)用的內(nèi)容存儲到其它數(shù)據(jù)庫表中作為活躍數(shù)據(jù)使用，此時源數(shù)據(jù)將進(jìn)入沉默階段，一般只在周期性的統(tǒng)計時會被調(diào)用。在分析季度商品銷售情況時，需要翻出這筆訂單來詳細(xì)的分析。
• 歸檔數(shù)據(jù)：歸檔數(shù)據(jù)指的是已經(jīng)被處理提取重要內(nèi)容的源數(shù)據(jù)，為了數(shù)據(jù)完整性，對源數(shù)據(jù)進(jìn)行歸檔處理，歸檔的意義不光是指備份數(shù)據(jù)，數(shù)據(jù)需要在生命周期的各個階段做好備份工作。歸檔的另一個意義是壓縮數(shù)據(jù)結(jié)構(gòu)，保障核心數(shù)據(jù)能夠被快速響應(yīng)。

在日常工作中，數(shù)據(jù)的等級界限也許不會這么明確，具體還得看需求的情況。

數(shù)據(jù)應(yīng)用

講完了數(shù)據(jù)的產(chǎn)生到歸檔，相信觀眾老爺心中對這個BI數(shù)據(jù)系統(tǒng)的搭建已經(jīng)有一個整體的規(guī)劃了，下面筆者將描述在筆者心中，一個理想的數(shù)據(jù)BI系統(tǒng)，應(yīng)該是長成什么樣子的？

圖：產(chǎn)品架構(gòu)

后臺的在進(jìn)行有關(guān)數(shù)據(jù)的操作時，都可以選擇進(jìn)行GUI和SQL的操作。下文的所有功能只描述GUI狀態(tài)下的使用，不描述SQL狀態(tài)下的使用。保留SQL功能的原因有以下幾點(diǎn)，就像Bash會比GUI界面發(fā)生意外的概率小很多一樣，純SQL操作比GUI操作來的穩(wěn)定，而且數(shù)據(jù)開發(fā)更樂意去使用SQL。這種保險設(shè)計可以在產(chǎn)品迭代的過程中，實(shí)現(xiàn)一些因?yàn)椴怀Ｓ枚笔У墓δ堋?/p>

下面按照操作流程，講講各模塊的功能。

數(shù)據(jù)管理

在生產(chǎn)環(huán)境中，業(yè)務(wù)數(shù)據(jù)，流量數(shù)據(jù)或著其他數(shù)據(jù)的元數(shù)據(jù)已經(jīng)產(chǎn)生，存儲在數(shù)據(jù)庫，這部分?jǐn)?shù)據(jù)稱之為「數(shù)據(jù)源」，這個功能的頁面稱之為「數(shù)據(jù)源管理」，整個后臺對數(shù)據(jù)源的唯一的權(quán)限只有讀取(select)，不然誤操作造成損失，這口鍋真不好分，直觀的看，好像是操作者的失誤，再深一步講，是技術(shù)規(guī)范的缺失，但追究到底，還是產(chǎn)品設(shè)計的缺陷，所以，權(quán)限切記控制到只讀。用戶(運(yùn)營，數(shù)據(jù)分析師，數(shù)據(jù)工程師皆稱為用戶)可以讀取數(shù)據(jù)源庫表中的元數(shù)據(jù)，并存儲到數(shù)據(jù)庫，這部分被提煉過的數(shù)據(jù)稱之為「數(shù)據(jù)集」。許多數(shù)據(jù)需要每日定時或者按照其它周期進(jìn)行處理，譬如那些避開服務(wù)器并發(fā)的時段的數(shù)據(jù)統(tǒng)計，這種數(shù)據(jù)的錯峰處理大多放在凌晨或者其他服務(wù)空閑的時段，為了節(jié)省用戶的精力和防止疏漏，這種周期性的點(diǎn)控式的任務(wù)就顯得很有意義，但是單個任務(wù)沒法滿足對復(fù)雜數(shù)據(jù)的處理需求，借用MySQL的事件調(diào)度器(Scheduler)和觸發(fā)器(Trigger)的設(shè)計理念，將這些任務(wù)連接在一起，讓它們按照指定條件依次執(zhí)行，從而實(shí)現(xiàn)按照序列處理數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)內(nèi)容的任務(wù)環(huán)。數(shù)據(jù)集操作生成的庫表的增刪改查權(quán)限控制在初始化時，默認(rèn)只開放給用戶自己，若有需求，后期可以在權(quán)限管理中配置。

業(yè)務(wù)報表

在完成了對數(shù)據(jù)的處理后，數(shù)據(jù)還只是純粹的單一結(jié)構(gòu)的內(nèi)容，干巴巴的數(shù)據(jù)難以直觀地觀察，所以數(shù)據(jù)可視化這一功能必不可少。市面上優(yōu)秀的開源前端框架有很多，這里推薦兩款——AntV和Echarts。這兩塊框架能夠滿足絕大多數(shù)業(yè)務(wù)場景，尤其推薦Echarts，給某度開源如此良心之作打call，Echarts中g(shù)allery社區(qū)的作品堪稱驚艷，如果這個框架能將性能再繼續(xù)優(yōu)化下去，那就是做數(shù)據(jù)可視化的不二之選。關(guān)于AntV的話，友商都說Ant Design可能是開創(chuàng)了UI組件庫的先河，組件的視覺、交互設(shè)計和前端的融合可謂是相當(dāng)讓人佩服。在實(shí)現(xiàn)上使用了較為先進(jìn)的框架，主要還是React實(shí)現(xiàn)，好在今年八月，Angular版本的總算發(fā)布了。不過框架歸框架，研發(fā)同學(xué)選擇技術(shù)方案是他們的權(quán)利，產(chǎn)品汪在進(jìn)行后臺設(shè)計時可以參考AntV，這樣可以讓你少走很多彎路。業(yè)務(wù)報表設(shè)計功能可以達(dá)到高度自定義，可以對業(yè)務(wù)報表的菜單、頁面布局進(jìn)行設(shè)計。在進(jìn)行圖表設(shè)計時可以選擇豐富圖表類型，從常規(guī)的折線圖、柱狀圖和餅圖等到不同領(lǐng)域常用的圖表，譬如K線圖，漏斗圖，關(guān)系圖等。然后再給圖表填充數(shù)據(jù)，按照規(guī)則給圖表入?yún)?，與此同時對該表報的展示對象進(jìn)行用戶選擇。這種高度自由的操作方式，看似會增加研發(fā)的周期和成本，但這種設(shè)計實(shí)際上將會解放研發(fā)同學(xué)。在后期產(chǎn)品迭代成型后，用戶自主使用數(shù)據(jù)生成報表，而不是常規(guī)進(jìn)行需求-開發(fā)的周期，從而讓研發(fā)同學(xué)將更多精力放在核心技術(shù)上而不是業(yè)務(wù)上。所以綜上所述，這種設(shè)計不光是功能上的設(shè)計，而且還是一種成本轉(zhuǎn)移的設(shè)計。

實(shí)時監(jiān)控

該模塊分兩個主要功能，一個是概覽功能，一個是異常預(yù)警。概覽頁面就是業(yè)務(wù)報表的Dashboard，唯一的差別就是這里的數(shù)據(jù)多為實(shí)時數(shù)據(jù)，所以不贅述，如果希望這個門面能好看點(diǎn)，那就單獨(dú)拿出來，作為一個獨(dú)立的功能需求進(jìn)行設(shè)計開發(fā)。關(guān)于異常預(yù)警模塊，很多時候名不副實(shí)，預(yù)警意義在于預(yù)測當(dāng)某個數(shù)值達(dá)到臨界點(diǎn)時進(jìn)行報警操作，但這種預(yù)警機(jī)制的算法可能會復(fù)雜，難以制定產(chǎn)品需求邏輯。所以在實(shí)際設(shè)計中，警報觸發(fā)的條件可以配置多個，按照執(zhí)行周期輪詢，觸發(fā)時進(jìn)行短信或者郵件等推送操作，和數(shù)據(jù)源管理一樣要注意的是庫表名稱的日期變量和事件環(huán)的設(shè)定。

權(quán)限管理

在講整個產(chǎn)品設(shè)計中，一直在強(qiáng)調(diào)權(quán)限的管理，不是筆者話多，這個關(guān)系到數(shù)據(jù)安全的問題還是得注意下的。數(shù)據(jù)庫的權(quán)限控制應(yīng)當(dāng)從服務(wù)器、數(shù)據(jù)庫到特定表，關(guān)于控制到特定的列甚至存儲過程，雖然MySQL有這個功能，但好像常規(guī)的權(quán)限真的沒必要控制到這么精細(xì)。當(dāng)然，對于數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)內(nèi)容的增刪改查權(quán)限還是有必要做權(quán)限控制的。最后，加上基本的操作日志的展示，用以查錯問責(zé)皆可。

講到這里筆者也就將整個產(chǎn)品設(shè)計的思路敘述完成了，觀眾老爺可能會覺得沒有圖解，過于抽象不好理解。但其實(shí)，筆者是故意沒放圖例的，因?yàn)閾?dān)心放了原型后，會誤導(dǎo)讀者進(jìn)行雷同的產(chǎn)品設(shè)計，故而只敘述核心功能，不做視覺和交互上的表現(xiàn)。如有哪里看不懂的或有歧義的可以向筆者公眾號提問，筆者會抽時間回復(fù)的。

企業(yè)在業(yè)務(wù)早期用第三方的平臺服務(wù)是高性價比的選擇，但也要考慮到后期數(shù)據(jù)遷移的問題。第三方平臺為了最大化平臺的價值，不可避免的設(shè)計通用的產(chǎn)品結(jié)構(gòu)和服務(wù)體系，以兼容更多業(yè)務(wù)場景，但這樣一來就不能適配企業(yè)一些特殊的業(yè)務(wù)需求。最重要的是，自家的數(shù)據(jù)的一系列操作都在別人家的服務(wù)器上運(yùn)行，這個數(shù)據(jù)安全的問題是塊心病。今年年中時，作為菜鳥物流的創(chuàng)始成員之一的順豐，受到菜鳥集團(tuán)的一波突襲，這已然不是站隊的問題了，從IaaS到SaaS，一大撂數(shù)據(jù)的處理和傳輸都是經(jīng)過別人家的基礎(chǔ)設(shè)施，在信息主權(quán)這個問題上，一旦發(fā)生了糾紛，那處理起來一個頭兩個大。前陣子開完的人大常會上，新修訂了反不正當(dāng)競爭法，也許有希望改善這個問題。畢竟對于企業(yè)而言，還是希望將更多的精力投入到業(yè)務(wù)經(jīng)營上，而不是進(jìn)行一些糟心的商戰(zhàn)。不過好在市場上已經(jīng)有越來越多的數(shù)據(jù)服務(wù)供應(yīng)商已經(jīng)可以提供私有化部署，加上個性化的功能設(shè)計在一定程度上可以解決企業(yè)的業(yè)務(wù)需求。

究竟是自建BI系統(tǒng)還是用第三方的平臺，其實(shí)，在觀眾老爺心中已經(jīng)有答案了。

圖：數(shù)據(jù)服商

文中產(chǎn)品設(shè)計參考了Dataworks和QuickBI的功能，如果觀眾老爺有興趣可以試用下，只是這個價格有點(diǎn)不太美麗(高級版的功能健全，基礎(chǔ)版的功能閹割太多了)。

筆者才學(xué)疏淺，若觀眾老爺有什么高見，還請猛烈拍磚。

作者：水果籃子，公眾號：老楊陪你來說事兒

本文由 @水果籃子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 unsplash