2017年入職，2019離職，2年社交產品后臺的工作，讓我對后臺產品有了很多思考與總結；匯總成這3萬字，分上中下三篇發布，此為上篇。希望能對大家有所幫助。

最近在找工作，所以利用課余時間，將最近一份工作的經歷進行了回憶和整理，供多年以后自己翻看自己的成長路徑。

之前主要工作與中后臺系統的供給端和訂單中臺，小有成就與心得，如果有類似方向用人的金主爸爸也可以隨時聯系我。

一、企業背景

開始之前，需要稍微花一點時間看背景和業務，否則下面做的事情將不好理解。

目前我在的公司（現在是前公司了），是社交廣告領域。社交廣告的意思是在社交平臺上利用網紅做廣告，像微博、微信、抖音、快手、小紅書這樣的平臺都是社交平臺，在這些社交平臺上面會存在許多KOL，這些KOL也就是人們常談的網紅，但是習慣還是叫博主。

我們的定位是中介，介于廣告主和博主中間，是一個雙邊交易平臺（也就是服務于雙邊市場）：博主帶著需求和錢來到市場的一側購買受眾的注意力，在另一側售賣他們的注意力換取報酬；博主能夠聚斂的受眾注意力越多（粉絲數），廣告主就越有可能在那個博主身上花錢，并且愿意花的錢也越多——我們的生意模式也就建立了。

越貴越容易被青睞——換句話說就是“被證明越有效”。所以我們面向的主要客群是中高端類的品牌客戶群，像寶潔、京東、雅詩蘭黛——因為他們買得起。

與之相對的，我們面向的主要博主群體也是中大型博主或MCN機構，像papi醬、辦公室小野、二咖傳媒、大禹文化。越大的博主越容易被青睞，也就越貴，只有越大的客戶消費得起——雙大的客群模式也就構成了。

二、面臨問題

雙大面臨的問題是受夾板氣：

對客戶端非標的業務，客戶來了想做什么都可以——我們拿到需求，進行策略匹配以后，客戶選中博主，下單后執行開始聯系博主端；博主端可能都不會來平臺，我司對于他們而言也只是一個訂單渠道商而已；本身檔期很滿，規矩很多，要很久再返回平臺，定價沒有標準，權益模糊?？蛻舳苏J可后再進行支付，達成交易進入制作環節，若客戶端不認可則全部作廢。

從流程來講，這是很低效的行為。而且信息越來越透明化，博主自己在簡介留聯系方式，社交平臺構建自己的交易平臺，雙方很容易就能拋棄公司進行交易。

三、護城河

目前我司還沒有被拋棄，核心的護城河基本上存在于3點：

1. 高效、高質撮合需求和博主：當博主越來越多，需求也越來越多的時候，勢必需要出現一家解決流程中效率問題的公司；
2. 采購方的強大：我們建立了數萬家機構的商務合同條款，這讓我們在商務上的效率是非常高的，因為有量在，所以我們能拿到比較低的市場價格，對客戶利益有較大保障；
3. 公司的金融能力：大客戶多需要賬期，意味著公司需要提前墊款，而一般公司是無法承接這樣大量的金融服務的。

這就是公司的3點立足的地方，也是公司可以持續十余年的原因。

隨著持續大客化，問題愈發嚴重。

核心問題不是上述所說的私單，而是為了預防私單建立競爭壁壘的第二點價格——大客持續壓價，無從喘息；再加上無數非標需求和高冷博主，交易平臺效能沒有被真正釋放，邊際成本居高，導致利潤進一步削薄。

為了補救，在其它客戶身上增厚利潤率，導致第二點價格優勢反而逐漸損失，客戶逐步流失。

所以，3年前自上而下公司啟動變革——這也是為什么上面說重構供給端找不到原因。

但銷售端的問題十分明確的，比如除原有的客戶必須來到我們平臺上的模式，拓展為SaaS版，也可以通過API的形式接入到客戶自身系統里，便于挑選、下單、生成財務審批單等動作。

四、業務流程

簡單講一下我們的整體業務流程，讓大家有一個大體的認知：

我們的系統都是2B的系統，客戶都是內部注冊制，注冊登錄后會進入客戶的后臺頁面，然后進入需求描述。

