關於遊戲裡的隱形問題，我想其實基本上都是可以看到反饋的。只不過數量大小差異而已，沉默使用者會一直沉默，默默的來，默默的離開，不用去想怎麼找出來讓他們發聲。只需要想辦法找出所有問題裡具體的原因。除了大公司那種可以搞出各種日誌記錄和資料分析的工具以外，還可以嘗試下我下面說的這個辦法。
在騰訊時，QA那邊會有個關於故障問題影響面預估的公式，就是：某時段內反饋的問題數*200=問題影響面。不要問我這個200怎麼來，公式為什麼這麼定，我只知道這是騰訊多年運營以來資料分析後固定下來的公式，因為每個來反饋單個問題的使用者背後都有一大批同類問題的沉默使用者。
所以，後來我在運營過程中，除去那些常規和突發問題的處理，針對遊戲內容的隱形問題如何挖掘和最佳化，我就套用了這個公式，並且把大問題給細分為很多細節問題，再來統計分析。
我通常會要求論壇、電話客服、網上客服定期給我想要的問題型別資料，我分的非常細，細到什麼程度？比如就遊戲的更新問題，這個是很多遊戲常見問題，貌似也不見得有多少人會重視，一般都是例行引導。而我會把更新失敗的玩家，按網路型別分長寬、聯通、鐵通、愛普、移動網、教育網等網路型別。還有更新後登入遊戲失敗，更新後登入顯示異常等。還有比如遊戲的戰鬥問題，會分戰鬥的操作、戰鬥的平衡、戰鬥的結果、戰鬥過程卡等細節問題。
那麼套用這個公式後，一般能找出最重要最影響體驗的問題，比如更新問題，也許一般的彙報就是，每次更新，大概40單左右的更新失敗反饋，對於一個在線上百萬的遊戲來，真心不算什麼，而按照更新頻率一個月8次，再套上公式就可以發現，影響面是40*8*200=64000人，而且我發現每次更新前臺後，有一大波愛普網路的使用者是更新失敗的，導致部分使用者登入失敗，玩不了。那麼我就找程式瞭解這種小網路執行機制導致更新失敗的原因，再根據這個原因去做各種情況下的更新保護和下載資源的方式。戰鬥問題則是發現過程卡這個問題，由此發現程式在傳送資訊包時的大小、方式都有很大的最佳化空間。
當然不在騰訊，可能就沒有這麼好的人力資源可以調動，那麼就需要靠自己來整理資料。對於論壇上，QQ群裡，自己默默的看，默默的記錄，默默的追問細節。需要注意的是針對使用者的內容，要比較敏銳，不用去思考使用者的內容，只需要判定是哪個系統哪個環節上的不爽，其他東西就先不要深想，最後再套公式來看所有問題下的小細節的影響面。
關於遊戲裡的隱形問題，我想其實基本上都是可以看到反饋的。只不過數量大小差異而已，沉默使用者會一直沉默，默默的來，默默的離開，不用去想怎麼找出來讓他們發聲。只需要想辦法找出所有問題裡具體的原因。除了大公司那種可以搞出各種日誌記錄和資料分析的工具以外，還可以嘗試下我下面說的這個辦法。
在騰訊時，QA那邊會有個關於故障問題影響面預估的公式，就是：某時段內反饋的問題數*200=問題影響面。不要問我這個200怎麼來，公式為什麼這麼定，我只知道這是騰訊多年運營以來資料分析後固定下來的公式，因為每個來反饋單個問題的使用者背後都有一大批同類問題的沉默使用者。
所以，後來我在運營過程中，除去那些常規和突發問題的處理，針對遊戲內容的隱形問題如何挖掘和最佳化，我就套用了這個公式，並且把大問題給細分為很多細節問題，再來統計分析。
我通常會要求論壇、電話客服、網上客服定期給我想要的問題型別資料，我分的非常細，細到什麼程度？比如就遊戲的更新問題，這個是很多遊戲常見問題，貌似也不見得有多少人會重視，一般都是例行引導。而我會把更新失敗的玩家，按網路型別分長寬、聯通、鐵通、愛普、移動網、教育網等網路型別。還有更新後登入遊戲失敗，更新後登入顯示異常等。還有比如遊戲的戰鬥問題，會分戰鬥的操作、戰鬥的平衡、戰鬥的結果、戰鬥過程卡等細節問題。
那麼套用這個公式後，一般能找出最重要最影響體驗的問題，比如更新問題，也許一般的彙報就是，每次更新，大概40單左右的更新失敗反饋，對於一個在線上百萬的遊戲來，真心不算什麼，而按照更新頻率一個月8次，再套上公式就可以發現，影響面是40*8*200=64000人，而且我發現每次更新前臺後，有一大波愛普網路的使用者是更新失敗的，導致部分使用者登入失敗，玩不了。那麼我就找程式瞭解這種小網路執行機制導致更新失敗的原因，再根據這個原因去做各種情況下的更新保護和下載資源的方式。戰鬥問題則是發現過程卡這個問題，由此發現程式在傳送資訊包時的大小、方式都有很大的最佳化空間。
當然不在騰訊，可能就沒有這麼好的人力資源可以調動，那麼就需要靠自己來整理資料。對於論壇上，QQ群裡，自己默默的看，默默的記錄，默默的追問細節。需要注意的是針對使用者的內容，要比較敏銳，不用去思考使用者的內容，只需要判定是哪個系統哪個環節上的不爽，其他東西就先不要深想，最後再套公式來看所有問題下的小細節的影響面。