誰負責數據質量？ 分析團隊的責任矩陣

由於低質量數據會使任何進一步的操作（例如計算歸因、向廣告服務發送投標或構建報告）變得無用，因此確保數據質量仍然是數字分析中的最大挑戰。 通常說分析師應對所有與數據相關的問題負責。 但這是真的嗎？

誰負責公司的數據質量？ 與普遍的看法相反，不僅僅是分析師。 例如，營銷人員使用 UTM 標籤，工程師應用跟踪代碼等。因此，在處理數據時出現混亂也就不足為奇了：每個員工都有很多任務，不清楚誰在做什麼，誰負責什麼，以及誰應該被問到結果。

在本文中，我們試圖了解誰負責每個階段的數據質量以及如何管理它。

即使在一家公司內，數據世界也可能充滿差異和誤解。 要為業務用戶提供優質數據並避免丟失有價值的數據，您需要計劃收集所有必要的營銷數據。 通過準備數據工作流，您可以演示所有部門的同事之間的數據是如何關聯的，因此可以很容易地連接這些點。 然而，這只是第一步。 讓我們看看為報告和儀表板準備數據的其他步驟：

1. 設置主要數據收集。
2. 將原始數據收集到數據存儲或數據庫中。
3. 將原始數據轉換為業務就緒數據，並帶有標記，經過清理並採用業務可以理解的結構。
4. 準備一個數據集市——一個平面結構，用作數據可視化的數據源。
5. 可視化儀表板的數據。

然而，無論如何準備，決策者經常會遇到數據質量較差的報告或儀表板。 他們做的第一件事就是向分析師提出問題：為什麼會有差異？ 或者這裡的數據是否相關？

然而，現實情況是，這些過程涉及不同的專家：數據工程師參與建立分析系統，營銷人員添加 UTM 標籤，用戶輸入數據。 讓我們詳細看看您應該經歷哪些階段以及應該如何實施這些階段才能為用戶提供高質量的數據。

雖然這一步看起來最簡單，但也有一些隱藏的障礙。 首先，您必須計劃從所有來源收集所有數據，並考慮所有客戶接觸點。 有時會跳過這個計劃步驟，但這樣做是不合理且有風險的。 採用非結構化方法會導致獲得不完整或不正確的數據。

主要挑戰是您必須從您使用的不同廣告平台和服務收集碎片數據。 由於在最短的時間內處理海量數據數組是複雜且資源密集的，讓我們看看可能會出現哪些瓶頸：

• 並非所有頁面都安裝了 GTM 容器，因此數據不會發送到 Google Analytics。
• 在廣告平台上創建了一個新帳戶，但沒有通知分析師，也沒有從中收集數據。
• API 不支持 UTM 標籤中的動態參數，也不收集或傳輸它們。
• 連接谷歌云項目的卡資金或信用不足。
• 用戶輸入的數據驗證不正確。

在此步驟中，除了所有其他挑戰之外，您還必須考慮控制對數據的訪問。 為此，我們建議使用經典的 RACI 矩陣，該矩陣定義流程的角色，並強調誰執行、控制、管理和負責什麼。 以下是可能的角色：

• R (Responsible) — 負責並執行特定流程的人
• C （Consulted）——諮詢並提供必要數據以實施流程的人
• A （Accountable or Approver）——對工作結果負責的人
• I (Informed)——必須被告知工作進展的人

根據 RACI 矩陣，數據收集的角色和職責如下所示：

下一步是決定在哪裡存儲所有獲得的數據。 如果您想在不修改原始數據的情況下完全控制它，我們建議您使用具有自動數據導入功能的單一存儲。 由於使用您自己的服務器來存儲每個字節的數據將花費一大筆錢，我們建議使用雲解決方案來節省您的資源並提供對無處不在的數據的訪問。

這項任務的最佳選擇是 Google BigQuery，因為它考慮了營銷人員的需求，可用於存儲來自網站、CRM 系統、廣告平台等的原始數據。如今，有大量的營銷軟件解決方案。 我們推薦 OWOX BI，它會自動將來自不同服務和網站的數據收集到數據倉庫（或數據湖）中。

讓我們看看在收集原始數據時會出現哪些經典錯誤：

• 廣告服務的 API 已更改。 因此，數據格式也發生了變化。
• 外部服務 API 不可用。 利益相關者在他們的個人賬戶中看到了某些數字，但同一廣告服務的 API 提供了其他數據。 此數據不匹配，因為與任何分佈式系統一樣，廣告服務 API 的數據源與 Web 門戶的數據源不同。
• 外部服務的 Web 界面和 API 中的數據是不同的。 文檔和數據處理格式可以不同。 例如，一種流行的廣告服務中的一個有趣的錯誤是，當費用不存在和實際為零時，費用都為零。 所有數據工程師和分析師都知道零和Null是不同的值，處理方式也不同。 在一種情況下，這些費用可能會出現並且必須再次請求，而零表示它們確實不存在並且被計為零。
• 外部服務的 API 提供了不正確的數據。

