轉換歸因評估可能涉及多個方,包括發布商、廣告客戶、廣告放送技術 (放送廣告的實體)、評估服務供應商等。本文件說明常見的轉換評估情境,但一般而言,凡是想收到 Attribution Reporting API (ARA) 歸因報表的第三方,都必須確保遵循本文所述的整合步驟。
舉例來說,發布商常常會有一或多家負責放送廣告的廣告技術,可能包括負責為廣告素材提供標記的一方、在廣告素材中提供曝光或追蹤像素的一方,以及為發布商頁面上廣告版位提供 SDK 或代碼的一方。這些廣告技術不一定能接收 ARA 的歸因報表,但這些廣告技術旨在確保下游廣告技術能接收歸因報表。
此外,廣告客戶也可能會透過第三方轉換評估服務供應商進行跨聯播網歸因,以及其他報表功能。廣告主會利用這些資料來瞭解多個不重複發布商和管道的廣告投資報酬率,因此需求端平台或廣告伺服器必須瞭解如何啟用 Attribution Reporting API,才能支援這類使用情境。想要使用第三方的廣告客戶則可繼續使用第三方評估服務供應商,或設定內部伺服器來登錄及接收來自 API 的報表。
Attribution Reporting API 可讓多項廣告技術登錄同一曝光或轉換的歸因來源和觸發條件,並透過 API 個別接收報表。舉例來說,需求端平台可以從 Attribution Reporting API 接收自己的歸因報表,並允許為廣告客戶的第三方評估服務供應商個別提供報表。廣告技術必須同時登錄歸因來源和觸發條件,才能接收來自 API 的報表,而廣告技術會使用該 API 個別登錄的歸因來源和觸發條件。
常見的轉換評估情境
在本節中,我們將探討兩種轉換評估的常見情況。
情境 1:廣告放送技術和第三方評估服務供應商都需要接收 Attribution Reporting API 的報表
廣告客戶想透過第三方評估服務供應商將廣告空間轉換歸因,而代管廣告素材的廣告技術要歸因該廣告空間的轉換。對於提供廣告素材標記、執行歸屬報表,以及與第三方評估或分析供應商整合的廣告客戶,通常會出現這類需求端平台或廣告客戶廣告伺服器 (第三方廣告伺服器 - 3PAS)。
在這種情況下,廣告放送技術也是在目前設定中觸發點擊和曝光事件的一方。廣告放送技術應在適當的位置設定新的 attributionsrc
,並確認重新導向設定正確。此外,廣告放送技術和第三方評估服務供應商都必須確認已註冊,且他們的伺服器已準備好接收及回應 Attribution Reporting API 要求。
典型的廣告活動設定看起來會像這樣:
廣告客戶廣告伺服器 (3PAS) 將廣告素材標記提供給 DSP,其中包括第三方評估服務供應商的曝光和點擊追蹤像素。廣告伺服器應確保廣告素材標記包含
attributionsrc
。需求端平台可讓您新增額外的評估曝光和點擊追蹤像素,並確保
attributionsrc
包含在其出價的最終廣告素材標記中。
情境 2:只有第三方評估服務供應商需要接收 Attribution Reporting API 的報表
廣告客戶想透過第三方評估服務供應商將廣告空間轉換歸因,但代管廣告素材的廣告技術沒有任何歸因評估要求。對於代管廣告素材的發布商、賣方平台或發布商廣告伺服器來說,如果他們不打算自行使用歸因報表,但想為自己的需求端平台合作夥伴或評估標記公司 (例如第三方廣告伺服器、評估或分析服務供應商) 啟用 Attribution Reporting API,就常會發生這種情況。
在此情況下,負責在目前設定中觸發點擊和曝光事件的一方,必須在廣告素材中新增 attributionsrc
屬性,並確保重新導向正常運作。這與每個發布商的整合方式密切相關,但對於點擊事件,可能是賣方平台、廣告放送技術或發布商本身。對曝光事件而言,這通常會是第三方評估服務供應商。
在情境 1 的一般廣告活動設定範例中,發布商廣告伺服器、賣方平台或發布商本身可能只需要確保需求端平台提供的 attributionsrc
屬性會在發布商頁面上顯示。
實作詳情
下表概略說明 Attribution Reporting API 的導入步驟:
操作步驟 | 工作責任 | 示例 |
---|---|---|
步驟 1:為現有廣告素材和評估程式碼啟用歸因來源 | 負責觸發曝光事件或處理點擊事件的實體,會加入 attributionsrc 屬性。 |
如果是點擊事件,顯示廣告素材的買方 (DSP/廣告客戶廣告伺服器) 通常會新增屬性。
如果是曝光事件、需求端平台 (DSP)、供應端平台 (SSP)、發布商、廣告伺服器或評估服務供應商,則會根據發布商的設定新增屬性。 如果是使用 VAST 格式的影片廣告,發布商和影片 SDK 會加入這個屬性。 |
步驟 2:啟用第三方來源的歸因報表 | 只要使用現有的重新導向路徑,並搭配 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 擷取 API 的曝光事件應包含
attributionReporting
選項選項選項引數 (傳遞至擷取 API 呼叫) 中。
- 負責新增
請參閱下表,瞭解點擊與曝光事件的修改內容摘要:
活動 | 標記 | 現有設定 | 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 = {...} window.fetch("[IMPRESSION_URL]", options);
|
const options = { attributionReporting: { eventSourceEligible: true, triggerEligible: false, }, // ... }
|
在 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 說明中的支援歸因報表一節。
啟用 VAST 格式的歸因報表
VAST 是放送及評估影片廣告空間的常用格式,在該標準中定義的事件中,有許多應視為可透過 Attribution Reporting API 登錄的潛在來源事件。歸因報表支援的 VAST 附加條款中有詳細說明,但簡單來說,所有 <Tracking>
、<Impression>
、<*ClickThrough>
和 <*ClickTracking>
事件都是可能的歸因來源事件。所有 VAST 導入作業都必須提供這些事件的註冊資格。
VAST 附錄會為這些元素定義新屬性,以便設定專門用於登錄歸因的次要網址。如果事件包含 attributiontype="DOUBLE_PING"
和 attributionsrc="[URL]"
,在啟用 Attribution Reporting API 時,觸發該事件的程式碼應使用 [URL]
做為 attributionsrc
屬性的值。VAST 附錄包含各種情境的範例。
為確保盡可能擴大涵蓋範圍,在觸發事件連線偵測時,VAST 導入作業應讓列出的所有事件都預設為符合註冊資格。舉例來說,觸發 <Impression>
事件網址時,應在用於傳送要求的 <img>
元素上使用 attributionsrc
屬性 (空白) 屬性 (或擷取呼叫中的對等項目),一律允許接收方利用 Attribution Reporting API 登錄該事件。
步驟 2:啟用第三方來源的歸因報表
如要允許第三方使用 Attribution Reporting API,您可以使用現有的重新導向,或是在 attributionsrc
屬性中加入第三方清單。在大多數情況下,每個廣告技術都有專屬的曝光追蹤程式,因此重新導向功能與點擊追蹤程式更為相關。
處理現有重新導向鏈結中的第三方來源
在一般廣告點閱中,許多點擊追蹤程式可能會顯示為 302
重新導向鏈結,這是使用者前往最終到達網頁的一環。如果原始點擊目標已加註 attributionsrc
,或者在 Protected Audience API 中的 registerAdBeacon/registerAdMacro
註冊,重新導向鏈中的每個要求都能透過 Attribution Reporting API 登錄。此外,重新導向鏈結中的廣告技術也必須註冊。
請注意,重新導向時不會傳送初始要求的內文。如果是 Protected Audience 競價,如果傳遞至 reportEvent
和 setReportEventDataForAutomaticBeacons
的 eventData
需要做為重新導向的一部分,則必須將其明確包含在重新導向網址中。
在以下範例中,我們將使用廣告放送技術 (serving-adtech.example
) 和第三方評估服務供應商 (3p-measurement.example
),做為兩個希望產生及接收歸因報表的不同實體。這個範例中的廣告放送技術是一個需求端平台,可在發布商網站顯示廣告素材,並擁有專屬的報表產品。第三方評估服務供應商可以是廣告客戶用來製作轉換報表的實體。
在來源登錄時,系統會採取下列步驟:
serving-adtech.example
會設定廣告素材中的attributionsrc
屬性。使用者造訪發布商網頁,瀏覽器就會向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
元素中列出多個網址,做法和登錄來源時相同,可從單一像素元素登錄多個觸發事件。系統會比對相同來源產生的來源事件和觸發事件。