和一般2C類的知道搜索內容不一樣，2B類一般不知道搜索內容，但是他們知道要做什么——比如在什么平臺，什么品牌，找博主做怎樣的事，這也就是我們所謂的需求描述。

需求提交后會有匹配模型進行匹配，這是整個公司的靈魂；之后的流程近似電商，先根據需求，出現博主列表（商品搜索結果頁，非派單制非標性導致），進入博主詳情（商品詳情頁），可以加入選號車（購物車），也可以立即下單，下單必須選中商品的SKU，進入支付信息確認頁（商品信息核對頁）。

后面的流程和電商不一樣了：

先支付保證金，支付后訂單正式進入交易流程，執行中心首次介入（執行中心整個的作用是負責這筆訂單的溝通/協調/制作/發布的護航）；博主回復對這個需求的確定制作價格，或者覺得我做不了取消訂單，若取消客戶可以免責收回保證金；博主回復價格后，客戶支付尾款，客戶若支付，博主根據客戶需求拍攝或者創作，執行中心持續跟進。

在支付前客戶也可以提出駁回，也就是再次協調，一般都是明確費用明細和壓價；支付前客戶也可自己取消，也可能博主取消，若客戶自己取消，需要客服中心判定客戶責任，也許會從保證金中扣除部分為平臺服務費。

客戶支付后也創作完了，客戶進行驗收，博主發布至社交平臺；客戶進行確認或者投訴，客戶確認后進行評價，訂單結束，推送至財務結算流程。

客戶也可以不確認，覺得不滿意進行投訴，相當于電商的退貨申請，客服中心介入進行處理；三方協商后進行退款或駁回等動作，訂單完結，推送至財務中心。

——這就是我們大體的流程。

通過流程講解可以知道：我們的商品是博主，所以供給端產品的主要定位就是為銷售提供子彈——博主，核心功能為梳理入庫流程、評估不同博主的能力，審核、上架，分門別類進行售賣，不斷給前端銷售這把槍提供源源不斷可消滅別人的子彈。

五、采購概述

供給端最重要的功能之一就是采購。

基于我們的業務形態，采購指的是和博主或博主所屬的機構，建立商務合作聯系的過程。入庫指的是將博主信息，放置在平臺上，可以供廣告主進行挑選，下單。

所以我們和電商所指的采購是不一樣的：沒有實體貨物往來，也就沒有錢款的往來，采購的過程基本就是入庫博主的過程。

而后面也有仿照電商的一些系統模塊，比如庫存管理、采購預警等，但比電商簡單得多。

比方說庫存管理，庫存就不用完全鎖死，我們只需要提示客戶風險就好，畢竟交易權最終還在博主手上——也就不用做超賣、調度層、倉庫層、增減凍結狀態消耗解凍等；對采購預警來講，也不會有傳統電商麻煩——下了采購單，還要走調度、倉庫管理、財務、庫存等流程。

供給端的主要用戶是外部的博主以及內部的博主采購和博主運營，被動采購渠道就是外部的博主注冊、錄入自己的信息，主動采購渠道就是內部博主采購在市場上進行搜索，代替注冊，后續接手的博主運營進行審核、評估、聯系、上架工作，后期的運營進行包裝標簽、客情維護等長期工作。

回顧項目之初，項目并沒有報很高預期，項目是自上向下驅動的，定位是僅僅完成政治目標抄前任。因為系統已經9年多了，需要接入更多的訂單，壓力無法承受，所以定位僅僅是重做一遍原需求迎合新技術架構就好。

但是我不太甘心——不能為了重構而重構，務必要解決實質的業務問題。

數據的理性思維解救了我。

六、做事節奏

接下來我就要切入供給端重構這件事了。

一般我做一件事，需要4個環節：定位分析、需求分析、框架結構分析和表現落地。

1. 定位分析包含：需求是解決什么問題的，服務誰，有怎樣的價值；
2. 需求分析是大體的功能分析：操作流程，角色流程，定義優先級和roadmap；
3. 框架結構分析是具象的功能，由什么頁面構成的，頁面上的信息結構是怎樣的；
4. 最終是表現落地——畫原型、寫PRD、溝通研發、溝通UE等；
5. 所有完成以后持續跟進直至上線，上線后的數據持續收集反饋，再優化。

