《不休的烏拉拉》背後的資料體系

專注遊戲資料的發表於2021-01-27
2020年11月19日,我們走進《不休的烏拉拉》《香腸派對》研發商「真有趣」,在真有趣大廈圖書館內舉辦了遊戲資料分析高階沙龍,特邀了真有趣《不休的烏拉拉》資料專案負責人何鵬老師進行分享。在本次活動中,何鵬老師根據TA系統在烏拉拉專案中的實踐經驗,為大傢俱體分析瞭如何利用TA系統提升專案資料利用率。本文為活動現場何鵬老師的內容部分實錄,需要觀看完整視訊的可以訪問數數科技官網。

大家好,很榮幸受邀來分享一下真有趣內部,主要是烏拉拉這個專案的資料分析實戰經驗。我們從接入TA系統開始到現在應該是還不到一年的時間。從這麼短的時間內,其實我覺得對於我們烏拉拉的整個的專案管理以及烏拉拉整個資料的利用率都提高了很大一個層次。今天的分享主要是有4部分:

01、我們為什麼選擇接入TA系統

我們接入TA系統,是想通過這個平臺給專案內所有人進行資料分析的機會,哪怕你之前沒有資料分析的基礎,你可以在TA系統上進行探索,比如說一些API這些詞彙你不明白是什麼意思,但是首先你要有個便利的平臺讓你去看,只要你去看了,那肯定就會對於你想分析的東西有一個概念,這個也是落實到我們真有趣的價值觀——資料導向,使用者第一,以使用者為導向,做使用者喜歡的產品。我們給使用者提供更多的選擇,給使用者帶來長期有效的快樂,邏輯就是我們不但從我們自己的經驗或者我們的專案經驗要給使用者帶來什麼,所有的基礎其實還是以資料為基礎,使用者是不是喜歡?是不是受歡迎,還是要以資料來說話,不能是你拍腦袋去想,否則專案是走不長的。

首先講一下烏拉拉之前沒有接觸數數科技的情況,也就是烏拉拉專案上線之初,我們採用的資料架構可以說是阿里雲的全家桶,開始資料收集,組建服務基地去做本地的gameserver,包括服務端所有的伺服器的日誌收集,然後去轉發到最後上傳到阿里雲,然後有一部分是到 OSS做日誌的機器查詢,但是它的查詢效率不高,因為它只有30天的有效期,而且對於這個產品包括你的SQL能力都是有很高的要求,然後做一些資料清洗,最後主要的資料查詢,包括資料分析都是通過DIH查詢,查詢已經清洗好了的資料,生成一個大寬表,但是查詢效率很低,我們會根據不同的事件去分表,還會對所有的使用者做分類,我們需要用到一些使用者屬性,因為DIY的系統只能做SQL查詢,對於資料分析來說,主要依靠資料分析師,包括資料開發,我們想要的資料分析是把資料轉起來。首先是資料埋點設計,然後做資料儲存,資料分析,以及資料分析的預警,這部分主要是資料分析師,包括可能還有一部分是我們平臺運營的一些同學做,然後因為策劃對於SQL可能是沒有那麼那麼普及,只有個別會,他們可能都需要通過跟資料開發同學去對接,經過再三確認,才能拿到他想要的資料結果,但是這些查詢的過程對接會佔用很大的一部分的精力,率就會很低,整個的它的埋點設計包括有效性驗證效率都很低。我們資料是T+1,但是整個轉起來它可能就會更慢。

《不休的烏拉拉》背後的資料體系

資料設計單方面最開始我們是以整個專案設計,因為我們資料開發人員也不是很多。資料的採集收集效率是T+1會很慢,包括資料清洗,如果錯了或者說有問題,整個都要重新來。資料分析時效性也不強,應用性也很差,只能通過指令碼或者SQL,或者用第三方的BI去去做資料展示,但是它的可定製化就比較弱。我們策劃或者運營,如果想要一個報表,想實時監控一個頁面,他要先提出需求,然後等很久才能看到報表,可能需要一週或者更長的時間,因為中間大部分時間是在做資料對接,資料驗證,對接消耗的能源太多,效率很低,儘管他提出了分析需求,資料組因為人手不夠,可能有一些需求就會沒有那麼快響應,或者說我沒辦法現在去響應,等有時間做的時候,可能這個活動也已經結束了,所以我就沒辦法看到這個活動的資料變化。

《不休的烏拉拉》背後的資料體系

02、接入TA過程中遇到的問題及解決方法

為了解決這個問題,我們最終還是決定接入 TA系統,首先第一個遇到的問題就是我們的文字資料結構跟數數科技的原始資料結構是一樣的,但是他們有一些資料,比如說關鍵欄位,埋點方式,還有我們的資料不光是我們自己用,因為和心動合作之類的,可能還有第三方,我們不可能完全改掉我們原有的埋點,整個程式都重構,這樣的話成本比較高,所以我們在中間加了一層資料轉發,把我們現有的埋點欄位轉成數數科技他們需要的,比如進看臺的這種就是做一層對映,因為數數他們使用的監視文字資料格式比較通用,所以轉起來也是比較順暢。

