在騰訊公司內部有非常多以技術架構為主的精彩的中臺的搭建經驗分享。那麼中臺產品需要產品經理嗎？如果需要的話，他和架構師的分工是什麼？中臺產品經理到底做什麼？筆者以中臺產品經理的視角，以“極光運營中臺”的經驗為基礎，談談構建一站式運營平臺的產品方法思考。（極光目前服務CSIG的6條產品線-騰訊手機管家、QQ同步助手、騰訊相簿管家、騰訊wifi管家、QQ安全中心、換機助手，覆蓋億級月活產品的運營中臺）
（一～三）部分為中颱產品方法、（四）部分為中颱搭建實戰和增長應用案例。
一、中臺產品需要產品經理嗎？
回答是肯定的。
中臺產品和C端產品一樣有很多產品的通用素質，著重分享與C有區分的產品工作。
1、是產品也是使用者：
中臺產品的構想，完全是由於作為一個C端產品經理的自己出發。深深被日常的“提數，配單，打包，資料回收”往返於各種平臺的重複工作困擾。自身需求的需要，可以說是搭建運營中臺的一個原始起點。
2、多角色需求驗偽：
類似使用者調研，但是調研物件主要是產品運營角色。
全形色訪談
剛開始訪談是完全圍繞產品和運營角色。隨著著訪談深入，發現運營需要依賴很多其他角色（測試，資料運維，開發開發）於是將利益相關者都補充到調研中-測試、資料運維、終端開發、設計師，覆蓋運營中臺真正要解決的全部問題。
真正去理解業務
- 相比C端調研，中臺需求調研使用者量不大，全部採用定性研究-訪談形式。
- 在訪談指令碼上，優先他們最熟悉也最關心的自身業務開始，非常容易挖掘到痛點。而非一來就是“你想要一個什麼樣的運營中臺？”
- 還有一個重要原因，業務的需求千差萬別，但是中臺不可能面面俱到，但需要提供一套統一的方案儘可能預見和包含大部分共性場景。透過不同業務的敘述，非常容易提煉到共性需求是什麼？
- 面對小眾的需求，可以再向其他角色驗證這個需求從中長期來看的真偽。
例如：在對“應用安全”的產品webber訪談時，發現他們有自己的一套後臺來輸送“有QQ和微信賬號風險“的使用者。
運營中臺是否要提供一個接入其他後臺資料來源的能力？
調研中發現有較多業務涉及到其他的資料來源後臺，這個需求有一定共性，只是其他產品需求暫時不迫切。
而當能力上線後，實際上有14%的業務都使用了接入資料來源能力！
拉上架構師一起訪談
驚歎於開發的溝通能力的同時，發現拉開發一起去訪談，除了提升參與感和使命感，也能從中長期幫助他們構思中臺方案。
3、持續關注行業：
行業能力分析，在後文“平臺搭建”部分會有詳述。這裡談一些關注行業的“野路子”
成為競品的會員
成了神策的訂閱會員後，他們的客戶經理會把最新行業方案會透過微信客服發給我。
另一方面會員在體驗demo上也會非常方便。
參與行業產品的會議
在參加行業頭部的某saas方案提供商的會議溝通中，瞭解到對方的通道sdk覆蓋量級以及每日的通道觸達比例，能大致對標自身產品在行業中的能力位置，方便為產品將來to b做能力定位。不是面對面談，是很難獲取這些資料的。
瞭解對方商業模式
行業產品與騰訊內解決方案最大差別，其實就在於商業模式。商業模式決定了各自的節奏。行業面向頭部客戶提供1V1定製方案，中腰部客戶以接入現有通用方案為主。
在騰訊內實際運營方案的需求上可以更多一線經驗驗證，也可以反向推動能力迭代。換句話說，我們與客戶之間幾乎沒有gap。
4、找到推動業務接入的支點：
別以為內部中臺推廣是沒有阻力的。舊平臺舊方案雖然痛，但業務的慣性是很強的，克服慣性的動力從哪來？
mvp-打造標杆：
挑選新業務線來接入，既不存在重新開發之痛，新方案也方便和舊方案做對比。
例如在手管產品完全接入之初，就選用了未接入過push的體檢業務，從頭開始，也打響了第一戰。
瞭解接入方的核心訴求
當推動同步助手接入的時候，對方的核心訴求是提升主動，透過手管在提主動的資料效果，和實際對同步助手的可提升空間分析，幫助團隊一錘定音，敲掉接入上的不確定性。
納入業務自己的流程中：
新業務在開發的時候往往還不會考慮到業務的運營場景，但是實際上開發的時候完全可以把push，彈窗的觸發和上報做完。
例如省電業務在第一期開發的時候就直接把開始充電和電量變化的觸發和上報一起做了，做到了業務和業務push等運營場景一起上線，一上線就吃到運營場景的資料紅利，扶持新業務渡過”初創期“。
用業務資料來做新特性宣講：
產品往往會聽說“**業務最近資料漲的很好”先準備學一波經驗，這個時候帶業務案例和資料的宣講起到的就是這個作用。
二、中臺產品經理和中臺架構師的分工是什麼？
說了上面的這麼多，其實已經回答了中臺產品在產品通用素質上的工作。
那在中臺設計的專業維度上，中臺產品經理和中臺架構師的分工是什麼？
產品經理主外
——類似工業設計師，負責外觀設計，互動介面設計。
需要理解業務邏輯，產品設計邏輯，同時還要了解中臺涉及到的技術原理。
和互動設計師一起完成中臺操作層設計。
架構師主內
——類似機械設計師，負責機械結構設計。
需要非常紮實的技術原理知識體系。
和終端以及其他後臺角色溝通完成中臺架構設計。
三、產品角度的中臺設計
1、中臺的使命
用業務角度來說：
就是把適合的內容在合適的時間合適的場景傳遞到適合的人手上
打個比方來說：
中臺就像是一家大餐廳，顧客會有自己的口味愛好，我們的目標就是讓顧客吃到最喜愛的菜品，讓顧客成為我們的忠實顧客。
2、中臺模組組織
要實現上面的輸送效果，中臺需要包含6個模組：
1、業務-食材
2、業務上報-使用者口味
3、任務-選單
4、下發通道-廚房
5、優先順序模型-上菜次序
6、業務場景-就餐場合
四、中臺產品搭建實戰
1、業務
業務是中臺管理的基礎維度
那到底業務怎麼理解？
我們把功能按照相對獨立的模組，可以一定程度在模組內完成一個需求的自閉環，這樣的模組可以拆成一個業務。
手機管家業務可以這樣劃分：垃圾清理，應用安全，病毒檢測，這三個業務（不列舉每個業務）
為什麼業務是基礎維度？其實這裡踩過一些坑
行業產品都是以場景作為基礎維度，極光也是這麼設計的。
當場景越來越多發現，每個場景業務都要接入一遍！可怕的重複造輪子竟然出現在中臺產品上！
其實業務在各個場景上是可以複用的！定義好業務在不同場景通用屬性，定義好業務在不同場景的不同屬性。就可以把通用場景屬性直接復
用到多場景。
那為什麼行業競品反而要以場景作為維度呢？當把極光售賣給中石化時就理解了這種出發點，很多b端產品只會接入一個場景，他們可能是隻需要push或者只需要微信通知，因此單一場景的接入更容易滿足他們的需求！
2、業務上報
業務上報可以告訴中臺使用者喜歡、不喜歡的業務是什麼，以及最近消費業務的頻次等。
業務上報主流解決方案有三類-個性化上報、業務通用上報、無埋點上報。
2.1業務個性化上報：
個性化上報，主要是分業務的需求差異比較大，強依賴業務本身完成上報。
例如垃圾清理關注使用者手機有多少垃圾，病毒檢測也關注本地有沒有可以軟體安裝包。一個業務關注的多個指標可以綜合來判斷業務對於使用者的價值，因此需要用業務來bound；
2.2業務通用上報（後文rfm模型的基礎依據）：
業務之間基本需求一致，記錄使用者使用該業務的頻率frequency、間隔recency、和正負反饋monetary；這裡由中臺來記錄使用者對於某個業務rfm的資料。
不同業務的單位不一樣，例如垃圾清理的間隔頻率較高單位用小時，病毒檢測頻率較低單位用天。
2.3業務上報的使用案例-新增使用者啟用
三種使用者分類：
主要根據新增使用者的業務個性化上報和通用上報和資訊將新增使用者分為：
A.有上報新增渠道號的B.沒有上報新增渠道號但使用過手管的使用者C.沒有上報新增渠道號也沒有使用過手管
A.有上報新增渠道號的——渠道號資訊啟用
案例：使用者在應用市場搜尋“號碼鑑定”搜到了手機管家，這個時候順手下載了手管。使用者就帶有了來自**應用用市場-號碼鑑定渠道的這樣一個渠道。
中臺承接方案：此時中臺上已經配置好了各種渠道號的對應啟用內容彈窗。使用者一開啟手機管家成功通訊後拉取到了對應彈窗，就會彈出引導使用者使用。
B.沒有上報新增渠道號但使用過手管某個功能——功能行為啟用
案例：使用者在安裝一週內使用過手管的“帳號風險監測”功能，而後就不再使用手管。
中臺承接方案：一旦行為資料匹配到中臺已經配置的外部引導內容，即對使用者下發。形式按照優先順序-外部push>通知欄訊息>桌面圖示（綜合轉化率與使用者體驗排序）
C.沒有新增渠道號也沒有使用過手管——冷啟動
案例：使用者沒有渠道資訊，且安裝後也沒有使用過手管，或者手管下發的啟用內容不感興趣。這個時候就將使用極光的冷啟動方案。
中臺承接方案：按照手管歷史轉化行為排序，剔除掉使用者不感興趣的功能，對使用者進行觸達和轉化。
最終效果：
3、任務
有了前兩步的業務+業務上報，只需要補齊一些配置即可生成任務。
3.1任務配置：
透過提煉運營操作場景，原來需要在打包平臺（素材打包）、雲推平臺（配單）、提數平臺（使用者畫像提取）的多分支流程合入到同一個一站式平臺上。
3.2任務組（abtest）
這裡著重介紹abtest的設計方案：
極光對於流量的處理方式也有兩種-
- 流量互斥，先選擇流量分層，同一層的流量再分桶，同層不同桶流量之間互斥。
- 流量正交，不同層流量之間的多桶流量正交。確保實驗的隨機性也就是實驗結果更可信。
最終對比實驗組內的關注指標，可以只配置單層，也可以配置單桶，用於正式階段的穩定投放。
更多流量實驗模型可以參考筆者整理的（空對照組、PSM模型、RDD模型、非依從實驗Trigger、MBA實驗等詳述）
騰訊文件實驗模型評估
https://docs.qq.com/sheet/DZGRrZ01hVHpFaFJv
實際使用示意圖：
4、下發通道
下發通道，就像廚房做菜，通常來說我們有兩種選擇：自己的廚房來做菜——app自身通道，或者自己做不過來，別人做的更快更好，那我們也可以去採購別人做好的菜——拓展通道。
不同通道的賬號體系不一樣，用賬號地圖來匹配拓展通道的使用者，確保觸達的正確性。
4.1極光整合擴充套件通道
4.1.1整合通道方案
極光sdk集成了多個擴充套件通道能力，同時還可以持續透過代理服務與介面對接的方式與其他通道sdk資料進行對接，動態擴充套件通道觸達能力。
- 手機廠商推送服務QueryPushTunnelServer&AndriodManuPushServer-透過手機廠商自帶的推送服務來下發訊息；
- 微信小程式/服務號通知WeChatAccessServer-透過對接小程式/服務號後臺下發訊息；
- 簡訊代理服務MobileMessageServer-透過呼叫第三方簡訊服務來下發簡訊。
4.1.2整合通道的使用
通常在使用擴充套件通道的目的都是唯一觸達（相對應的是重複觸達，重複觸達容易增加解除安裝風險）
極光設計了對於通道進行優先順序控制，按照優先順序層級對通道進行觸達指定，一旦在某一層完成了觸達，任務即停止，不再觸達下面的通道。
4.1.3擴充套件通道效果
透過擴充套件通道，對不存活的使用者觸達（訊息送達）達到45%以上滲透（滲透取決於各通道能力&接入擴充套件通道數量）
4.2賬號圖譜
由於擴充套件通道涉及通道較多，不同通道識別使用者的id不一樣，而極光需要一張統一的賬號圖譜來覆蓋多個通道的使用者id。
4.2.1使用者唯一賬號user-id：
透過整合多個通道使用者id資訊的統一user id，作為一個複合型代表一個人在多個通道唯一性身份的id，這個uid的依據就來自下面的裝置vid和社交aid。就像我們的身份證可以對應駕照對應護照對應港澳通行證的一對多關係。
4.2.2裝置賬號vid：
通常有guid，imei，oaid和idfa。完成對於聯盟、手機廠商到訊息推送的使用者定位。
4.2.3社交賬號account-id：
例如微信和qq。完成對於小程式/服務號通知下發。甚至手機簡訊下發。
5、優先順序模型
優先順序確定有三層
5.1rfm自動模型：
透過上面“️業務上報“部分獲得的使用者上報資訊，業務的頻率frequency、間隔recency、和正負反饋monetary，進行單一變數實驗。
確定業務優先順序與使用者行為對關係：
- 間隔recency——拆分為三個觸達視窗期：冷卻期，聯絡期，挽回期
業務使用間隔越短的冷卻期應減少打擾；間隔適中期間，保持聯絡；挽回期增加聯絡。
- 頻率frequency——與忠誠度成正比，達拆分為忠誠&普通使用者
業務忠誠度高的使用者減少打擾，業務普通使用者嘗試其他功能觸
- 活躍天數monetary——不通業務偏好的使用者對於主動活躍天數有明顯差異，拆分為三個梯隊：高頻、中頻、低頻
高頻業務優先推薦，中頻業務其次，低頻最低
透過上面的實驗資料，透過忠誠度和觸達視窗可以劃分為6種使用者聚類：忠誠活躍使用者、普通活躍使用者、忠誠使用者、普通使用者、忠誠預流失
使用者、普通預流失使用者。
每種聚類提供相對應的使用者自身偏好功能，保留符合命中區域策略內的任務，剔除未命中任務進行下發。
5.2轉化率獎懲模型：
有了上面5.1的rfm模型之後，自動化的優先順序達到最佳轉化的目的就有了底層的實現。
5.2.1為什麼要做轉化率獎懲？
這時出現了一個新問題。就是高轉化業務永遠獲得更高流量，低轉化業務永遠墊底。對於業務側無法透過“自身努力”調整業務獲得明顯的逆襲。對用使用者側感知也會經常收到相似的推送。
長此以往，業務間的流量變成“一潭死水“
5.2.2如何做獎懲？
簡單的說“點選率提高強獎勵，點選率下降弱懲罰”，曝光-點選這一層是業務自身最容易透過abtest去最佳化的一層，我們用點選率作為指標，幫助努力的業務逆襲
計算規則如下：
5.2.3自動化流量分配效果如何？
流量被盤活-原來頭部效應明顯的業務，變得有起有落，業務有動力主動最佳化
5.3業務人工干預：
人工對於業務進行優先順序按照比例排序，這一層優先順序高於上面兩層自動化模型
5.4全域性風控：
出於使用者體驗，和合規風險。務必進行全域性維度風控，這樣各個業務不需要關心和其他業務的衝突，中臺會從全域性去控制體驗。
5.5優先順序控制效果
5.5.1曝光轉化率提升
透過提高了觸達對準確性，最終提升了運營內容從曝光到點選的轉化。
以手機管家為例，接入極光前運營場景的點選率均值5.16%接入後提升到10.03%提升將近一倍。
5.5.2負反饋收斂
解決了原來業務各自開發各自觸達，一發版本就有很多新業務湧向使用者對負反饋問題。
同時在應對合規和一些特殊節點的運營內容控制要求上，也非常靈活。即配即生效，不需要等版本和開發。
6、業務場景
不通的業務場景的樣式有差別，能力支撐上也有差異。
6.1單一場景：
顧名思義，任務只投放到一個場景，例如只投放push或者只投放banner位置。不同業務的性質不一樣，決定了對應運營素材的樣式不一樣。例如垃圾清理偏向工具樣式，病毒查殺偏警告樣式。
6.2串聯場景：
6.2.1串聯場景邏輯：
簡單的說，就是根據使用者在第一個場景的決策，出對應的第二個場景，甚至第三個場景。在串聯的場景中幫助使用者完成轉化。
但是場景之間有冷卻期，例如使用者在場景一點選了負反饋，那麼場景二會冷卻一段時間後再曝光，也可以終止任務，或跳過場景二進入場景三。
任務串聯能力目前在業界也較前沿（對於中臺和客戶端的互動要求較高，也更適用於強運營訴求的場景）
6.2.2串聯場景案例：
手機管家在與國家反詐合作“最新詐騙案例”普及時
——透過替換“詐騙高風險人群畫像”圖示 >該人群透過點選“識破新詐騙”圖示>進入手機管家>推送相應詐騙案例訊息，實現人群科普。
6.3分場景觸達效果
透過整合外部觸達場景，可以將業務的曝光觸達率達到83%
觸達率=單一場景曝光uv/單一場景極光後臺下發uv
*push彈窗觸達率，主要受懸浮窗許可權授權限制；
*通知欄觸達率，主要受通知欄許可權授權限制；
*桌面圖示觸達率，主要受到華為，oppo，vivo，小米四大廠商在手管機型中的佔比限制
整合觸達率=總和場景曝光uv/總總和場景後臺下發uv
後記
寫給C端產品轉中臺產品的建議
在騰訊內部其實可能也有非常多的C端產品有過這樣的十字路口，要不要自己搭一個運營中臺。
全文主要說一些我們自己搭建的優勢和挑戰，幫助大家加強信心，做一個轉型必要性的判斷。
至此，包含中臺產品通用能力，產品搭建實戰，通道能力應用案例基本講完了。
作者：swanshi，騰訊CSIG高階產品
