這個系列主要記錄我在工作中遇到的數據分析專案,不僅能幫助自己整理經驗(也能用來準備面試),同時也希望能讓讀者了解數據分析師的日常工作,以及在遇到分析問題時可以如何處理。
如果覺得文章對你有幫助,歡迎在留言區留言分享你的想法!
財務報告與其他報告的不同之處
這篇文章的主題是財務報告,主要指大家常聽到的財務三表(損益表、資產負債表、現金流量表)。不過,在我們公司的分工下,我實際需要計算的部分主要是損益表中的獲利與支出,其他部分則由財務同事負責整理。與數據分析師常見的其他數據報告相比,財務報告有一個關鍵特性:
財務報告交出去的數字不能變動
在一般產品分析中,例如監測某個功能的使用情況,即使數據來源有所變動,導致歷史數據略有調整,通常影響不大,因為我們關心的是趨勢,而非特定時間點的絕對數字。
然而,財務報告則不同。一旦提交就不能回頭修改過去的數據。如果因為定義調整或其他因素導致歷史數據變動,這些變動必須體現在未來的月份中。這個特性使得財務報告在計算上需要特別小心。
三種常見的數據報告
在進一步探討財務報告的計算細節前,先來簡單區分一下常見的數據報告類型:
1. 一次性的數據分析
- 例如新功能上線後,分析其成效。
- 這類分析主要幫助 PM 判斷是否保留該功能,通常是「做完就結束」(除非有特別要求)。
- 由於是一次性分析,計算方式可以較為靈活,甚至可以使用手動整理、不定期更新的 spreadsheet 作為資料來源。
2. 定期監測的儀表板(Dashboard)
- 這類報告主要用來追蹤產品或業務的關鍵指標,需定期更新,以便觀察趨勢並與歷史數據比較。
- 由於需長期維護,撰寫 SQL 時要考慮可讀性與可維護性,並確保所使用的數據來源會定期更新。
3. 財務數據的儀表板
- 本質上與一般監測儀表板類似,但最大差異在於 「數字不能變動」。
- 計算邏輯必須特別謹慎,確保未來的變動不會影響過去的數據。
計算財務報告時容易踩的坑
由於財務數據不可變更,在計算時需要特別留意避免常見的錯誤。以下是幾個我曾遇到的「雷區」:
1. 資料標籤(Label)變動導致數據錯誤
舉例來說,假設財務報告會排除所有標記為 "cancelled" 的交易,並且是根據 created_at
來決定認列時間。
如果某筆交易的狀態後來從 "cancelled" 變更為 "completed",這筆交易將突然出現在歷史數據中,導致數字不一致。
解法:
- 在設計報表時,要考慮狀態變更的影響,盡量避免使用可能變動的狀態作為篩選條件。
2. 使用 updated_at
作為認列時間
某些數據表會使用 updated_at
記錄最後一次修改時間,但如果財務報告以此作為認列依據,可能會遇到以下問題:
- 某筆數據可能已被計算過,但下個月又因
updated_at
變動而重新出現在報表中。
解法:
- 避免使用
updated_at
作為財務數據的認列時間,應改用不會變動的欄位(如created_at
或confirmed_at
)。
3. 退款(Refund)的處理方式
在一般產品分析中,計算淨營收時可能會簡單地使用「總付款 - 總退款」來計算。但在財務報告中,時間點非常重要:
- 退款通常發生在不同月份,因此需要將消費與退款拆成兩筆記錄,分別計入正確的月份。
解法:
- 針對退款,應記錄兩筆交易:
- 第一筆為原始消費金額,記錄在當時的月份。
- 第二筆為退款金額,記錄在退款發生的月份。
4. 刪除帳號後的數據處理
如果用戶刪除了帳號,我們不能單純根據 deleted
來決定該筆數據是否應該保留。例如:
- 如果某用戶 1 月有交易,但 3 月刪除帳號,那麼回溯 1 月的財務報表時,這筆交易仍應存在,而不應因
deleted
被標記為刪除就移除。
解法:
- 計算時,不應直接依賴最新的
deleted
狀態來決定數據是否保留,而應確保刪除帳號前的數據仍可回溯。
如何發現財務數據異常?
由於財務報告的數據不能變動,如果在更新新一個月數據時,發現使用相同邏輯計算的歷史數據有變動,就需要追查原因,並評估是否需修正計算邏輯。
然而,如果問題是由於狀態變更導致的(例如某筆交易從被認列變成未被認列,或反之),那麼在計算當下很難回溯當時的數據狀況。
解法:
- 為了解決這個問題,我們公司的做法是對每個月的財務報告明細建立 snapshot,將所有明細的當下結果與欄位存起來,這樣每個月都能回頭對比上個月的數字。
希望上述的分享對你們有幫助!如果對於其他數據分析主題有興趣,也歡迎參考我的職場心得沙龍~