身為產品經理,我很高興在日常工作中能夠依賴數據。我知道我可以順暢地工作,而不會因為缺少所需的洞察而被打斷。我的目標是透過為團隊提供所需的儀表板和有用的數據視覺化,來培養團隊的數據素養。這有助於我們保持在正軌上,並預先發現趨勢和效能變化。
但並非一直如此。
我過去常使用大型 Google 試算表,這些試算表超過 1 萬行,而且速度非常慢。我建立了大量的樞紐分析表來分析數據,但光是等待結果就花了我很長時間。
我透過學習 SQL 從中解脫。我與我的經理談過,並獲准測試 Google BigQuery 並獲得資料工程師的一些幫助。這為我們的自助式產品分析奠定了基礎。
我如何使用 Metabase 為我的產品團隊建立自助式分析
我目前的職責之一是弄清楚報告應該是什麼樣子以及如何建立它們。我們與資料工程師密切合作,準備所有基礎設施,讓我們的團隊做出數據驅動的決策。
我們在 Google BigQuery 之上設定 Metabase 作為我們的商業智慧工具。透過 API,我設定我們的第三方資料每天被擷取。有些資料仍然存在 Google 試算表中,但現在也已連接到 Google BigQuery。我也使用 dbt 來轉換所有原始資料以進行進一步分析。
以下是我遵循的步驟
-
確保每天擷取數據。
- 有些廣告聯播網透過 API 提供他們的數據(例如Audience Networks Ads API、Google Ad Manager API)。我使用 Google Cloud Function 排程每日運行,以將數據導入 Google BigQuery。
- 有些廣告聯播網要求我們從他們的後台或電子郵件下載數據。我沒有每天手動下載 CSV/XLS,而是使用 Python 腳本將 CSV/XLS 格式傳輸到 Google BigQuery。
- 我新增了測試作為監控,以檢查數據是否每天都在擷取。如果沒有,我會收到 Slack 頻道的警報。
-
準備數據轉換。
- 所有原始資料都以 Google BigQuery 中的
raw_XX
表格形式儲存(請參見下面的架構)。 - 有些表格是在連接到 Google BigQuery 的 Google 試算表中手動編輯的。這些是商業規則,例如,我們合作的廣告聯播網和我們新增的廣告單元。請參閱下面的
All_Adunits_v2
。
- 所有原始資料都以 Google BigQuery 中的
-
傳輸原始資料
- 我的目標是建立
report_adnetwork
和report_adrevenue
。report_adnetwork
整合所有原始資料和商業規則,以便輕鬆查看來自廣告聯播網的廣告單元的曝光次數。report_adrevenue
是 `report_adnetwork` 的延伸,因此我可以輕鬆比較來自所有廣告聯播網的廣告單元的曝光次數。
- 我的目標是建立
-
根據傳輸到 Google BigQuery 中的數據建立儀表板。
以下是結構:原始資料 → 按廣告聯播網分類的表格 → 按廣告收益分類的表格
最終表格顯示不同時期的收益。有了這個表格,我的團隊可以從不同角度分析數據:按平台、按廣告聯播網、按廣告單元等。
對於許多專案,我使用 Metabase 和 Google Data Studio 來幫助我。我的團隊非常喜歡使用 Metabase 儀表板訂閱功能,該功能將報告發送到我們公司的 Slack 頻道,並將最重要的指標呈現在我們面前。我們也將 Data Studio 用於我們的一些自助式儀表板。
即使我花了幾個月的時間學習和建立儀表板,它也幫助我的團隊更好地了解我們的效能。
作為產品經理,以下是我在儀表板的幫助下追蹤的內容
- 我們進階方案的顧客獲取漏斗:我的團隊可以看到有多少使用者註冊、試用進階功能並轉換;
- 進行中的實驗:我們執行 A/B 測試並監控其效能。我通常在實驗啟動前建立儀表板,以實現順暢的追蹤流程;
- 使用者旅程:我的團隊監控我們的使用者在主要路徑上的表現。
儀表板幫助我的團隊變得更有效率
- 設計師開始分析哪個步驟可能導致使用者感到阻力;
- 工程師開始執行更多實驗;
- 其他部門也採用了這種思維模式,因為他們有理由追蹤他們的專案的執行情況;
作為產品經理,我從這種數據驅動的方法中受益匪淺。當出現任何對話時,我可以快速提取所有需要的資訊並做出深思熟慮的決策。
最好的事情是數據本身會說話,並團結團隊。當我們執行實驗時,我們都會看到它們的執行情況,而且我們不再花時間爭論它。