ti-tech-ads

剩餘流量 GAM-native 變現聯播網｜Network 23315141024

運作流程簡報 v1.0
整體架構 — 巢狀雙層 GAM 瀑布
我方 ti-tech 層夾在「Publisher 直售/高價之後、Publisher 自家 AdX 之前」；以 friendly iframe 承接流量，內嵌我方 GAM 做二次仲裁。
外層 Publisher GAM
我方 AdTag (friendly iframe)
內層 我方 Ti-Tech GAM
填充成功
Passback 交還
Publisher 網站 GPT (Google Publisher Tag) 發送廣告請求
↓
外層：Publisher 自家 GAM（例：LTN GAM）
1
最高優先 直售 / 高價 Line Items → 填充 → 直接渲染，流程結束
未填充，waterfall 往下
2
我方 LI-1（Network 優先） ti-tech Line Item — Publisher 自建
優先序介於直售與 Publisher AdX 之間
Friendly Iframe → https://tiads.ti-tech.ai/ad-tag.html
AdTag 載入後，在 iframe 內 defineSlot 到我方 network，並啟動 Prebid 競價：
內層：我方 Ti-Tech GAM（Network 23315141024 / ti_prebid_display）
DEMAND A
Prebid (Teads)
HB Line Item
ta_pb_X
VS
DEMAND B
我方 AdX
Open Auction
Backfill
我方 GAM 仲裁 → 出價較高者勝出
填充成功
渲染廣告 + 寫 KV 歸戶 (refresh_site_id / refresh_pairing_id)
全 No-fill
AdTag 執行 Publisher 指定的 passback code（per-publisher 配置）
passback code 執行後，Publisher 指定的 fallback 變現接手（與我方 AdX 循序，非同時競價）
3
Publisher Fallback Publisher 指定的 Passback 變現 → 接手，曝光交還 Publisher
AdSense GAM Passback 第三方 JS — onboarding 時 per-publisher 配置
重要政策設計
循序競價
我方 AdX 與 Publisher AdX 為 passback 後的循序競價，非同時競價，避免雙 AdX 政策衝突
不碰 Publisher GAM
Publisher 自建 LI-1 指向我方 AdTag；我方只佈建自家 network 資源
Send Top Price
Line item 只綁 hb_pb（最高出價）；hb_bidder 僅作報表維度拆帳
📥

情境 1 — Publisher 未填充，進入我方系統

Publisher 直售/高價 line items 全數未填充，waterfall 落到我方 LI-1，觸發我方變現流程

1
Publisher 網站發送廣告請求
網頁透過 Google Publisher Tag (GPT) 對 Publisher 自家 GAM 發送 ad request。
2
Publisher GAM 依 waterfall 優先試填直售 / 高價
Publisher GAM 從最高優先的直售、固定 CPM 高價等 line items 開始嘗試填充。
本次情境：直售/高價全數 未填充（庫存量不足 / 無匹配條件）
3
Waterfall 落到我方 LI-1（Network 優先）
Publisher GAM 選中我方建立的 line item，優先序介於直售之後、Publisher 自家 AdX 之前。
Priority: Network Publisher 自行 Traffic
4
Creative 載入我方 AdTag（Friendly Iframe）
LI-1 的 creative 為一段 HTML，在 friendly iframe 內載入：
https://tiads.ti-tech.ai/ad-tag.html
Friendly iframe 與父頁面同源，允許 postMessage 雙向通訊，passback 訊號可穿透
5
AdTag 啟動：同時發起 Prebid 競價 + 呼叫我方 Ti-tech GAM
AdTag 在 iframe 內執行兩件事：
Prebid requestBids
呼叫 Teads adapter 發起競標
我方 GPT defineSlot
到 ti_prebid_display ad unit
6
進入我方 Ti-tech GAM 仲裁層
Prebid 競價完成後，設定 targeting，送入我方 GAM（Network 23315141024）進行仲裁：
DEMAND A
Prebid (Teads)
HB line item ta_pb_X
VS
DEMAND B
我方 AdX
Open Auction Backfill
情境繼續到情境 2（Prebid 贏）或情境 3（AdX 接手）或情境 4（全 no-fill）
📡
進入我方變現層 Publisher 流量已由 ti-tech 系統接管，開始 Prebid(Teads) vs 我方 AdX 仲裁。後續結果見情境 2 / 3 / 4。
🏆

情境 2 — Prebid (Teads) 贏得我方 GAM 仲裁

Teads 在競價中出價最高，我方 GAM 選中 Prebid HB line item，由 Teads 廣告填充並拆帳歸戶

