聊一聊遊戲版本運營

今天我們聊一聊遊戲運營裡的版本運營模組的工作，介紹一下這個崗位的主要工作內容。

簡單來說，版本運營日常工作主要是負責保障遊戲線上運營的穩定性，同時也可能需要去處理一些線上的突發事件。

基於此，做好版本運營我們可以從以下幾個方面進行展開，更好的服務於專案以及我們的使用者。

1. 基礎

對於版本運營同學來說，可以從遊戲研發期開始介入，完成一些基礎性的版本運營工作，比如SDK接入、運營工具、GM工具以及平臺能力項接入等等；在進行遊戲測試調優之前，還需要梳理版本維護更新發布流程、多版本（包）管理、渠道上下架操作、tlog埋點以及運營資料後臺等等。

1.1. SDK接入

關於SDK的科普可以參考我之前寫的《關於移動遊戲SDK，你想了解的都在這裡》。今天我們不聊那麼細，簡單介紹SDK所包含一些基礎內容和擴充內容。

1.1.1 基礎內容

賬號體系、充值以及SDK資料上報（一般是客戶端日誌資料）

賬號體系

• 從使用者角度來看，登入遊戲的方式可以有多種，比如賬號密碼登入、手機號登入又或者第三方賬號如QQ、微信、微博、蘋果id登入等等；
• 而對於同一個遊戲（不同渠道包算不同的）來說，這些登入方式最終都是一個賬號體系之下的；
• 從產品角度，其實支援多種登入方式，那麼這些不同的登入方式其實就需要去對應的開發者後臺申請對應的引數。
  

關於這些引數的申請，不同的公司的流程可能不一樣，有的可能是中臺部門負責或者商務同學負責，也有的可能是版本運營同學負責。但是不管怎麼樣，最終基本都需要版本運營去進行對接協調（作為專案組與其他部門之間的溝通橋樑），所以作為版本運營，把這些流程與實操都熟悉掌握很有必要。

tips：一般引數申請需要提供產品的基礎資訊，比如 名稱、包名、icon以及簡介等等，這部分差不多就是需要版本運營同學來準備了。

充值

對於有內購的遊戲來說，充值是必不可少的。國內常見的充值有支付寶、微信支付與蘋果支付等，此外還有手機話費卡支付、銀聯卡支付等等；海外可能就是GiftCard、PayPal、VISA/萬事達等等。同樣的，這些支付方式也是需要去對應的開發者後臺申請引數，它們的流程和賬號體系基本一致。

SDK資料上報

SDK資料上報一般是SDK自帶的一類，主要是裝置資訊與SDK相關資訊一類的資料，可以提前和中臺部門瞭解下具體有哪些預設資料上報等等，這樣就便於後續測試驗收。

1.1.2 擴充內容

除了上述的基礎內容之外，我們還可能涉及到其他的一些擴充內容，比如：

• 為了方便使用者在遊戲裡進行交流，需要接一些第三方的語音SDK；
• 為了更好的採集使用者行為資料，可能會接入做的比較好的第三方資料平臺的SDK；
• 為了進行流量變現，可能會接入第三方的廣告SDK；
• 為了方面使用者手機號登入，可能會接入手機號一鍵登入的SDK；
• 為了收集使用者體驗遊戲時裝置的一些奔潰資訊，可能會接入第三方的崩潰上報SDK等等。
  

同樣的，我們如果需要上架一些聯運渠道，則還需要接入這些聯運渠道的SDK，這個SDK則會帶有上述第1部分中的基礎內容以及一些渠道定製化的內容（比如浮窗功能、內建社群等等）。

以上只是部分擴充內容，實際專案中會根據專案本身的產品需求進行第三方SDK的選取，而對於第三方SDK的接入也基本上都是 提供產品的基礎資訊用於引數申請，作為版本運營的同學也一定需要搞清楚這個SDK的功能是什麼，以及如何驗收。