——這是整體的做事流程。

定位分析：供給側產品對公司定位非常清晰，服務外部博主和內部運營，用于幫助內外的高效變現；但是供給端需要重構，解決的問題在當時并不明確——到底是這次重構有明確需要解決的問題和目標，還是抄前任，重做一遍迎合新技術架構，新系統方案就好？

為了明確需求，唯一的手段就是理性數據分析。

1. 數據呈現

動銷率是跟供給端最相關的數據。

當時的月動銷率大約是0.3%，數據量級是幾十萬的博主，有賣出動作的大概是幾千。

（這個動銷指的不是交易完成；如果是交易完成會更低，僅僅指的是有下單行為的，后續還有可能被取消）

無論怎樣，0.3%的動銷率都不是一個正常的數據——正常情況下一個良好的倉庫，動銷可以做到30%-50%。

基于此數據，可以分析出的單邊結論是：博主沒有經過有效的篩查，被批量進入庫內，導致分母太大，動銷率不理想。

通過回顧前兩年的政策佐證了此猜測結論：在前兩年，公司的戰略為搶占市占，搶占市占取決于搶客戶。當時公司是銷售導向公司，對客戶需求把控較弱，并不能預測客戶端需求是什么。

也有時局因素——當時社媒廣告剛剛興起，一切都在摸索，怎么玩都是未知的。為了能讓客戶的需求可以隨時被反饋，也就先入進來再說了。對應地，在前兩年的采購部核心KPI是入庫數量，完成KPI的驅使下，有如此巨量的入庫，也就不難理解了。

當大分母因素，通過邏輯去掉的時候（過去一年內有過交易行為的博主），再去看動銷，果然上升至12%左右了，但是距離合理情況的底線仍有很大的距離。

再來從交易流程中數據看：從表達需求到下單，再到支付，再到制作完成發布，再到確認。

首先是需求到結果集準確率：一般情況下我們的準確率能在50%左右，也就是假定出現100個搜索結果的博主，有50個左右會被有效點擊查看，有效點擊的意思是頁面滑動、停留時間、有點擊交互行為。

翻頁使用情況基本和準確率相符：翻頁中位數在17左右，搜索結果集總頁數中位數在27頁左右，深度在63%左右。

篩選使用頻次較高：單次使用后，準確率能提升到60%左右，翻頁中位數降為6左右，搜索結果集總頁數中位數在13頁左右，深度在46%；組合篩選后更為降低。

綜上可以推斷：我們的核心撮合匹配模型的效率是很高的，對于客戶需求的畫像和博主畫像較為精準，客戶基本上有一半的博主都被有效查看。

繼續向下驗證此結論：

加購率（我們也有加購率）：假定分母是100個博主，一般加購中位數在60個左右（這個和需求強相關，我只是舉某一類需求的樣例，需求和平臺/預算/玩法/檔期等強相關，可能需求出來博主都沒30個，可能客戶會加購十來個）。當時分析的時候是“分需求等級，均看一遍的”——針對上述這個需求類別，所以我們的加購率中位數在60%左右，很高了。

最終轉化為待支付狀態的訂單：從加購到下單看，下單率18%左右，也就是18單；總體的下單決策時間中位數在3-4小時左右，包含了加購時間和加購后下單時間，慣性習慣都是看到差不多的資源慣性加購，在購物車里精選，這個時間會比較長，所以對于一個商業行為的決策，相對還是很快的。

由此基本可以驗證：出現的博主是沒問題的，供給端的梳理似乎抄就可以了。

最后我們又看了一下訂單層面的數據，發現了問題：

在業務重構前，下單后執行中心就會接手進行服務聯系博主，無償下單。博主會告訴執行人員這個需求多少錢，修改訂單價格后客戶可以進行支付，支付后訂單真正生效。

這時候看到一組數據：

支付率，下單18單，只有2單被支付，支付率占比下單數的11.1%。

那問題出在哪兒？

詳細拆解來看：

