如何監控數據質量——詳細指南

防止數據收集中的錯誤比處理其後果更容易。 您的業務決策是否明智取決於數據的質量。 在本文中，我們將告訴您如何在收集的所有階段（從工作說明到完成的報告）檢查數據的質量。

不幸的是，許多花費大量資源存儲和處理數據的公司仍​​然根據直覺和他們自己的期望而不是數據做出重要決策。

為什麼會這樣？ 數據提供的答案與決策者的期望不一致的情況會加劇對數據的不信任。 此外，如果有人過去在數據或報告中遇到過錯誤，他們傾向於傾向於直覺。 這是可以理解的，因為根據不正確的數據做出的決定可能會讓你倒退而不是讓你前進。

想像一下，您有一個多幣種項目。 您的分析師以一種貨幣設置了 Google Analytics，而負責上下文廣告的營銷人員設置了以另一種貨幣導入 Google Analytics 的成本。 因此，您的廣告活動報告中的廣告支出回報率 (ROAS) 不切實際。 如果您沒有及時注意到此錯誤，您可能會禁用盈利活動或增加虧損活動的預算。

此外，開發人員通常很忙，實施 Web 分析對他們來說是次要任務。 在實施新功能時——例如，帶有附件的單元的新設計——開發人員可能會忘記檢查谷歌分析是否正在收集數據。 結果，當評估新設計的有效性時，結果發現數據收集在兩週前就被破壞了。 驚喜。

想像一下，您在規範階段犯了一個錯誤。 如果你找到它並立即糾正它，修復將相對便宜。 如果在實施後、構建報告時、甚至在決策時發現錯誤，修復它的成本將非常高。

數據收集通常包括五個關鍵步驟：

1. 制定業務挑戰。 假設您需要評估算法在推薦塊中選擇商品的效率。
2. 負責數據收集的分析師或人員設計了一個要在站點上跟踪的指標系統。
3. 此人設置 Google Analytics 和 Google Tag Manager。
4. 一個發送參考條款供開發人員實施。
5. 在開發人員實施指標並設置數據收集後，分析師將使用報告。

在幾乎所有這些階段，檢查您的數據都非常重要。 有必要測試技術文檔、谷歌分析和谷歌標籤管理器設置，當然還有在您的網站或移動應用程序中收集的數據的質量。

在進行每一步之前，我們先來看看數據測試的一些要求：

• 沒有工具就無法測試。 至少，您必須在瀏覽器中使用開發者控制台。
• 沒有抽象的預期結果。 你需要確切地知道你最終應該得到什麼。 對於與網站的任何用戶交互，我們總是需要收集一組特定的參數。 我們知道這些參數應該取的值。
• 需要特殊知識。 至少，您需要熟悉您使用的網絡分析工具的文檔、實踐和市場參與者的經驗。

正如我們所提到的，如果您在規範中發現錯誤，則更容易糾正錯誤。 因此，在收集數據之前很久就開始檢查文檔。 讓我們弄清楚為什麼我們需要檢查您的文檔。

測試文檔的目的：

• 毫不費力地修復錯誤。 文檔中的錯誤只是書面文本中的錯誤，因此您所要做的就是快速編輯。
• 防止將來需要進行可能影響站點/應用程序架構的更改。
• 保護分析師的聲譽。 一份在製定過程中出現錯誤的文書可能會質疑起草人的能力。

規格中最常見的錯誤：

1. 錯別字。 開發人員可以在不閱讀參數的情況下複製參數名稱。 這與語法或拼寫錯誤無關，而是與參數名稱或這些參數所包含的值有關。
2. 跟踪事件時忽略字段。 例如，如果表單未成功提交，則可能會忽略錯誤消息。
3. 字段名稱無效且與增強型電子商務方案不匹配。 使用dataLayer變量實現增強型電子商務需要清晰的文檔。 因此，在起草規範時最好檢查所有字段兩次。
4. 您沒有多幣種網站的貨幣支持。 此問題與所有與收入相關的報告有關。
5. 不考慮命中限制。 例如，假設目錄頁面上最多可以有 30 種不同的產品。 如果我們同時傳輸所有產品的瀏覽量信息，Google Analytics（分析）中的匹配很可能不會被傳輸。