《不休的烏拉拉》背後的資料體系

接下來分享一下實時資料這一塊,因為我們烏拉拉的技術站是夠的,我們要運維兩套環境,就繼續沿用我們之前的元件,但是需要考慮到介面問題,當時也是數數連夜給我們用他們的API介面重新調整一個資料格式,我們通過更輕量化的一個資料收集轉發,通過ATP介面轉發到TA端,解決了實時的問題,經過測試一秒鐘是上萬條是沒問題的,同時傳上萬條也沒有資料丟失。

再分享一下歷史資料,歷史資料最開始匯入時間拉得比較長,其中的一個問題是我們怎樣把資料導到數數平臺,在保證資料的唯一性同時更高效,好在TA有各種的資料接入介面,整個測試下來效率還是很高的,使用下來也很順暢。再講講數數的分析平臺,我主要講一下我們自己的使用體驗。

先看流程部分,如果是我們傳統的BI報表,首先會遇到的一個問題是複雜度的問題,因為你的需求要同時去想,至少涉及到研發和平臺部,平臺又要分後端和前端分別負責計算和展示的部分,最後你做一個驗收。這套流程走下來,它的時間很長,而且跨度很大,跨部門的難度很大,中間萬一出了bug,是研發上報的資料有問題,還是平臺的計算邏輯有問題,還是平臺的前端展示有問題,很難排查。整個過程就會很漫長,它的成本也很高。在接入數數的TA之後,我們現在的流程依然是提出需求,但是隻需要研發做一個資料埋點,剛剛講到埋點的資料會直接回復到我們的平臺本身的資料庫裡面,然後我們只要對資料來源,資料本身做一個驗收就可以了。比如說我們去跑一下他的生成資料事件,看一下這個升級的資料是不是對的,就可以做我們的報表了,整個複雜度和時間是有很大優化的。所以我們可以說TA平臺提供的這套模組化的工具集帶來的一個流程優化比較顯著。

接下來跟大家介紹一下我們在TA系統下的應用經驗。

《不休的烏拉拉》背後的資料體系

首先事件分析,流程分析都是我們經常會用到的,開箱即用極大的提高了效率,我們在分析日活或者不同事件的日活,如果用我們之前自己DIY的系統查詢的話,雖然知道怎麼查,但是SQL都要重新寫,其實對於資料分析師來說,成本就會比較高,比如上了一個新的玩法,上了一個新的禮包或者一個新的寵物,所有的分析都要從0開始。然後複雜分析就是說我們的漏斗,包括路徑分析,資料下鑽,它就會探索遊戲內各步驟的轉化情況,包括流程其實也可以來分析,分析使用者的偏好以及關鍵節點的漏斗分析,如果單純寫SQL的話,從零開始進行路徑分析其實是很難的,分析越多整個資料複雜度會成倍的增加,通過數數科技的產品我們就能簡單操作,直接新增一個事件,整個的分析過程就會很順利很便利。

使用者畫像,就是使用者分群,使用者標籤以及使用者屬性。使用者分群從多角度掌握我們指定使用者的分群特徵, 我們根據使用者的特徵,使用者的一些行為屬性,包括付費,活躍度,包括它在是否參與某個事件,去分析當前指定使用者的情況,比如我們有時候分析烏拉拉一個寵物,最近上線一個寵物進化的功能,我們首先在立項做這個功能前,我們就可以分析當前的寵物玩家,就是玩家對於寵物這個模組的使用參與率以及他在這個方面付費的情況,在功能上線之後,我們就可以對比。如說之前他是重度玩家重度玩寵物的,或者對於寵物這個功能他並不感興趣的。在我們上線之後,對於這部分群體,就是說我們劃分了標籤之後,我們就可以看轉化情況,喜歡玩的是不是更喜歡,不喜歡玩的,是不是更多的去參與新的寵物進化這個模組。

自定義查詢就是對於資料分析和資料開發很有幫助,我們對於現有的模型,或者我們的埋點沒辦法去覆蓋的一些資料,可以通過回溯達到我們想要的效果。

比如自定義的SQL查詢,可能他它外部UI皮膚沒辦法覆蓋,比如說20%有這些需求,我們可以去查詢,再去展示,反饋給我們的策劃,包括我們的運營。

資料回溯,舉個例子,在烏拉拉,我們之前對於裝置新增其實沒什麼辦法,因為我們之前是沒有客戶端SDK埋點的,所以我們只有資料來源的資料,服務端的資料,我們是沒辦法去做的,通過資料回溯,我們可以通過歷史採集的一些裝置ID,去存量計算,比如當前哪些裝置是新增的,再反過來說,用裝置新增去看我們新的裝置,包括裝置新增到賬號建立到角色,建立到登入它的一個轉化率,主要是平臺後臺的維護。

《不休的烏拉拉》背後的資料體系

許可權的話,其實是我今天重點想講的,也是TA系統的看板分享,TA系統給我們帶來的變化,是多部門的協作更加密切,不同部門的分析結果,不光會自己看,而是分享出來,大家都可以去檢視你的報表,也可以看你的整個的分析過程,就是說你的資料是可追溯的。