第一輪博主可能會取消訂單（博主取消率大約是20%左右，還剩15單會回給廣告主），15單里最終只有2單進行了支付，因此客戶原因的取消占比80%。

博主端取消率的20%里，主動取消的大概占70%，被動取消的占比30%（主動取消就是這需求我做不了，不接；被動取消就是訂單過期自動取消了）。

詳細訪談博主和博主運營后，得出以下兩條關鍵結論：

1. 我司只是博主的接單渠道之一，他們在市場上有非常多的訂單；
2. 我們對博主端的約束力出現問題，約束力主要取決于訂單多少，而當巨量資源的時候，需求還是還是那么多的時候，后果可想而知。

再回過來，客戶80%取消比例——所以這里到底發生了什么，下單的動機是什么，回復后的訂單滿足了怎樣的下單動機？

結合內部訪談執行和訪談客戶，可以歸因出2個最大的原因：

1. 客戶通過需求聯系一下博主，其實并不是真的要下單，有點像發消息沒回復，電話震一下，后面才有真正需求跟上；
2. 下單到支付，比例大約只有10%，大量訂單被取消。

這是很嚴重的問題——因為我們的業務是很特殊的，業務有著很強的非標性，導致少不了人的溝通和參與，而且我們還是To B的企業，這個屬性更被加劇。所以，客戶在下單后，就要馬上有執行人員介入（負責聯系溝通三方，非標需求的一單一價），公司成本非常高（從來到回大約要2天，而且可能是多個執行，訂單被取消后的效能損耗會非常高）。

這是對三方都非常不友好的行為：

• 浪費了平臺的系統和人員資源，沒有有效降低平臺的邊際成本；
• 浪費了客戶的時間，也浪費了博主的積極性——可能優質的博主每天都被過度打擾，時間久了就可能被動從高配合度變成低配合度。

第一個問題的解題思路，相對簡單，也就是清洗。針對這個問題，與運營一起設計博主評估模型和博主巡檢模型，分別在入庫前攔截不值當的博主和在入庫后清洗賣不出去的資源，以保證庫內博主的優質和降低系統維護成本。

第二個問題的第一個原因相對簡單，就是失去對博主約束力了。當博主約束力持續下降的時候，客戶對這件事的印象才會持續上升，直到到達某個臨界點，變為客戶印象中的必然事件。所以對于約束力不足的問題，解決思路的一個方向是把因果關系的因去掉，利用已經實現的評估模型和巡檢模型，將博主自身變量因素降為最低（也就是自營簽約博主，畢竟再計算好也都是別人的）。

不過這個自營目前應該被放棄了——因為簽約好博主成本太大，簽差的博主，客戶不會用，賣不出去就是白養著。

目前對約束力的調控，是在于增加約束力——也就是讓外部博主多接些訂單，單多了約束一定強，就是評估模型和算法策略之間的互相服務了。

第二個原因，有兩個方向：一個是提升支付率，一個是降低下單率。

提升支付率是行不通的，因為客戶的預算cover在這里，無論你怎么引導他支付順滑，畢竟和2C不一樣；那就剩下的一個方向——降低下單率。

所以我們繼續思考：究其客戶下單的動機是什么，有什么一定要通過下單？滿足下單動機。

所以只能選擇后者——降低下單率。

如何可以有效降低下單率而對整體收入不受影響？

從原理進行分析后發現：我們之前由于業務的非標性，賣的都是非標品；非標品的特性是不穩態的，當商品也就是流程終點不穩態（有多種可能性的話），意味中間的過程只能通過堆砌數量而獲取期望結果，也就側面造成了表象層的數據結果，那么問題會急劇收斂。

穩態下的標品到底是什么，長什么樣子？

回歸到客戶行為層面不難發現：通過下單選擇非標商品，服務后返回的信息客戶會進行最終決策，這是符合標品化之后穩態特征的——服務后返回的信息與服務前信息差導致商品從非標變為標準商品。

舉個例子：

寶馬汽車客戶來了，說要做個case，通過我們的需求匹配模型，算出來papi醬可能適合他，但是這時候能證明的就是這個博主適合，真能做否，沒辦法知道，只有博主自己知道。所以客戶只能下單，說papi醬，需要你給寶馬汽車做一個植入的軟廣，能做嗎？多少錢？我能拿到你的肖像授權嗎？然后在執行問過一輪之后回來之后的信息是：能做，10萬。這時候客戶可能覺得，有點貴，算了，導致訂單被取消。