檢查技術文檔後的下一步是檢查您的 Google Analytics（分析）和 Google Tag Manager 設置。

為什麼要測試 Google Analytics 和 Google Tag Manager 設置？

• 確保數據收集系統正確處理參數。 Google Analytics 和 Google Tag Manager 可以與您網站上的指標實施並行配置。 在分析完成之前，數據不會出現在 Google Analytics 中。
• 更容易測試嵌入在網站上的指標。 您只需要專注於開發人員的部分工作。 在 X 的最後階段，您需要直接在站點上查找錯誤原因，而不是在平台設置中。
• 維修成本低，無需開發人員參與。

Google Analytics 中最常見的錯誤：

1. 未創建自定義變量。 這對於 Google Analytics 360 帳戶尤其重要，它可以有多達 200 個指標和 200 個參數。 在這種情況下，很容易錯過一個。
2. 指定的訪問範圍無效。 您將無法在 dataLayer 審核階段或通過查看您發送的匹配來發現此錯誤，但是當您創建報告時，您會發現數據看起來不像預期的那樣。
3. 您會得到一個現有參數的副本。 此錯誤不會影響正在發送的數據，但可能會在檢查和構建報告時導致問題。

Google 跟踪代碼管理器中最常見的錯誤：

1. 未添加任何參數，例如 Universal Analytics 代碼或 Google Analytics 設置變量。
2. 代碼中的索引與 Google Analytics 中的參數不匹配，從而產生將值傳遞給錯誤參數的風險。 例如，假設您在 GTM 中為 item rating 參數指定了 number of users 參數的索引。 在構建報告時可能會立即發現此錯誤，但您將無法再影響收集的數據。
3. 在 dataLayer 中指定的變量名無效。 創建 dataLayer 時，請務必指定將在 dataLayer 數組中找到變量的名稱。 如果您鍵入或寫入另一個值，則永遠不會從 dataLayer 中讀取此變量。
4. 未啟用增強型電子商務跟踪。
5. 啟動觸發器配置不正確。 例如觸發X的正則表達式寫錯或事件名稱有錯誤。

測試的最後階段是直接在站點上進行測試。 這個階段需要更多的技術知識，因為您需要查看代碼、檢查容器的安裝方式以及閱讀日誌。 因此，您需要精明並使用正確的工具。

為什麼要測試嵌入式指標？

• 檢查實施的內容是否符合規範並記錄任何錯誤。
• 檢查要發送的值是否足夠。 驗證參數是否正在傳輸要傳輸的值。 例如，商品類別不傳遞其名稱。
• 向開發人員提供有關實施質量的反饋。 根據此反饋，開發人員可以對站點進行更改。

最常見的錯誤：

1. 並未涵蓋所有場景。 例如，假設可以將一個項目添加到產品、目錄、促銷或母版頁上的購物車中——也就是說，任何有項目鏈接的地方。 有這麼多的入口點，你可能會錯過一些東西。
2. 該任務並未在所有頁面上實施。 也就是說，對於某些頁面或某些分區/目錄，根本不收集數據或僅收集部分數據。 為了防止這種情況，我們可以製定一份清單。 在某些情況下，我們可以對一個函數進行多達 100 次檢查。
3. 並非所有參數都實現； 也就是說，dataLayer 只是部分實現。
4. 用於增強電子商務的 dataLayer 方案已損壞。 對於諸如將商品添加到購物車、在結賬步驟之間移動以及單擊商品等事件尤其如此。 實施增強型電子商務的最常見錯誤之一是Products數組中缺少方括號。
5. dataLayer 使用空字符串而不是 null 或 undefined 將參數歸零。 在這種情況下，Google Analytics 報告包含空行。 如果您使用 null 或 undefined，則此選項甚至不會包含在您發送的命中中。

我們用來測試數據的工具：

• 谷歌分析調試器 Chrome 擴展
• GTM 調試器，您可以使用它在 Google 跟踪代碼管理器中啟用預覽模式
• 開發者控制台中的dataLayer命令
• 開發者控制台中的網絡選項卡
• 谷歌標籤助手 Chrome 擴展

讓我們仔細看看這些工具。

