Google、Meta、LINE 三大廣告平台的資料模型統一實戰

「把三個廣告平台的數據整合到一個畫面」——聽起來像是接三個 API 的工作，實際上八成的工夫花在一件事上：讓三套各說各話的指標定義，變成一套可以互相比較的語言。

這篇拆解我們為一家醫療產業廣告代理商實作三平台整合的技術決策。商業脈絡很簡單：操盤團隊每天在 Google Ads、Meta Ads、LINE Ads 三個後台之間切換，客戶要看成效只能等人工報表——而人工報表上的跨平台比較，其實從根本上就不成立。

問題的根：三個平台，三套世界觀

同樣叫「花費」「轉換」，三個平台講的不是同一件事：

• 歸因窗口：每個平台的轉換歸因規則不同——同一筆成交，可能被兩個平台同時算成自己的功勞。
• 幣別：帳號幣別設定不一，數字直接相加就是錯的。
• 時區：日報表的「一天」在不同平台可能切在不同時刻，跨平台的「昨日花費」根本對不齊。

把這三套數字直接放進同一張 Excel 比大小，得到的不是洞察，是誤導。

解法核心：統一指標語意層

我們的做法是在原始數據之上建一層統一語意層（semantic layer）：幣別統一換算、時區統一切齊、歸因口徑標準化之後，才進到報表和儀表板。

原始數據照存——語意層是「翻譯」，不是「竄改」。每一層數據都誠實標示它的深度與可信度，這是後來歸因數字能被客戶信任的前提。

先把數據地基打穩，AI 分析才有意義。數據不可信，AI 只是加速產生錯誤結論。

LINE Ads：沒有官方 SDK，就自己寫一個 client

Google 和 Meta 都有成熟的官方 API 生態，LINE Ads 則沒有官方的 Node SDK——文件裡只有 REST 規格和簽章要求。

我們自行實作了帶 JWS（HMAC-SHA-256）簽章的 REST client：每個請求自組 payload、計算簽章、掛上驗證標頭。這類「平台沒給路就自己鋪」的工作沒有捷徑，但做完一次，之後每日自動拉數就是純粹的例行公事。

三平台從此同一個節奏：每日凌晨自動同步，同步失敗會主動告警——不會靜默過期，讓客戶盯著三天前的數字做今天的決策。

時序資料：用連續彙總取代手刻 rollup

廣告數據天生是時序資料：每天進來一批，查詢永遠是「近 7 天」「近 8 週」這種區間彙總。

傳統做法是自己寫 cron job 定期跑 rollup、維護一堆彙總表。我們改用 PostgreSQL 時序擴充的連續彙總（continuous aggregates）：彙總視圖由資料庫自動增量刷新，不用自己排程、不用處理補跑邏輯，少一整類會在半夜壞掉的東西。

多租戶：內部看全部，客戶只看自己

代理商的儀表板有一個天生的權限需求：內部團隊要跨客戶看全局，每個客戶登入後只能看到自己的數據。

我們用資料庫層級的 Row Level Security（RLS）做多租戶隔離——權限規則寫在資料庫裡，而不是散在每一段應用程式碼中。配合 Google OAuth 與角色權限（RBAC），客戶自助入口和內部管理面板走的是同一套資料、不同的視野。

這一切的商業回報

技術決策落地之後，商業上的改變是：三平台數據、多客戶帳號，一個畫面看完，每日自動更新無需人工；再往上接預約與成交資料後，廣告花費第一次能對到實際成交金額——「真 ROAS」，而不是平台自己宣稱的轉換。完整案例在案例研究。

如果你的團隊也在多個廣告後台之間人工搬數字，或者你懷疑平台報表的「轉換」跟實際成交對不上——這個題目我們做過完整的一輪。

預約 30 分鐘免費流程診斷 →