開放平台- 互動玩法演進之路

1. 背景

隨著直播業務和用戶規模日益壯大，如何豐富直播間內容、增強直播間用戶互動效果，提升營收數據變得更加關鍵。為此，直播互動玩法應運而生。透過彈幕、禮物、按讚、大航海等方式，用戶可以參與主播的直播內容。 B站也透過開放平台，為第三方廠商和開發者提供了強大的技術支持，讓直播互動玩法更加便捷、穩定和高效，為用戶和主播創造了更多的樂趣和價值。

圖：星體工作室互動玩法案例

2. 平台建設

在著手開發之前，我們需要確立清晰的業務劃分邊界，特別是涉及多方參與的開放平台互動玩法業務。這有助於避免日積月累的問題，確保未來的發展不受制於歷史債務。

我們的業務劃分主要集中在幾個核心場景和能力模組上：

• 開發者管理平台：與開發者互動，包括入駐流程、應用審核、禮物與面板審核。作為開發者數據的展示出口，為他們提供數據回收的支援。
• 應用程式商店平台：與主播互動，包括平台與直播姬的應用程式展示與獲取。提供客製化應用推薦演算法的出口，以提升應用的曝光和吸引力。
• 應用互動平台：與直播​​間使用者互動，利用事件平台進行控制，包括開關禮物與面板。互動玩法期間資料流轉等行為。監控與標記應用程式的即時狀態，確保流暢的使用者體驗。
• 結算平台：與營收互動，包括應用期間營收資料的統計、落庫與對帳。為確保透明度和準確性，提供完善的結算支援。

因此我們設計的如下的業務模組分層：

圖：平台架構

3. 專案生命週期

圖：互動玩法生命週期

社群優先的原則確保了我們平台的演進和提升是以開發者和用戶的需求為中心的良好策略，明確了業務邊界之後，圍繞互玩的整個生命週期，我們將重心放在四個核心提升目標上：

• 開發者入駐效率與權益保障：透過簡化入駐流程，提供清晰的文件與支持，確保開發者能夠快速且順利地接觸平台。提供快速且準確的審核機制，加速應用上線，促進生態系的快速發展。提供明確的營收手段與完善的對帳系統，確保開發者收益。
• 主播使用體驗：提供直覺且易用的工具和功能，以增強主播的覆蓋率和互動性，提升直播品質。
• 直播間使用者體驗：優化直播間介面，降低使用者參與門檻。提供有趣、多樣化的互動玩法，激發用戶的參與熱情，提高用戶黏性。
• 平台管控能力：強化內容的管理與監督，確保內容的合法性與安全。提供豐富的工具，快速回應違規行為，維護平台生態安全與健康。

3.1 入駐與開發

在整個互玩生命週期過程中，開發者接取平台與開發作為起點，門檻會直接影響開發者數量與互玩的供給速度，有些問題是我們需要思考並解決的：

• 開發者如何快速建構模型？
• 開發者如何以低成本進行資料互動調試？
• 個人開發者在缺乏專業的禮物UI設計師的情況下如何進行禮物設計？

3.1.1 SDK&演示

我們明白對事物的認識往往從「是什麼」開始，然後才能理解「為什麼是這樣」。身為首次接取開放平台的開發者，要理解眾多API和呼叫文件並梳理出清晰的互動流程確實需要時間。同時由於開發者的歷史開發背景各異，對官方接取文件的理解也會有所不同。

為了降低開發者的開發成本並減輕研發的解答壓力，我們在完善官方技術文件的同時，提供了不同語言的範例，以幫助開發者建立概念模型：

• Unity&C#客戶端SDK
• Python&Growing 演示

圖：互動玩法接取SDK&Demo

3.1.2 啟動調試能力

測試階段是完整的應用開發流程中不可或缺的一個重要環節，未經充分測試的應用可能存在潛在的不可預估的風險，為了輔助開發者在應用上架之前能夠進行充分且完善的測試，我們解決了以下兩點問題：

Q：開發者在應用程式開發完成之後如何在真實環境下測試應用功能？

A：在應用程式通過審核之前，開發者可以選擇將其直播間設定為白名單直播間，這意味著開發者可以在真實的線上環境中對其開發的應用進行完整的測試與功能回歸。

Q：送禮、發送醒目留言以及大航海是互動玩法互動的重要組成部分，在線上環境應該如何進行這幾種互動操作的調試？

A：這幾種直播間使用者參與的高成本行為，讓開發者在線上環境使用正常流程進行大量的測試顯然是不合理的。為了解決這個問題，我們提供了開發者調試工具。透過這個工具，開發者可以透過後台操作主動觸發由開放平台發出的長連接訊息內容（包括彈幕、送禮、大航海和醒目留言），從操作到出口訊息的過程則由平台側保證數據的正確性。

