遊戲雲間之資料分析應用

資料分析應用——遊戲雲間系列八

「昨夜同門雲集，推杯又換盞。 今朝茶涼酒寒，豪言成笑談。 」

上一篇我們介紹了遊戲資料分析的好處、指標，資料的採集、存放和處理（遊戲雲間之七：初識遊戲分析 ），如果不能切實地改進遊戲、增加收入，那便成笑談。

今天，我們來進行案例分析，看看如何利用資料分析來切實地改進遊戲。

此次我們舉例一款移動端的紙牌類遊戲，類比桌游21點。 遊戲的大眾版本免費，使用者在支付一定的費用後可獲取無廣告和擁有額外功能的版本。 問題是，這款21點遊戲並沒有帶來預期收入。 期望是解決這個問題、提高使用者參與度和消費。

如果遊戲的設計者並沒有資料分析的概念，也沒有搜集充足的資料以備分析，那只能拍腦袋制定策略變更。 而如果資料分析的思路在設計之初就以部署，那接下來的每一步分析都會有根有據。

我們假設遊戲的設計之初就已考慮資料分析，在 阿裡雲 上按照下圖的方式部署：

ECS作為遊戲伺服器；

RDS作為業務資料庫，維護事務相關資料，通過阿裡雲的采雲間將需要分析的資料同步至ODPS；

SLS作為日誌服務，定期將日誌資料導入至ODPS

ODPS作為開放資料處理服務，進行資料分析。

為了找出遊戲並未帶來預期收入的原因，我們一步一步地排查，並做出相應動作：

1.是否有足夠多的人下載該應用？

查看下載總量和遊戲的首次安裝量。 下載量和安裝量都可以維護在RDS中。

如果沒有足夠的下載量，需要公關部和市場部圍繞產品的知名度展開工作。 例如在遊戲中加入創造性的元素，和運營方合作推廣，採用新的皮膚包裝或是誘人標題。 在移動瀏覽器或是搜索用戶端方面加大廣告投入。

如果資料顯示有足夠多的使用者下載量和首次安裝量，那說明問題不是出在知名度方面，那也無需額外增加公關方面的投入，而是繼續查看步驟2。

2.對於安裝遊戲的使用者，他們在遊戲中做的第一件事情是什麼？ 所有使用者中那些玩過多輪直到完全結束該遊戲占多大的百分比？

對於第一個問題，我們查看資料庫中記錄的登陸活動（Entry Event Distribute，EED），這也可以維護在RDS中。 對於第二個問題，我們在每一次使用者完成遊戲時，自動向伺服器發送一條消息來收集該資料。

如果有很多使用者進入遊戲，但大部分人沒有選擇升級到付費版本，那可能這款遊戲很有趣，吸引人們的注意，卻沒有很好的貨幣化。 如果是這種情況，需要思考升級的價值，找出它能給使用者帶來更多價值的點並讓使用者瞭解。

如果只有很少的使用者完成遊戲，或者大部分人在玩遊戲初期便退出，那麼繼續看步驟3.

3. 使用者在哪一步退出的？

為了獲知該資料，需要在使用者執行操作時記錄每一步。 因為只能基於事件發生前執行的操作來決定退出事件（Exit Event Distribution，EXD），所以需要在使用者執行每一步操作時添加資料點，而且細微性越細越好（資料量嘩嘩滴）。 顯然這樣的資料不適合放在業務資料庫，也就是上圖中的RDS裡，而使用阿裡雲的日誌服務SLS，可以自動讀取產生的日誌檔，並自動導入進ODPS中，供後續分析。 既不會佔用即時業務資源，也便於大量資料的分析處理。

接著，因為不知道使用者是否還會回來繼續進行遊戲，需要篩選出那些在一定的時間段內都不再重新登錄的使用者。 方法是，估算出活躍使用者的平均登錄間隔，然後再乘以10來判斷使用者是否永遠流失。 比方說，如果大部分使用者的平均登錄間隔是1天，那麼對於10天內都未再登錄的使用者，可以判斷其為流失。

這裡EXD相應可以有很多分支，比方說，有多少使用者完成遊戲指南？ 如果大部分使用者是在完成指南之後退出，那指南本身可能有一定的複雜性，需要對遊戲指南進一步設計。 如果大部分使用者沒有完成指南，需要考慮在遊戲的主頁面將指南設置成為可選項，讓使用者可以跳過遊戲指南直接進入遊戲。

如果大部分使用者完成了遊戲指南，那麼繼續看步驟4。

4.當使用者準備開始遊戲時，他們是否能成功配對同玩物件？

使用者首先選擇那一種遊戲物件？ 和另一名玩家對戰或是隨機播放？ 獨自玩或是與機器對玩？ 還是與身邊的人使用「熱座模式」？ 如果大部分使用者首先使用對戰按鈕來和朋友玩，當他們這樣做時，他們使用什麼選項來找尋夥伴？ 現在很多人都會在「微信」中尋找。 當選擇「微信」導入時，會彈出一個允許頁面，詢問是否允許該應用的訪問。 多少使用者選擇允許應用的訪問？

這些資料可以記錄在RDS或是用日誌的方式由SLS導入ODPS。 通過在ODPS裡設置map、reduce規則，得到需要的分析資料。

如果「不允許」的比例很高，那說明可能是允許頁面的內容嚇壞了使用者。 這樣的情況下，可以去掉一些通用的語句比如「隨時訪問資料」，「打擾我的朋友們」，讓頁面看起來不會那麼地打擾使用者。 另外，有多少使用者是通過這個過程找到朋友然後一起玩遊戲的？ 可以通過查看多少人進入「微信」選項，對比此時開始遊戲並且立即進入遊戲的人數。 如果這個比例很低，那說明在遊戲配對處需要改進。 當然，這裡就需要多一些的資料分析規則。

5. 當使用者進入遊戲時，他們是否完成該遊戲？ 他們玩了多少回合？

如果在玩了一兩個回合後退出，那麼如果遊戲的對方是人，並且他們之間的回合過長，那麼可能是因為回合的持續時長而導致厭煩。 這一點可以通過回合間的平均耗時來查詢。

如果回合時長看起來合理，但是玩家仍然在一兩局之後退出，那需要檢查遊戲可玩性的問題。

6.對於那些玩過幾把遊戲但仍然流失了的使用者，考慮下面幾個問題：

這些玩家是否在自己的遊戲回合中總是贏或總是輸？ 如果總是贏或輸，可能他們覺得這個遊戲太過簡單或者太過複雜。 如果輸贏結果比較隨機，那需要更精准的遊戲對玩資料來啟發。 如果遊戲對方是他們的朋友，可能能啟發的不多。 如果遊戲對方是機器，那麼需要更多的資料收集來進一步研究。

以上的這些步驟只是資料分析對遊戲改進的一個簡化舉例，如文中的圖所示，遊戲過程中的資料由RDS或SLS導入ODPS，再從ODPS中對大量資料進行分析，説明指定後續的決策。 由此也可見，資料分析在整個過程中對分析問題的默默支援，正是「我願意，化流沙躺湖堤。 只陪你，恭候春夏的輪替。 」

原創作者：架構雲肖凱 文章來自：HTTP://game.aliyun.com 轉發請標明出處