行銷資料
把跨平台廣告資料變成每天自動更新的資料管線
Google Ads、Meta Ads、素材與名單資料進入同一套 BigQuery 架構,讓分析不再從人工匯出開始。
問題
廣告成效分散在不同平台,各自使用不同的帳號、欄位、更新節奏與歸因定義。人工匯出可以暫時做出報表,卻很難穩定重跑,也無法清楚回答某一天的資料缺漏是 API、權限、排程還是欄位變更造成。
限制
- Google Ads 與 Meta Ads API 有不同的驗證方式、配額、資料結構與更新時間。
- 權杖會更新或失效,平台欄位也可能在沒有同步發布週期的情況下改變。
- 公開案例不能呈現真實廣告花費、客戶名稱、活動名稱或素材內容。
我們做了什麼
先保留來源,再建立分析層
各平台資料先以可追蹤的來源結構進入 BigQuery,再由轉換層對齊共同維度與指標。
沒有選擇另一條路,因為 沒有在擷取時直接壓成一張通用報表,因為那會丟掉平台差異,也讓未來重算失去依據。
排程本身也是可觀測的系統
用 Cloud Workflows 協調每日工作,將平台擷取、素材處理與名單流程拆成可辨識的步驟。
沒有選擇另一條路,因為 沒有把所有工作塞進一支長時間執行的程式,因為單一步驟失敗時難以定位,也會增加重跑範圍。
以可重跑為前提寫入
資料以日期與來源範圍控制更新,讓同一批次重新執行時能得到一致結果。
沒有選擇另一條路,因為 沒有把成功假設成唯一情境而只做追加寫入,因為 API 暫時失敗後補跑會產生重複或缺口。
把權限與資料問題分開處理
工作流程保留驗證失效、配額限制與資料結構錯誤的不同失敗訊號,縮短判斷來源的時間。
沒有選擇另一條路,因為 沒有把所有 API 錯誤都當成同一種重試,因為權限失效不會靠等待自行恢復。
成果
- Google Ads 與 Meta Ads 資料依排程每日進入 BigQuery。
- 跨平台分析可從同一個查詢層開始,不再以人工匯出檔案作為前置步驟。
- 素材處理與名單擷取納入可追蹤的雲端工作流程。
技術
- Google Ads API
- Meta Marketing API
- BigQuery
- Cloud Workflows
回頭看
如果重來,我們會更早替資料新鮮度與欄位契約設下明確標準。資料有進來不代表資料可以用;延遲、回補與平台欄位變動都應該在報表被看見之前先被辨識。