轉換歸因評估可能涉及多個當事人,包括發布商、廣告主、放送廣告技術 (放送廣告的實體)、評估供應商等。本文將說明常見的轉換評估情境,但一般來說,任何想透過 Attribution Reporting API (ARA) 接收歸因報表的當事人,都必須確保遵循本文所述的整合步驟。
舉例來說,發布商通常會有一或多個廣告技術負責放送廣告,包括負責提供廣告素材標記的各方、負責提供廣告素材曝光或追蹤像素的各方,以及負責提供發布商網頁廣告版位 SDK 或代碼的各方。這些廣告技術可能想接收或不想接收 ARA 的歸因報表,但可確保下游廣告技術能收到歸因報表。
此外,廣告主也可能使用第三方轉換評估服務供應商進行跨聯播網歸因,以及其他報表功能。廣告主會使用這項資料,瞭解多個不重複的發布商和管道的廣告投資報酬率,因此 DSP 或廣告伺服器必須瞭解如何啟用 Attribution Reporting API,才能支援這些用途。如果廣告主想透過第三方執行這項作業,可使用第三方成效評估服務供應商,或設定內部伺服器以登錄及接收來自 API 的報表。
Attribution Reporting API 可讓多項廣告技術為同一曝光或轉換登錄歸因來源和觸發條件,並接收來自 API 的個別報表。舉例來說,需求端平台可以從 Attribution Reporting API 接收自己的歸因報表,並允許廣告主的第三方成效評估服務供應商取得個別報表。廣告技術必須同時登錄歸因來源和觸發事件,才能接收來自 API 的報表,而系統則會依據廣告技術使用該 API 個別登錄的歸因來源和觸發事件完成歸因作業。
常見的轉換評估情境
在本節中,我們將探討兩種常見的轉換評估情境。
情境 1:放送廣告技術和第三方評估供應商都需要接收來自 Attribution Reporting API 的報表
廣告主希望使用第三方評估服務供應商,將廣告空間的轉換歸因於廣告,而代管廣告素材的廣告技術也希望將廣告空間的轉換歸因於廣告。DSP 或廣告主廣告伺服器 (第三方廣告伺服器 - 3PAS) 通常會提供廣告素材的標記、自行執行歸因報表,並與整合第三方評估或分析供應商的廣告主合作。
在這種情況下,放送廣告技術也是負責在目前設定中觸發點擊和曝光事件的廠商。放送廣告技術應在適當位置設定新的 attributionsrc,並確認重新導向設定正確。此外,放送廣告的廣告技術和第三方評估服務供應商都應確認已註冊,且伺服器已準備好接收及回應 Attribution Reporting API 要求。
一般廣告活動設定可能如下:
廣告主廣告伺服器 (3PAS) 會將廣告素材的標記提供給 DSP,其中包含第三方評估供應商的曝光和點擊追蹤像素。廣告伺服器應確保
attributionsrc包含在廣告素材標記中。需求端平台提供新增額外評估曝光和點擊追蹤像素的功能,並應確保最終廣告素材標記中包含
attributionsrc,以便出價。
情境 2:只有第三方評估服務供應商需要接收來自 Attribution Reporting API 的報表
廣告主希望使用第三方評估供應商,將廣告空間上的轉換歸因,但代管廣告素材的廣告技術沒有歸因評估需求。如果發布商、SSP 或發布商廣告伺服器代管廣告素材,且不打算自行使用 Attribution Reporting,但想為 DSP 合作夥伴或評估標記公司 (例如第三方廣告伺服器、評估或分析供應商) 啟用 Attribution Reporting API,通常就會採用這種做法。
在這種情況下,負責在目前設定中觸發點擊和曝光事件的廠商,需要在廣告素材中加入新的 attributionsrc 屬性,並確認重新導向功能正常運作。這高度取決於各發布商的整合方式,但就點擊事件而言,可能是 SSP、放送廣告技術或發布商本身。如果是曝光事件,通常是第三方評估服務供應商。
在情境 1 的典型廣告活動設定範例中,發布商廣告伺服器、SSP 或發布商本身可能只需要驗證需求端平台提供的 attributionsrc 屬性是否出現在發布商網頁上。
實作詳情
下表大致說明 Attribution Reporting API 的導入步驟:
| 步驟 | 工作責任 | 範例 |
|---|---|---|
| 步驟 1:為現有廣告素材和評估程式碼啟用歸因來源 | 負責觸發曝光事件或處理點擊事件的實體會新增 attributionsrc 屬性。 |
如果是點擊事件,通常是放送廣告素材的買家 (DSP/廣告主廣告伺服器) 會新增屬性。
如果是曝光事件,則由需求端平台 (DSP)、供應端平台 (SSP)、發布商、廣告伺服器或評估服務供應商新增屬性,具體做法取決於發布商的設定。 如果是使用 VAST 格式的影片廣告,發布商和影片 SDK 會新增屬性。 |
| 步驟 2:為第三方來源啟用 Attribution Reporting | 如果使用現有的重新導向路徑和 302 重新導向,這項功能會立即生效。 如果無法使用 302 重新導向,可以使用 |
一般來說,只要將 attributionsrc 屬性加到廣告素材中,第三方重新導向就會收到 Attribution Reporting API 呼叫。 |
| 步驟 3:設定 Attribution Reporting API 要求的相關回應 | 如要接收來自 Attribution Reporting API 的報表, | 廣告主使用的 DSP 和第三方評估服務供應商 |
請注意,每個步驟的具體內容取決於廣告素材在發布商網頁上的顯示和放送方式,以及哪些廣告技術實體會收到 Attribution Reporting API 傳送的報表。
步驟 1:為現有廣告素材和評估程式碼啟用歸因來源
第一步是啟用歸因來源。
attributionsrc 屬性的運作方式
新的 attributionsrc 屬性會指定要將 Attribution Reporting API 要求傳送至何處。負責觸發曝光和點擊事件的實體必須使用 attributionsrc 屬性更新素材資源。attributionsrc 應加入現有的點擊和曝光事件,且可為空白或非空白。
如要使用重新導向的點擊事件,請將 attributionsrc 屬性新增至導覽。導覽後的任何 302 重新導向都不需要新增 attributionsrc 屬性,只要初始導覽已新增 attributionsrc,就會符合 ARA 資格。
如果 attributionsrc 為空白,系統會將 ARA 要求傳送至錨點標記 (到達網址) 的 href 屬性中定義的網址。定義 attributionsrc 屬性後,系統會將 ARA 要求傳送至 attributionsrc 屬性中定義的網址。到達網址也符合登錄來源的資格。
一般來說,如果代管到達網址的伺服器可以接收及回應 Attribution Reporting API 要求,請使用空白的 attributionsrc 屬性。如要將 Attribution Reporting API 要求傳送至其他伺服器,請自行定義 attributionsrc 網址。
空白 attributionsrc 屬性的範例:
| 現有設定 | 整合 ARA |
|---|---|
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
|
如果 attributionsrc 屬性為空白,Attribution Reporting API 要求會傳送至錨點標記的 href 屬性所定義的網址。
attributionsrc 屬性不為空的範例:
| 現有設定 | 整合 ARA |
|---|---|
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc="[ATTRIBUTION_SRC_URL]">...</a>
|
如果 attributionsrc 不為空白,Attribution Reporting API 要求會傳送至 attributionsrc 標記定義的網址。到達網址也符合登錄來源的資格。
為點擊和曝光事件新增 attributionsrc
- 點擊事件:
- 負責新增
attributionsrc的實體通常是放送廣告技術。 - 含有點擊事件的錨點標記應新增
attributionsrc屬性。 - 使用
window.open的點擊應使用window.open呼叫的windowFeatures引數,指定歸因來源。
- 負責新增
- 曝光事件:
- 負責新增
attributionsrc的實體通常是放送廣告技術和評估供應商。 - 從
<img>代碼或<script>代碼觸發的曝光事件應包含attributionsrc屬性。 - 使用 Fetch API 的曝光事件應在傳遞至 Fetch API 呼叫的 options 引數中,加入
attributionReporting物件。
- 負責新增
如需點擊和曝光事件的必要修改摘要,請參閱下表:
| 事件 | 標記 | 現有設定 | 整合 ARA 後 |
|---|---|---|---|
| 點擊 | HTML |
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
|
| JavaScript | window.open("[CLICKTHROUGH_URL]", "_blank"); |
window.open("[CLICKTHROUGH_URL]", "_blank", "attributionsrc"); |
|
| 曝光 | HTML <img> 標記 |
<img src="[IMPRESSION_URL]">
|
<img src="[IMPRESSION_URL]" attributionsrc>
|
HTML <script> 標記 |
<script src="[IMPRESSION_URL]"></script>
|
<script src="[IMPRESSION_URL]" attributionsrc></script>
|
|
| JavaScript |
const options = {...} |
const options = { |
在 Protected Audience 競價中啟用歸因來源登錄
如要在 Protected Audience 競價中評估轉換,請使用 registerAdBeacon/registerAdMacro 和 setReportEventDataForAutomaticBeacons/reportEvent 啟用登錄歸因來源,而非使用 attributionsrc。
如要回報 Protected Audience 信號,報表工作單元內可使用 registerAdBeacon 函式,買家得標回報工作單元內則可使用 registerAdMacro 函式。然後,使用 Fenced Frame Ads Reporting API 的 reportEvent 和 setReportEventDataForAutomaticBeacons 函式,將廣告影格內的事件資料新增至已註冊的信標和巨集。這樣一來,Protected Audience 報表工作單的信號和廣告素材影格事件酬載就能相互關聯。
當影格的 reportEvent 呼叫觸發信號和巨集,或瀏覽器觸發自動信號時,系統會在要求中加入 Attribution-Reporting-Eligible HTTP 標頭。您可以使用信號的回應註冊歸因來源。信號要求可能會重新導向,以允許第三方評估。
如要深入瞭解,請參閱 Fenced Frame Ad Reporting API 說明文件中的「支援 Attribution Reporting」一節。
啟用 VAST 格式的歸因報表
VAST 是放送及評估影片廣告空間的常見格式,該標準中定義的許多事件都應視為潛在來源事件,可透過 Attribution Reporting API 登錄。VAST 歸因報表支援附錄詳細說明瞭這點,但簡單來說,所有 <Tracking>、<Impression>、<*ClickThrough> 和 <*ClickTracking> 事件都是潛在的歸因來源事件。所有 VAST 實作項目都應為這些事件提供註冊資格涵蓋範圍。
VAST 附錄會為這些元素定義新屬性,以便專門設定用於歸因註冊的次要網址。如果事件包含 attributiontype="DOUBLE_PING" 和 attributionsrc="[URL]",則在啟用 Attribution Reporting API 時,觸發該事件的程式碼應使用 [URL] 做為 attributionsrc 屬性的值。VAST 附錄包含各情境的範例。
為盡量涵蓋所有情況,VAST 實作項目應預設在觸發事件 Ping 時,讓所有列出的事件都符合註冊資格。舉例來說,在觸發 <Impression> 事件網址時,應在用於傳送要求的 <img> 元素 (或擷取呼叫中的對等項目) 上使用 (空白) attributionsrc 屬性,一律允許接收方使用 Attribution Reporting API 登錄該事件。
步驟 2:為第三方來源啟用 Attribution Reporting
如要允許第三方使用 Attribution Reporting API,您可以運用現有的重新導向,或在 attributionsrc 屬性中新增第三方清單。在大多數情況下,每個廣告技術都有自己的獨立曝光追蹤器,因此重新導向與點擊追蹤器更相關。
處理現有重新導向鏈結中的第三方來源
在一般的廣告點擊中,系統可能會在導向最終到達網頁的過程中,進行一連串的302重新導向,因此可能出現許多點擊追蹤程式。如果原始點擊目標已使用 attributionsrc 註解,或已在 Protected Audience API 中使用 registerAdBeacon/registerAdMacro 登錄,則重新導向鏈結中的每個要求都符合透過 Attribution Reporting API 登錄的資格。重新導向鏈中的廣告技術也必須註冊。
請注意,系統不會在重新導向時傳送初始要求的主體。如果是目標對象受保護競價,如果 eventData 傳遞至 reportEvent,且 setReportEventDataForAutomaticBeacons 需要做為重新導向的一部分,則必須明確傳遞為重新導向網址的一部分。
在下列範例中,我們將使用廣告放送技術 (serving-adtech.example) 和第三方成效評估服務供應商 (3p-measurement.example) 做為兩個不同的實體,這兩個實體會產生及接收歸因報表。在這個範例中,放送廣告的廣告技術可以是 DSP,在發布商網站上算繪廣告素材,並擁有自己的報表產品。第三方評估服務供應商可以是廣告主用於轉換報表的實體。
在註冊來源時,系統會執行下列步驟:
- 在廣告素材中設定
attributionsrc屬性。使用者造訪發布商網頁,瀏覽器會將請求傳送至serving-adtech.example.serving-adtech.example serving-adtech.example會以Attribution-Reporting-Register-Source標頭和Location標頭回應。serving-adtech.example會使用Attribution-Reporting-Register-Source標頭,回應要登錄的來源相關中繼資料。serving-adtech.example會使用Location標頭,加入重新導向至3p-measurement.example的連結。請注意,現有的點擊追蹤流程可能已使用Location標頭,支援302重新導向至第三方。
- 瀏覽器會收到
serving-adtech.example的回應,並剖析Attribution-Reporting-Register-Source標頭。瀏覽器會使用serving-adtech.example做為報表來源,儲存來源事件。 - 由於這項要求是重新導向,瀏覽器也會向
3p-measurement.example發出新要求。 3p-measurement.example會傳回包含Attribution-Reporting-Register-Source標頭的回應。- 瀏覽器會從
3p-measurement.example收到這項回應,並讀取Attribution-Reporting-Register-Source。瀏覽器會使用3p-measurement.example做為報表來源,儲存來源事件。
針對不在重新導向鏈結中的第三方來源使用 attributionsrc
如果多個檢舉者來源想在導覽事件中登錄來源,但因任何原因無法顯示在重新導向鏈中,您可以在 attributionsrc 中將多個網站列為歸因來源,做為替代解決方案。
| 現有設定 | 已修改 ARA |
|---|---|
<a href="[CLICKTHROUGH_URL]">...</a>
|
<a href="[CLICKTHROUGH_URL]" attributionsrc="[REPORTING_URL_1] [REPORTING_URL_2]">...</a>
|
在本例中,符合 Attribution Reporting API 資格的要求會傳送至 REPORTING_URL_1 和 REPORTING_URL_2。傳送至到達網址的導覽要求也符合登錄歸因來源的資格。
步驟 3:設定 Attribution Reporting API 要求的相關回應
針對收到 Attribution Reporting API 要求的來源,請確認伺服器會傳回適當的 Attribution-Reporting-Register-Source 標頭。請參閱「註冊來源」指南和說明,瞭解如何建構回應。
登錄多個觸發條件
您可以在轉換端新增多個像素元素 (每個觸發條件各一個),藉此登錄多個歸因觸發條件。attributionsrc 元素為觸發事件登錄的選用元素。
您也可以使用重新導向要求,或在 attributionsrc 元素中列出多個網址,從單一像素元素登錄多個觸發條件,方法與登錄來源相同。系統會比對由相同來源產生的來源事件和觸發事件。