圖：開發者調試工具

3.1.3 官方素材庫

在互動玩法系統初期，開發者需要手動設計並上傳禮物素材，不僅增加了開發者的研發成本，也增加了營運審核的難度和成本，進而導致素材管理混亂。為了解決這個問題，我們為開發者提供了一個更方便的解決方案：官方素材庫。

現在，開發者只需從官方素材庫中選擇適合的內容，提交創建禮物即可。這項方案在業務規範性方面有很大的提升，同時降低了設計成本和審核成本。為整個互動玩法系統創造了更有序和統一的環境，促進了生態的永續發展。

同時為了確保官方素材庫中的禮物符合使用者需求，我們會定期進行使用者研究。並且也會定期更新官方素材庫，添加新的禮物元素和主題，以滿足用戶不斷變化的需求和興趣。

圖：官方禮物素材庫

3.2 提交與審核

3.2.1 套件管理工具

當進行互動玩法專案的提審並需要上傳包體時，如何有效地避免被當作一個網盤服務？這時候我們可以反向利用單點故障理論來思考。

單點故障理論：系統中存在一個或一些關鍵的元件、環節或節點，如果其中的任何一個被破壞、故障或失效，可能導致整個系統的崩潰或失效。

我們可以透過分析利用平台作為網盤的使用路徑來找到其專屬單點故障：

1. 獲取上傳連結
2. 上傳文件
3. 進行持久化存儲
4. 下載文件

在不影響正常業務邏輯的情況下，我們針對第3步進行處理，持久化存儲追加前提條件，提升存儲門檻，以業務的視角控制有效文件的判定，定時掃描刪除無效包體。

同時這個問題普遍出現在開放平台的各個業務場景，因此我們搭建了一個套件管理系統，統一收口這一業務場景。

圖：套件生命週期管理

3.2.2 營運審核工具

我們可以透過分析利用平台作為網盤的使用路徑面向進行審核：

• 互動玩法內容是否合規，是否有敏感內容？
• 互動玩法呼叫模式是否符合開放平台規範？

作為運營，只能夠在審核的使用過程中，對於互動玩法內容作出合規性校驗，因此我們為運營提供基礎的合規性校驗工具對於包體進行校驗，為運營提供審核依據。

此工具需同時滿足兩個條件：

• 監聽服務對於開放平台的請求
• 統計介面的呼叫頻率

在技​​術研究初期，想透過抓包工具對資料進行分析，監聽https請求的443埠流量，並且從流量中過濾出來host為"live-open.biliapi.com"的相關請求，即對開放平台相關請求。

圖：監聽埠流量

經過測試，由於透過抓包工具是在七層協議中傳輸層截取的數據，基於https協議的請求數據都被加密，無法獲取具體的請求內容，不滿足條件2，因此該方案被否決。

圖：抓包結果

為了取得介面呼叫的詳細情況，有兩個資料來源，呼叫方和被呼叫方。在無法強制在呼叫方程式碼中插入統計邏輯的情況下，目光便聚焦在被呼叫方，但線上伺服器用作測試統計，顯然是不合理的。

線上真實環境不能用，便考慮使用仿真沙盒環境， 此時代理轉送的方案呼之欲出，大概思路如下：

1. 使用者更改本地host配置，把開放平台的網域指向localhost
2. 本地啟動一個代理服務，監聽443端口
3. 本地代理負責轉送"live-open.biliapi.com"的相關請求與記錄介面呼叫結果
4. 本地服務關閉時輸出呼叫結果。

圖：沙盒代理流程

圖：檢測結果

3.3 使用與結算

3.3.1 身份碼體系

互動玩法的使用與直播房間強綁定，因此在互動玩法開啟時，玩法客戶端需要一個途徑與當前直播間進行關聯操作，基於此問題，我們考慮過以下兩種途徑：

提供方式	優勢	劣勢
開啟互動玩法後主播輸入房間號	使用門檻低，可在OBS使用	安全性低，主播可在他人直播間開啟互動玩法
讀取主播的登陸狀態傳遞房間號	安全性中，主播之間不可互相開啟	使用門檻高，只能在直播姬使用 開發者可以開啟任意房間的互動玩法

在上述兩種途徑的劣勢都不可接受的情況下，我們需要一種新的房間號碼標識的傳輸方式，並且同時要滿足以下幾個要求：

• 不依賴直播姬的登陸態，主播在使用其他直播工具時依然可以開啟互動玩法
• 主播之間不可知，主播不可以透過一個公開識別啟動其他主播的應用
• 開發者不可知，玩法開發者無法取得任意主播的應用