拉高前置決策成本，減輕后置決策，減少信息經過交易系統的浪費，對于下單率可能同樣會有驟降，原理是一樣的。

還有關鍵指標是預算消耗度，也就是——客戶預算是否被有效、高效地消化完畢了。別到時候下單率是降低了，但是錢也不花了。

所以數據預期，最核心要觀察這3個指標以驗證整體方向的正確與否（當然博主端的取消，客戶端取消率，同樣要看作為參考）。

上述所有數據均為模擬數據，并非真實數據。

2. 執行 To do

根據數據和分析最終匯總，可以總結出幾個核心的事件：

• 非標品轉為標品，收斂不確定性，用于滿足下單后取消的情況。標品信息應當包含訂單內的確定性信息和與需求相關的高度不確定信息，代表的就是價格，所以確定性信息要完整展示，不確定信息要盡量精準通過模型預測；
• 強約束博主，如果不能通過訂單約束，看能否通過自營簽約約束——后續成本過高幾近放棄；
• 通過建立分級模型，將庫內巨量博主重新清洗，將不值得被維護的博主清洗下架、凍結，降低系統消耗；
• 目標性采購工具，結合分級模型和市場的新增博主，予以采購的決策建議，提升真實動銷率；
• 有償執行需求，也就是保證金制度，發布需求有償化，對應的服務也就有償化了，會讓系統的無效損耗有人買單，也會降低博主被打擾的頻次。

3. 落地節奏

公司對于第一個問題并不是沒有察覺，但是只是當時采購方過于強硬，沒有人驅動。

我最終可以驅動的原因是利用同理心，深入敵方內部：

1. 先協調運營變更KPI（如果KPI不變啥都白搭），先將入庫數量拿掉，擬定變為動銷以考察采購的入庫質量，但現階段執行只會引起強烈反抗；
2. 范圍性質達成一致，比如和采購商議，持續3、5年都沒成交過的博主，就下架了吧，真賣不出去，而且你看KPI也變了；
3. 打成一片，掏空采購同學智慧，比如評估一個博主是通過幾個方面評估的，如何感知到這個博主肯定能成單，有經驗的采購一眼便知；
4. 根據采購的智慧，得知博主的內容質量與商業度非常重要，內容質量越高的，他入庫以后的商業素質也會比別人好，賣出去的概率變大；
5. 協調AI進行模型的打分，并且用庫內的博主測試一下，直到與大多數人相符，階段性目標一致；
6. 利用AI輸出的模型數據為基礎，實現分級模型，將博主有效評級，繼續用庫內博主測試，仍與大多數人達成一致后；
7. 開始清洗資源，因為這個結果是和大家達成一致后才推行的，故此阻力小很多，但還是有，是為以后的業績而顧慮；
8. 改裝槍沒收了，劣質子彈銷毀了，那也要提供之前沒有的利器才能讓整體效率更高——那就是市場的爆款博主監控和競品監控：當工具發現市場上哪些內容傳播蹭蹭上漲時候，但是這博主還沒入庫，就會進入內容評估模型進行評估，達到入庫標準后給采購提供精準打擊的利器；以及監控競品平臺與我方博主交集和非交集，著重開墾非交集區域（當然也要予以評估后進行入庫決策，沒準競品也只是為了KPI入庫）；
9. ?最后，問題基本圓滿解決；這時候再嘗試將動銷率列為KPI去觀察，最終成功推行。

從第一件事里對我最重要的幫助不是成功落地推動了，而是服務第二件事；第一件事相比第二件還是小，與采購同學打得火熱，調頻一致，獲取信任，大家在一個戰線向前沖的，所以第二件事相對就容易很多。

