Google Analytics App + Web – 詳細了解新功能

最近，Google 推出了一項新的 App + Web 功能，允許您將來自網站和移動應用程序的數據合併到一個 Google Analytics（分析）屬性中。 對於希望跨不同平台跟踪和分析用戶行為的公司來說，這一新功能應該會讓生活變得更輕鬆。

目前，App+Web 處於 beta 測試階段，肯定會進一步開發和完善。 但是，我們已經對其進行了測試，檢查了它的數據結構，並嘗試了內置的導出到 Google BigQuery 功能。 我們渴望與您分享我們的第一印象。

在標準的 Google Analytics 中，一切都是圍繞會話構建的。 App + Web 則背離了這一點，使用了基於事件、參數和用戶的數據模型。 原則上，它使用與 Google Analytics for Firebase 相同的數據方案並具有相同的功能，只是補充了新功能。

一方面，這種方法將使產品分析師的工作更輕鬆，因為來自網站和應用程序的數據將以相同的格式收集。 另一方面，由於新的結構和數據處理邏輯，現有的報表將需要重做。

App + Web 的測試版使用事件參數和用戶屬性，而不是點擊、會話、產品和用戶級別的通常自定義參數。 乍一看，這似乎限制了您的能力。 事實上，只有用戶級別和命中級別的選項仍然可用。 此外，尚不清楚是否有必要為現有的自定義跟踪（例如自定義維度）開發和實施單獨的指標系統。

我們很高興看到增強測量 - 一個很酷的選項，無需向您的網站添加新標籤。 除了事件（在 App + Web 中自動收集）之外，您還可以跟踪頁面查看和滾動、點擊、站點搜索、視頻查看和文件下載。 要配置他們的跟踪，只需激活資源設置中的選項。

如果您使用的是 SDK 或 gtag.js，您可以使用 App + Web 來收集一些用戶屬性，而無需向您的網站添加任何額外的代碼。 例如，您可以收集人口統計數據、設備品牌、設備型號和類型、用戶語言和用戶興趣。 這些屬性可用作報表中的受眾和常規過濾器的參數。

另一個 App + Web 獎勵是自定義銷售漏斗報告（又名“特殊漏斗”），以前僅適用於 Google Analytics 360 用戶。

此外，在新的 App + Web 屬性中，此報告提供了更多機會。 例如，現在最多可以使用十個步驟，而不是五個步驟。 您可以設置步驟之間的時間限制，使用可選步驟等。這種靈活的設置將幫助您確定轉換的重要步驟，並在不使用第三方工具創建報告的情況下找出用戶在漏斗的哪個階段迷路。

熟悉的實時報告在 App + Web 中被 StreamView 功能取代。 一方面，它提供了更詳細的信息：您可以看到更多關於在過去半小時內訪問過您的站點或應用程序的用戶的數據。 另一方面，StreamView 不提供 Google Analytics 中實時可用的流量來源數據。

DebugView 工具也從 Firebase 遷移到了 App + Web，這極大地簡化了測試並為網站引入了新功能。

與標準的 Google Analytics 相比，App + Web 對設置以及事件和參數的數量和名稱有更嚴格的限制。

例如，在 App + Web 中，您可以使用：

• 最多 500 個唯一事件（不包括自動事件）（事件名稱最多 40 個字符）
• 最多 15 個轉化事件（類似於 GA 中的目標）
• 每個事件最多 25 個參數（傳輸參數值最多 100 個字符）
• 多達 25 個用戶屬性
• 最多 50 位觀眾

此類限制可能會干擾大型和中型公司的運營，這些公司擁有收集許多附加參數的大型站點。 例如，對於具有大量微轉化的企業來說，十五個轉化事件是不夠的。

App + Web 界面更像 Firebase，而不是標準的 Google Analytics，因此您不會找到一些對營銷人員很重要的報告。 例如，沒有流量來源、成本分析、電子商務或網站搜索的報告，沒有廣告渠道分組等。

廣告費用數據和線下數據也仍然無法上傳到 App + Web 中。 並且無法調整會話的持續時間，默認為 30 分鐘。 或許當 App + Web 結束 beta 測試時，其中的一些功能就會出現。