1
AdTag 執行 Prebid — Teads 出價
AdTag 內的 Prebid.js 向 Teads bidder 發起競價，Teads 回傳出價 hb_pb = X（price bucket）。
pbjs.requestBids() teadsBidAdapter
2
設定 Prebid Targeting — Send Top Price
Prebid 競價完成，呼叫 setTargetingForGPTAsync，將最高出價設到我方 ad slot targeting：
hb_pb = X hb_bidder = teads（報表維度）
採 Send Top Price 策略：line item 只綁 hb_pb，hb_bidder 僅用於拆帳報表，不影響仲裁
3
我方 Ti-Tech GAM 仲裁：Prebid 出價 > AdX 出價
我方 GAM（23315141024）比較 Prebid HB line item（ta_pb_X）與我方 AdX 的競爭出價。
Teads $X
Prebid HB (ta_pb_X)
>
AdX $Y
Open Auction
→ Teads 勝出
4
Universal Creative → pbjs.renderAd() 渲染 Teads 廣告
我方 GAM 選中 Prebid HB line item，載入 universal creative，呼叫：
pbjs.renderAd(doc, '{{AUCTION_AD_ID}}')
Teads 廣告素材在 iframe 內完整渲染，Publisher 版面正常顯示廣告
5
曝光歸戶 + 拆帳 KV 寫入
廣告渲染同時，寫入歸戶 KV，供 GAM Report API 拆帳：
refresh_site_id = <publisher_site> refresh_pairing_id = <ad_unit_instance>
GAM Report API 以 KV dimension 計算各 Publisher 分潤；tag instance ID 防止 tag 複製/錯放導致拆帳錯誤
🟢
靠 Teads 變現 Teads 廣告填充，曝光收益歸我方。KV 寫入完成，GAM Report 可拆帳給對應 Publisher。
📈

情境 3 — Prebid 未贏 / 無出價，我方 AdX 接手

兩種子情境：A）AdX 出價更高；B）Prebid 完全無出價。最終皆由我方 AdX 填充

情況 A Prebid 有出價，但 AdX 出價更高
Teads 回傳出價 $Y，但我方 AdX 在 Open Auction 出價 $Z > $Y。
我方 GAM 仲裁時 AdX 勝出，Prebid line item 落敗。
Teads $Y
<
AdX $Z 勝出
情況 B Prebid 完全無出價
Teads 本次未競標（庫存缺失、targeting 不符、timeout 等）。
我方 GAM 只有 AdX Open Auction 參與競價，AdX 直接接手填充。
Teads — no bid
→
AdX 唯一競標，直接填充
1
Prebid 競價結束 — Teads 未勝出（情況 A）或無出價（情況 B）
情況 A：hb_pb = Y 但低於 AdX 出價｜情況 B：Prebid 無任何有效出價
2
我方 Ti-Tech GAM 仲裁：AdX 勝出
我方 GAM（23315141024）進行仲裁：AdX Open Auction 出價 > Prebid 出價（或 Prebid 缺席）。
AdX Backfill 委刊項 Open Auction 接手填充
3
我方 AdX 渲染廣告
我方 Ti-Tech GAM 由 AdX 填充，廣告在 friendly iframe 內渲染。Publisher 版面正常顯示廣告。
我方 AdX（23315141024 關聯）與 Publisher AdX 為循序競價（此時 Publisher AdX 尚未進場），符合 Google 政策
4
曝光歸戶 + 拆帳 KV 寫入
同情境 2，寫入歸戶 KV 供 GAM Report 拆帳：
refresh_site_id refresh_pairing_id
🟠
靠我方自家 AdX 變現 我方 AdX 填充，曝光收益歸我方。與 Publisher AdX 循序非同時，無雙 AdX 政策衝突。
🔄

情境 4 — 我方 GAM 全 No-fill，Passback 交還

Prebid 無出價且我方 AdX 也無填充，發出 passback 訊號，曝光安全交回 Publisher，不損失

