【淺談遊戲數據分析的理解與經驗分享】 - By RF
延續前篇文章提到的營運基本素養，本文來說明筆者對於數據分析的理解與經驗分享，
數據分析可簡單分為三個區塊 Data→ Information → Solution
產品的每日數據表、鑽石產出消耗統計、禮包購買狀況等這類經統計出的「數字」，可視為 Data：
舉例: 每日鑽石產出約150-200萬鑽，但在5/6產出400萬鑽；
深入挖掘造成其數字變化的「背後原因與傳遞出的資訊」，可視為 Information：
舉例: 造成此5/6的鑽石產出變化原因，可能有bug被洗大量鑽石、有大型儲值活動吸引大量付費玩家出來付費、有大R怒儲100萬鑽、活動獎勵配置錯誤等原因；
最後根據其數據分析得到的資訊與結論，做出「相對應的決策與後續計畫」，可視為 Solution：
舉例: 本次活動獎勵配置原先預期A獎勵較吸引中小用戶，經分析後發現是B獎勵命中大R用戶需求，導致大R瘋狂付費，此時可以重新檢視品項設計與用戶需求內容，並思考該如何延續本次的活動成效，同時也要評估是否會過度投放而造成道具失效的狀況。
以下為筆者過去在數據分析時得到的經驗，提供大家參考。
1. 資料驗證
錯誤的分析結論可能會導致錯誤的決策，所以《資料正確性》為首要注意的項目。
營運人員大多從數據後台或請技術撈取資料，尤其在額外撈取的資料當中，有可能因需求說明不清楚或是一時疏失導致撈取欄位或內容錯誤，故在撈取資料前要預先想好如何檢驗資料正確性，且拿到資料後第一時間需做資料驗證。
舉例: 想瞭解A產品在 5/1-5/7的每日營收，在資料撈取需求時可以額外拆分付費渠道(GP、IOS、官網)，來進行資料比對與驗證，當拆分付費渠道後的營收加總與每日總營收不同時，此時可以先回頭確認資料源哪裡有異常。
2. 數據結構
《用戶特性差異巨大》，根據自身運營的產品統計，所有用戶中僅10-20%的用戶會付費，在付費用戶中的前20%大R用戶會貢獻約75%-85%的營收，在判斷所有數字時要盡可能瞭解其用戶輪廓，且要有更多種面向的數據來進行輔助判斷。
舉例: 在分析鑽石產出消耗時，如果是所有用戶一起看，可能會無法定位到明確的問題，如果細分成免費用戶、付費用戶(大中小R)等細分數據，則可瞭解各階層用戶花費鑽石的地方，進而找到用戶需求。
3. 輻射思維
大部份情況下，可能是因為看到某個數字異常值或是想解決某個問題而進行分析，建議可以從問題中心進行《射放性的假設與思考》，如果是單線性的思考，過度聚焦於某個論點，容易花了很多時間最終發現方向錯誤導致浪費時間，甚至演變成先射箭再畫靶的情況。
舉例: B產品因為調整活動獎勵，預期ARPPU會從1200元提升至1500元，最終結果提高至2000元，此時如果只是「說明」本次如何調整活動所以達到此結果，而沒有思考其他可能性的話，有可能會忽略真正發生的原因。
4. 善用工具
最常使用也最容易入門的是Excel，其中最重要的功能是「樞紐分析表」，可以將大量資料依自身需求快速轉換成清楚明瞭的統計報表；其次如vlookup等函數，可以加速資料處理與比對，這些基本功除了多使用還是只能多練習來熟能生巧，更進階的也能學習SQL語法、Python、Tableau等軟體與工具來加快資料處理的速度。
5. 挑戰自己
在數據分析的過程中，不斷挑戰自己的想法與觀點，同時切換不同視角來審視自己的分析與結論，除了可以發掘不同問題與報告缺陷外，也可以提前預想上級主管或聽講者會想得知哪些資訊與提問內容。
「重分析，更重結論與後續追蹤」
剛開始接觸數據分析的營運人員容易太重分析或太相信數字，反而忽略了「產品體驗」與「解決問題」，進而導致輕易下結論或缺乏有效驗證其方案。
數據分析雖不是萬能，但也是遊戲營運一項必備技能，時刻關注數據變化，培養數字敏銳度，才有辦法一眼看出異常值！
希望以上內容對你有所幫助，也歡迎大家一起多多交流。
--
本篇為客座專欄，作者RF，現為知名遊戲公司營運主管，希望藉由分享自身經驗，給有志於遊戲營運的朋友一些啟發。
sql判斷欄位是否有值 在 Re: [SQL ] 是否避免null值- 看板Database - 批踢踢實業坊 的推薦與評價
※ 引述《lashante (杏花天影)》之銘言：
: 以前在學 PL/SQL 時，
: 是由一位有相當不錯業界經驗的老師教的。
: 老師有特別提到，設計資料庫的欄位時，
: 若可以不使用 null 值，就應該盡量將該欄位設 NOT NULL，
: 即使沒有資料，也塞一些將來可以辨識出來為無資料的值進去，
: ex : '' OR -1 之類的，
: 他說：「如果你習慣使用 null 值，
: 將來總有一天你會遇到大問題。」
: 雖然這樣的話感覺很武斷，
: 但我想他的原意應該是，遇到null值時，
: 在處理table和下SQL指令時，可能總是要做一些額外判斷，
: 若是沒處理好，取資料若取出奇怪的結果，就很不好找原因之類的。
: * * * * * *
: 現在剛開始工作不久，在開 table 時，
: 我遇到一個 entity A，
: 它關聯於 entity B 或 entity C 其中一者，
: 這三個 entity 分別存放於 TABLE A', B', C'，
: 其 PK 都是由 1開始 increment 1 的正整數。
: 所以 TABLE A' 就有二個欄位, say: B_id, C_id，
: 分別對應到 TABLE B' 及 TABLE C' 的PK，
: 我很自然的，就將 B_id, C_id 設 NOT NULL，
: 而若 entity a1 是對應到 entity b1，
: 則 entity a1 的 B_id 欄位 就給對應 entity b1 的pk值，
: C_id 欄位就給 -1。
: 老闆後來看到，就覺得我多此一舉，
: 問我幹嘛不把 B_id, C_id 允許 NULL，
: 沒對應到的就不寫值, 留 null 就好。
: 其實我因為經驗不是很夠，無法了解老師當初的深意，
: 所以也對老闆講不出個什麼東西來，
: 但是我的老闆也好講話，也沒真的很計較這件事，沒有叫我改回來。
: 我想請教較我更有經驗的各位，在習慣上，
: 避免使用 NULL 值是否真會帶來什麼優點，
: 或是反而會有什麼缺點？
: 若是習慣使用 NULL，是否會像在埋地雷一樣？
我不知道 null 值到底好不好，不過目前接到一個資料庫，情況是這樣
如果沒有值，有可能是 NULL 或是 ' ' ...
這樣我判斷是否有值時都要加 TRIM ...
以上只是一種情況... 好壞不確定...
不過我最近在寫plsql， NULL 值會有一個缺點 (也不知道算不算缺點)
以下舉例
假設有一個欄位是 sex
sex 描述是這樣
'1' 代表男人， '2' 代表女人， ' ' 或 NULL 代表無值， 若有其他值代表錯誤
今天假設你要做判斷，可以這樣做 (以下擷取片段plsql)
case TRIM(ROWDATA.sex)
when '1' then dbms_output.put_line('男人');
when '2' then dbms_output.put_line('女人');
when NULL then dbms_output.put_line('無值');
else dbms_output.put_line('錯誤');
end case;
以上，是錯的... 因為你永遠到不了 NULL 那一行 ...
因為跟 NULL 比較的欄位回傳值是 NULL ... ( 不是true 也不是 false )
在 plsql 裡面，無法比較 NULL
所以你判斷 NULL 時會用 IS NULL 而不是 = NULL
以上例子只是一個 case ... 而且是真實的 case ...
若要修改成可以正確輸出會是這樣
case NVL(TRIM(ROWDATA.sex),'NULL')
when '1' then dbms_output.put_line('男人');
when '2' then dbms_output.put_line('女人');
when 'NULL' then dbms_output.put_line('無值');
else dbms_output.put_line('錯誤');
end case;
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 119.77.195.98
... <看更多>