第一個原因解決起來相對容易，實際就是失去博主約束力了。當平臺對博主約束力持續下降的時候，客戶對這件事的印象才會持續上升，直到到達某個臨界點，變為客戶印象中的必然事件。所以對于約束力不足的問題，解決思路一個方向是因果關系——把因去掉（也就是利用我已經實現的評估模型和巡檢模型，用于將博主自身變量因素降為最低）；采購還自驅動的往另一個方向努力，控制約束力，也就是自營簽約博主（畢竟再計算好也都是別人的）。

不過，這個自營目前應該被放棄了——因為簽約好博主成本太大，簽差的博主，客戶不會用，賣不出去就是白養著。目前對約束力的調控，是在于增加約束力，也就是讓外部博主多接些訂單，單多了約束一定強，就是評估模型和算法策略之間的互相服務了。

第二個原因通過聚焦后發現，不穩態的是賬號，將內部服務后獲取的所有信息用一個詞可以概括成：服務能力，所以讓不穩態的商品變為穩態的是博主的服務能力，比如上述papi醬的汽車客戶的植入廣告創作能力。

問題截止到這個階段，就很具象了；服務能力有哪些，如何獲取，怎樣落地，可以逐步解題了：

1. 掏空運營腦子、抽象歷史訂單以及供給端的訪談等手段，挖掘結構，因不同渠道、立場、能力的原因，無法結構化表述，產品能力必須要結構化整合；
2. 根據第一步的結果，設計商品信息架構，最終其實發現和電商商品信息結構很像，我們也就借用了電商系統商品信息的結構形式，SKU+SPU——我們把SPU設計為商品，也就是博主的賬號，非標；在此基礎上，新增服務能力也就是SKU，繼續收斂，將第一步獲取的信息按照架構設計塞進去；
3. A/B測試用于驗證結果，也就是協調采購補全一部分的博主SKU屬性，其它其實都有，沒好關系真干不了，是出人出力；
4. 結果返回超預期，向上匯報確定最終重構方向，達成一致后，構思開始落地；
5. 協調入庫抓取服務、AI模型，建立入庫流程，根據采購智慧設計博主估值模型，當SKU+SPU+價格+庫存信息完整后，聯調測試，抓庫內號進行調整；由于商品特殊性，信息分為2類，一類是確定性信息，一類是不可確定信息。確定信息是客觀呈現不可變的；不可確定信息是與需求本身高度相關的。以我們的業務為例有2個，一個是價格，一個是檔期，也就是庫存。所以對于確定性信息，盡可能前置化，準確、完整、多維的呈現，對于不可確定信息，我們結合歷史數據和相關維度比如周期性、庫存量，設計相關預測模型解決，也就是博主報價模型和庫存模型。由于這兩個信息的特殊性，沒有把它放在SKU和SPU里了。最終上線后重組成博主信息結構，完全滿足客戶所需。
6. 最終上線完成博主信息標品化的工作，考察關鍵性數據，下單率、支付率、預算消耗度。

后面整體我按照入庫流程進行落地的表述，評估、巡檢等解決第一個問題的手段，均串行在整體流程中。

4. 信息結構

上述已經說過了，我們的SPU是博主，標準化產品單元。比方說papi醬，SKU是papi醬下面的一個服務能力——快消飲料的搞笑植入廣告；SKU最終定義是由博主的“基本信息+分類+供應商+屬性”構成的。

其中：

• 基本信息就是你能看到的一切，像頭像、昵稱、簡介、粉絲數等；
• 分類是機器清洗出來的這個博主的分類，共8大類目，美妝、汽車、母嬰、快消、游戲、知識教育、美食、vlog、其它；
• 供應商是指的這個博主是哪個供應商提供的，或者是MCN，背后掛著的是供應商一系列信息，后面再詳細說供應商管理的細節；
• 屬性分為銷售屬性和非銷售屬性，銷售屬性對應著規格信息，是最核心最重要的，銷售屬性也叫能力，包含玩法，平臺，行業，玩法運營抽象收斂的固定幾類，比如種草、開箱、評測、換頭像等，這個是銷售直接相關屬性，不可修改。比方說客戶要微信上的種草玩法，客戶是美妝客戶，那么就按照這個條件去匹配符合這個銷售屬性的貨品，對應的輸出規格信息。
• 規格主要包含業務強相關的通用規格有物料、權益、制作周期，非通用規格有位置（微信）、形態（微博），備注。
• 物料就是物料的一些規格，你做什么需要提供怎樣的圖片，幾張/大小/需求描述等；
• 權益就是你在交易過程中，能改幾次腳本，改幾次內容，有沒有內容分發版權，我是否承諾效果之類的；
• 制作周期是博主去制作這個案例要幾天的時間。
• 非銷售屬性一般是比較通用的，與本次需求無關的了。目前有是否提前下單鎖檔期，是否必須提前給錢，是否有競品協議，行業、品類、品牌等。