1
Prebid 無出價 且 我方 AdX 也無填充
Teads 本次無競標，我方 AdX 在 Open Auction 也無符合出價——兩個 demand 同時缺失。
Teads
no bid
我方 AdX
no fill
2
我方 Ti-Tech GAM 偵測 isEmpty → 觸發 Passback
GPT slotRenderEnded 事件偵測 isEmpty = true，AdTag 立即觸發 passback 流程。
3
AdTag 取出該 Publisher 預先配置的 Passback Code
我方 AdTag 讀取 onboarding 時與該 Publisher 綁定的 passback 設定（與 KV 一起 per-publisher 配置）。Passback code 由 Publisher 在上線時指定，三種形態皆支援：
AdSense Code
Google AdSense 填充
GAM Passback 代碼
Publisher 自家 GAM
第三方 JS
任意 JS 變現代碼
Publisher-agnostic：什麼 passback code 都接；onboarding 時由 Publisher 指定，與 refresh_site_id / refresh_pairing_id 一起 per-publisher 配置
4
AdTag 在 Slot 內執行 Publisher 指定的 Passback Code
AdTag 直接在版位內執行該 passback code，不依賴 postMessage 或 Publisher 頁面監聽——passback 行為完全由我方 AdTag 自主完成。
每個 Publisher 的 passback code 各自不同，可能指向不同 demand 來源；我方 AdTag 保存並在 no-fill 時忠實執行
5
Publisher 自家 Fallback 變現接手填充
Passback code 執行後，Publisher 指定的 fallback 變現（AdSense / Publisher GAM / 第三方）接手版位填充，廣告正常渲染。
關鍵政策點：我方 AdX 已退出本次競價後，Publisher fallback 才接手——兩者循序，非同時競價。不碰 Publisher AdX 政策，符合 Google 雙 AdX 規範。
🔴
曝光交還 Publisher 自有變現 — 不損失 我方讓出本次填充機會，AdTag 執行 Publisher 指定的 passback code，Publisher 自家 fallback 接手渲染，曝光不浪費。
Passback 架構示意（per-publisher 配置）
我方 Ti-Tech GAM
isEmpty = true
→
AdTag (iframe)
讀取 per-publisher passback code
→
在 Slot 內
執行 passback code
→
Publisher Fallback
填充 / 曝光交還
Passback code 型態（Publisher 指定，onboarding 時配置）：
AdSense Code GAM Passback 代碼 第三方 JS
與 refresh_site_id / refresh_pairing_id 一起 per-publisher 配置，彼此獨立，支援任意 demand 來源
🔄

AdRefresh 運作 — 每一輪刷新都重新競價

我方 AdTag bundle 內含 AdRefresh，廣告渲染後自動啟動，以「重新走完整競價流程」放大同一版位的曝光次數

AdRefresh 定位
AdRefresh 硬編進我方 AdTag bundle，無需 Publisher 額外整合。廣告成功渲染後自動啟動，在同一版位連續觸發刷新， 每一輪刷新都重跑完整的 Prebid 競價 + 我方 GAM 仲裁，等同於多次首次填充——放大剩餘流量變現效益。
核心機制
Own-slot 模型
只刷新我方自己的 slot
刷新操作完全在 我方 friendly iframe 內，不碰 Publisher 容器，不影響 Publisher 頁面框架。 ti-tech 巢狀 iframe 架構天生符合 own-slot 原則。
Viewability Gating
版位在可視範圍才刷新
使用 IntersectionObserver 偵測版位可見度，只在版位可見時才觸發刷新計時器，確保有效曝光、符合廣告政策。
Refresh Declaration 合規
≥30s 間隔 + maxRefreshes 上限
刷新間隔 ≥ 30 秒（Google 政策下限），並設定 maxRefreshes 上限；在 GAM 創意層聲明 refresh declaration，完全合規。
拆帳歸戶
每輪帶 KV，正確歸戶
每一輪刷新的 ad request 都帶 refresh_site_id / refresh_pairing_id，刷新曝光正確歸戶到對應 Publisher / 版位，防止 tag 複製錯帳。
★ 每輪刷新 = 重跑完整競價流程
以下循環在每次 refresh 觸發後完整重走一次，與首次填充邏輯完全相同
刷新循環（至 maxRefreshes）
A
廣告渲染完成 — AdRefresh 啟動
首次或上一輪刷新後廣告成功渲染（情境 2 / 情境 3 任一），我方 AdTag 內的 AdRefresh 啟動監聽。
情境 2：Teads 填充 情境 3：AdX 填充
B
Viewability 偵測 + 計時 ≥30s
IntersectionObserver 確認版位在可視範圍後，計時器啟動。達 ≥30 秒後才觸發下一輪刷新。
版位離開可視範圍時計時暫停；回到可視範圍後繼續，保障有效曝光品質
C
★ 重新執行完整 AdTag — 重跑 Prebid 競價 + GAM 仲裁
這是每輪刷新的核心：完整重走首次填充的所有邏輯，Teads 與我方 AdX 每輪都重新競爭最高價。
DEMAND A — 重新出價
Prebid（Teads）
重新發 bid request → 取得新 hb_pb
VS
DEMAND B — 重新競價
我方 AdX
Ti-Tech GAM Open Auction
↓
我方 Ti-Tech GAM 重新仲裁（與首次填充相同邏輯）
情境 2 邏輯：Teads 出價最高 → 渲染 情境 3 邏輯：AdX 接手 → 渲染 情境 4 邏輯：全 no-fill → 停止刷新
每一輪都是一次全新競價，最大化每次刷新的 yield
D
新廣告渲染 + KV 歸戶
最高出價者勝出，新廣告渲染到版位。每筆 refresh ad request 都帶 KV，刷新曝光正確歸戶。
refresh_site_id refresh_pairing_id
E
檢查 maxRefreshes 上限
計算本輪是否已達 maxRefreshes。未達上限：回到步驟 A，繼續下一輪刷新循環；達到上限：停止刷新，版位保持最後一次渲染的廣告。
↩
未達 maxRefreshes → 回到步驟 A，繼續下一輪（≥30s 後）
🔄
每一輪刷新 = 一次全新競價，最大化剩餘流量 yield Teads 與我方 AdX 每輪都重新出價，我方 GAM 每輪都重新仲裁，填充邏輯與首次完全一致。刷新不是「只刷 AdX」，而是每次都走完整的多 demand 競爭。
★ 刷哪些版位 — 兩種 Inventory 來源
每輪 refresh 觸發後，以下兩種來源的版位都會收斂成「刷我方 ad unit → 重跑完整 Prebid + GAM 仲裁」
來源 1 我方已填充的版位
情境 2（Teads 填充）或情境 3（我方 AdX 填充）成功渲染後——AdRefresh 在同一版位繼續刷新，每輪都重跑 Prebid + GAM 仲裁。