1.2 運營工具

顧名思義，運營工具就是在遊戲運營過程中會使用到的工具，常見的發公告、跑馬燈、全服郵件等等就是。

我們按照功能型別可以分為以下幾類，具體詳情需要根據具體專案進行定製化：

使用者資訊查詢

通過使用者賬號、角色ID或暱稱等查詢使用者資訊，不同的產品資訊展示有所不同

• 當前詳情資訊（如等級、充值金額、揹包資訊等等）
• 歷史資訊記錄（如道具操作流水、充值流水等等）
  

資源管理

比如公告、跑馬燈、全服&單人郵件、push訊息等等

伺服器狀態管理

開/關服、預開服（維護）、排隊人數設定、白名單等等

遊戲功能管理

為了儘可能保證遊戲線上運營的穩定性以及能儘快的響應線上突發事件，遊戲功能管理模組可以無限擴充。最簡單的就是對可能出現問題就會影響線上的功能都做開關功能，線上上出現問題時第一時間進行功能關閉處理，讓負面影響儘可能小。

• 比如 角色 開關，關閉某個角色則該角色無法使用，如果該角色出現數值異常則可以第一時間先關閉之；
• 比如 充值 開關，關閉某充值則該充值項無法充值，如果該充值出現異常比如充值給的獎勵配錯了，則第一時間關閉之；
• 比如 某活動出現問題，我們也可以關閉活動，則也可以減少損失；
• 再比如 某期間 要求玩家不能改名，我們就可以關閉改名功能等等。
  

以上只是部分由於某功能異常導致的問題的快速響應，作為版本運營同學需要對遊戲的各個功能都有清晰的認知，又能考慮到可能出現問題的邊界情況及其負面影響，然後和對應的策劃一起商量確定其功能開關的具體功能為最佳。

通過上述功能可以看到，運營工具就是遊戲運營同學操縱遊戲的核武器，熟練掌握並能不斷完善該核武器，可以極大提高我們的工作效率以及應對突發事件的處理能力。

（提個小問題，某運營同學在給個人傳送補償郵件的時候不小心發到成了全服，怎麼快速處理可以讓損失最小？）

1.3 GM工具

GM工具其實也是運營工具的一種，這裡我狹義的指代對使用者狀態操作的工具

通過使用者賬號、角色ID等對使用者進行相關的狀態操作，不同的產品使用者狀態有所不同

• 處罰型別（如：封號、禁言、禁止某玩法、禁止排行榜等等）
• 資訊修改（如：強制改名、道具刪減、修改段位等等）
  

比如，某使用者在體驗遊戲的時候開掛了、故意送分了等等，我們就可以對其進行封號處理；某使用者暱稱不雅被舉報了，我們就可以對其進行強制改名等等。

需要注意的是，不管是運營工具還是GM工具，我們在設計的時候都需要考慮該功能使用後如果會影響玩家的正常體驗，則一定要給予玩家合適的前端提示。比如封號後，玩家登入的時候需要有彈窗提示告知玩家 因為什麼原因被封到什麼時候之類的；我們關閉某個功能後，需要在玩家點選該功能的時候提示 該功能暫時關閉之類的。（具體功能具體分析了）

此外，就是這些工具的具體功能需求，對於運營同學來說就是在某個網頁前端進行輸入與結果的展示。而實際上涉及運營與網頁前端的互動、中臺（製作網頁前端的部門）與遊戲伺服器之間的互動、遊戲伺服器與客戶端之間的互動以及玩家與客戶端之間的互動。其中前2類互動需要版本運營同學去撰寫具體的需求，後2類的互動則需要版本運營與策劃溝通並大多數情況下由策劃去撰寫具體的需求。

1.4 平臺能力項接入

像我們在SDK接入裡提到的很多功能如QQ、微信和微博等第三方賬號登入方式，一般來說它們也提供諸如分享等功能，這些就屬於平臺能力項。不過，這些第三方的能力項大部分都是僅用於各自獨代的一些產品。