——這組信息共同構成了一個貨的SKU。

我們的頁面展示是以SPU為維度的，也就是切換SKU，頁面也不會變；所以SPU在上述基礎上，只增加了對博主的運營包裝和評價。

包裝一般是人工運營標簽，會對應一些動作：

• 可能是專題的聚合，會給到客戶一張專題頁比方說本月最佳的母嬰博主，盡量讓客戶從這里去選擇；
• 特殊的頁面呈現，比方說SKU變紅字了，或者頁面特殊位置增加了一些描述語，頁面的樣式之類的變化；
• 機器的包裝標簽，系統根據一定的規則運算出一個標簽，呈現在博主的搜索列表和詳情頁上，就沒有像人工那么豐富了；當然也會有都沒有的。

評價是在交易結束后收集的重要信息，對商品中心的重要意義在于完整商品信息，稍后詳細介紹。

構想后，基本可以將原有的非標品轉化為標品，從而收斂不確定性。

papi醬可能有美妝種草、美妝開箱、游戲植入、快消植入能力，客戶選中游戲植入服務能力?？蛻酎c選后，需要客戶提供的物料規格（幾張圖、多大、必須包含什么、需求明細等），以及客戶能獲得的權益，同時我制作這個內容需要多久時間。

但是對于商品來講，少兩個東西：價格和庫存。

這兩個已經說過是不可確定信息，稍后再講。

5. 通用庫

介紹完商品信息架構，也要介紹實現商品信息架構的底層通用庫。

從整個商品庫而言，我們沒有做通用庫像屬性庫，我們業務來講能力（SKU）數量還是有限的，雖然SPU一大堆，但是SKU也就頂天了幾百個。我們目前只有供應商庫、分類庫、規格庫、標簽庫是屬于通用庫，這個是屬于服務性質的，不太參與業務；供應商庫我在稍后詳細介紹，規格庫上述基本也有大概介紹，剩下的就是分類庫和標簽庫。

本質來講這兩個是最重要的，如果沒有它，啥也沒法干。

分類庫和標簽庫原先都是在標簽庫里的，只不過分類太過重要，把它拆出去專門列為分類標簽進行維護和展現。主要包含標簽的類別，分為風格、業務、品牌、品類、分類幾個類別：

• 風格目前有劇情搞笑、溫情、MC喊麥、勵志、科普等；
• 業務包含業務線比方說非標業務、標準業務、外來合作業務等；
• 品牌標簽就是品牌了；
• 品類標簽目前包含2層，美妝，修容，眉筆，意圖是找到每個博主都做過哪些品類的內容，供推薦引擎推薦博主和標簽引擎打標簽；
• 分類目前就8大分類+其它，和品類是上下級關系，分類是一級，品類是二三級。

所有的關鍵詞必須包含：中文、英文、拼音、類別、中文定義、同義詞、近義詞、關聯詞。

關聯詞一開始是人工關聯；隨著量級越來越大，人工+機器識別參半，機器運用AI的NLP技術，將同框出現的關鍵詞，按照頻率清洗，人工核查，賦予。所有的關鍵詞庫都是最底層的服務，供博主信息維護、AI模塊、推薦模型、搜索、機器打標簽模塊、需求畫像模塊和一些其它服務共同調用，以保證口徑統一。

6. A/B test

當上述信息架構梳理完畢后，還不是落地，先要去做A/Btest——畢竟這是一個系統級的需求，如果錯了那就傻了。

如何做A/B也是問題：A肯定是目前現有信息結構面，B是新的，如何在不開發的前提下實現B？

那就是半人工化，大體是這樣做的：