因此我們推出了一套獨立標識（即身份碼系統），主播可以產生唯一標識與房間號綁定，並且在公域對他人不可見，確保主播之間以及主播與開發者之間的信息是隔離的，與開放平台的交互通過身份碼進行，由開放平台進行數據轉換，並且同時為了避免身份碼洩漏造成安全問題，提供定時刷新以及手動強制刷新能力，保證數據的合規安全。

3.3.2 互動結算

與開發者分成由互動玩法產生的營收流水是建構良好合作模式的關鍵。然而，如果僅以互動啟動時間作為計算依據，可能會導致不合理的結果，因為在啟動期間產生的艦長、醒目留言等營收行為都會被計算在內。

為了解決這個問題，我們提出了一個與互動玩法緊密相關的流水計算依據：互動禮物。每個互動玩法都有自己特定的禮物，我們只統計由互動禮物產生的營收。這樣可以準確反映互動玩法的實際貢獻，避免了其他不相關因素的干擾。

透過將互動禮物作為流水運算的依據，我們希望能夠建立一個更公正、透明且與互動玩法緊密相關的分成機制，從而激勵更多的開發者參與。這不僅可以提高開發者的積極性，也有助於形成一個健康、正向循環的互動生態。

由於不同的互動玩法的分成比例不同且可以即時調整，這給我們的管理和感知帶來了挑戰。為了有效因應這些變化，我們需要建立一套與公司內部結算體系緊密相關的結算系統。

圖：結算架構

同時為了保障公司和開發者的權益，我們需要進行流水對帳工作，主要包括以下兩個維度：

• 即時對帳：在互動玩法運行過程中，建立即時對帳系統，即時追蹤並核對每一筆交易的流水，以便及時發現和解決可能出現的問題。
• 日流水對帳：日流水對帳是即時對帳的補充，也是在出具日帳單前的最後查核工作。透過日流水對賬，我們可以確保對帳的準確性和完整性。

圖：結算對帳流程

3.4 監控與回饋

在開放平台的互動玩法系統的迭代維護過程中，確保系統的安全性和穩健性是至關重要的。面對各種不確定性、噪音以及變化，保障系統在這些情況下能夠保持穩定的基本能力是一個重大因素。考慮到互動玩法系統的呼叫方均為外部開發者，相較於公司內部業務，我們需要更嚴格的管控措施。

上線並不是互動玩法生命週期的終點，我們採取了一系列措施來持續追蹤監控系統，對系統bug進行觸達回饋，並對惡意呼叫進行限流或封禁，以確保平台高效運轉或在極端情況下降低運行。

以下是我們採取的一些措施：

• 安全中心系統：為防止突發流量的惡意要求，我們將互玩相關介面連接到開放平台統一的安全管控中心。超過預設限制的呼叫方將被一段時間封禁，並隨著觸發次數的增加，封鎖時間會逐漸延長，後續可以單獨討論安全中心的相關建設。
• 監控大盤與資料統計：除了突發流量，開發者頻繁的錯誤請求也是常見問題。我們在請求時進行上報統計，並將資料連結到公司的監控平台，即時觀察和統計。這有助於降低警報的噪音，同時提高對問題的敏感度。
• 線上問題回饋：針對互動玩法內的bug，我們為主播提供了專門的回饋管道。透過定期機器人同步，營運團隊能夠將問題及時回饋給開發者，從而實現問題的快速定位和解決。

圖：監控大盤

4. 未來展望

B站的互動玩法目前仍在發展完善階段，我們經歷了從0到1的探索階段，並結合開放平台的體系完成了全鏈路的建造與建構。然而，在1到100的發展過程中，相較於市場中的競品，我們仍需不斷演進與探索。

我們面臨的挑戰有以下幾個面向：

• 數據即時分析能力不足：在互動玩法過程中，我們即時數據分析能力不足。強化資料預警分析能力可以幫助我們及時發現潛在問題並做出相應調整。
• 商業化體系尚待完善：我們需要提升直播間用戶的消費能力，同時深入研究直播間廣大用戶的潛在商業價值。完善商業化體系將有助於增加收入來源並提高用戶參與度。
• 超前思考系統穩定性建構：隨著上架的互玩和使用的主播擴大，我們需要以超前的思維佈局，持續思考和落地系統的穩定性建設。這包括技術和流程的不斷優化，以確保系統的穩定性和使用者體驗。

在面對這些挑戰時，透過持續的努力和創新，我們相信可以不斷優化互動玩法系統，更好地滿足用戶需求，使其在市場中脫穎而出。