如何輕鬆升級您的 Google Analytics 4 報告

已發表: 2023-03-16

Google Analytics Universal (GAU) 的用戶將不得不在 2023 年夏季切換到 Google Analytics 4 (GA4)。這樣做的主要問題是,與 GAU 相比,GA4 中的數據模型和指標計算邏輯截然不同。 切換到GA4後,部分歷史數據會保存在GAU結構中,新數據會保存在GA4結構中。 出於這個原因,企業必須認真評估轉換後的同比 (YoY) 指標(中級數據分析師至少需要 100 多個小時的工作)。

對於分析師來說,這意味著他們將日復一日地編寫和安排 SQL 查詢頁面,以實現 Google Analytics Universal 和 Google Analytics 4 指標之間的一致性。 但是,有一種方法可以解決這個問題! 分析師可以在幾分鐘內創建臨時報告,而無需不斷重寫 SQL 查詢,在本文中,我們將告訴您如何操作。

如果您需要幫助將報告更新為 Google Analytics 4 數據模式,請註冊觀看 OWOX BI 演示。 我們會以與您的業務相關的方式告訴您最好的方法。

預約演示

目錄

  • 將報告更新到 Google Analytics 4 時出現問題
  • 如何使用 OWOX BI 加速和簡化 Google Analytics 4 報告的更新
    • 什麼是數據模型
    • 什麼是數據建模
    • 為什麼需要數據建模
    • OWOX BI 如何與數據建模一起工作
  • 數據建模的優缺點
    • 優點
    • 缺點
  • 要點

將報告更新到 Google Analytics 4 時出現問題

Universal Analytics 將於 2023 年 7 月 1 日停用,並由 Google Analytics 4 取代。對於 Google Analytics 360(GA 的付費版本)的客戶,過渡期已延長至 2024 年 7 月 1 日。但無論您使用哪個版本的 GA,您的報告將更新為新的數據模式只是時間問題。

鑑於這種轉變,分析師面臨的最具挑戰性的任務之一是以統一格式提供來自 Google Analytics Universal 和 Google Analytics 4 的數據。

使此任務複雜化的情況:

  • GAU 和 GA4 的指標計算邏輯有很大不同。 值得注意的是,這些產品版本甚至以不同的方式計算傳統指標。 您不能將 GAU 和 GA4 中的所有指標拖到一張圖表中並期望一切順利。
  • Google BigQuery 數據模式也有很大不同。 Universal Analytics 使用基於會話的數據模式,而 Google Analytics 4 具有基於事件的數據模式。
  • 儀表板包括 YoY 指標和季節性趨勢。 所以問題是如何繼續使用包含所有這些指標的儀表板。

讓我們看一個具體的例子。 假設我們有這個儀表板:

具有數據范圍比較的儀表板
具有數據范圍比較的儀表板

此儀表板最關鍵的部分是季節性指標,它代表當前和過去時期的特定指標的比較。 歷史數據和運營數據必須採用相同的格式,以支持營銷儀表板上的同比指標。

在這種情況下,分析師面臨的挑戰是升級 N+ 遺留 SQL 查詢,以便為營銷團隊提供可靠的報告。 很難測試和調試可能受 SQL 查詢微小修復影響的所有內容。

數據分析師計劃在不破壞任何內容的情況下對一年前創建的 SQL 查詢進行小的修復
數據分析師計劃在不破壞任何內容的情況下對一年前創建的 SQL 查詢進行小的修復

還應考慮轉型風險。 將報告轉移到新來源(從 GAU 到 GA4)後,分析師可能無法解釋數據架構和指標計算邏輯中的根本差異。 例如,會話的形成方式不同:在 GA4 中僅考慮第一個用戶來源,而忽略導致會話的所有其他來源。 因此,報告中不會顯示某些流量來源。

起初,這可能會被忽視。 但在兩到三個季度內,不正確的儀表板將導致廣告支出效率低下,預算流失 30% 或更高。

準備和創建儀表板讓我們想起 Jenga。 每次他們需要更換報告中的一個塊時,分析師都會祈禱整個結構不會倒塌。

在 OWOX,我們已經成功解決了類似的問題,同時將我們客戶的報告從 Universal Analytics(或 GA 360)數據架構轉移到 Google Analytics 4 數據架構。 這就是為什麼我們想與我們的博客讀者分享我們的解決方案和一些 SQL 查詢。 希望這些信息可以幫助您輕鬆傳輸報告。

如何使用 OWOX BI 加速和簡化 Google Analytics 4 報告的更新

我們準備報告的方法(不管它們是為哪個業務領域創建的)是基於原始數據而不是建模數據。

什麼是數據模型

數據模型描述數據實體、它們的屬性以及實體之間的關係。 例如,對於給定會話,用戶在網站上的操作會合併,一個用戶可以在一個會話中進行多次在線轉換。

有四個對象——操作、用戶、會話和在線轉換——以及三個連接:會話和操作之間的一對多、用戶和在線轉換之間的一對多以及會話和在線轉換之間的一對多。在線轉換。

數據模型反映了我們對現實世界的看法,並回答了諸如我們的數據是關於什麼的問題。它有什麼關係?我們在處理數據時適用哪些條件和限制? 數據模型對於人們清楚地相互理解是必要的。

什麼是數據建模

數據建模是將數據轉換為滿足數據模型要求的格式的過程。

為什麼需要數據建模

  • 通過以下方式提高分析工作的價值和效率:
    • 加快報告結構和指標計算邏輯的變化
    • 降低支持報告和儀表板的成本
    • 簡化報告討論和批准
  • 通過以下方式提高報告中的數據質量:
    • 實現參數和指標計算邏輯時避免重複
    • 擁有一個數據層作為準確數據的來源