根據矩陣，在此過程中，營銷人員是顧問和知識來源：例如，了解您需要從哪些帳戶下載數據、UTM 標籤是什麼以及廣告活動的標記。

也有開發者想知道如果使用谷歌標籤管理器，容器會發生什麼變化，因為他們對網站的下載速度負責。

此時，數據工程師已經在扮演負責的角色，因為他們正在配置數據管道。 分析師對工作結果負責。 即使一名員工執行這些職能，實際上也會有兩個角色。 因此，如果公司只有一名分析師，我們仍然建議按角色實施矩陣。 然後，隨著公司的發展，你會有一個新同事的職位描述，並且清楚地知道特定角色的職責是什麼。

在這個階段，利益相關者有興趣了解哪些數據可用以及其質量存在哪些問題，因為它確定了旨在收集數據的優先事項和資源。 例如，OWOX BI 數據監控功能被我們的客戶廣泛應用。

數據準備是下一步。 它通常被稱為數據集市準備——這是一個包含將在儀表板上顯示的參數和指標的平面結構。 工具、預算和時間有限的分析師通常會跳過準備業務數據的階段，立即準備數據集市。 它看起來像是在數據倉庫中收集的原始數據。 然後，還有一百萬種不同的 SQL 查詢以及 Python 和 R 腳本——這種混亂會導致儀表板上出現一些問題。

如果您一直跳過準備業務數據的準備工作，則會導致重複出現的錯誤，需要在每個來源中進行更正。 其他可能出錯的事情包括：

• 原始數據中的常規錯誤
• 在所有 SQL 查詢中重複的業務邏輯
• 查找數據差異的原因需要大量時間
• 改進現有數據集市的時間與重寫請求的時間相當
• 客戶無法理解的報告邏輯

最簡單和最常見的錯誤示例是新用戶和返回用戶的定義。 大多數企業不像谷歌分析那樣做出這種區分。 因此，用戶類型定義的邏輯經常在不同的報表中重複出現。 常見的錯誤還包括難以理解的報告邏輯。 業務客戶在查看報告時首先要問的是它是如何構建的，它基於什麼假設，為什麼使用數據等等。 因此，業務數據的準備是一個絕對不能跳過的階段。 從原始數據構建數據集市就像在吃蔬菜和水果之前不洗。

如果我們根據矩陣分配職責，那麼對於數據準備，我們將得到：

業務就緒數據是與業務模型相對應的經過清理的最終數據集。 它是可以發送到任何數據可視化服務（Power BI、Tableau、Google Data Studio 等）的現成數據。

自然，不同的企業以不同的模式運作。 例如，“用戶”、“B2B 用戶”、“交易”、“潛在客戶”等的定義對於不同的公司意味著不同的含義。 這些業務對象實際上回答了企業如何從數據方面考慮其業務模型的問題。 這是對業務核心的描述，而不是 Google Analytics 中的事件結構。

數據模型允許所有員工同步並大致了解數據的使用方式以及對數據的理解。 因此，將原始數據轉換為業務就緒數據是不可跳過的重要階段。

在這個階段可能會出現什麼問題：

• 不清楚公司擁有/使用哪種數據模型
• 難以準備和維護模擬數據
• 難以控制轉換邏輯的變化

在這裡，您需要決定選擇哪種數據模型以及如何控制數據轉換邏輯的變化。 因此，這些是變革過程中參與者的角色：

利益相關者不再只是被告知，而是成為顧問。 他們做出決定，例如應該將什麼理解為新用戶或返回用戶。 分析師在這個階段的任務是讓利益相關者盡可能多地參與做出這些決策。 否則，可能發生的最好的事情是分析師將被要求重做報告。

根據我們的經驗，一些公司仍然沒有準備業務就緒數據並在原始數據上構建報告。 這種方法的主要問題是無休止地調試和重寫 SQL 查詢。 從長遠來看，使用準備好的數據比在原始數據上一遍又一遍地做同樣的事情更便宜、更容易。

OWOX BI 自動從不同來源收集原始數據並將其轉換為報告友好的格式。 因此，您會收到現成的數據集，這些數據集會自動轉換為所需的結構，同時考慮到對營銷人員很重要的細微差別。 您不必花時間開發和支持複雜的轉換、深入研究數據結構並花費數小時尋找差異的原因。

預訂免費演示，了解 OWOX BI 如何協助準備業務數據，以及您如何從當今的全自動數據管理中受益。

下一階段是準備數據集市。 簡而言之，這是一個準備好的表格，其中包含特定部門的某些用戶所需的確切數據，這使得它更容易應用。

為什麼分析師需要數據集市，為什麼不跳過這個階段？ 沒有分析技能的營銷人員和其他員工發現很難處理原始數據。 分析師的任務是以最方便的形式為所有員工提供對數據的訪問，這樣他們就不必每次都編寫複雜的 SQL 查詢。