此外，我們接入的聯運渠道，它們一般也會有一些平臺能力項供接入使用，比如浮窗、內建社群等等。

我們可以根據自己的產品需求來進行相關能力項的選取。

1.5 版本維護更新發布流程

當我們的產品開始接觸使用者，就會有新內容、舊內容迭代以及一些問題修復等等，這就涉及到維護更新與釋出了。有明確的更新發布流程，可以讓我們這類工作高效有序的展開。

一般來說，更新可以分為以下2類：

強更

也叫冷更、大版本更新等等，使用者需要更新一個完整的包，大多數時候，這種更新需要停服操作

熱更

這是一種更新頻率非常高的方式，使用者在現有的版本基礎上更新一些遊戲資源即可，一般不需要停服操作

對於強更這種情況，一般都是提前準備好了完整的包上架渠道或者CDN，到指定的時間進行停服操作，操作結束後玩家自動更新最新的包，這種情況一般涉及到比較大的版本內容更新或者比較底層的程式碼改動。

對於熱更這種情況，一般可以分為兩種：使用者無感的更新與使用者需要重啟遊戲的更新。無感的更新多數情況下是一些純資料或少數美術資源層面的更新，玩家在遊戲中就靜默更新了。使用者需要重啟遊戲的更新則可能涉及到相對較大資源或者是比較關鍵的資料（比如競技類遊戲裡的 戰鬥數值）更新，玩家在遊戲大廳則需要重啟遊戲進行更新。

其實，很多遊戲都可以做到基本不需要停服更新，比如多個login、game服等，涉及到伺服器需要重啟更新的內容進行相關子節點的輪流重啟就可以了。

以上的一些具體更新邏輯則需要版本運營同學和對應的前後端技術、運維和測試同學一起進行協商溝通並最終確定。

一般來說，更新流程可以概況為以下（具體專案具體討論）：

• 確定版本更新內容
• pc端驗收（內網）
• 手機端 ftp環境驗收 （內網）
• 手機端 cdn環境驗收 （預釋出，無限接近外網）
• 運營釋出公告、跑馬燈、各社群&自媒體平臺釋出更新公告（告知更新時間、型別、內容、補償方案等）
• 釋出前的操作（伺服器狀態操作，是否灰度等等）
• 線上釋出
  

1.6 渠道上下架操作

一般除了官方渠道（官網、官方社群等），我們還可能上架一些平臺或者聯運渠道等，這就涉及到多版本（包）的管理以及渠道的上下架操作。

作為版本運營，儘量熟悉不同渠道的上下架操作是有必要的（雖然很多時候這些操作可能是商務或者渠道對接同學負責）。

在本地版本包的管理上儘量的規範，這樣在實際的工作中就可以更加方便。

常見的上架需要準備的材料有如下幾類：

• 安裝包
• 五圖（icon如果換則加上）
• 更新內容
• 主副標題（如果換的話）
• 是否新增內購檔位等
  

不同的渠道對這些素材的要求可能不同，整理一份材料需求清單，建立不同渠道的材料資料夾進行統一管理可以讓工作效率大大提高。

關於渠道包提審，在實際操作中可能會遇到很多不同的問題，我們都需要根據實際情況進行一一處理。

常見的有以下一些場景：

• 某渠道SDK更新了，且是需要強制更新版本的，對於這種情況，建議在原定的上架時間前2-3周找商務同學進行各渠道SDK更新狀態的統一彙總以儘可能避免此類情況；
• 某渠道新增了一些遮蔽字，是否第一時間補充到遊戲遮蔽字型檔了；
• 聯運渠道包不能出現一些外鏈引導類的功能以及廣告sdk等等；
• 一些新的合規政策的出臺，比如最近1年越來越嚴格的關於隱私政策&使用者協議、防沉迷、隱私清單等的要求，我們需要去研究解讀具體的政策條款，同時也要去了解渠道對這些政策條款的要求，然後合到遊戲裡。
  