要開始使用，您需要在瀏覽器中安裝此擴展並啟用它。 然後打開頁面 ID 並轉到控制台選項卡。 您看到的信息由擴展程序提供。

此屏幕顯示與命中一起傳輸的參數以及為這些參數傳輸的值：

還有一個擴展的電子商務塊。 您可以在控制台中以ec的形式找到它：

此外，此處還會顯示錯誤消息，例如超出命中大小限制。

如果您需要檢查 dataLayer 的組成，最簡單的方法是在控制台中鍵入dataLayer命令：

這是傳輸的所有參數。 您可以詳細研究它們並驗證它們。 站點上的每個操作都反映在 dataLayer 中。 假設您有七個對象。 如果單擊空白字段並再次調用dataLayer命令，控制台中應該會出現第八個對象。

要訪問 Google Tag Manager Debugger，請打開您的 Google Tag Manager 帳戶並點擊Preview按鈕：

然後打開您的網站並刷新頁面。 在下部窗格中，應該會出現一個面板，顯示該頁面上運行的所有標籤。

添加到 dataLayer 的事件顯示在左側。 通過單擊它們，您可以檢查數據層的實時組成。

移動瀏覽器測試的特點：

• 在智能手機和平板電腦上，網站可以以自適應模式啟動，也可以有單獨的移動版網站。 如果您在桌面上運行網站的移動版本，它將與您手機上的相同版本不同。
• 通常，擴展程序不能安裝在移動瀏覽器中。
• 為了彌補這一點，您必須在 Universal Analytics 代碼或網站上的 Google Analytics 跟踪代碼中啟用調試模式。

移動應用測試的特點：

• 使用應用程序代碼需要更多的技術知識。
• 您需要一個本地代理服務器來攔截命中。 為了跟踪設備發送的請求數量，您可以按應用程序名稱或請求發送到的主機過濾請求。
• 所有匹配均以 Measurement Protocol 格式收集，需要額外處理。 收集和過濾命中後，必須將它們複製並解析為參數。 您可以使用任何方便的工具來執行此操作：Hit Builder、Google 表格中的公式或 JavaScript 或 Python 應用程序。 這一切都取決於什麼對您更方便。 此外，您需要了解 Measurement Protocol 參數來識別已發送匹配中的錯誤。

1. 通過 USB 將您的移動設備連接到您的筆記本電腦。
2. 在您的設備上打開谷歌瀏覽器。
3. 在 Chrome 開發者控制台中，打開遠程設備報告：

1. 通過單擊對話框中的確定來確認與您的設備的連接。 然後選擇您要檢查的選項卡並單擊Inspect 。
2. 現在您可以在標準模式下使用開發人員控制台，就像在瀏覽器中一樣。 您將擁有所有熟悉的選項卡：控制台、網絡等。

1. 要使用移動應用程序，您必須安裝並運行代理服務器。 我們推薦查爾斯。
2. 安裝了您的代理服務器，檢查應用程序連接到哪個 IP 地址：

3. 然後拿起您的設備並使用端口 8888 通過代理服務器配置 Wi-Fi 連接。這是 Charles 默認使用的端口。

4. 之後，是時候收集熱門歌曲了。 請注意，在應用程序中，命中不是發送到收集而是發送到批處理。 Batch 是一個打包的請求，可以幫助您發送多個請求。 首先，它節省了應用程序資源。 其次，如果出現網絡問題，請求將存儲在應用程序中，並在網絡連接重新建立後立即發送一個公共池。

5. 最後，必須將收集到的數據解析（反彙編）為參數，按順序檢查，並根據規範檢查。

這一步是最快和最簡單的。 同時，它確保在 Google Analytics 中收集的數據是有意義的。 在您的報告中，您可以檢查數百種不同的場景，並根據設備、瀏覽器等查看指標。如果您發現數據中有任何異常，您可以在特定設備和特定瀏覽器中播放腳本。

您還可以使用 Google Analytics 報告來檢查傳輸到 dataLayer 的數據的完整性。 即根據每個場景，填充變量，裡面是否有所有參數，參數是否取正確的值等等。

我們希望分享最有用的報告（在我們看來）。 您可以將它們用作數據收集清單：

• 電子商務報告：
  • 產品性能
  • 產品列表表現
  • 內部推廣
