大家好，我是才哥。

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

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

基于此，做好版本運營我們可以從以下幾個方面進行展開，更好的服務于項目以及我們的用戶。

1. 基礎

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

1.1SDK接入

今天我們不聊那么細，簡單介紹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.3GM工具

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類)的處理外，其實像外掛或者其他一些玩家違規游戲行為的處理也需要得到重視，營造和諧的游戲環境很重要。

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

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

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