以上其實就需要版本運營同學也要時常關注各渠道以及國家在遊戲方面的一些政策規定等，然後進行鍼對性的預警或處理，以確保專案穩定有序開展。

關於iOS提審與釋出可以參考我後續要出的一期介紹哈（敬請期待）


1.7 資料埋點

資料埋點就是對使用者遊戲行為以及遊戲本身資料的記錄，常見的使用者註冊、創角、登入、登出等等，此外就是和玩家對遊戲的各個玩法系統的行為資料事件的採集了。

這些埋點資料都是後設資料，也就是每一次行為事件都會記錄成一條，我們後續複雜的資料分析都是基於此。

一般來說，我們可以將事件的屬性分為兩類：通用屬性與事件專屬屬性。

通用屬性 可以理解為在每個事件裡都需要記錄的屬性（取不到的不算），比如使用者的賬號、角色id、等級、vip等級、創角時間、暱稱、渠道、平臺等等。

事件專屬屬性 可以理解為每個單獨的事件所需要記錄的屬性，其實這個是資料埋點設計的核心，它的設計思路其實需要反推，比如我需要通過玩家對局（moba）來分析英雄出場率、勝率以及一些對局屬性資料來進行平衡性調整等等，則可以做如下埋點設計（簡單的參考）：


當然了，資料埋點這方面版本運營同學不一定需要去負責，像資料運營或者對應系統的策劃又或者數值策劃等都可以參與到這個工作中來。除了我們需要用於分析的屬性之外，技術也可能會提一些用於定位問題的屬性欄位，加到埋點設計裡即可。

1.8 運營資料後臺

有了埋點資料之後，我們就可以進行運營資料後臺的搭建了。

當然了，現在很多公司都有自己的的資料中臺，我們直接按照他們制定的資料埋點的統一格式來，那麼基本上就可以很簡單的接入到對應的資料後臺了，常見的一些資料包表基本也就不需要額外去設計了。又或者我們接入一些第三方的資料後臺，按照對應的資料埋點要求進行埋點設計，一樣可以快速的完成一些基礎的資料包表設計。

其實，有了後設資料，資料分析就都好做了。

常規報表的製作，特殊的專項資料分析則可能涉及到SQL或者python的一些處理，這方面可以參考我們們公眾號歷史文章進行學習。

不過，現在除了遊戲裡的一些玩家行為資料之外，我們還有買量資料，這方面也是可以整合到運營資料後臺的，當然也是可以單獨拿出來做分析，結合遊戲裡的資料看使用者質量（留存、LTV、roi之類的）。

2. 進階

在基礎部分，我們主要介紹的是屬於基建部分，如果要把版本運營做的更好，我們需要更多的思考，對產品的以及對使用者的。

2.1 口碑運營

從遊戲測試調優開始到遊戲上線運營之後，我們都需要開始關注口碑運營這塊的工作。核心就是日常線上環境的監控，及時妥善處理遊戲的各類突發運營事件。

遊戲面向使用者後，就需要注意口碑。任何一個負面的問題都會導致口碑的下降，而每次妥善的處理也往往能將口碑拉昇。

所以，我們需要遊戲線上的運營情況，這個情況可以是直觀的資料曲線，也可以是外網輿情，還可以是客服反饋等等。

從資料曲線的折線變化我們可以及時發現線上可能的問題，比如伺服器當機導致線上數陡降，接著我們就從外網輿情發現玩家反饋登入不上游戲，客服也反饋過來很多玩家掉線等等。

又或者資料曲線都正常，有玩家反饋某玩法無法參與等等。

這個時候，版本運營的同學就需要開始跟進並推動處理這一系列問題。

一般來說，大致流程可以是這樣：