數據集市有助於解決這個問題。 確實，如果填寫得當，它將準確地包括某個部門工作所需的數據切片。 同事們將確切地知道如何使用這樣的數據庫，並將了解其中提供的參數和指標的上下文。

準備數據集市時可能出現問題的主要情況是：

• 數據合併邏輯是不可理解的。 例如，可能有來自移動應用程序和網站的數據，您需要決定如何合併它以及使用哪些鍵，或者決定如何將廣告活動與移動應用程序中的活動合併。 有很多問題。 通過在準備業務數據時做出這些決定，我們只做了一次，它們的價值比現在為特定報告臨時做出的決定更大。 這種臨時決定必須反复做出。
• 由於數據倉庫技術限制，SQL 查詢無法運行。 準備業務數據是清理數據並將其引入模擬結構的一種方法，這將使處理和加速查詢的成本更低。
• 目前尚不清楚如何檢查數據質量。

我們根據矩陣看看現階段誰負責什麼：

很明顯，數據準備是數據分析師以及利益相關者和數據工程師的責任，他們是過程中的顧問。 請注意，OWOX BI 分析師可以為您處理此任務。 我們可以收集和合併數據，為您的業務模型建模，並準備一個數據集市，並附有詳細的說明和構建邏輯的描述，允許您在必要時進行更改（例如，添加新字段）。

在報告和儀表板中直觀地呈現數據是一切實際開始的最後階段。 顯然，數據應該以信息豐富且用戶友好的方式呈現。 更不用說自動化和正確配置的可視化顯著減少了查找風險區域、問題和增長可能性的時間。

如果您已準備好業務就緒數據和數據集市，則可視化將毫無困難。 但是，也可能出現錯誤，例如：

• 數據集市中的不相關數據。 如果企業不確定數據質量，那麼即使數據質量很高，企業客戶的第一步也是要求分析師仔細檢查所有內容。 這是低效的。 很明顯，企業希望免受錯誤的影響，而不是急於下結論。 因此，高質量的數據是以後有人使用的保證。
• 選擇了不正確的數據可視化方法。
• 沒有向客戶正確解釋度量和參數計算的邏輯。 通常，對於不使用 SQL 和指標來正確解釋數據的業務客戶，他們需要了解每個指標在報表上下文中的含義、計算方式以及原因。 分析師不應忘記，任何使用該報告的人都應該能夠獲得對報告背後內容、報告核心假設等的解釋。

根據 RACI 矩陣，分析師已經具有雙重角色——批准者和負責人。 利益相關者是這裡的顧問，他們很可能已經提前回答了他們計劃做出什麼決定以及他們想要測試什麼假設的問題。 這些假設構成了分析師工作的可視化設計的基礎。

RACI 矩陣不能回答有關使用數據的所有可能問題，但它絕對可以簡化您公司中數據流的實施和應用。

由於不同角色的人參與數據流的不同階段，因此假設分析師對數據質量負全部責任是錯誤的。 數據質量也是參與數據標記、交付、準備或管理決策的所有同事的責任。

所有數據的質量總是很差，不可能永久消除數據差異，使數據保持一致，消除噪音和重複。 這種情況總是會發生，尤其是在像營銷這樣快速且動態變化的數據現實中。 但是，您可以主動識別這些問題並設定目標以使您的數據質量為人所知。 例如，您可以獲得以下問題的答案：數據何時更新？ 可用數據的粒度是多少？ 我們知道數據中的哪些錯誤？ 我們可以使用哪些指標？

對於那些想為提高公司數據質量做出貢獻的人，我們推薦三個簡單的步驟：

1. 創建數據流模式。 例如，使用 Miro 並勾勒出您的公司如何使用數據。 您會驚訝地發現，在一家公司內對這種模式有多少不同的看法。
2. 建立一個責任矩陣並就誰負責什麼達成一致，至少在紙面上是這樣。
3. 描述業務數據模型。

OWOX BI 團隊擁有多年的專業知識，知道如何分配職責以及分析師需要什麼。 基於這些知識，我們為分析師團隊準備了責任分配矩陣模板。

獲取矩陣

此外，OWOX BI 團隊可以幫助您配置和自動化本文中描述的所有數據步驟。 如果您需要任何這些任務的幫助或想要審核您的分析和數據質量系統，請預訂演示。

1. 暗數據：為什麼你不知道的東西很重要 David J. Hand
2. 信號與噪音：為什麼這麼多預測都失敗了——但有些預測失敗了 Nate Silver
3. Dan Ariely 博士的《可預見的非理性》
4. 非理性猿：為什麼我們會因虛假信息、陰謀論和宣傳而墮落大衛·羅伯特·格蘭姆斯
5. Antriksh Goel 的“數據生態系統”體驗