首先，我們的思路肯定是通過人工錄入當時系統內沒有的信息——但是錄入是有范圍的，絕不可能所有博主均錄入。那么我們就從需求端反推博主：當前怎樣的需求比較多，我們應該準備怎樣的博主去配合？收斂需求端和博主端。

將某類需求錨定后，選出博主，要博主運營幫我們傳遞給到博主（自然都是線下先問一輪回來記錄的結果），最后把回來這些SKU信息手工寫入這些博主庫中；整個大概選了600多個博主，花了一周左右集齊。

測試階段可以達成的效果是：當有客戶來，輸入需求，若需求為目標類型需求，則出現測試結果集，測試結果集至少保證600個博主，即結果集分為AB兩類。

傳統的A上面信息仍為原始信息，包括博主基本信息和博主過去參考價以及評價和歷史案例；B上面的信息包含除上述信息外，博主有什么服務能力（SKU），也就是能幫我做什么事，我能獲得怎樣的權益，需要我提供什么，你制作需要多久，線下摸索回的預估報價是多少錢。

下單后的支付流程，和A其實是一樣的：我們沒有把參考價直接變為SKU的價格，檔期因為和下單時刻相關度太高，也就沒有收集，應該不會過多影響最終結果的準確率。

這樣保證ab在同樣的場景和條件下，被同樣的決策者看到，我們去觀察前期錨定的數據指標。

結果顯示：同比下，a類客戶基本在3.5小時左右，和之前的3-4小時數據相符；b類客戶在信息前置后的下單決策時間由之前的拉長到2-3天。

后續去訪談客戶得知，這段時間不是在平臺上，而是將這些目標博主的情況直接導出給予領導層匯報決策了，所以時間很長，客戶認為這個價格就是準確的支付價。

數據符合前期預想，但是也拿到一個tips：頁面一定要突出是參考刊例價，線下測試可以把控住，但是一旦批量，都造成誤會不是鬧著玩的。

根據客戶反饋的數據，去補了一個數據——添加購物車后的充值行為和金額，發現b類客戶遠遠高于a類：b類幾乎占比80%以上，a類占比約為0%；因為大家都習慣了，在博主反饋后再支付充值，而且也不知道充多少，b類對于平臺的資金沉淀更長。

再看下一組數據：

a類客戶加購率基本和之前持平，在57%，下單率占比大約為35%，與之前的30%近似相符，b類客戶加購率高達79%，可下單率低至4%——數據也是和預測相符的。

加購率的提升推測有可能是由于數據的完善，導致博主都較為符合客戶的需求，全部都要暫存，后面慢慢再選，客戶將原來需要下單才能完成的試探比較的動作，消化為在自己的購物車內了；而下單率相比下驟減，貼合了之前的猜測結論，意味著下單變為謹慎了，下單即成單的趨勢逐漸形成。

再來看很重要的預算消耗度，主要是在輸入需求的時候收集了預算，最后和實付訂單價作為對比即可。

可以看到：

預算消耗度可以穩定在90%-110%，甚至有些還會超出；和a組對比，a組平均只能到70%-90%。

最后輔看下支付率：

本次測試a類總支付訂單數為2個，與之前認知一致；

b類支付數也為2個，意味著需求數恒定，數據可信。

先看取消率情況，計算有效單：

a類博主取消率與認知樣本相符，為20%；

b類博主沒有取消的情況，為0%。

而最終看的是支付率：

a類下單20，有效16，支付2，支付率為12.5%；

b類下單數為3，有效3，支付數為2，支付率為66.6%。

結合所有數據看，毫無疑問b類是奏效的。

為了避免偶發性，持續觀察將近一個半月，最終進行推進的決策。

上述所有數據均是模擬數據，并非真實數據。

最后小廣告：目前還在找坑，有需求的老板隨時騷擾，中后臺方向/供給側/中臺訂單，謝謝觀看。

#專欄作家#

吳邢一夫，人人都是產品經理專欄作家。5年產品經理工作經驗，需求、用戶、數據有深入研究。歡迎交流想法，拒絕無意義添加好友。

本文獨家發布于人人都是產品經理。未經本站許可，禁止轉載。謝謝合作

題圖來自 Unsplash，基于 CC0 協議