• 收集問題（儘可能詳細，使用者賬號或角色id、時間、場景、具體問題等）
• 可自測的先自測（比如登入問題、充值問題、玩法參與等比較顯而易見的）
• 同步線上問題群（相關模組負責人都在的專項群）
• 評估風險等級
• 高風險的緊急處理方案（這個時候要善於使用運營工具和GM工具等）
• 處理方案同步使用者（公告、跑馬燈、社群、自媒體，客服答覆玩家的統一口徑等）
• 協調推動問題的處理
• 覆盤總結，一方面嘗試從機制上避免，另一方面看是否可以完善處理機制等
  

作為版本運營，需要對遊戲機制（一些功能的實現邏輯）有非常熟悉的理解，以便於能第一時間對問題進行判斷，儘快響應！

在事故問題的處理中一定要積極主動的push，協調各部門儘快修復上線！

同時和其他模組運營同學（尤其是玩家運營、自媒體運營等）保持緊密配合，儘可能妥善處理外網輿情。

簡單概況對突發事件的處理就是要做好：全方位（公告、跑馬燈、社群自媒體等）告知玩家處理方案（時間、具體措施、補償方案等），儘快處理，統一口徑！

除了高風險的突發事件的緊急處理外，也需要去關注日常玩家對遊戲的反饋，不管是bug還是設計體驗反饋，都記錄備案（日期、歸屬版本、反饋型別、反饋內容、反饋頻度、玩家資訊等），為後續版本優化提供參考。

一定注意，顯而易見的bug和一些合理的建議，能儘快進版本就儘快，否則容易讓玩家覺得我們不作為而影響口碑。

2.2 版本規劃

一般來說，遊戲性的版本規劃可能是很早就有制定，不過在運營階段，收集到線上玩家的一些有效反饋建議以及從運營資料分析得到的一些參考建議等都可以作為後續版本的開發方向。

常見的bug類問題的修復，體驗優化類的需求以及玩家的一些對玩法或資源追求的合理性需求等等。以上這些則需要運營同學對產品、對使用者以及對資料都有比較深刻的理解。一定注意，並不是玩家的反饋建議就一定要聽！

2.3 測試服

現在很多上線運營的遊戲都有測試體驗服，比如每次大版本上線之前，由於涉及到的新增功能點較多。為了更完善的測試（相對趨近於線上正式環境），我們就可以先安排上線測試體驗服，邀請一批玩家進行體驗。一方面可以找bug，另外一方面還可以提前體驗新內容然後專項反饋，讓我們可以進行上線前的調優，這樣正式上線後的版本的版本質量更有保障。

其實，對於測試服與正式服同時存在的情況，對於專案組來說相對而言是維護了兩個正式版本（同時還有開發版本需要維護），多多少少會存在一些的工作壓力。如何去協調測試服與正式服的工作就顯得比較重要了！

這裡，我們的做法大致是這樣：

根據實際的產品需求，不定期進行測試服的測試招募（針對性招募指定屬性人群），進行專項的測試。比如要上新的英雄或者玩法，招募一批玩家在指定時間按照測試要求參與，專項提交這些英雄或玩法的bug與體驗反饋，負責該英雄或玩法的策劃owner可以加入到測試群瞭解玩家反饋也可以等測試周期結束後統一看我們彙總的反饋，或者參與組織的專項訪談！如果測試中間遇到一些阻斷性的bug，比如英雄無法使用、遊戲高頻閃退、英雄數值變態等，則需要及時處理並更新；如果遇到的是一些其他型別不影響核心測試目的的問題或反饋，則暫時先無視。

另外，就是如果與正式服運營版本之間存在人力需求交集，以正式服為主。

除了專項測試之外，特定的在正式服上線前2-3周進行一次相對正式版的測試服跑測，主要是版本穩定性測試。

