引言
商品的資訊結構化程度在某種意義上來說決定導購效率的天花板。閒魚商品結構化和**/天貓最大的區別在於閒魚賣家都是個人使用者，無論是專業程度還是行動力遠不及**賣家。為了不阻礙商品發布，閒魚一直倡導輕發布，理想狀況使用者拍完**輸入一段描述即可完成發布。但是這和商品結構化相悖：賣家輸入資訊越多，越有利於商品結構化，但是使用者發布商品的意願就會越低。
我們要做的就是在不阻礙使用者發布商品的前提下提高商品結構化程度。
結構化歷程
閒魚商品結構化的探索一直沒有停過。目前為止，可以劃分出四個階段
2023年：2023年以前閒魚類目處於刀耕火種的原始狀態，發布時需要選擇商品應該在哪個類目之下。所以我們建立了閒魚渠道類目，將類目對映到渠道類目。另乙個嘗試就是將閒魚商品直接與天貓的spu(standar product unit,標準產品單元)對映。
2023年：啟動了哥倫布專案，進一步挖掘影象潛力。通過影象相似度識別，直接將閒魚商品和**/天貓商品進行關聯，通過對**同款的結構化資訊清洗得到閒魚商品的結構化資訊。
當前結構化策略
目前圍繞著演算法，我們在商品發布的各個環節都提供了同款關聯的入口：從智慧型發布到發布完成之後的演算法識別以及售賣體系。
現階段閒魚商品結構化圍繞著演算法，在商品發布的各個環節都提供了同款關聯的入口：從智慧型發布到發布完成之後的演算法識別以及售賣體系。
通過同款關聯，閒魚商品結構化往前走了一大步，使得閒魚商品結構化的比例有將近47%的提公升。儘管如此閒魚商品結構化現狀仍不容樂觀，主要體現在
同款覆蓋率。覆蓋雖然提公升比例較大，但離目標還有一定的距離。
同款精度。1）部分類目精度低，比如手機和手機殼在影象上相似，但實際是不同的商品。2）整體精度離目標仍有較大gap。
結構化資訊應用。目前只應用在了搜尋場景的商品擴招回，結構化資訊的應用仍有待充分挖掘。
未來的打法
當前結構化策略面臨著乙個問題：當演算法能力達到上限後，如何繼續推進結構化覆蓋&精度提公升？目前為止起碼有三種手段
然而在現階段以演算法為中心的工程體系中，上面的策略應用上會面臨很多痛點
這些問題大部分本質還是工程問題（結構化定義，多演算法融合，輸入輔助等）。所以轉換一下結構化思路：以演算法為中心轉向以工程為中心，把演算法當作能力補齊外掛程式。結構化圍繞著屬性補齊做如下抽象
總體策略
總結起來做這幾件事
閒魚vid體系重新定義結構化標準。
演算法多模態接入，提公升覆蓋&精度。
引入規則引擎，服務於輸入輔助等場景。
結構化資料持久化&特徵計算，提公升搜尋推薦等導購場景的匹配效率。
重新定義結構化
這套標準稱為閒魚vid（想好名字前暫且叫vid）體系，基於閒魚渠道類目+屬性組成。這套標準有兩種方式生成
天貓spu體系。天貓的spu運營到現在，資料體系已經較為完善，標準品類和閒魚有很大重疊部分，這部分可以直接實現spu互通。
對於非標品，從需求側分析而來。通過搜尋推薦等導購場景反向分析可以拿到當前買家關心的品類+屬性。這部分可以補齊spu缺失的資料。
基於這套標準體系，可以很好的解決多演算法接入問題：直接以vid體系對應的種子商品集為候選池，實現同款掛靠。除此之外，演算法沒法覆蓋的商品(**質量較差)如果能確定類目和屬性，也能實現vid掛靠。
演算法多模態
工程上主要解決演算法接入效率問題。當從商品發布到最後的導購主鏈路搭建完成，演算法以外掛程式化的方式執行在主鏈路之上。
這裡多模態主要包括兩方面：1）識別能力從影象擴充套件到文字，**結合。2）演算法模型從單團隊拓展到多團隊，能力互補。
解決的問題主要包括
遮蔽資料差異。不同演算法資料產生方式的差異，實時/準實時/離線。
資料融合。演算法快速上線/資料效果對比/結構化資訊入引擎。
演算法結果對齊。根據定義的結構化標準，抹平演算法結果差異。如果識別出的同款商品本質上是同乙個商品，那多演算法的識別結果最終應當能歸一化。
輸入輔助
輸入輔助需要解決兩個問題：
使用者體驗：嚴苛的實時性要求。使用者輸入是乙個連續且對時效要求極高的過程，所有資料的互動需在極短時間內完成。
第乙個問題很好解決，素材池提煉可以包括：
搜尋逆向分析產出。根據使用者query統計分析，可以得到買家關心的屬性。
演算法產出：演算法對動銷高的商品進行特徵提取得到，並歸到對應的渠道類目上。
運營行業經驗產出。
第二個問題最好的解法肯定是把所有的邏輯全部下放到端上本地執行避免響應問題。然而不可能把所有的邏輯放到端上，比如需要演算法介入時，我們不可能把複雜的演算法模型執行在端上。所以把素材池分成兩部分：
需要演算法介入的邏輯放在服務端來完成。
其餘邏輯選擇適當時機下發給端上執行，這部分需要保證良好的擴充套件能力。
通過對輸入輔助的執行邏輯進行抽象發現其存在形式類似於規則引擎中的規則。在規則引擎中規則一般包含三要素：事實，規則，模式。
這裡的事實對應著使用者的輸入，module對應著單個判定條件，rule則對應著條件判定以及對應的action。以運營的行業經驗產出為例，手機類目下有兩個很重要的屬性：
1）是否維修過。
2）是否過保。那這條經驗可以翻譯成兩條規則：
1）if 類目=手機 and 屬性不包含 是否維修過 then 引導使用者選擇。
2）if 類目=手機 and 屬性不包含 是否過保 then 引導使用者選擇。
當執行邏輯被抽象成若干條規則時，就可以在適當的時機下發到客戶端側本地執行。整個流程抽象如下
當新的運營經驗或者分析資料產生時，通過翻譯成規則可以很好的實現輔助輸入的擴充套件性。通過規則的共享，客戶端的邏輯可以無感知的在服務端執行。
上線效果
商品結構化的目標圍繞著結構化資訊的覆蓋&精度進行，目前已經上線了部分功能（文字同款以及演算法多模態），從資料上看取得了不錯的效果：1）演算法多模態接入能對結構化覆蓋佔比8%絕對提公升。2）文字同款正在分桶測試中，從分桶資料來看覆蓋**13%絕對值提公升。
展望
結構化的願景是在不影響發布體驗的前提下完成商品結構化工作。理想情況下只需要一張**，一段描述就能完成商品發布，其餘工作統統移交給演算法以及工程同學。當影象和文字內容能被充分挖掘理解，標籤成色甚至類目這些都可以去掉，使用者只需要點確認發布按鈕即可。我們會不斷朝著這個目標努力。
電商 如何防止商品超賣
怎麼導致超賣？多個使用者同時購買同一件商品 相同sku 產生高併發多執行緒。如果商品的個數僅有1個,a執行緒獲取到結果時因為剩餘數量大於0,生成訂單 使用者付款。此時若在a執行緒生成訂單的途中,b執行緒獲取的商品剩餘數量是大於0的，也會生成訂單 使用者付款。導致結果只有一件商品賣了兩次,超賣了。解決...
電商App如何讓使用者直接開啟商品詳情頁
首先從運營的角度來說，通常的手段有 1.初期的種子使用者尋找 在產品的冷初期階段需要種子使用者，這一批使用者維護的好後期會成為核心使用者，是口碑最好的宣傳者。2.場景化的活動運營 除了節假日必備的活動，還要準備日常的活動，提高使用者粘性，活躍使用者。可以通過簽到 登入 積分等。3 精細化內容的推送 ...
如何設計乙個電商系統 三 商品系統
商品系統中的問題 商品系統主要就使用來維護商品的基本資訊，下面列出介個主要的版塊 商品管理 商品審核 商品 站 搜尋及批量還原 刪除操作 商品批量操作 商品分類 商品分類 商品分類的crud 商品型別 商品型別 商品的規格 引數的資訊維護 品牌管理 品牌名稱搜尋 批量操作 顯示品牌 隱藏品牌 品牌資...