到目前為止，App + Web 還沒有與 Google BigQuery 直接集成：數據是通過 Firebase 上傳的，此功能僅適用於 Blaze 計劃的客戶。 也就是說，上傳的數據可能是未採樣的，但您必鬚根據數量為數據處理支付額外費用。

至於上傳時間，每15分鐘將當天的事件數據加載到中間表中（流導出）。 每天一次將完整數據導出到單獨的表，然後刪除中間表。

目前，App + Web 的上傳結構與 Firebase 的上傳結構相同。 在這方面，很可能表中的數據是根據 Firebase 邏輯進行處理的。 從字段的描述來看，上傳數據時，首先將用戶帶到應用程序（或網站）的來源、渠道和活動都記錄在 BigQuery 表中。 對於歸因，在 traffic_source 字段中使用了最後點擊（多渠道）模型。

進行了測試上傳後，我們注意到源、媒體和活動也與事件參數一起傳輸，但不是與所有事件一起傳輸（我們尚未找到任何官方信息，但我們假設它們已傳輸瀏覽量和/或轉化事件）。 使用哪種歸因模型尚不清楚。

Firebase 中的歸因細微差別：

• 歸因數據僅適用於轉化事件。
• 當沒有關於來源、媒介、廣告系列、廣告網絡類型或創意的數據時，來源中的（未設置）標記會出現。
• Firebase 中的轉化時間範圍無法更改：安裝時間為 30 天，重新參與時間為 180 天（應用內轉化）。

不僅對廣告渠道的評估，銷售計劃的執行也取決於您使用的歸因模型。 理想情況下，歸因模型應該在下單前考慮到鏈中各個渠道的客觀貢獻，結合線上和線下數據，並具有透明的計算邏輯。 OWOX BI Attribution 完成了所有這些工作。

使用 OWOX BI Attribution，您可以評估您的活動對您網站和實體店銷售的貢獻，並有效分配您的廣告預算。

借助 App + Web，Google 改變了在 Google Analytics 中構建報告的方法。 這個新屬性使用基於事件及其參數的數據模型。 因此，上傳到 Google BigQuery 的數據格式發生了變化。

總的來說，App+Web 的功能還是比較粗糙的。 但該產品處於測試階段，Google 團隊正在計劃更改和改進。 許多標準 Google Analytics（分析）用戶熟悉的報告、設置和功能在這種新的媒體資源類型中尚不可用。

那麼你現在應該切換到 App + Web 嗎？ 在標準的 Google Analytics 中停止收集數據絕對不值得。 最好嘗試這兩種方法並比較它們的數據模型和報告。

希望在單一界面中分析其應用程序和網站數據的公司會喜歡 App + Web。 它可以讓您了解哪些廣告渠道和哪些平台最能吸引新用戶並帶來更多轉化。

由於數據以不同的、更簡單的結構從 App + Web 上傳到 Google BigQuery，因此產品分析師需要擔心的嵌套字段更少。 因此，使用 SQL 查詢更加方便。

通過此次更新，Google 簡化了收集數據並將其從 Google Analytics 傳送到 Google BigQuery 的過程，適用於準備顯著改變其報告結構和網站上的指標系統的項目

• 由於 App + Web 還沒有關於流量來源和成本分析的標準報告，營銷人員將很難使用它來評估廣告活動的有效性——找出特定來源帶來了多少會話，比較 ROAS所有頻道等
• 關心從 Google BigQuery 獲取實時、原始、非抽樣數據的企業
• 將大量自定義參數從其網站傳輸到 Google Analytics 並希望針對這些參數構建 Google BigQuery 報告的公司也不會受益。
• 此外，App + Web 不適用於希望上傳到 BigQuery 並在報告中使用交易數據的項目，也不適用於希望在漏斗中考慮用戶的每一步並誠實評估廣告渠道而不給出所有價值的公司用於在訂購前轉換到最後一個頻道。

然而，並不是所有的事情都如此悲傷。 您仍然可以使用 OWOX BI 或 BigQuery 導出功能來完成所有這些事情，該功能在 Google Analytics 的付費版本中可用。 您可以在我們關於 OWOX BI 與 Google Analytics 360 的不同之處的文章中詳細了解這兩種方法的功能、優缺點。

如果您需要幫助設置網絡分析並為您的業務創建單獨的度量系統，請發送電子郵件至[email protected] 或填寫我們網站上的聯繫表。