Glia Ad Network
產品與資料模型導覽

換句話說：媒體不需要自己去談廣告、串接十幾個廣告平台的 SDK，把 GliaCloud 的播放器嵌進頁面，GliaCloud 就代為處理廣告競價、政策合規（ads.txt / sellers.json）、營收拆帳與付款。這是一個典型的 video ad network（影音廣告聯播網）商業模式：對媒體是「一站式影音變現」，對廣告主／廣告平台是「一個可以買到大量優質影音版位的供應商」。

錢的流向，由右到左依序被切分：

結算與付款是月結、以 Agency（對外簽約單位）為單位進行：

整個系統可以看成一條由「誰付錢」到「誰收錢」的階層鏈。上層是商業/合約關係，下層是實際發送廣告請求的技術單位：

每一層在系統裡負責的事情不同，整理如下：

以下依「使用者打開頁面、播放器實際發送廣告請求」的即時發生順序來寫。

1. 決定用哪個 SlotSetting 版本

一個 Slot 底下可能同時存在好幾個 SlotSetting 版本：一個當作 control（現行版本），其他是 ExperimentSetting（實驗組），各自帶一個 traffic 權重（0～100）。Slot 發布給 player 的設定（Slot.entity_model）會把 traffic > 0 的版本全部列出來，player 載入頁面時依權重從這份清單挑一個版本來服務這次瀏覽——挑到哪個版本，接下來就照那個版本當下已經算好的 ad unit 順序繼續往下走。

2. Waterfall（廣告序列播放機制）

一個版位（Slot）底下的 SlotSetting 可以同時掛好幾個 demand 通路（AdUnit），每個 AdUnit 依 priority 排出順序、分組（groupId）。播放器初始化後會依序試打廣告請求：先打優先權最高的一組，該組沒有廣告回應（no fill）才往下一組打，逐層往下——這就是「waterfall」名稱的由來。播放時機（waterfall_mode：interval／pre-roll／mid-roll）、每輪間隔秒數，以及最多試幾輪（maxRounds/maxFalls）都可以設定。

3. 輪到 Prebid AdUnit 時：Header Bidding

waterfall 裡有一種 AdUnit 類型是 Prebid（GamPrebidVideoAdUnit／StandardPrebidVideoAdUnit 等）：輪到它那一組時，會同時向多個 SSP／DSP（Magnite、Openx、InMobi 等）發起即時競價，出價最高者成交——同一組裡原本要一個個問的多家 demand，改成同時比價，避免漏接願意出更高價的買家。

4. 輪到 GAM AdUnit 時：Google Ad Manager 與 MCM

waterfall 裡另一種常見的 AdUnit 類型會直接打 Google Ad Manager，由 GAM 依 LineItem／底價決定播出哪支廣告。Glia 同時營運兩個獨立的 GAM 網路，各自也跑一套 MCM（Multiple Customer Management），代表規模不足以自己申請 AdX／GAM 的「child publisher」去賣廣告版位：

MCM 媒體要先通過一套上線審核，才會有 demand 可以打——審核流程跟卡關會怎樣，寫在「合規與監控機制」一節。

版位自動優化，指的是系統自動調整版位設定（廣告排序、要不要繼續跑某個設定）來提高營收，而這件事是透過實驗系統做到的。實驗系統是用真實流量做 A/B 測試的機制：把一個版位的一小部分流量分給新設定（實驗組 ExperimentSetting），其餘留在現行設定（control），兩邊同時跑、直接比營收成效。實驗組的設定會由以下兩個排程任務依成效數據持續自動調整：

Yield 優化（自動排序演算法）

排程任務 ad.tasks.UpdateDynamicExperimentAlgorithm（cron id 40）會套用掛在 ExperimentSetting 上的 ExperimentFunction——一段後台可編輯的排序演算法，依歷史 RPM／eCPM 把 ad units 重新排序，讓歷史表現好的通路排前面優先搶單，也可以排除掉後段低效的通路（要不要排除、門檻多少都是演算法程式碼裡自己決定，因實驗而異）。目標很單純：在每一次曝光上，盡量賣到最高的價錢。這個排程多久重跑一次，就在上面 cron id 40 那筆記錄裡調整。