• 行為 - 事件 - 熱門事件
• 收購——活動——成本分析
• 自定義報告——例如，顯示重複訂單的報告

讓我們看看這些報告在界面中是什麼樣的，以及這些報告中你需要首先關注哪些。

該報告中最有價值的標籤是購物行為。 它分析了增強電子商務每個階段數據收集的完整性。 也就是說，我們可以看到谷歌分析是否傳輸產品列表視圖、點擊、產品詳細視圖、添加/刪除產品到/從購物籃，以及購買本身。

這裡我們應該注意什麼？ 首先，如果任何列中的值為零，這很奇怪。 其次，如果您在某個階段的值比前一階段的多，那麼您在收集數據時可能會遇到問題。 例如，假設某件商品的唯一購買次數大於結帳次數。 這很奇怪，值得關注。

您還可以在此報告中的其他參數之間切換，這些參數也應發送到增強型電子商務。 例如，如果您選擇項目類別作為主要選項，您可能會看到某些類別的項目有銷售，但這些項目沒有視圖，沒有添加到購物車等。

首先，有必要遍歷傳輸到 Google Analytics 的所有參數，並查看每個參數的值。 通常情況下，一切是否正常都會立即清楚。 可以在自定義報告中對每個事件進行更詳細的分析。

另一個可用於檢查將費用數據導入 Google Analytics 的標準報告是成本分析。

我們經常看到某些來源或廣告活動有費用但沒有會話的報告。 這可能是由 UTM 標籤中的問題或錯誤引起的。 或者，Google Analytics 中的過濾器可能會排除來自特定來源的會話。 這些報告需要不時檢查。

我們想強調允許您跟踪重複交易的自定義報告。 設置非常簡單：參數必須是交易 ID，關鍵維度必須是交易。

請注意，當報告中有多個交易時，這意味著有關同一訂單的信息被多次發送。

如果您發現類似問題，請閱讀這些有關如何解決問題的詳細說明。

Google Analytics 有一個非常好的自定義警報工具，可以讓您在不查看報告的情況下跟踪重要更改。 例如，如果您停止收集有關 Google Analytics 會話的信息，您會收到一封電子郵件通知。

我們建議您至少為以下四個指標設置通知：

• 會話數
• 跳出率
• 收入
• 交易數量

根據我們的經驗，這是最困難和最耗時的任務——錯誤最常見的窄線。

為避免 dataLayer 實現出現問題，必須每周至少進行一次檢查。 一般來說，頻率應該取決於您在網站上實施更改的頻率。 理想情況下，您需要在每次重大更改後測試 dataLayer。 手動執行此操作非常耗時，因此我們決定自動化該過程。

為了自動化測試，我們構建了一個基於雲的解決方案，使我們能夠：

• 檢查站點上的dataLayer變量是否與參考值匹配
• 檢查 Google 跟踪代碼管理器代碼的可用性和功能
• 檢查數據是否發送到 Google Analytics 和 OWOX BI
• 在 Google BigQuery 中收集錯誤報告

測試自動化的優勢：

• 顯著提高測試速度。 根據我們的經驗，您可以在幾個小時內測試數千個頁面。
• 獲得更準確的結果，因為排除了人為因素。
• 降低測試成本，因為您需要更少的專家。
• 增加測試頻率，因為您可以在每次更改站點後運行測試。

我們使用的算法的簡化方案：

當您登錄我們的應用程序時，您需要指定要驗證的頁面。 您可以通過上傳 CSV 文件、指定站點地圖的鏈接或簡單地指定站點 URL 來執行此操作，在這種情況下，應用程序將自行查找站點地圖。

然後為每個要測試的場景指定 dataLayer 方案很重要：頁面、事件、腳本（一系列操作，例如結帳）。 然後您可以使用正則表達式來指定頁麵類型與 URL 匹配。

在收到所有這些信息後，我們的應用程序會按計劃運行所有頁面和事件，檢查每個腳本，並將測試結果上傳到 Google BigQuery。 基於這些數據，我們設置了電子郵件和 Slack 通知。

PS 如果您需要全面的網站審核，您可以向 OWOX BI 請求諮詢服務。 註冊一個演示，我們將討論可能性。