入場前提：Publisher 已完成 First-fill LI 整合（情境 1 進場路徑）
情境 2 填充後 情境 3 填充後
來源 2 白名單內的 Publisher Line Items / Ad Units
即使首次是 Publisher 自己的 creative 填充的版位，只要在白名單內，AdRefresh 偵測到後——下一輪刷新時由我方 takeover 接手，載入我方 AdTag，重跑完整競價。
白名單 LI / Ad Unit Takeover 接手
兩種來源在 refresh 時都收斂成同一路徑：
刷我方 ad unit → 載入我方 AdTag → Prebid（Teads）競價 + 我方 Ti-Tech GAM 仲裁 → 依結果走情境 2 / 3 / 4 邏輯
Publisher 控制 / 信任機制
白名單 Gating
只刷 allowed 的版位
只有在白名單內的 line items / ad units 會被我方 takeover 刷新。Publisher 的直售、Premium、不想被刷的版位，不在白名單就不碰——Publisher 完全保有控制權，隨時可調整白名單範圍。
Own-slot 非破壞性
不 Destroy Publisher 的 Slot
Takeover 使用我方自己的 ad unit / 容器刷新，不 destroy、不覆寫 Publisher 的 slot——Publisher 頁面框架結構完全不受影響，安全無副作用。
★ 兩條進場路徑 — AdRefresh 是獨立的低門檻路徑
A
First-fill LI 整合
前面 4 情境的進場路徑
Publisher 在自家 GAM 建立 line item（LI-1），指向我方 AdTag creative。Publisher 直售/高價未填 → waterfall 落到 LI-1 → 我方接管。

整合深度：Publisher 需在 GAM traffic 我方 LI，設定 priority、targeting、creative。
情境 1–4 需 GAM LI 整合
B
AdRefresh 獨立進場
本區塊的進場路徑
不需要 Publisher 把我方 AdTag 整合進 GAM line item。

只要裝 RF SDK + 設定白名單可刷版位 → 每一輪刷新就載入我方 AdTag → 重跑 Prebid + GAM 仲裁 → 捕捉增量曝光與收益。

整合深度：只需裝 SDK + 設白名單，無需動 GAM 結構。
AdRefresh 路徑 低門檻 快速上線
Publisher 不用大動 GAM 整合，光接 AdRefresh 就能立刻多賺增量曝光
路徑 A（LI 整合）讓我方捕捉「Publisher 直售之後的首次剩餘流量」；
路徑 B（AdRefresh）讓我方在每一次刷新都捕捉「首次填充後的增量曝光」——無需 Publisher 動 GAM，低門檻、快上線。

機制已於合作媒體落地驗證，兩條路徑可並行，效益互補不衝突。
合規設計摘要
Refresh Declaration
在 GAM 創意層聲明；AdRefresh bundle 已處理 Google refresh policy 要求
間隔 ≥30s + maxRefreshes
符合 Google refresh 間隔政策；上限可配置，防止過度刷新
Own-slot（不碰 Publisher）
刷新只發生在我方 iframe 內，Publisher 頁面框架完全不受影響