維度表加虛擬屬性,其實對於資料埋點,你之前的埋點設計跟你後續的分析可能有一些出入,或者有一些考慮不到的地方,你沒有直接去埋點,我會通過維度表去對映,比如我們的一些媒體型別,比如職業。對於一些記錄的時間,虛擬屬性的靈活度會更高,因為我們烏拉拉可能有一個不同點就是我們有一個和服,我們分了各個首列季,賽紀的和服,我們其實只記錄了他是某個賽季的,對於這個賽季的和服時間在日誌裡面其實是不好記錄的,我們可以通過虛擬屬性,就是它通過自己本身所在賽季開服的時間,然後去對映,我們通過計算事件發生的時間,然後去計算當前屬於這個賽季開服的第幾天,或者這個事件發生的時候屬於它的生命週期。這樣對於說我們在資料分析的時候,就會有更多的維度指標去篩選,或者說去分組去分析。

報警管理主要是常用的指標實時監控,你可以設定你的預警值,如果出現異常,那就可以及時發出訊息。

《不休的烏拉拉》背後的資料體系

03、TA系統為烏拉拉專案帶來的變化

第三部分講講我們接入TA系統之後我們做了什麼,TA系統為烏拉拉專案帶來的變化,從三個方面來講。

《不休的烏拉拉》背後的資料體系

第一個,運營分析,比如不同的活動不同的時間段去上線,想看看玩家的付費意願,我們可以在數數平臺上面,用報表用看板的形式把這些這些專案這些活動都作一個分組,能夠持續的去觀察,觀察它的ARPU,如果把他們都放在一個介面裡,看板如果做完了,我們後續再上線一個新的活動,就不需要再去重新開始去拿這個活動的 ARPU,到了固定的時間上線,我們的報表裡面就會有展示, 這對於我們持續觀察,或者對比我們歷史上線的專案,都有很大的幫助。

第二點,我們可以持續觀察指標的變化,比如說創作有效性,需要多方位判斷,不光是跟自己比,還要和同類的專案對比,看有沒有提高。對於CPI我們會去設定它的預警值,一個專案如果連 CPI都達不到,那肯定是有問題的,後續要總結經驗去優化。

《不休的烏拉拉》背後的資料體系

最後主要是業務分析,比如玩法分析,比如說寵物,我們之前推出三個超級寵物老虎,狼,龍。對於說我們推出的寵物,只要他抽到了,並且進化,對於它之後的一個使用者的活躍,包括留存,其實都是有很大的提升。其實我們之前在沒有接入TA系統之前,主要是策劃提需求,我們去分析,但是接入TA之後,這次的寵物進化都是策劃自己去分析的。因為整個策劃是他們做的,對於模組有更深的理解,如果策劃去分析的話,對於業務邏輯或者說他想要達到的一個設計目的,他會有更深的一個理解,他分析出來可能更有說服力,我們資料分析可能就會有更多的精力從我們的角度去驗證它,去分析。我們每一個版本都會有分析,我們從不同的角度去分析活動。看看這個結論是不是都是正向的,或者說完全相反,TA系統的上線對於這種思維碰撞都有推動作用。

《不休的烏拉拉》背後的資料體系

04、如何更好的使用TA系統化

最後說說烏拉拉和TA系統後續合作的一個期待,也希望我們的合作能走的更長遠,首先有一個好的工具,可以解放大部分生產力。我們之前對接策劃和運營的需求,會佔用大量工作時間,就沒有更多精力再去分析,以我們的角度分析專案其他的功能。使用TA系統也提升資料分析能力,這其實需要深度的瞭解業務,並且具有嚴謹的邏輯推理能力。我覺得除了策劃或者專門做資料分析運營的同學,其實對於業務瞭解更多的或者說邏輯推理能力更強的,我覺得程式開發也更有發言權。我希望能夠增強公司整體的資料意識,不光是公司的高層或者產品,比如程式設計師或者UI美術,依託於TA系統這樣好的工具,都可以培養大家的資料意識,在資料上反應使用者為我們做的東西花費了多少精力,有沒有付費或者付費的多少,使用者的熱情是什麼?這樣才能推動我們對於我們所做的東西有成就感,更好的推動我們去優化我們開發能力,如果你看到我們線上的bug也好,能夠真實的看到資料。比如今天日活是100萬,因為出現了 bug,日活掉了10萬。是不是你更有動力去做好自身的業務模組,然後給整個專案一個正向的反饋。

《不休的烏拉拉》背後的資料體系

最後想說和數數的合作,一起發現了資料的價值,資料是資訊的載體,也是玩家對於我們遊戲產品的反饋。我們希望堅持使用者第一、提高創作的有效性,並且不斷豐富我們的資料分析思路,充分發掘資料的價值。希望和數數團隊也有更多的交流,不斷進行效率提升,謝謝大家。


來源:遊戲茶館
原文:https://mp.weixin.qq.com/s/f5OUkF9om47oN2N4WJB5dQ

相關文章