數據分析經驗分享（一）：財務報告的歷史一致性

這個系列主要記錄我在工作中遇到的數據分析專案，不僅能幫助自己整理經驗（也能用來準備面試），同時也希望能讓讀者了解數據分析師的日常工作，以及在遇到分析問題時可以如何處理。

如果覺得文章對你有幫助，歡迎在留言區留言分享你的想法！

財務報告與其他報告的不同之處

這篇文章的主題是財務報告，主要指大家常聽到的財務三表（損益表、資產負債表、現金流量表）。不過，在我們公司的分工下，我實際需要計算的部分主要是損益表中的獲利與支出，其他部分則由財務同事負責整理。

與數據分析師常見的其他數據報告相比，財務報告有一個關鍵特性：

財務報告交出去的數字不能變動

在一般產品分析中，例如監測某個功能的使用情況，即使數據來源有所變動，導致歷史數據略有調整，通常影響不大，因為我們關心的是趨勢，而非特定時間點的絕對數字。

然而，財務報告則不同。一旦提交就不能回頭修改過去的數據。如果因為定義調整或其他因素導致歷史數據變動，這些變動必須體現在未來的月份中。這個特性使得財務報告在計算上需要特別小心。

三種常見的數據報告

在進一步探討財務報告的計算細節前，先來簡單區分一下常見的數據報告類型：

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，將所有明細的當下結果與欄位存起來，這樣每個月都能回頭對比上個月的數字。

希望上述的分享對你們有幫助！如果對於其他數據分析主題有興趣，也歡迎參考我的職場心得沙龍～