此外，就是非官方組織的測試周期外，有餘力的情況下可以多對測試版本進行一些維護，確保後續需要使用的時候合版本的時候問題儘可能的少！

測試服也是需要很好的維護，如果招募的玩家發現測試服問題一大堆且官方基本不維護，正式服上線後測試服就存在的很明顯的問題還在，那麼這些玩家參與測試服的積極性甚至對遊戲的積極性都會大打折扣！

2.4 版本主題

新的版本內容最終確定後，我們就可以考慮對這個版本進行主題包裝了，具體主題我們可以找文案策劃一起勾兌，然後找平面設計進行相關素材的製作。主題包裝的作用有一定的品宣效果，配合買量或者渠道動作，可以把價值發揮到最大。

常見的主題包含涉及到的工作可以有：

• 新的icon
• 新的登入介面
• 新的大廳主KV
• 新的宣傳圖
• 新的CG或視訊
• 官網、社群與自媒體的主KV
  

在新版本正式上線前1-2周，我們就可以安排陸續進行新版本爆料，營造氛圍！

同樣的，我們在定好更新內容後，可以將更新內容準備兩套，一套詳細的圖文類用於官網和社群自媒體，一套簡單的用於遊戲內公告。

這個時候，我們還可以和商務一起，將新版本的亮點、賣點梳理，然後找渠道進行資源置換！

如何更好的進行版本主題包裝，如何藉此協調各方的資源，將新版本的buff加到最大是版本運營全域性規劃能力的一種體現！

2.5 運營需求池

除了收集的玩家有效反饋建議和bug之外，我們在運營過程中也會有一些從運營出發的需求，比如渠道新功能希望我們能接入一下、市場或買量同學與外部渠道（短視訊平臺等）的合作需求、運營工具或GM工具新增需求等等。

這個時候，作為版本運營則需要對這些需求進行歸檔整理成運營需求池，考慮到專案組開發人力是有限的，所以並非全部的需求過來都要立馬安排上，如何協調，就需要版本運營好好考慮了。

我個人比較喜歡的做法就是會先自己熟悉下這些需求的具體背景、大致可能需要的人力資源，然後再跟需求方一起溝通優先順序，再組織會議溝通進行需求的評審（類似策劃需求評審，需要專案側PM、需求發起者以及相關人員一起）。

有些需求可能專案組內部就能消化，比如短視訊平臺的合作需要的只是禮包或者遊戲內宣傳圖，這類找美術提需求遊戲內新增配置即可；有些需求可能還需要中臺部分協助，比如渠道新功能，我們需要找中臺進行聚合，則還需要考慮中臺的排期。

懂技術、會專案管理，是版本運營同學多多少少需要掌握的！

2.6 其他

線上上運營的過程中，我們還會遇到很多各式各樣的場景，版本運營需要根據不同的場景進行合理的安排處理，隨機應變。

除了我們之前提到過的突發事件（bug類）的處理外，其實像外掛或者其他一些玩家違規遊戲行為的處理也需要得到重視，營造和諧的遊戲環境很重要。

關於外掛，需要考慮其影響面，如何針對性的處理：一方面需要出臺相關處理流程（如何判定、判定後如何處罰、如何公示等等），另一方面則需要和專案組一起制定能從機制上避免或者自動處罰外掛的方案。

關於違規遊戲行為（比如惡意送分、刷分、退款、言語辱罵等等），其實也和外掛處理的流程邏輯型別，一方面從運營角度處理，另一方面從機制上完善。

此外，還有一些諸如開服、合服、關服以及賬號遷移等等都是版本運營在工作中可能涉及的內容，這些都根據具體問題具體處理就好了，不再展開！

以上就是本次的全部內容，很多模組並沒有詳細展開，如果你感興趣，可以加我好友，我們一起交流學習，希望你能喜歡，謝謝！


來源：可以叫我才哥
原文：https://mp.weixin.qq.com/s/BQ1J7md3jHWttNnbaE_2IA