數據模型取代了眾多工具並描述了報表的邏輯,因為它描述了對象及其計算邏輯(對所有報表都有效)。

OWOX BI 如何與數據建模一起工作

OWOX BI 將原始數據轉換為分析就緒格式,為您節省數小時的數據準備時間。 它將 Universal Analytics 和 Google Analytics 4 數據無縫集成到您的報告中。

以下是基於 Google Analytics 數據構建的數據模型示例:

標準數據模型
標準數據模型

如您所見,有幾個對象,包括會話、事務、頁面和設備。

這裡最有趣和最重要的是,這些對象的結構不是相互關聯的,與數據源無關。 使用什麼來源來用實時數據填充這些對象並不重要(Matomo、Adobe、Google Analytics 等)。 無論數據源如何,模型都會返回與數據模型代表您的業務相同的對象。 它說明了您使用的真實世界對象和指標。

讓我們看看它在現實世界中的樣子。

您可以創建建模數據,而不是在原始數據之上編寫 SQL 查詢,例如從 Universal Analytics 導出的會話或從 Google Analytics 4 導出的事件。 它是頂部通用且易於理解的表格,代表現實世界中的對象和實體,例如會話、用戶和頁面視圖。

讓我們考慮具體的例子和數據模式。

這是原始數據的示例。 這些是 Google Analytics Universal(左)和 Google Analytics 4(右)的 Google BigQuery 數據模式的屏幕截圖。

來自 Google Analytics Universal 和 Google Analytics 4 的 Google BigQuery 數據架構

正如我們上面所寫的,數據模式不同。 我們需要找到一種方法將此數據鏈接到 Google Data Studio 儀表板。

根據我們的經驗,構建模型表是簡化數據準備的最佳方式。 它們看起來像這樣:

這些是來自上面數據模型的對象列表。 您可以看到對象列表對於 Google Analytics 360 和 Google Analytics 4 是相同的。

這意味著您可以使用相同的查詢將儀表板查詢與此數據連接起來。 這個查詢的結構是一樣的。

數據建模的優缺點

讓我們看看考慮基於建模數據而不是原始數據構建報告的重要原因。

數據建模的優缺點

優點

1.數據就像水果:必須先清洗再混合。 分析師從不同的服務和系統收集數據。 自然地,該數據的結構和格式因來源而異。 要構建報告,必須正確合併來自不同來源的數據。 通過連接器或各種 ETL 服務上傳的數據本身是不准確的(包含錯誤、重複和差異)並且缺乏統一的邏輯和結構。 必須清理不准確和零散的數據並將其規範化為分析就緒格式。

使用 OWOX BI,您無需手動清理、構建和處理數據。 該服務會自動將原始數據規範化為分析就緒格式。

2、你不需要為每個報表複製和重寫業務邏輯;例如,您不需要:

  • 刪除重複事務
  • 過濾機器人和內部流量
  • 定義渠道分組規則
  • 定義新用戶和回訪用戶的標準
  • 修復 UTM 參數跟踪

毫無疑問,每個數據分析師都聽到過來自營銷人員的這樣的要求:我們希望根據歷史數據調整或改進我們的渠道分組規則,或者我們希望確定新用戶和回頭客的標準,而不是按照它的工作方式在 Google Analytics 中,但以我們自己的方式,或者我們想考慮只返回那些在過去六個月內進行過購買的用戶。

如果您基於原始數據構建報告,則所有數據轉換和準備活動都必須在報告級別執行。 這意味著您必須花費大量時間將業務邏輯複製到每個報告中。

如果您在建模數據上構建報告,則不必復制業務邏輯。 您在建模階段創建一次。

3.基於建模數據構建報告可加快臨時分析。您可以節省編寫新 SQL 和編排轉換以啟用年度分析的時間。

4.由於數據建模,您可以為所有報告創建單一的真實來源。當您更改報表中的數據源時,您不再需要解決每個有問題的查詢。 您可以依賴此來源獲取會話、事務和事件數據。

5.簡化報告層。在建模數據之上構建報告比處理嵌套字段和記錄字段以及編寫一些窗口復雜函數甚至 JSON 提取函數更容易。

缺點

1.建模數據多了一個中間層。 調整需要時間,您還必須監控和調試建模數據。

2.用於規範化的複雜 JOIN。

3.額外的數據處理。為了以模型格式轉換數據,您必須查詢數據。 我們建議您在日期上使用分區表。 使用圍繞日期維度構建的分區表,您可以僅更新必要的數據。 您不必重寫所有巨大的表格,也不必為 Google BigQuery 中所有已處理的數據和千兆字節或千兆字節的數據付費。 您可以只升級和更新您需要的分區。 這種方法比處理所有數據表更經濟。

為了幫助您解決這些問題,我們準備了用於對 Google Analytics 360 和 Google Analytics 4 數據進行建模的 SQL 模板。 您可以通過下載本文提供的附加材料來檢查它們。

讀者獎金

適用於 Google Analytics 360 和 Google Analytics 4 架構的 SQL 模板

立即下載

要點

將您的報告更新為新的 Google Analytics(分析)4 數據架構有多容易? 使用建模數據。 您可以在 GA Universal 和 GA 4 架構之上創建通用且易於理解的平面表格,而不是基於原始數據構建報告。

這樣做將消除複製數據和將規範化邏輯插入數十個 SQL 查詢的需要。 您將在數據建模階段完成一次。 雖然不是對每個項目都是靈丹妙藥,但對於那些需要定期提交特別報告的項目來說,這是最佳方法。

如果您想設置和編排建模表,請註冊 OWOX BI 演示。 我們很樂意分享有關如何根據您的數據在您的項目中準備類似表格的詳細信息。

預約演示