說說在toB公司和toC公司，做數(shù)據(jù)開發(fā)的差異
點擊上方 "大數(shù)據(jù)肌肉猿"關(guān)注, 星標一起成長
后臺回復【加群】，進入高質(zhì)量學習交流群
背景
通常來說，大數(shù)據(jù)開發(fā)的整體架構(gòu)基本一樣，都涉及到底層的數(shù)據(jù)平臺架構(gòu)、數(shù)據(jù)中間件的選擇、數(shù)倉模型的建立、可視化展現(xiàn)，其中數(shù)據(jù)層面主要是數(shù)據(jù)的采集（埋點、業(yè)務數(shù)據(jù)）、數(shù)據(jù)處理（離線、實時）、數(shù)據(jù)治理（數(shù)據(jù)分層、數(shù)據(jù)字典、指標體系、數(shù)據(jù)監(jiān)控、數(shù)據(jù)安全、數(shù)據(jù)數(shù)倉）、數(shù)據(jù)展現(xiàn)（BI、可視化）。
但是C端和B端對應的用戶群、核心訴求都不太一樣，會導致兩塊的數(shù)據(jù)目標、對數(shù)據(jù)的要求以及產(chǎn)品的思維方式都是不太相同的。
本人有幸針對電商C端做大數(shù)據(jù)開發(fā)2年，針對B端也做了2年，下面是我對這兩個維度的數(shù)據(jù)產(chǎn)品以及開發(fā)思維的一些見解：
產(chǎn)品思維方式的不同
1、B端數(shù)據(jù)產(chǎn)品經(jīng)理面對的是企業(yè)內(nèi)部的業(yè)務協(xié)同與業(yè)務過程，產(chǎn)品目標是通過數(shù)據(jù)提升業(yè)務的決策效率，為業(yè)務過程提供定制化的數(shù)據(jù)產(chǎn)品服務。從而將消費者的需求精準而快速地傳遞給供應鏈，使得品牌與消費者的互動更加簡潔和頻繁。
2、C端產(chǎn)品需要用數(shù)據(jù)思維做產(chǎn)品設(shè)計，產(chǎn)品設(shè)計本身就是業(yè)務過程，產(chǎn)品的目標是通過數(shù)據(jù)能夠快速的做用戶圈選、用戶畫像、用戶行為分析，為產(chǎn)品的迭代和優(yōu)化方案提供可靠的數(shù)據(jù)支撐，方便快速進行產(chǎn)品迭代，能夠很好的服務客戶。
服務對象不同
1、B端服務的對象是企業(yè)。核心訴求是：功能，流程，效率。作為B端某個方向的負責人的話，是對整個方向產(chǎn)品線負責，要學會在實際的業(yè)務需求中發(fā)現(xiàn)問題，解決問題，考慮系統(tǒng)的延展性與彈性，從而提升整個業(yè)務工作效率；
2、C端服務的對象是個人，側(cè)重滿足個人生活需求，給用戶提供愉悅感（滿足便利、新鮮感、虛榮心、欲望沖動），好玩。核心訴求是：交互、體驗、使用成本。
數(shù)據(jù)的需求不同
1、B端根據(jù)客戶的戰(zhàn)略或服務于線下已有的流程，構(gòu)建生態(tài)體系，推動將流程系統(tǒng)化，提高效率。客戶關(guān)心的是軟件是否滿足企業(yè)的需求，是否符合實際業(yè)務流程，是否提高企業(yè)運作效率，是否實現(xiàn)規(guī)范化管理，同時更關(guān)心投入產(chǎn)出比(ROI)。。
2、C端更多的關(guān)注是如轉(zhuǎn)化率、功能留存、增長、頁面停留時長等指標，只有關(guān)注這些指標才能更好的對產(chǎn)品進行優(yōu)化和迭代。同時需要深挖消費者的心智模型，使用習慣，付費習慣，構(gòu)建出能夠滿足消費者需求的有用戶價值產(chǎn)品，進而在用戶價值的基礎(chǔ)上建立商業(yè)模式，產(chǎn)生商業(yè)價值。
to B相比to C在經(jīng)營模式上需要一支鏈條更長的團隊來運作。
to C，有產(chǎn)品經(jīng)理、研發(fā)、再加一個推廣運營就OK了，一支團隊、三個角色可能就夠了；但是to B不一樣，得有市場營銷，有了線索之后得有銷售去轉(zhuǎn)化，銷售過程中可能還需要售前的配合，要給客戶出方案，而客戶不僅是一個人更是一個團隊，還需要產(chǎn)品、研發(fā)、客服和技術(shù)支持等等，每個環(huán)節(jié)都是人在運作。鏈條一旦復雜之后，如果沒有很好的戰(zhàn)略能力、戰(zhàn)略定力和組織能力，to B很難經(jīng)營得很好。
to C的客戶是一個個的人，我們自己也是一個個的人，我們可以問自己，問身邊的人，觀察周圍的人；但to B我們面對的是一個個特定行業(yè)、特定場景里的組織，我們得真正理解這個行業(yè)。
項目
C端項目，之前主要做了2大塊：
1、APP的各個頁面、模塊的健康度（針對APP的優(yōu)化升級和版本迭代）
業(yè)務需求：
APP版本迭代，驗證每個頁面、頁面上的每個模塊是否滿足用戶需求，驗證各個模塊的調(diào)整是否符合用戶習慣，驗證新上線的活動是否達到預期目標，驗證每個模塊帶來的商品加購和成交轉(zhuǎn)化率是否達標。
技術(shù)方案：
設(shè)計埋點規(guī)范，前端對頁面進行埋點，并對觸發(fā)進行監(jiān)控，保障數(shù)據(jù)回傳的準確性；
數(shù)據(jù)采集，保障數(shù)據(jù)的準確性和完整性，確保不丟失數(shù)據(jù)（加入第三方數(shù)據(jù)校驗）；
數(shù)據(jù)校驗，上線之前，對埋點數(shù)據(jù)進行校驗，保障埋點數(shù)據(jù)的不丟失；
數(shù)據(jù)ETL，將采集的數(shù)據(jù)進行解析，并生成格式化數(shù)據(jù)存儲到HDFS；
數(shù)據(jù)聚合，統(tǒng)計每個頁面、每個模塊的訪問和點擊情況、頁面的停留時長、曝光商品數(shù)、帶來的加購和成交等核心數(shù)據(jù)指標；
數(shù)據(jù)展現(xiàn)，將統(tǒng)計結(jié)果的數(shù)據(jù)存到可視化平臺（QuickBI、Matebase等），進行可視化展現(xiàn)，并發(fā)現(xiàn)訪問的趨勢等；
粗略的大概是以上指標，但是UV又區(qū)分到用戶分層和活躍用戶的情況，訂單也涉及到首次加購和復購情況，商品詳情頁也分為普通商品、活動頁等等。。
基于以上的數(shù)據(jù)指標可以分析出：
APP的日活是否正常；
一些功能入口設(shè)計沒有帶來訪問和停留，是否可以優(yōu)化或者替換；
導購模塊鏈路是否合理，一些導購入口訪問量很大，但是帶來的商品詳情頁的訪問和下單加購確不合理，是否是因為一些功能設(shè)計不夠合理；
每個模塊帶來的訂單轉(zhuǎn)化對比，定期迭代相應的模塊，提高轉(zhuǎn)化率；
2、APP用戶鏈路分析（針對用戶活躍、留存、拉新、增長、分層等）
用戶規(guī)模、用戶活躍、用戶留存、用戶復購、用戶分層等。
業(yè)務需求：
用戶分群和精準推送、用戶畫像、搜索推薦等
技術(shù)方案：
埋點數(shù)據(jù)采集和ETL；
業(yè)務數(shù)據(jù)的監(jiān)聽和采集；
不同維度數(shù)據(jù)的聚合和ETL；
數(shù)倉模型搭建和數(shù)據(jù)聚合，完成業(yè)務數(shù)據(jù)支撐；
這塊統(tǒng)計涉及到維度和統(tǒng)計范圍都是比較廣的，涉及到埋點日志、業(yè)務數(shù)據(jù)、推廣和投放等各個渠道的數(shù)據(jù)。如何對這部分數(shù)據(jù)進行ETL和聚合是這塊的主要技術(shù)難點。
B端項目，主要也做了2大塊
1、B端線索分配數(shù)據(jù)
業(yè)務需求：
整合B端售前數(shù)據(jù)，提供工作臺展現(xiàn)各個門店的核心指標數(shù)據(jù)以及ROI；
整合線索流轉(zhuǎn)的軌跡，和各個階段的轉(zhuǎn)化率和流失率；
挖掘影響最后成交的核心點，對該點進行優(yōu)化；
按照區(qū)域、大區(qū)去發(fā)現(xiàn)門店適合做什么活動方便門店快速的成交。
技術(shù)方案：
業(yè)務流程的數(shù)據(jù)治理和整合，打通了線索分配到車商后的整個流轉(zhuǎn)過程；
建立線索分配后各個節(jié)點的DW層數(shù)據(jù)，方便后續(xù)聚合；
將各個流程模塊化，相互之間強關(guān)聯(lián)，但是弱耦合。強關(guān)聯(lián)是為了分析整個業(yè)務流程的趨勢，以及各個流程之間的相關(guān)關(guān)聯(lián)和轉(zhuǎn)化程度，弱耦合是為了保障各個模塊獨立性，每個模塊的數(shù)據(jù)單獨展現(xiàn)，可以隨時在模塊中新增、刪除或者替換指標，并不影響整個工作臺看板數(shù)據(jù)的展現(xiàn)。
建立數(shù)倉模型，以線索創(chuàng)建為事實表，并對后續(xù)跟進、約見、成交、活動等事實表進行維度上卷，聚合成線索+門店為唯一性主鍵的大寬表；
基礎(chǔ)數(shù)據(jù)流程：
數(shù)倉模型-雪花模型（線索域）
2、B端店鋪分層/門店健康分分層（在to C的時候也做過對入駐APP的店鋪進行分層）
業(yè)務目標：
按照一定的維度進行店鋪分層，區(qū)分頭部、腰部、尾部的店鋪，通過對頭部店鋪的行為進行分析，將一些好的行為和活動賦能給其他的門店，希望能夠提升所有門店的結(jié)果。
前提：驗證店鋪好不好的唯一標準就是成單量（ORI）
技術(shù)方案：
確定和店鋪健康程度相關(guān)的一些指標；
列出對應的加分項和減分項；
將指標進行關(guān)聯(lián)性性分析，對于同一節(jié)點中強相關(guān)的指標可以選擇一個重要指標作為唯一指標。
篩選出固定指標后，例如歷史數(shù)據(jù)的情況來添加權(quán)重，建立分層模型。
預測未來幾個月不同層級店鋪成單情況，如果符合模型預測，則這個模型沒啥問題，不符合重新調(diào)整參數(shù)。
分析頭部門店的銷售能力、業(yè)務操作，將其規(guī)范化賦能給其他店鋪。
通過過去6個月的數(shù)據(jù)來確定各個指標對應的數(shù)值或者權(quán)重。
例如：
銷量為例：銷量得分總分為100分。
對店鋪按照銷量進行排序，如果該店鋪銷量在全部店鋪排名為前1%，那么得分為100。
當然還可以按照優(yōu)先級進行權(quán)重評判。
結(jié)論
當然上面的情況只是在兩家公司的總結(jié)，并不能作為一個普適的標準，就算to C的電商公司賣的商品也會有很大的區(qū)別，例如買小型商品和奢侈品的平臺在商業(yè)模式是是有很大的區(qū)別的。在電商公司看來很重要的加購行為，在拼多多是不能適用的。
但是to B和to C還有有點本質(zhì)差別的：
to C講究的是創(chuàng)新和匠心，特別看中玩法，不論像之前的搭伙、拼團，還是后面的紅包、優(yōu)惠券，都是不同的玩法，如何抓住新用戶（創(chuàng)新）、維護一批忠實客戶（匠心）是C端產(chǎn)品主要研究的點。
to B講究的是賦能，或者像網(wǎng)易所說的“合能”，主要是聚集在效率上，希望跟你合一起，幫助你成長，相對來說在模式上需要一個更長的鏈路去支撐，尤其是市場營銷，而且這一塊大部分偏線下，不太好把控。
相對來說，to B更加的困難。
to B賣出去產(chǎn)品僅僅是一系列工作的開始。要實現(xiàn)產(chǎn)品價值，還有漫長的過程。
B 端獲客周期長，獲客成本高。
難獲真實需求，主觀臆想易犯低級錯誤，to C你本身可能就是核心用戶，所以在定義用戶需求中，不會犯特別低級的錯誤。
要用標準化產(chǎn)品滿足碎片化需求，企業(yè)服務的競爭力核心，就是如何盡量用標品、盡量用產(chǎn)品化的方式，來解決用戶不同的問題。
提高效率是to B的最主要的賦能方式。
營銷環(huán)節(jié)是to B獨有而且重要的環(huán)節(jié)，To B 業(yè)務的價值鏈長很多，首先做好產(chǎn)品本身就不容易，因為客戶個性化需求多。其次光做好產(chǎn)品還不行，還需要銷售、服務、客戶成功等多部門的協(xié)同配合，這就對組織能力提出了更高的要求。
當然上面都是一個數(shù)據(jù)開發(fā)人員的視角，可能只是一個片面的結(jié)論。
開發(fā)人員能做的就是切合到具體的業(yè)務場景，根據(jù)它具體的業(yè)務模式和數(shù)據(jù)情況來分析出能夠賦能業(yè)務的數(shù)據(jù)指標。
--end--
掃描下方二維碼
添加好友，備注【交流】
可私聊交流，也可進資源豐富學習群
更文不易，點個“在看”支持一下??