本白皮書說明 Google Ad Manager 廣告選擇程序的工具及運作方式，以及從候選委刊項中選出廣告素材的方式。這份文件僅供網路管理員、廣告投放專員及銷售專員使用，並假定讀者對 Ad Manager 系統和廣告放送概念已有一般程度的瞭解。
本頁內容：
內部委刊項和競價
注意事項和定義
- 本文中的 HTTPS 是指廣告放送時使用的通訊協定。為了保護使用者隱私權，Ad Manager 對「一律使用 HTTPS」模式提供完整支援。
- 如果您使用 GPT 的單一請求架構 (SRA)，系統會使用單一 HTTPS 要求，請求同個網頁上的所有廣告版位。
- 如果網頁有多個廣告版位，請根據版位應填入的順序在標頭中宣告版位定義。版位順序可協助 Ad Manager 選擇廣告並影響放送行為 (如路障型廣告和廣告素材輪播)，本文稍後將會說明。進一步瞭解版位定義和順序。
- 本文內容不包括廣告代碼語法；如需相關資訊，請參閱這篇文章，瞭解如何產生 Ad Manager 廣告代碼。
- 需求端平台 (DSP) 的詳細導入方式不在本文討論範圍內。
廣告選擇程序總覽
Ad Manager 廣告選擇程序的設計宗旨是在合適的時間，向合適的對象放送適當的廣告。Ad Manager 的廣告選擇程序如下：使用者的網路瀏覽器載入網站的 Ad Manager 廣告代碼，或行動裝置載入應用程式的 Ad Manager 廣告程式碼，接著觸發廣告請求。這個請求會將資訊傳遞至廣告伺服器。
- 廣告伺服器將所有與指定條件相符的委刊項列成清單。
- Ad Manager 會使用動態分配，檢查是否能在不影響保證委刊項放送目標或放送速度的前提下，放送 Ad Exchange、AdSense、公開出價，或剩餘委刊項。這樣一來，聯播網的整體收益將獲得提升，同時也不會增加放送次數不足的風險。
- 廣告伺服器從候選委刊項或即時出價需求中，選出最適合的廣告素材。
- 廣告伺服器向使用者放送廣告素材。
廣告選擇程序
後續章節會進一步說明這個程序中的每個階段。
1. 廣告請求將資訊傳遞給廣告伺服器
使用者網路瀏覽器或行動裝置所產生的廣告資源 (例如 GPT 等網頁 JavaScript 程式庫，或者行動應用程式上的應用程式程式碼) 會觸發廣告請求，並向廣告伺服器送出 HTTP 要求。
與使用者和裝置相關的資訊會透過廣告請求傳遞給 Ad Manager，以便 Ad Manager 為使用者選出適合的廣告。廣告請求中會傳送五項重要資料：
- HTTP 標頭
- IP 位址
- 使用者 ID (不包含個人識別資訊)，可能是下列其中一種：
- 可重設的行動裝置廣告 ID (用於應用程式內廣告請求，例如 Android 的廣告 ID、iOS 的廣告識別碼，以及 Roku 等裝置的其他 ID)
- PPID (已在廣告請求中設定 PPID 的發布商)
- DoubleClick Cookie (電腦瀏覽器和行動瀏覽器)
- 發布商在 Ad Manager 廣告代碼中設定的自訂指定目標條件
- 同個網頁上多個廣告請求共用的「Correlator」值
下表詳述這些資料在廣告選擇程序中的用法。Ad Manager 廣告伺服器只會檢查前面提到的使用者 ID，前提是使用者允許，也就是未在瀏覽器設定或行動追蹤限制中停用或封鎖，廣告伺服器才會進行檢查。
資料類型摘要 (表格)| 資料 | 提供下列資訊： |
|---|---|
| HTTP 標頭 | 瀏覽器類型 |
| 作業系統 | |
| 日期和時間 | |
| IP 位址 | 地理位置 |
| 與網際網路相關的指定資訊，如使用者網域 | |
| 使用者 ID | 展示頻率上限 |
| 廣告素材輪播 | |
| 目標對象名單效期 | |
| Ad Manager 廣告代碼 | 廣告單元及大小 |
| 廣告單元可接受的廣告素材類型 | |
| 自訂指定目標參數 (鍵/值) | |
| Correlator 值 | 哪些廣告請求屬於相同的網頁檢視 (用於路障型廣告等進階放送功能) |
2. 建立相符委刊項和收益群組的清單
廣告伺服器收集到廣告請求的相關資訊後會產生一份清單，列出所有符合部分指定條件的委刊項和收益群組。
舉例來說，如果請求是來自一位使用 Linux 作業系統的台北男性使用者：
- 清單會列出指定「台北男性」的委刊項或收益群組。
- 委刊項或收益群組指定的對象是使用 Windows 作業系統的「台北男性」，就不會列入清單。
- 清單不會列出指定「台中男性」的委刊項或收益群組。
廣告伺服器會將指定廣告單元層級到聯播網層級之間，某個廣告空間的所有委刊項/收益群組都納入考量。這樣一來，您就能輕鬆建立全站隨機放送廣告或全聯播網隨機放送廣告，而不必明確指定樹狀結構中的每一則廣告單元。舉例來說，指定「體育」或「棒球」的全聯播網隨機放送委刊項，放送到的代碼可能含有名為「體育」的第一層廣告單元，以及名為「棒球」的第二層廣告單元。
3. 選出最適合的委刊項
找出條件相符的委刊項後，廣告伺服器會移除所有不符合放送資格的委刊項。可能影響放送資格的因素包括：
- 展示頻率上限
- 時段
- 排除條件 (競爭限制和類似委刊項)
廣告伺服器也會利用廣告請求中傳遞的 Correlator 值，找出已獲選在相同網頁檢視中放送的其他廣告。伺服器先前在網頁上放送的廣告可能會在下列情況下，影響其他委刊項放送到相同網頁檢視的資格：
- 路障型廣告 (同時顯示兩個以上廣告素材) 或密集展示 (AMAP) (路障型廣告僅於 Google Ad Manager 360 中提供)。
- 廣告主排除條件 (避免兩家彼此競爭的廣告主出現在相同頁面)。
透過動態分配，Ad Manager 能夠在設有明確目標的委刊項放送過程中，以最有效的方式分配剩餘廣告空間 (包括 Ad Exchange、公開出價、中介服務等)，而且不會影響預訂目標。具體來說，使用動態分配時，只要能夠放送到符合資格的曝光，無論是包量委刊項或剩餘委刊項，Ad Manager 都會納入考量。接著，Ad Manager 會根據符合資格的剩餘委刊項千次曝光出價，或設有放送目標的委刊項機會成本計算結果 (兩者中較高者)，選出最適合的委刊項。
在動態分配流程中評估保證和剩餘委刊項時，Ad Manager 會考量下列事項：
- 剩餘委刊項是位於剩餘空間的委刊項，在特定競價中的優先級等於或低於以下優先級 (兩者中較高者)：
- 優先級 12
- Ad Exchange、AdSense 或價格優先委刊項
- 保證委刊項是不在剩餘空間內的委刊項。
4. 選出最適合的廣告素材
選出最合適的委刊項後，Ad Manager 廣告伺服器就會選擇最合適的廣告素材：
- 不符合廣告請求大小的廣告素材將被篩除。
- 伺服器只會考慮格式 (如圖片、影片等) 適用於這個版位的廣告素材類型。
- 如果委刊項中的某個廣告素材已經顯示在此網頁檢視中，就不會放送到網頁上的其他版位。如此可以預防「同時同頁放送」，亦即同一個廣告素材放送到同個網頁上的所有版位。
- 篩選結束時：
- 如果委刊項只有一個相符的廣告素材，系統就會放送該委刊項。
- 如果委刊項中沒有相符的廣告素材，廣告伺服器會針對下一個最佳委刊項執行此程序。
- 如果委刊項有超過一個相符的廣告素材，廣告素材輪播規則就會開始運作：
- 平均：平均輪播廣告素材。
- 最佳化：選擇歷來點閱率最高的廣告素材。
- 加權：隨機選擇廣告素材，但會根據每個廣告素材的指定相對權重 (例如 70/30) 做選擇。
- 依序：按您指定的順序輪播廣告素材，每個廣告素材加上 1 到 80 的編號。廣告素材依序輪播時，每次委刊項向使用者放送，使用者都會按您指定的順序看到廣告素材，即使跨越多個網頁檢視也一樣。最後一個廣告素材播完後，系統會再從第一個廣告素材依序放送。
5. 放送廣告素材
這是廣告選擇程序的最後一個步驟。到了這個階段，Ad Manager 已經為所有屬於 HTTP 要求的廣告版位選出要放送的廣告素材。Ad Manager 會記下獲選廣告的相關資訊，以供製作放送報表；接著建構包含廣告素材程式碼的 HTTP 回應，回應原始 HTTP 要求。
網站和行動網站的 GPT 廣告代碼程式庫，或是行動應用程式的廣告 SDK 會接收回應並加以處理。如果是 GPT SRA 請求，就會比對特定廣告素材與網頁上適合的廣告版位。廣告素材加入版位後，系統也會下載並顯示任何其他資源 (例如外部圖片或程式碼)。到了這一步，廣告就算放送完成。