停損檢查（Auto-pause）

排程任務 ad.tasks.UpdateExperimentTraffic（cron id 41）會比較每個 ExperimentSetting 跟它 control 在同一段觀察期的 RPM／CPM 等指標：每個實驗組可以設定 AutoPauseCondition（累計自實驗開始，或只看最近一天，門檻在後台設定），一旦成效比 control 差到觸發門檻，系統就自動把該實驗組的 traffic 砍到 0（停用，不會再被挑中服務任何頁面瀏覽），並發 Slack 通知。

最核心的事實表是 Performance，一列資料的顆粒度是：

更細顆粒（per ad unit）的 AdUnitMetric 才有現成算好的 eCPM、RPM、fill_rate 欄位；Performance 本身不存這些比率，要自己用 revenue／impression／request 算。

資料怎麼進來的：兩段式匯入

這 60+ 家 driver 涵蓋 Google GAM/AdX、日本／東南亞區域型影音聯播網（FreakOut、Fluct、Aniview）、Prebid 供應商（Magnite、Openx、InMobi）、以及多家歐洲／全球型影音聯播網（Sparteo、SmartAdServer、ShowHeroes）——反映 GliaCloud 是一個橫跨多國市場、同時對接 waterfall 與 header bidding 的區域型影音聯播網。

月結時，先在 Channel 層算淨營收：net_revenue = gross_revenue × share / 100。同一個 Agency 底下所有 Channel 的淨營收加總後，系統自動產生一張 PaymentNotice（每個 Agency 每月一張）。若加總金額低於該 Agency 設定的 min_payment 門檻，就不會觸發付款，金額會累積到下個月。

為什麼有三間法人？

每個 Agency 綁定一個 contract_entity，決定用哪個法人簽約、開哪一種付款模板（幣別／稅務格式）——目的是讓海外媒體的合約與付款不必全部走台灣公司，簡化跨境稅務與匯款流程。

Rebate（回溯調整）

部分 Agency 有「上月總 gross revenue 達到某個級距，就退一定比例回饋金」的自動 rebate 設定（金額級距 → 回饋 %），每月結算時會反推回「分潤前」金額計算，確保分潤（share）套用後金額仍然正確。

ads.txt／sellers.json 是 IAB 制定的反詐騙標準，用來對抗「假冒媒體賣廣告版位」：ads.txt 由媒體自己公開宣告「哪些廣告平台有權賣我的版位」；sellers.json 反過來，由廣告平台公開列出「我代理哪些賣方」。廣告主的競價系統下單前會核對兩者是否對得起來——對不起來，廣告平台就悄悄不出價，不會報錯，只會讓某個 demand 的營收無聲無息掉到 0。這也是為什麼系統有一整組自動檢查，各自的執行頻率都在後台 Cron 設定裡調整（連結見下表各筆）：

此外，GamViolation 會匯入 Google 寄來的政策違規報告，追蹤哪些站台／頁面被 Google 停止投放（政策違規、可疑流量等），提供 AM 主動處理。

MCM 媒體上線審核

媒體要能真正吃到 MCM demand（見「廣告投放機制」一節），得先通過一套審核流程，一關卡住就沒有 MCM 營收：

1. 邀請（Invitation）：Glia 發出 MCM 邀請，媒體接受
2. Google 帳號審核：Google 端做身份與地址驗證（ID verification／mail PIN）
3. 網站審核（Site approval）：媒體的每個網域都要單獨送審，通過 AdX 政策檢查
4. Readiness：帳號、網站、驗證都過了，狀態才會變成 READY，這時才真的能吃到 AdX demand

這是分析媒體「為什麼這個月營收突然跟其他 slot 落差很大」時第一個該查的地方。